The scope of projects that IT project managers undertake should never deviate very far from the established deadline set down in the WBS. Yet there are elements within an IT shop that unexpectedly surface, serving to slip the scope far from its original moorings.
IT shops run into interesting twists and nuances that will very definitely impact the project scope and that may be beyond ordinary scope assessment and planning. Let’s examine some things that you’d want to think about when evaluating the scope of your IT project.
The size of an IT shop has a very direct impact on a project’s scope. If you have a shop of only a handful of people, all of whom are constantly engaged on one project or another, then it’s understandable that the scope of new projects depends highly on people’s schedules. A major constraint is the limitation you have with human resources. Project priority comes into play in smaller shops as well. Suppose, for example, that all of your folks are working on a project when suddenly you’re presented with a new project that’s of much higher importance to the organization. What do you do—drop everything you’re working on and begin on the new project or wait until you finish the first? It’s a tough call to make—one that small shops are frequently faced with. If adequate assumption gathering hasn’t been built into the first project (i.e., “we assume that the project might be interrupted by more important work”) then you may be faced with a huge dilemma, one that impacts the scope, time, and cost (probably quality too, because it’s tough for people to come back from a newer project and begin working on the old one without getting their sea legs back).
More importantly, IT shops that aren’t heavily staffed might have a hard time simply maintaining the balance of the day’s work, let alone take on new projects. And yet, in the interest of making sure that you meet your customer’s needs (your end users are your customers, right?) you might be tempted to take on projects that you think you can effectively manage. In such situations, the server administrator also might be the one who manages the databases and so forth.
IT projects in minimally staffed environments such as the above often suffer from not having well-formed requirements and a well-developed WBS, never mind the rest of the support documentation.
For projects that have to be developed by folks in small or understaffed IT shops, it’ll be key that you concentrate on making sure that the requirements are fully understood, that the WBS is very succinctly spelled out, and that your plan project fits within the confines of the schedules that the IT shop workers follow. In other words, you can’t expect that a new Oracle database server project will be brought online in just a few days’ time by people who are busy running around with their hair on fire most of each working day. That is, unless you expect them to bring up the server during the night (which is precisely what some administrators do—they’re just too slammed during the day to finish projects).
Communication with your business customers in such situations is very important—you have to be sure that you communicate to stakeholders why the project can’t be completed in the blink of an eye. Customers might suggest that some of the work be outsourced in the interest of time. But this recommendation (i.e., to bring in a vendor or consultant to help) might be met with some disfavor by the IT folks. The reasons for this are myriad. If the idea of outsourcing is acceptable to all concerned you should be quite sensitive to the way that you present the idea.
Usually it’s easier to define the deliverables of an IT project with obvious requirement outcomes. For example, suppose that you’ve met with a business unit manager who wants a new software application written to meet a specific need. After some requirement-gathering efforts, you have a pretty firm idea of what the software’s supposed to do. In talking with the folks in your IT shop you determine that the majority of your servers are Windows Server 2003, that the database of choice is Microsoft SQL Server 2000, and that there is plenty of room and hardware beef on which to host your application. From there the deliverables are pretty straightforward—you just figure out how the program will be delivered to the user (thin-client? thick?), settle on a programming environment, and away you go.
But defining the deliverables when the outcome of the project is more esoteric can be challenging. For example, suppose that you have a project in which you’re going to replace your current help-desk software system with one that’s more robust. What are the deliverables? Well, they might include a new server or servers and certainly the new software. But other deliverables will also include conversion of the old help-desk database data to the new database, training the users how to use the new system, creating new custom reports that match reports you had in the old, and so forth.
It’s like skeet shooting: it’s easy to see that red clay disk when it’s flying across blue sky, much more difficult to spot it when it’s traversing the landscape. You have to think of all of the deliverables that a project is going to produce—some of which aren’t immediately obvious. As we mentioned earlier, for example, training stakeholders and creating support documentation are two of the deliverables you’re likely to overlook if you don’t really examine the complete output of your project.
IT shops exist to serve the needs of the business unit end users. To that extent, an IT shop doesn’t really have ownership in the organization’s business processes and instead must rely on the input and expertise of the business unit to make a successful project. In other words you serve the business unit but you’re not necessarily a part of it.
There are all sorts of things that fall out of this relationship that you might spot as adversely affecting the scope of your project. For one, consider the business unit director that loses interest in the project halfway through. Since the director is one of the project sponsors, how can you possibly proceed and satisfactorily complete the effort without her dedication?
Also, consider a business unit that’s too busy to lend you an SME to help make sure that the deliverables actually match the unit’s business needs. It’s very difficult to simply assume that you know what your business unit needs when you don’t have reliable input from those who actually do the day-to-day work. Many projects get done this way and they produce poor results.
What about the business unit that does all of its own research for a new COTS application, finds one that they think will work, then asks you at the last minute (almost as an afterthought) to implement the new program? The business unit stakeholders’ idea of the project’s scope might very well be a whole lot different than your own!
You might handle these elements by putting them in the assumptions section of your scope statement. For example, “It is assumed that marketing will lend the project team one full-time business representative for the first 30 percent of the project.”
Suppose that you are working on a new Internet-based e-commerce software application. One of the requirements of the application is that it must be guaranteed to be highly secure—that transactions taking place on the system are well-secured and not privy to hacking.
How on earth do you evaluate such a requirement in order to provide evidence that the system is safe? Furthermore, what happens when, well into the system’s creation, the operating system manufacturer reveals that there are known security gaps in the code and affected systems must be patched? How will this news affect the operation of the system you’ve just created? Will the patching in some way affect your system’s operation?
Like the items in the annual performance appraisal and report that your boss gives you every year, sometimes it’s tough to put metrics to a subjective outcome. But you should try to pinpoint tangible reasons for why you’re doing the project—what your customers hope to accomplish by creating the deliverables.
Perhaps the most devastating scope killers arise out of the belief that you’ve completely uncovered the business processes only to find that your business end users are keeping track of some elements in their office automation software or, worse, they don’t disclose all of their business processes because they either didn’t think of them at the time you interviewed them, or they deliberately withheld some elements.
The first of these problems is what we call sidebar systems, meaning that users keep track of some things by using a spreadsheet or “mini-database” program, and then use that information to work with the primary system. For example, suppose that you have an old mainframe-based program that’s been in use for 30 years. Its functionality isn’t up to par with what the users require (and hasn’t been for years), so sidebar systems have been developed to overcome the system’s shortfalls. At requirement-gathering, business-process-discovery time, users just don’t reveal that these sidebar systems are in use—they probably don’t even connect the dots—and as a result your system winds up missing some key functionality.
Alternately, users might not fully disclose all of the process elements involved in a business transaction for whatever reason. In some cases, a user might just be forgetful about all of the processes he or she goes through in order to successfully conclude a transaction. But sadly, in some instances, a user might be (subconsciously?) trying to sabotage the new effort. This sounds paranoid, but it actually happens. You can imagine the consequences when you get far down the implementation road only to discover that some pretty important process has been left out!
In projects that are smaller in scope, your relationship with a vendor or contractor may not be as important to them as ones with bigger budgets. While the vendor or consultant is certainly very anxious to assist you, they may have another project on the hook that has the ability to demand instantaneous use of their time, resulting in you being left high and dry waiting for them to return. This, of course, shoots your planned scope out into the stratosphere while you wait on the contractor to come back to finish something.
You’re the applications development manager for your company’s IT department. You’ve recently been presented with a request from one of your business units to automate a function of theirs that currently takes a lot of time and person-hours to accomplish.
You assign a systems analyst to the project. She begins the business analysis methodology by working with users to identify the business processes involved and trying to firmly nail down the requirements of the project. She comes back with her standard well-drafted documentation, including DFDs that show the logical flow of the current process.
Everything looks great and you begin to go forward with your project. Halfway into the development of the system code, after going back to the stakeholders for routine communications updates, you find that little elements here and there are missing—almost as though your systems analyst didn’t fully perform her usual thorough discovery.
Upon re-interviewing some of the people that she initially sat with, you find a variety of sidebar systems that they evidently didn’t bring up at the first interview. One man, for example, keeps a little Excel file listing of computations that he has done toward accomplishing the business function. These things are extremely valuable pieces of information that really should be included somehow in the new system. Another person keeps sticky notes on her desk blotter as she goes through the process. You realize that these step-monitoring activities actually are quite important for the new program and yet you had no knowledge of them when you began.
Now you must go back to the design drawing board and add in these fundamental processes.
Delivery of parts is another issue that can dramatically affect the scope of your project without you being able to adequately spot it at scope-development time. For example, we recently completed a large Storage Area Network/Network Attached Storage (SAN/NAS) project. A simple element such as the rails for a server rack held up completion of an important project phase for almost a month! The vendor sent the wrong rails (ordered through a third-party provider) and was very slow in correcting the order. Finally, just to get a set of rails installed we wound up borrowing a set of the correct rails from another IT unit just so we could bring closure to this phase of the project.
Suppose that you laid down your WBS tasks relying heavily on one of your more senior people. Further, suppose that the person moves on to greener pastures. What then? Do you have a less capable junior person to take his or her place? Recall that some IT teams aren’t very big. What if you don’t have anyone to take his or her place until someone’s hired? Voila! The scope juts out like a cowlick on a kindergartner!
Again, in your assumptions statement, you’d note that you assume a certain caliber of individuals will be available.
Perhaps you work for an organization that has several different IT shops that serve different business units. For example, maybe the manufacturing segment of your company is so big that it has its own IT arm. Ditto for the legal department. You handle the rest. Suppose that you have a project in which everyone in the company will use the primary deliverable—for example, an electronic timesheet system that’s going to be hosted through the company’s intranet. You need the assistance and buy in from the other IT shops so that you appropriately meet the needs of the end users who will use the system. The manufacturing arm, for instance, is the only unit that has 24/7/365 workers, so their timesheet posting will be quite different from others.
In such instances, project management takes on a political diplomat flavor in which you work hard to garner buy in and cooperation from entities that don’t necessarily have to play along (unless the CEO says “make go!”).
Understandably, in a situation such as this, the scope is very much shaped by the priorities that each IT shop has weighed against the importance of the project. You might get Joe the graphics designer from marketing for 15 percent of his time per week, for example.
Lots of different IT projects require that you go through some testing elements to verify that the deliverables meet the requirements. Software development, for example, requires that you perform extensive testing to make sure that you’re pushing out code that meets the user’s needs as stipulated in the project requirements documentation. There are three forms of testing to be concerned with:
Unit Testing — This test involves the technician performing tests on his or her modules or elements that are going to be included in the overall package of deliverables. For example, a server administrator might get done burning a server, then go through a litany of tests to make sure that it’s working as it’s supposed to. A programmer, after completing her module, might run through a variety of tests to validate that the module is performing as expected. When you think unit testing, think singular —that is, usually a single person testing a single element. While this isn’t a hard and fast rule, it gives you the flavor of what unit testing is all about.
Integration Testing — When you perform integration testing, you’re testing a bunch of elements that are combined together to form a whole. For example, perhaps you’ve got several servers that are now burned and that will work together in an array of load-balanced Web servers. Integration testing would test these servers as a whole, rather than in distinct units. A programming team might test several modules that, when combined together, form a complete program element. For example, one programmer may have coded the print module, another the calculational elements, another the reporting. When they’re combined, they should accurately calculate some figures, create a report, and print it out successfully. Integration testing would prove that this is so.
Life is tough for you. You’ve been forced to fly to Bordeaux to meet with Monsieur Fourche so that you can discuss the email server and intranet sites. You really needed to visit each site so that you could understand what the physical connectivity elements are like. For example, you need to get a picture of where the server could actually be placed. Additionally, you also need to understand what the telecommunications picture is like—what wide area network prices are for, say, a T1 circuit (called an “E1” in Europe), what the provision times are for such connectivity, and where the demarcation point will be at the Fourche site.
You have to do the same things for Senior Sanchez’ location and the Roo wines site.
On returning, you create a scope document containing the following elements:
Business Need The president of Chaptal Wines, Kim Cox, has requested that the three new offshore acquisitions be connected to share email and calendar information as well as vinovital information such as residual sugar (RS) and other viticultural data, vintage charts, wine blends, regulatory updates, and so forth. Two systems are required: an email system that connects all four sites together and a system that runs an intranet site.
Deliverables Description The deliverables will consist of the installation of a server or servers at each site. The servers will connect together via wide area networking technology. Email software will be installed on each server in such a way that all sites belong to a single email organization. Users will utilize conventional email software to keep their email and calendars online. Additionally, an intranet site will be created on a Chaptal winery server and key users in each of the offshore sites will be trained how to post important data to the intranet so that all employees have complete data at their fingertips.
Major Deliverables The deliverables include the following elements:
Success Criteria Your success criteria includes the following:
Server gear will be installed at each site, baselined, and certified 100 percent functional.
Connectivity between sites installed and baselined by a telecommunications company.
ISP for each site will be determined and contracted.
Routers installed and router tables built. Firewalls installed, configured, and baselined. Administrator will be able to ping each site server within the network and send a test email to each site server. Port sniff will show ports 20 and 21 (FTP), 25 (SMTP), 80 (HTTP), and 443 (HTTPS) open, all others closed.
Intranet site created and all initial elements requested by the business made operational.
Users will be trained and documentation provided and maintained.
Users in all sites will be able to send email to one another 100 percent of the time and access viti-vital information 100 percent of the time.
Assumptions You have the following assumptions:
No variance in the behavior of like hardware.
Telecommunications companies in each nation will have reasonable wide area network setup request procedures and installation timelines.
Average T1/E1 cost is assumed to be $350/month U.S. dollars.
Intranet development time is assumed to be 60 person days (30 working days, 2 persons)
All sites will provide reasonable access for installers and a secure, climate-controlled, power-conditioned room for the electronic gear.
Routers will use Open Shortest Path First (OSPF) routing protocol.
Contractual help will be used for configuration of the routers.
Constraints Your constraints for the email server and intranet sites are:
Availability of people at any given site to be able to help with setup due to problems with the winemaking efforts
Harvest and crush seasons
Work Breakdown Structure (WBS) Finally, this list represents your WBS:
1.0 Hardware procurement—Chaptal administrator
1.10 Purchase servers and network operating system (NOS) licenses
2.0 Wide area network telecommunications connection procurement—Chaptal administrator working with site business managers
2.10 Provision an E1 connection with French telco
2.20 Provision a T1 connection with So. Australian telco
2.30 Provision a T1 connection with Chile telco
2.40 Provision a T1 connection with California telco
3.0 Internetworking gear installation—installed by contractor
3.10 Contractor installs router and switches at French site, configures, baselines, and tests.
3.20 Contractor installs router and switches at So. Australian site, configures, baselines, and tests.
3.30 Contractor installs router and switches at Chile site, configures, baselines, and tests.
3.40 Contractor installs router and switches at California site, configures, baselines, and tests.
4.0 Server installation—installed by Chaptal administrator
4.10 Install server at French site. Baseline and test.
4.20 Install server at So. Australian site. Baseline and test.
4.30 Install server at Chile site. Baseline and test.
4.40 Install server at California site. Baseline and test.
5.0 Email software installation—installed by Chaptal administrator
5.10 Install email software on French server. Baseline and validate the software is working correctly.
5.20 Install email software on So. Australian server. Baseline and validate the software is working correctly.
5.30 Install email software on Chile server. Baseline and validate the software is working correctly.
5.40 Install email software on California server. Baseline and validate the software is working correctly.
6.0 Intranet development—contractor
6.10 Develop intranet pages
7.0 Training of users—Chaptal administrator
7.10 Train French users on the use of email.
7.20 Train French users on the use of intranet.
7.30 Train So. Australian users on the use of email.
7.40 Train So. Australian users on the use of intranet.
7.50 Train Chilean users on the use of email.
7.60 Train Chilean users on the use of intranet.
7.70 Train California users on the use of email.
7.80 Train California users on the use of intranet.
8.0 Unit, integration, and user acceptance testing
8.10 Unit testing
8.20 Integration testing
8.30 User Acceptance Testing (UAT)
We’ve also included part of what the tree structure diagram might look like for this case study as well. (See below.)
User Acceptance Testing (UAT) — The final element of testing happens when designated users are brought in to give the system a test drive. This is also probably the most revealing of all the testing phases you’ll go through because it points out how well the team has done its job, in terms of the way that the users interact with the system. Be prepared for brutally honest assessments of your product.
At any step in the testing, if things don’t work correctly the folks working on the problem must, of course, correct it. Significant testing errors will undoubtedly result in out-of-scope scenarios in which you’re burning time and money trying to solve a problem. This is why project managers really harp on the idea of pairing the correct person for a task—so that you’re sure the task gets done within the estimate that he or she provided.