Chapter 3-3:Summary
Summary
Scope planning uses the output of the initiation process, the project charter, to create the scope statement and the scope management plan. The project scope statement is the basis for many of the other planning processes. It is also the basis for setting the boundaries of the project with the client and stakeholders.
A scope statement includes project justification, project description, major deliverables, time and cost estimates, success criteria, assumptions, and constraints. The scope management plan documents how you will manage changes to the scope. The work breakdown structure (WBS) is created by taking the major deliverables from the scope statement and decomposing them into smaller, more manageable components. The breakdown continues through multiple levels until the components can be estimated and resourced. Each lower level of deliverables includes the components that produce the next highest level in the tree. The lowest level of decomposition is the work package. The WBS includes all of the work required to complete the project. Any deliverable not listed on the WBS is assumed to be excluded from the project. The WBS is one of the most critical outputs of planning. A WBS is the basis for time estimates, cost estimates, and resource assignments.
Certain elements in IT shops need to be taken into account when dealing with IT projects. The size of the IT shop very definitely affects the project’s time estimates, as do deliverables that may be challenging to define. Business clients may have some hidden processes —“sidebars” that they’ve not revealed when you’re busy trying to discover the processes. Success criteria can be especially tough to define in IT projects. A key project team member leaving can have a remarkable affect on the status of the project’s scope.
Chapter 3-2:Evaluating Your IT Project Scope
Evaluating Your IT Project Scope
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.
Size of the IT Shop
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).
| Note |
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. |
Definition of the Project Deliverables
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.
Working with Your Business Clients
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.”
Success Criteria Tough to Define
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.
Sidebar Systems and Undisclosed Process Elements
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!
“Mini-Project” Consultant/Vendor Relationships
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.
Senior Project Technician Quits or Leaves
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.
Project Goes across IT Shops
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.
Testing Elements Need Good Definition
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.
-
Email software will be installed on each site server, site connections with the other site servers validated, and languages installed 100 percent.
-
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:
-
Language barriers
-
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.
Chapter3-1:Scope Overview
Scope Overview
Imagine trying to work on a project without knowing your expectations, limitations, or the nature of what you’re producing. Would you even be able to begin a project without knowing these things? Luckily, in the project management business, there are rules and processes that help project managers define the limits of a project.
Scope puts boundaries around your project. Scope is like putting a fence around your property. The fence is a clear definition of where your property starts and where it ends. It is clear to anyone looking at your property what is included and what is excluded. Scope planning serves this same purpose for a project.
The project scope is the work that is done to deliver the product or service. Although this sounds simple and straightforward, a poorly defined scope can lead to missed deadlines, cost overruns, and unhappy clients. Good scope planning helps ensure that all of the work required to complete the project is agreed on and clearly documented.
Scope planning builds on and adds detail to the outputs you have created for the project charter. Scope planning is the starting point for defining the activities required to deliver the product requirements that were discussed in Chapter 2.
Depending on the detail of work completed for project initiation, scope planning may also include a more detailed analysis of the product, a cost/benefit analysis, and a look at alternative solutions. You may find that some of the work required for scope planning has already been completed during the initiation process. If that is the case, congratulations, as you are now ahead of the game.
The processes to define the scope planning elements are iterative, do not always occur in sequence, and can overlap. Regardless of the sequence, scope planning produces a scope statement, a scope management plan, and a work breakdown structure. Let’s take a look at what is required to complete each of these.
It’s important to understand that PMI’s A Guide to the PMBOK defines scope definition as the process of breaking down the major deliverables from a scope statement to create the WBS. For the purposes of the CompTIA objectives and exam, scope definition is used in a much broader sense to cover several scope planning elements including the scope statement and the scope management plan.
Project Scope Statement
Have you ever received a bid to do remodeling work on your house? A remodeling bid typically includes a description of the work to be done, a list of the major deliverables, estimates for time and cost, and any assumptions and constraints. A contractor tells you in writing that he will remodel your bathroom (description) by replacing the countertops, flooring, and tile (deliverables) in six weeks at a cost of $4,550. The bid assumes no change to the existing bathroom fixtures and a stated grade of countertops and tile. The start of the project will be constrained by whether the chosen tile is in stock or must be special ordered. The bid documents the agreement between the contractor and the homeowner as to the scope of the remodeling work.
A project scope statement serves a similar purpose to the remodel bid. A project scope statement documents the agreement between the project manager and the stakeholders as to what is included in the delivery of the project. It is the foundation for defining the activities required to complete the project, and it will be used as a baseline to manage change requests to the project. Any major deliverable, feature or function, that is not documented in the scope statement is considered a change. Typically, the scope statement includes a project justification, product description, major deliverables, success criteria, time and cost estimates, assumptions, and constraints.
Let’s take a closer look at what is included in each of these.
Project Justification
In the project justification portion of your scope statement, you must state the reason the project is being undertaken and document the business need that the project will address. You want to be clear what is driving the project request. Is the project creating a new product for external customers? Is the project developing a new system for an internal organization? Is this a legal mandate? The project justification identifies the source of the project request.
It is very important that any legal requirement behind the project request be documented in this section. This alerts anyone reading the scope statement that this is not an optional project.
Product Description
In your product description , briefly describe the features or function of the product. The description is what makes the product unique . (Remember that uniqueness of the product is part of the definition of a project.) You need to be as precise as you can using all of the data you have available. It may be appropriate to include not only the features or functions the product includes, but features or functions it does not include, if doing so will add clarity to your description. You can use your existing product description from the project charter and make changes or refinements based on any additional information you have obtained.
|
|
Tip |
By listing both included and excluded features, a product description narrows and clarifies the technical work that is required to produce this product—and keeps customers from coming back at product creation time to ask you for more for goodies to be added. |
Major Deliverables
In the major deliverables section of the scope statement, you will list the summary level achievements that make up the delivery of the product. It can be easy to get hung up on just the end result when you are listing the major deliverables. When you are putting together the deliverables section, make sure that you focus on the entire project. Your end result may be a new software application for the company’s sales agents, but there are other deliverables besides the application itself. Do not overlook key areas such as user documentation, user training, or help-desk training, to name a few. If you include at least one deliverable from each organization represented on the project team, it will show the big picture of what is involved in completing this project.
Success Criteria
Under success criteria in the scope statement you will define the measurable business results the product is expected to produce. This section is where you address items such as an increase to corporate revenue, a higher productivity rate, compliance with regulatory procedures, or reduced staffing needs. This section is very important as a tool for evaluating the project after it is complete. This is the section the stakeholders can reference to compare the actual business impacts of the project with the projected impacts. You want to define the success criteria so that each one can be measured. Criteria such as “become an industry leader” or “provide world class service” may sound good, but aren’t measurable. It is much better to state a sales figure, a revenue figure, or a customer waiting interval that can be measured and compared to that same data collected prior to the completion of the project. The idea behind success criteria is to supply metrics by which people can gauge whether or not the project was successful.
Completion Criteria
Completion criteria denotes what needs to be delivered. For example, you may stipulate in your scope documentation that the system will be fully functional at delivery time. Or, you may choose to stipulate that the project will be considered complete after a 3-month period of testing to make sure that all components are working correctly.
Time and Cost Estimates
In the time and cost estimate portion of the scope statement, you’ll provide an estimate of the time it will take to complete all of the work and the current high-level estimates for the cost of the project. These will be order of magnitude estimates based on actual duration and cost of similar projects or the judgment of someone familiar with the work involved in the project. These do not have to be precise estimates. A high-level estimate may also use ranges for either time or cost, in some cases including a worst case, best case, and most likely scenario.
|
|
Note |
Estimates made during scope planning may be stated in different ways depending on the estimating method used. An estimate made strictly from the actual time and cost of a similar project is stated: “Based on the results of Project XYZ, it is estimated that New Project MAL will take three months to complete and cost $350,000.” An estimate for the same project based on using ranges is stated: “New Project MAL will take between one and six months to complete at a cost of $100,000 to $500,000. The most likely scenario is four months at a cost of $400,000.” |
The time estimate for a new product created by market demand may also be defined based on the window of opportunity to market the product.
Target Completion
You may be asked to provide an estimated or target date for project completion. You really do not have enough data at this point to make a precise estimate. If you are forced to provide an estimated date in the scope statement, use either a month or a quarter, such as July 2004 or third quarter of 2004 instead of a specific date. When providing a target completion date, always include an assumed start date; otherwise, if the project starts later than anticipated, your sixmonth estimate may become three months.
Level of Confidence
Project estimates may include a caveat regarding the level of confidence the project manager has in the accuracy of the estimates. Estimates made during scope planning are based on very little detail, so don’t say you are 90 percent confident just because that is what your client or your sponsor wants to hear. Cost estimates made during scope planning are commonly as much as 75 percent off the actual budget figures. We will talk more about the different types of cost estimates and the typical range of accuracy for each estimate in Chapter 5, “Cost Planning.”
Assumptions
In the assumptions section of the scope statement, you’ll document the beliefs the team shares regarding the project. An assumption is an action, a condition, or event that is believed to be true. The problem with assumptions is that they may not be common among all project team members or stakeholders. You may think something is obvious, but if it is not written down, chances are other players will have a different opinion. Assumptions must be shared, agreed on, and documented.
A key area to review in defining assumptions with your team is to discuss and document both what is included and what is excluded from the project. This is a good way to further clarify and bound the project scope. If you are developing software for a new desktop support system, you may assume that the software will be deployed on the existing computers at the client site. The client may assume that new workstations are part of the project. You will need to document in the assumptions section that the software will be deployed on existing workstations.
Constraints
The last part of your scope statement is the constraints list. A constraint is a restriction that will impact the outcome of the project. There are two types of constraints. The first are the constraints that apply to all projects. Every project faces potential constraints in time, budget, scope, or quality. From the start of the project at least one of these areas is limited. If you are developing software to support a new product with a very short market window, time will be your big constraint. If you have a fixed budget, money will be your constraint. If both time and money are constrained, quality may suffer. A predefined budget or a mandated finish date needs to be factored in to any discussion of project scope. Scope will be impacted if both time and budget are constrained. As the project progresses and scope changes are requested, scope may become a constraint that drives changes to time, cost, or quality.
|
|
Note |
You may have heard the term triple constraint bandied about by project managers. Some project management books reference only three constraints: time, cost, and quality. Although you may still see the phrase triple constraint used in project management, be advised that most project managers think about project scope as a fourth constraint. |
The second type of constraint is that specific to a project. These constraints may involve the schedule or previous commitments of human resources you need or the availability of a test system.
The push and pull of project constraints is an issue the project manager must deal with throughout the project life cycle. If a constraint is placed on time, cost, scope, or quality during up-front planning, now is the time to communicate with your stakeholder team regarding the impact of constraints. The project manager needs to have an understanding as to how the client prioritizes these constraints and be able to communicate possible scenarios that might occur as the project moves forward. As an example, if cost is cast in concrete during the planning phase, the client may have to give up functionality and scale down the scope of the project once more definitive cost estimates have been made. As you can see, the scope statement contains a lot of important project information. Let’s take a look at a sample scope statement to help you put all the pieces together.
Real World Scenario—Sample Project Scope Statement
Imagine you are a project manager for a wireless telecommunications carrier in charge of a project for a new consumer product called Voice Activated Dialing (VAD). The product is critical to the corporate strategy to become one of the top three carriers in the markets where your company offers wireless service. Using your high-level requirements, the project charter, and input from various team members and stakeholders, you are ready to create your project scope statement.
Here is what your project scope statement might look like.
Project Justification: Market research and customer feedback indicate that a demand for Voice Activated Dialing (VAD) has increased 40 percent over the past three months. One of our competitors has already announced a launch date for this product, and two others are expected to follow within the next two months.
Our market share growth is expected to decline by 20 percent if we do not add VAD as part of our product mix.
Product Description: The product features included in Voice Activated Dialing are dialing by speaking a phone number or name into the phone and the ability to create address book entries from a website. Voice Activated Dialing does not include the ability to add/edit/delete address book entries over the phone or an interface to personal information managers.
· Product requirements defined
· System requirements defined
· System requirements developed
· Sales training developed
· Customer service training developed
· System enhancements implemented
· 3,000 Sales consultants trained
· 500 Customer service technicians trained
· Marketing communication plans executed in all markets
· VAD available in all markets
Success Criteria: The launch of VAD will generate $2.5 million in incremental annual revenue for the corporation.
The additional training required for sales consultants to be knowledgeable in offering the VAD product will increase the total sales consultant training package time by no more than two hours.
Time and Cost Estimates: VAD must be completed within six months for the company to be a viable player in this market.
The development and launch of VAD is estimated to cost $750,000. This includes all IT work, sales consultant training, customer brochures, and the marketing campaign. This is a high-level estimate based on the schedule and cost of a similar new product. Estimates will be refined as more detailed data is available.
Assumptions: IT has resources to implement system changes within the six-month time frame we need to start offering VAD.
Fifteen percent of our customers will add VAD to their current service option. Product will have a 15 percent take rate. VAD will be priced at $4.95/month.
Constraints: Billing releases are only done on a quarterly basis. The enhancement to bill for VAD must be scheduled within those parameters.
The window to obtain a share of the VAD market is six months.
As you can see, a lot of very important information is included in the project scope statement. From reading the VAD sample scope statement, you know the strategic value of the product, the features included and excluded in the product, the anticipated revenue the product will generate, and the aggressive schedule that must be met. This document can be used to give a clear and concise overview of the project to clients, team members, and other key stakeholders.
|
|
|
|
Review and Consensus
Once you have completed the scope statement, hold a review session with your entire project team to make sure that everyone is in agreement and there are no unresolved issues. Individual team members may have worked on specific sections of the scope statement, and a formal team review of the entire document will confirm that everyone is on the same page and prevent later misunderstandings of the project scope. Once the project team has resolved any outstanding issues, present the scope statement to all of the stakeholders and obtain approval from the project sponsor and the client. Other approvals may be required depending on the policies of your organization.
If any changes are made to the scope statement during the review with the client and the sponsor, you will need a follow-up meeting with the project team to cover the changes and discuss the impact on the project. One of your most important duties as project manager is to keep your team informed. We will talk a lot more about how to communicate with your project team in Chapter 6, “Additional Planning Processes.”
With our approved scope statement in hand, we are now ready to create a scope management plan.
Scope Management Plan
Now that you have an approved scope statement, the real work begins. You may have heard horror stories from other project managers. How do you keep this “thing” from growing out of control and choking any chance you may have to successfully complete the project? You need to master that dreaded demon that has plagued every project manager—scope creep. Scope creep is the term commonly used to describe all those minor changes or small additions that just seem to happen out of nowhere, until suddenly you are not managing the same project anymore. The solution, of course, is having a plan.
The scope management plan documents how you will manage changes to the scope. Project scope change is inevitable with the majority of projects. The key to dealing with scope change is how you handle it. In our experience, you save yourself a lot of pain during project execution if you take the time at the start of the project to define the basics of how the team will handle requests for any changes to the defined scope.
If the project team defines the basic scope management framework early in the planning process, each team member has a point of reference to communicate with clients and stakeholders who may come to them with something they forgot to mention when the scope statement was approved. Everyone involved in the project needs to understand that the rules set up at project implementation time need to be followed to make a request to change the scope of any project. Without a documented plan, you will soon find that interested parties are talking to team members and changes are happening. The team members will, understandably, want to try to accommodate the client’s needs. But without analysis of the impact these changes, adding 10 or 20 “minor” code changes may put your schedule or your budget in jeopardy.
Key items to consider when you are developing a scope management plan include:
Stability of the scope You probably have some indication at this point in the project as to how stable the scope is based on the work you have already done to define requirements, prepare and review the project charter, and define the scope statement. If you found major disagreement between stakeholders or gaps in the product description, you have a high probability for scope instability.
Impact of scope changes If you are constrained with a dictated finish date, any scope change can be critical. Adding to the scope of the project may also impact the budget. Do you have available resources to add to the project to complete the additional work? What is the process for securing additional funding?
Scope change process One of the primary reasons a project gets out of control is the lack of a documented process for scope changes. Clients and stakeholders will go directly to team members and before you know it, people will be working on deliverables that were never included in the scope statement.
Your scope change process needs at a minimum:
· A standard form to submit the request. Information required on a scope change request includes a description of the change, the reason for the change, and the originator of the request.
· An analysis of the impact of the request on the scope, budget, schedule, and quality of the project. The results of the analysis can be added to the form used to submit the request, so that all pertinent data in is one location.
· An approval process to accept or reject requests. This can range from ad hoc meetings called as scope changes are received to a formal change review board that meets on a regular basis.
· A communication plan to keep stakeholders informed of the status of requests.
· A method to incorporate approved changes into the project plan.
The implementation of your scope management plan will be discussed further in Chapter 9, “Project Control.”
|
|
Tip |
You can see why project managers are so interested in making sure they’ve established the scope of the project as best as they can before any work starts. Generally speaking, if you’ve done due diligence and tightly defined the scope of the project, with the exception of very minor changes, most new requests for changes on an IT project should be considered for “Version 2” of the product and included in a brand new project after the first one concludes. |
The Work Breakdown Structure (WBS)
The final element of scope planning is the work breakdown structure (WBS), where the project team starts decomposing the project deliverables. Decomposition is the process of breaking down the high-level deliverables into smaller, manageable components from which you can do time estimates, resource assignments, and cost estimates. The WBS is a deliverables-oriented hierarchy that defines all of the project work. Each level has more detail than the previous level.
A WBS is one of the fundamental building blocks of project planning. It will be used as an input to numerous other planning processes. It is the basis for estimating activity duration, assigning resources to activities, estimating work effort, and creating a budget. Because the WBS is a graphical representation, it can be a better vehicle for communicating the project scope than the charter or scope statement. It also contains more detail to further clarify the magnitude of the project deliverables.
The WBS acts to put boundaries around the project. Any work not defined in the WBS is considered outside the scope of the project. A WBS is a tool that can be used to keep customers, team members, and stakeholders focused on what is included in the project scope.
Like a blueprint used to build a building, the WBS is the document that will be used to build your project’s product.
It is important that the project team devote adequate time to develop the WBS. Development of the WBS should focus on all aspects of the project and all impacted areas of the business.
The team may go through several iterations to complete the WBS. Once the team concurs that the WBS is complete, review sessions are scheduled with the client, the sponsor, and key stakeholders to examine and approve the WBS.
Organizing the WBS
The quality of your WBS depends on having the right players involved in the development. Provide adequate notice when you schedule a WBS session. Involve as many project team members or functional representatives as possible. Project team members may not be named at this point, but you’ll probably have a good idea of the various groups or departments that will be involved based on the list of project objectives and deliverables. Work with functional managers or if necessary your sponsor to get representation from each group. A WBS is not something that should be developed in a vacuum. A WBS developed in isolation by the project manager frequently misses key components of the project. It is also more difficult to get buy in on something people had no input on.
A WBS is typically created using either a tree structure diagram or an outline form. A tree structure is the best method to use with a project team. The structure can be created on a white board or easel paper using sticky notes to write the tasks. This allows for tasks to be moved around as you work though the process. Figure 3.1 is an example of a template that can be used to create a WBS.
The space you reserve to conduct the WBS development needs to be adequate to allow all participants to see the work in progress. You need to encourage brainstorming. You can always remove or move activities as you work through the process or when you do subsequent reviews. Make sure that all of the participants have reviewed all previous documentation like the charter and scope statement. Have copies of these documents available as reference. They will be your starting point for creating the WBS as well as a reference if there are questions.
Decomposing Major Deliverables
Decomposition, the breaking down of the project deliverables into smaller components, can be a challenge. Let’s take a closer look at this tree diagram and how to work your way through the creation of a meaningful WBS.
The highest level of the WBS tree diagram encompasses the entire project. This level is referred to as level 1. The next level, level 2, relates to the high-level project deliverables defined in your scope statement. This level usually takes the form of listing the deliverables themselves. We have also seen this level show the phases of the project life cycle, the departments involved in the project, or a geographical focus. There is not one correct way to create a WBS, but the method you choose must be a logical way to break things down for your particular project.
Take for instance a simple home improvement project such as painting a porch. Figure 3.2 shows a few of the project deliverables for painting the porch. You’ll notice that level 1 is the porch-painting project itself, and level 2 demonstrates the deliverables needed to paint the porch.
Project Planning Using the Tree Structure
You can begin brainstorming a WBS by utilizing the tree diagram and a bunch of sticky notes on a white board.
Recently we had to move 2,000 users from various places around the city into one centralized location—a brand new 11-story building. Each of these groups of users had a different function in life, with different managers and move timelines. Imagine the complexity of making sure that you move all the users’ computers into this new building at different times and making sure that everything works. Now imagine that you’re trying to figure out all the obstacles and tasks even before the building is complete—you’re trying to get an advance feel for what’s involved.
Our project managers started this effort by getting various stakeholders into a room and then, as ideas were voiced, writing them down on sticky notes and pasting them to a white board. Another person began to arrange the notes into some sort of logical order. One stakeholder, for example, might cry out “Make sure all monitors work!” while another would say “We need our email to work when we come in on Monday.” Each of these sticky notes had something to do with powering up the machine and validating that it was connected to the network.
In time, as we fleshed out various components of the project, the white board looked just like a tree with yellow leaves all over it!
|
|
|
|
As Figure 3.2 illustrates, you should always work through level 2 before moving down to the next level of decomposition. This method will help you make sure you encompass all of the project goals.
Each subsequent level should be a breakdown of the previous level. In our porch-painting example, we have taken Prepare Porch and decomposed it as shown in Figure 3.3.
Figure 3.3: Decomposing a Major Deliverable
The process continues until a task does not need to be subdivided again. You need to get to a level of detail that generates manageable activities, but do not go down to a level of detail that you cannot track and control. PMI’s A Guide to the PMBOK refers to the lowest level of the WBS as a work package. The work package is just how far down you need to go to decompose the deliverables.
Guidelines for Creating a WBS
Getting started creating a WBS can sometimes seem overwhelming. we’ve found that a lot of people who struggle with this process are actually taking on more work than they should. Once you start breaking down your deliverables into activities, there is a temptation to immediately put the activities in order (called sequencing the activities) or estimate the length of an activity so you can just get people started on the work. Unfortunately, this type of behavior usually leads to a situation where key deliverables are missed or task sequences are incorrect because many tasks were not defined. The clock is ticking and people are working hard, but not necessarily on the right things, because time was not taken to create a thorough WBS. Although there is no one “right” way to complete a WBS, there are some tips on pitfalls you can avoid to help you be more successful. Here are some guidelines that we find helpful to review with project teams before diving into a WBS session.
Recruit knowledgeable as well as available resources. Do not try to complete the WBS yourself in the interest of saving time. If you are not an expert on the deliverables, you will miss key elements. You also want the team members to do the work so that they buy into what has been created. Involving knowledgeable team members in the creation of a WBS is far more effective at communicating what the project is all about than handing someone a completed WBS. If there are team members who will be involved in the project but who cannot participate in the session, make arrangements to get input from a representative at a separate session. Ideally, you want everyone in the same room, but if that is not possible make sure you get the input in some other fashion.
Work though all items at level 2 before you go down to the next level. You should be confident that the entire work of the project is represented at the high level. If you are completing the WBS as a team exercise, you will need to control the tendency the team may have to start decomposition immediately once a deliverable has been put up on the board. This is a natural inclination, once people see a deliverable, to start thinking of what it will encompass. As a project manager, you need to take control of the situation and remind the team to not decompose anything until all of the high-level deliverables have been identified. Otherwise you may end up putting tasks under a deliverable that are not really a part of that deliverable or worse yet miss a key component of the project. Keep referring the team back to the scope statement until everyone is confident that your high-level deliverables are covered. Then you can start decomposing.
Each item in a lower level is a component of the level above. Completion of all of the items in the lower level should mean completion of the higher level. As a checkpoint, you should always review the items at the lower level and ask the team if completion of those items will result in the task at the next higher level. If the answer to this question is no, than you have not identified all of the lower level tasks.
List all activities and continue to break them down to component parts. Make sure you get to a level where the team feels comfortable that resources can be assigned and estimates can be completed. Sequencing, assigning resources, and estimating are all separate activities that you will complete after the WBS is complete. We have seen many teams waste time doing separate tasks such as sequencing the activities while creating the WBS. These teams managed to break down the activities, but at the same time they got hung up with the sequence, which is not the goal of the WBS.
Do not create a To Do list. You should not decompose activities any further than to a level where they can be easily assigned, estimated, and produce a meaningful deliverable. Since the WBS will become the foundation for the project schedule, do not break down beyond a level that you can control. If you create a series of very short sequential tasks, you are expected to manage all of those tasks.
Let’s take a look at the Purchase Materials deliverable for our porch project. Under Purchase Materials you could have just listed all the items you need to buy: sandpaper, sealer, paint, brushes, etc. But if you included your shopping list in your WBS, you would not have actually listed the activities that make the purchase complete. The items that you need to purchase to complete the porch project are only one of the activities associated with “Purchase Materials.” Your shopping list is referenced on the WBS by the activity “Make a List,” as shown in the completed Porch Project WBS in Figure 3.4.
Use the appropriate number of levels for each leg. Each major objective will have a different level of decomposition to get to the point where you can do estimating and resource scheduling.
It is not uncommon for one leg to have three levels and another to have seven levels. You should be concerned about getting to a manageable activity, not on balancing the WBS. If you try to force an even number of levels across all deliverables, you will end up with some legs that are not broken down in adequate detail and others that end up listing all the steps to complete a simple task.
Create a numeric identifier for each item on the WBS. This is very similar to the format used for a numeric outline. Start at the left of the WBS and work across. Your major deliverables are 1.0, 2.0, 3.0, etc. As you move down a level, increment the second number. The level under deliverable 1.0 is labeled 1.1,1.2,1.3,1.4, etc. Figure 3.5 shows numeric identifiers added to the WBS we created earlier for the porch project.
Figure 3.5: WBS with Numeric Identifiers
Benefits of the WBS
The WBS is often listed as one of the most important components of a successful project. As you will see in later chapters, the WBS is an input to numerous project management processes. In our experience as a project managers, we have also found it invaluable in many other ways.
The WBS is an excellent tool for team building and team communication. With a graphic representation of the major project deliverables and the underlying activities, team members can see the project big picture and how their portion fits in. The direct link between a given activity and a major project deliverable can also help clarify the impact of an individual team member. As new resources are added to the project, the WBS can be used to bring these new team members up to speed.
A good WBS can be turned into a template for future projects. Software development projects frequently have a similar life cycle, and what was done on a previous project can be used as a starting point for a new project. This allows the team to take an existing structure and customize it to fit the new project. This is also an excellent way for teams to look at areas of the project they may not have thought about on their own.
The picture of the project scope the WBS provides is an excellent tool for communicating with clients and stakeholders. People do not always comprehend the magnitude of a project until they see the diagram of the project objectives and the activities required to reach those objectives. It also is an excellent tool to use when discussing staffing requirements or budgets. It clearly shows what work is included in the project. If something is not covered in the project objectives and supporting activities, it is not part of the project.
A detailed WBS will not only prevent critical work from being overlooked, it will also help control change. If the project team has a clear picture of the project objectives and the map to reach these objectives, they are less likely to go down a path unrelated to the project scope. We do not mean to imply that a WBS will prevent change; there are always changes during the project life cycle. But a WBS will clarify that a request is a change and not part of the original project scope
Chapter 3: ScopePlanning
THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE:
-
1.5 Given a scope definition scenario, demonstrate awareness of the need to secure written confirmation of customer expectations in key areas.
-
1.6 Given a project initiation document (a project charter or contract), including a confirmed high-level scope definition and project justification, demonstrate the ability to identify and define key elements.
-
1.7 Given a project initiation document (a project charter or contract), including the client’s highest priority between quality, time, and budget, estimate a number of elements.
-
1.9 Given a proposed scope definition and based on the scope components, assess the feasibility of the project and the viability of a given project component against a predetermined list of constraints.
-
1.10 Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organizational resources as the project scope statement is being developed.
-
1.11 Given an incomplete project scope definition, complete or rewrite the definition to (1) reflect all necessary scope components or (2) explicitly state which is included in the project and which is not.
-
1.12 Identify possible elements of a final project scope definition and the circumstances in which they would be appropriate.
-
1.14 Recognize the need to obtain consensus of stakeholders and to obtain buy in from the team to proceed to the planning stage of the project given a high-level estimate of scope, schedule, budget, and resources.
-
2.6 Given a project description/overview and a list of the project business and technical requirements, perform key tasks to ensure project success.
-
2.7 Describe the goals of a useful project requirements review with the client (e.g., verify mutual understanding of client’s product delivery, product performance, and budget requirements, etc.) and describe when it is important to have such reviews.
-
2.8 Given the client’s approved project requirements and the input of stakeholders, decompose these requirements into business and functional requirements while maintaining trace ability within strict configuration control.
-
2.9 Given a project planning scenario, demonstrate an understanding of and the ability to develop a phase-oriented WBS with high detail for an early phase and with low detail for later phases.
-
2.10 Given a scenario involving tasks, resources (fixed or variable), and dependencies for a multiphase IT project, demonstrate knowledge of the standards for creating a workable WBS.
-
2.11 Recognize and explain the need to obtain consensus and formal approval (sign-off).
Now that we have covered the initiation process and have an approved project charter, it is time to talk about project planning. Planning can be one of the most overlooked areas of project management. Once a project is approved, everyone just wants to run off and start working. As a project manager, you may even find that your organization does not support taking the time to do planning. If you have ever had an executive call you to task for wasting valuable time planning when there is work to be done, you know what we are talking about.
A good understanding of the planning processes will prepare you to communicate within your organization about the benefits of taking time up front to define all aspects of managing a project before the work actually starts. Starting with this chapter and continuing through Chapter 7, “Creating a Comprehensive Project Plan,” we will cover all the aspects of project planning. Our first planning topic is project scope.
Project scope is defined as the size of the work involved to complete the project. As a project manager, you need to be aware of what is included in the project as well as what is excluded. Scope planning will assist you in getting your arms around a project and setting the boundaries for what is included in the project.
You need to define and document three scope components to complete scope planning: the scope statement, scope management plan, and work breakdown structure (WBS). The scope statement provides a common understanding of the project by documenting the project objectives and deliverables. The scope management plan documents the procedures that you will use to manage any proposed changes to the project scope throughout the life of the project. The final component of scope is the work breakdown structure, which breaks the project deliverables down into smaller activities from which you can estimate task durations, assign resources, and estimate costs.
Chapter2-5:Summary
Summary
Initiation is the formal authorization for the project to move forward. It starts with the identification of a problem, a business need, or a requirement that in turn sparks a project request. Events that trigger a project request are market demand, internal business need, legal requirement, new technology, external customer request, technological change, and social need.
The initial project request needs to be clarified to create high-level requirements, or the product description. High-level requirements and associated cost estimates are presented during a project selection process. This stage may be formal or informal, and may be done on a corporate basis or departmentally.
Project selection techniques involve the use of decision models, such as a cost-benefit analysis and expert judgment, to allocate limited resources to the most critical projects.
Project stakeholders are people who are involved in the project or people who will be impacted by the result of the project. Some project stakeholders you will likely encounter, besides yourself as the project manager, include team members, functional managers, customers (both internal and external), and end users. A project sponsor is a stakeholder who will promote the project and is available to mentor the project team as applicable.
The output from the Initiation process is the project charter. This contains the signature of the person or persons who have the authority to move the project forward. This document will be the basis for more detailed project planning. It should contain the project description, information on the project team, measurable objectives, and a high-level business case.
Chapter2-4:Project Charter
Project Charter
The result of the Initiation planning process is the project charter. This document provides formal approval for the project to begin and authorizes the project manager to apply resources to the project. This is a major milestone, as the charter is the first official document of your approved project. All that hard work in the Initiation process has finally paid off.
The person or group approving the project issues the project charter. If your organization has a formal project selection committee, it may define who issues the project charter. This is typically someone in upper management, but this will vary between companies or departments. It may or may not be the project sponsor.
The charter is the project blueprint; similar to the blueprint you develop if you build a new home. The finished product will look a whole lot different, but at least you now have a map to help you get started.
Organizational standards drive the specific format of a project charter and the information it contains. As a project manager, you always want to determine if there is a template or required format to follow. At a minimum, your charter should contain a description of the project, the business need that created the project, and formal approval for the project to begin. If your project was involved in a formal selection process, you will have more data and can develop a project charter that contains the project description, project team information, goals and objectives, high-level business case, and formal approval.
Let’s discuss the components of a charter in more detail.
|
An IT project description needs to be a quick-read paragraph that encapsulates and describes in a few sentences what the project’s product will do. It documents the key characteristics of the product or service that you’re going to create as well as the work required to deliver the project.
The following are some examples of IT project descriptions:
|
Project Description
The project description documents the key characteristics of the product or service that will be created by the project and the work required to deliver the product. The description in the charter will be high level and more detail will be added when you develop the project scope statement, which is discussed in Chapter 3. The project description documents the relationship between the product being created and the business need that drove the project to be requested. This description needs to contain enough detail to be the foundation for the scope planning process that will be the next step.
Project Team
The project charter should formally identify the project manager and his or her authority. Detailing the project manager’s authority in writing early on will prevent misunderstandings or issues down the road. Authority areas to document include personnel management and budget authority.
-
Does the project manager have hiring and firing authority over team members?
-
Does the project manager have input into the appraisals or salary reviews of team members?
-
Is the project manager authorized to spend the project budget?
-
Are there any limits on the dollar amount that can be spent without sponsor or other executive approval?
All known project team members can be listed. A charter does not normally list project team members by name, but lists the category of resources required. Job titles such as Business Analyst, Systems Analyst, Programmer, and Tester can be listed. Charters for cross-functional projects should also list known team members from other departments such as a Product Manager, Marketing Communications Manager, Training Developer, or Contract Specialist.
Goals and Objectives
The charter documents the high-level goals and objectives of the project. The project charter is the first communications document to explain what the project is all about.
A charter needs to include a clear statement as to what end result the project will produce and how success will be measured. Goals and objectives must be clear and stated in such a manner that the end result can be measured against the objective. Instead of stating, “Install a fast customer record retrieval system,” a goal should state a measurable outcome like “Retrieve customer records in an average of 5 seconds.”
Working with the client to document quantifiable and measurable goals is key to the project success. It puts the client, the sponsor, key stakeholders, the project manager, and team members on the same page. Fuzzy objectives with no measurement create vastly different perspectives as to what constitutes project success.
Business Case
Approval of the project charter also marks the initial approval for project funding. The amount of funding initially approved for the project is linked to the business case. A business case formally documents components of the project assessment generated by the project selection process. It includes a description of the analysis method and the results.
A business case is typically a stand-alone document that is initially created at a very high level with multiple iterations over the course of the project. Details to the business case are added at various points in the project planning process. Many organizations have business case templates, with some of the sections completed at the time of project selection.
A business case summary in the project charter may include high-level costs, benefits, and payback period estimates.
Costs All costs estimated at the time of project approval should be listed. These costs include estimates for materials, equipment, and human resources. The estimates in a project charter are very high-level estimates based on costs of similar projects or estimates from experts familiar with the type of work involved.
In a typical IT project, there are both capital and expense costs. Capital costs would include the purchase of new equipment such as servers or workstations. Expense costs include items like salaries, travel, and training.
Benefits A key benefit is revenue. Revenue is the cash flow generated by providing a billable good or service to an external customer. Not all projects generate revenue, but for those projects that will be sold to external customers, this is a critical component. The early revenue estimates are provided by the marketing organization based on a target price and a forecast of sales.
Revenue is a benefit that can be quantified and measured. A new product may be projected to bring in $2M in revenue during the first year of product launch.
Other benefits, such as increased customer satisfaction, may be more difficult to quantify. Benefits that cannot be easily quantified in dollars are sometimes referred to as soft benefits.
Payback period The payback period identifies when the project will pay for itself. For a revenue-generating project, this can be a timeline of the project costs compared to project revenue.
There can also be a payback period on a project that does not generate revenue. A new call handling system with menu options may drive efficiencies in a call center operation that will allow the center to grow without adding additional staff. This cost avoidance figure can be used to calculate when the system will pay for itself.
Formal Approval
The project charter should be signed by the executive with the authority to move the process forward. This person could be the project sponsor, the project client, or a representative of the project selection committee. The key is making sure the person signing the charter is at the appropriate level within the company to authorize the project.
This sign-off provides the project manager with the authority to move forward with the work required to complete the project. This approval may be required prior to the release of purchase orders or the formal commitment of functional managers to provide resources to support the project.
Issuing the project charter moves the project from the initiation phase into the planning phase. Regardless of who actually signs the project charter, now is the time to make sure you have buy-in from your stakeholder group. All of the stakeholders need to receive a copy of the charter. It is also a good idea to schedule a meeting to review the charter, review next steps, and answer any questions or concerns. To eliminate any future disagreements regarding the outcome of the meeting, all key points and any decisions made should be documented in a memo sent to all the stakeholders. Issues that are dealt with as soon as they surface are easier to resolve. Ignoring concerns or not keeping stakeholders in the loop can create escalations to higher management and start your project off on the wrong foot. The support of management is critical and the best way to maintain this support is through ongoing communications. Maintaining consensus among stakeholders is a key part of the project manager’s responsibility throughout the life cycle of the project.
IT Chain of Command
When considering the overall project, especially in context of the charter and the associated names of people in that charter who are able to authorize the resources necessary to enact the project, it will be beneficial for you to understand who’s in the IT chain of command so that you know who is capable of doling out this authorization. While most IT shops are somewhat smallish (i.e., just a few members in each specialty group—servers, programming, etc.) these groups can be broken out among various managers who each have their own budget, and who can call the shots for the employees under them. For example, your project might call for a telephony person, who reports to the telecommunications department, of which there are four or five employees and who have a manager over them who is responsible for their day-to-day operations. This person is one who must appear on the charter because he has the ability to authorize the use of the resources you require. Ditto for programmers, who probably come from a different group, with a different manager. You can’t schedule a telecommunications person using the authorization of the programming manager because she doesn’t manage the telecom folks! So it’s prudent to understand the chain of command that’s involved with any given technological project.
The IT chain of command can vary widely depending on the size and spread of the organization you’re working for. Generally speaking, however, there will always be a supervisor or manager of the software development, network operations, server administration, telephony, security, Internet/intranet, architecture, and database teams.
Typically, these supervisors/managers report to a director-level individual or perhaps even the chief technology officer (CTO) or chief information officer (CIO) (the so-called C-band executives) of the company. This, of course, depends on the company’s size. See Figure 2.1 for an example of the IT reporting hierarchy.
Figure 2.1: The IT reporting hierarchy
In Figure 2.1 you’ll see a department called the project management office (PMO). Some (not all) enterprises have realized that many endeavors benefit from a professional project manager overseeing the project—whether the project is technical in nature or not. So the idea of a PMO was formed—a centralized location for all project managers, staffed and managed by project professionals, and capable of taking on any project in the organization.
The Frustrations of Hierarchy
Because the charter speaks to the types of people who will be required to complete the project (note that we may not necessarily know the names of the people at this point in time, but we do know that we need a certain class of individual) understanding the chain of command makes your job easier when it comes to understanding who’s got to sign off on who’s joining the project. You can’t, for example, stipulate that you need a programmer but not list the head of the programming department as one of the persons who must authorize the usage of his or her resources.
Here’s the problem with a chain-of-command hierarchy in a standard IT shop: The director of applications development’s goals may not be the same as the director of operations. Your job as a member of the project management office (PMO) is to try to get these two on the same page with respect to your project—to see that the outcome of this project is of paramount importance and that the two must agree on this. But that’s not always the case. So you wind up doing a lot of resource allocation planning, working with the leaders of each unit in order to come up with convenient windows of time when the people you need are going to be available. You don’t usually have the luxury of a manager telling you “You can have my best programmer for as long as you need him or her!”
Another similar, only worse, problem arises when the directors of these various units don’t report to the same individual, as shown in Figure 2.2.
Figure 2.2: Business units not associated with the IT hierarchy
Now you’ve got an issue where you not only need to coordinate resources across various managers but also across executive leaders. While the executive might say “Sure, you can use so-and-so!” the manager may not be so wild about the idea. Or vice versa.
Still more confusing is the hierarchy in which the business unit has some IT staff and you also have some IT folks who are going to work on the project. This is similar to the CIO/CTO model shown in Figure 2.2 except that the business unit’s objectives may be quite different than the objectives of executives who are committed to IT. You may well find that you get an initial commitment from the business unit director to use a staff IT person, but that permission is yanked back at the last minute due to other pressing issues. Or you might find that your assigned staff person is a yo-yo, being pulled constantly off of the project in order to put out business unit IT fires.
Unfortunately, there is no really good way to manage such complicated scheduling issues, apart from doing your best to anticipate problems up front and then planning into your project enough leeway to handle such issues. Business unit leaders need to understand that a commitment to an important IT project means that the staff you need are available to you at the time you need them and they cannot be used for other work!
|
This case study will follow you through the remainder of the book. It’s designed to be complicated enough to require the use of all of the project management components we talk about, using information from each chapter you read.
You work for a mid-sized winery—Chaptal (named for the process of adding sugar to wine to increase its alcohol level—chaptalization)—in the Sonoma county region of California.
Business has been very, very good! Wine is hot, hot, hot all over the country and your wine maker, Rachel Ranee, has gained in stature and favor throughout the major wine circles.
The owner of the winery, Kim Cox, has decided to set up shop in other interesting parts of the world: Chile, southeastern Australia, and western France. She has established strong partnerships in these areas and is now ready to connect the three sites together into one network so that she can keep track of the daily activities of each new winery. The prospective new wineries are as follows:
France LaCroix is in the Bordeaux region of France. Chaptal’s partner is Guillaume Fourche, a long-time Bordeaux negociant, one who buys wine from the various smaller wine merchants to blend into interesting cuvees that are then bottled and sold. Kim wants to set up an international distributorship with this man, utilizing Rachel’s wine-making skills to seriously kick up the quality of the wines that LaCroix distributes.
Chile Metor Sanchez in the Aconcagua Valley has been making wonderful Chilean red wines for several years now. Metor Sanchez is interested in branching out internationally and understands that a partnership such as one through Chaptal would be beneficial for both wineries.
Southeastern Australia In Adelaide, Australia, a new renegade winery has sprung up. Roo Wines, headed up by a young new upstart wine maker, Jason Jay, holds Kim in a spell with the luscious dark Shiraz wines that they release.
Kim has entered into financial agreements and working partnerships that allow her to own a stake in each of the wine company’s output, while allowing them to retain their original look and feel. The people who work for each entity will ultimately report to Kim, but each endeavor is free to continue doing what it does best. Kim has committed to not creatively interfere.
As the head of IT for Chaptal, you’ve been with the winery since it had one little fileserver on which Kim kept the spreadsheets for the various accounts and Rachel kept track of the residual sugar readings of the grapes.
Today Kim has told you that she wants you to install an email server in each of the other three locations, connecting them so that everyone can quickly communicate with one another. She also wants an intranet site set up so that the new wine releases can be easily pre-released to all sites for comment and approval.
Having just recently passed the CompTIA IT Project+ test, you understand that there are some basic elements you need to capture in this first meeting:
Basic Requirements You have two requirements that you must fulfill:
Stakeholders Clearly, Kim is the project sponsor, but who will be the stakeholders? In addition to Kim there are three primary stakeholders:
-
Guillaume Fourche
-
Metor Sanchez
-
Jason Jay
But in addition to this list, various staff members will benefit from the new changes. Also, the support entities that assist in the production of the various wines will be stakeholders as well.
Chapter2-3:Project Stakeholders
Project Stakeholders
The refinement of high-level requirements and the project selection process is where you will first interact with a very important group of people: stakeholders. You have probably seen or heard references to project stakeholders. But what exactly is a stakeholder and why is it important to identify all your key stakeholders?
A stakeholder is a person who is either actively involved in the project or is impacted by the project. Stakeholders have something to gain or lose, and you need to meet their expectations. Stakeholders may be interested and involved with the project at different phases.
Some stakeholders may not support your project. A project that creates a major impact on operational procedures may be viewed as a threat. Change can be a frightening proposition. Projects that result in a more efficient business operation may cause a staff reduction. Fear of job loss may cause certain people or organizations to work against a project.
Dealing with your stakeholders is where you will put to use many of the general management skills we discussed in Chapter 1. Individual stakeholders may have very different priorities regarding your project, and you will do a great deal of negotiating with your stakeholder group. Building consensus among a group with diverse viewpoints starts with up-front negotiation during Project Initiation and continues with ongoing communication throughout the life of the project. In Chapter 6 we will discuss Communications Planning in detail, including how you define and implement a communications plan geared to the needs of individual stakeholders.
Set up individual meetings or interviews early on in the project to get to know your stakeholders and understand their perspectives and concerns about the project. These people will not go away, and if you ignore some of your stakeholders, the issues they raise will become more difficult to resolve.
Project Sponsor
The project sponsor is a special type of stakeholder. Although projects have multiple stakeholders, whom we will discuss shortly, there is (or should be) only one project sponsor.
The sponsor is the person who champions the project throughout the organization. The sponsor acts as an advisor to the project manager. The project manager keeps the project sponsor informed of current project status, including conflicts or potential risks. The project sponsor typically has the following accountabilities:
-
Provide or obtain financial resources.
-
Analyze key stakeholders.
-
Negotiate support from key stakeholders.
-
Monitor delivery of major milestones.
-
Run interference and remove roadblocks.
-
Provide political coaching to the project manager.
Note From time to time you might hear a reference to a person called the project champion. The project champion is generally a technical person aligned with the project for the purpose of supporting the project. She is not necessarily one who has a lot of power, but is one who understands the goals of the project and can help you keep the project moving forward.
Other Project Stakeholders
A complete list of stakeholders varies by project and by organization. The larger and more complex your project is, the more stakeholders you will have. Sometimes you will have far more “stakeholders” than you want or need, especially on high-profile projects. I recommend that you define who you think the other stakeholders are on the project and review the list with your project sponsor. He or she is often in a better position to identify what we refer to as “political” stakeholders—influential people in the organization who have expressed a desire to be involved in this project, without a direct or obvious connection. You do not want to ignore these people just because their role is not obvious, and your sponsor can assist you in identifying the needs of these stakeholders.
Some stakeholders are more obvious and much easier to identify. In addition to the project sponsor, the following are generic stakeholders you should find on most projects:
Project manager We have already talked about the project manager in detail. This is the person responsible for managing the work associated with the project.
Project team members These are the experts who will be performing the work associated with the project. Depending on your organizational structure, these people may report directly to the project manager, matrix report to the project manager, or simply be provided by another department. Project team members may be assigned to the project either full-time or part-time. Most projects have a combination of dedicated and part-time resources. If you have part-time resources, you need to understand the other obligations of these team members to make sure they are not being over allocated.
Your project team may include only people from other IT groups, or it may include other departments such procurement, legal, public relations, marketing, sales, and customer service.
Functional managers If your resources are supplied by another organization, the functional managers who assign those resources are critical stakeholders. Normally multiple projects compete for the same resource pool. You need to establish a good relationship with your functional managers. Documented agreements on the amount of time a resource will be available to the project as well as the deliverables the resource is accountable for will prevent future misunderstandings. You should obtain up-front agreement as to your input in such areas as appraisal, salary increase, and bonus opportunity.
The functional manager is the decision maker in these areas. If you approach functional managers with these questions up front, there will be much greater clarity as to your role and your authority.
Customer/Client The customer is the recipient of the product or service created by the project. In some organizations this stakeholder may also be referred to as the client. A customer is often a group or an organization rather than a single person. A customer can be internal to the company, as would be the case if you were on a project to install a server system for the sales organization. An example of external customers is the people who purchase a new feature.
End user The term end user denotes the person who directly uses the product produced by the project. This term is often seen in IT projects to distinguish between the organization purchasing the output of the project and the group who will use it on a daily basis. As an example, the sales department may be viewed as the customer for an online order entry system, while the frontline sales consultants are the end users of this system.
End users may participate at some level in requirements review or functional testing of the product.
As you can see from even this generic list, your stakeholders represent a wide range of functional areas and very diverse wants and needs relative to your project. To keep track of everyone, you may want to develop a stakeholder matrix.
Who Are Your IT Project Stakeholders?
Typically your IT stakeholders will come from the corporate business unit(s) requesting the project. Because IT touches virtually every facet of an organization’s business, it’s very likely that as time goes on you’ll encounter a variety of projects from all or a combination of the business units that your particular IT shop supports. You’re likely to encounter three classes of IT projects that will affect specific groups of stakeholders: single business unit projects, multiple business unit projects, or enterprise projects. Let’s talk about each of these in more detail.
Single Business Unit Project
In a single business unit project, you might be approached by a representative from, say, marketing or sales, for example, to help design and build a system that meets a specific business requirement.
Often in such situations you’re presented with a system that the business unit is currently using but is not satisfied with. In a lot of cases, business unit stakeholders have already done some research into what they want and have some recommendations to offer for COTS applications that they think will meet their needs. As a project manager you should scrutinize the software very carefully because it may not meet the scalability requirements that larger shops have. Additionally, if the software being put forward is from another firm that wrote a custom application but is willing to “loan their code” you need to be doubly careful to make sure that the application being considered is solid, reliable, and, most important, supportable by your IT shop.
In some cases, the business unit has no idea about any other software applications that are available to meet a business objective or solve a business problem and they’re coming to you to formulate a project that fulfills the goal. You’re afforded much more leeway in a situation such as this. Generally speaking, COTS applications are so plentiful today that you will probably be successful finding a fairly close match to what the business unit is asking for. However, some instances may require that a new software application be written to custom specifications. It is up to you as the project manager wearing a systems analysis hat (or vice versa) to make the best educated decision about the proper approach to the solution.
Multiple Business Unit Project
Sometimes two or more business units can make use of a system in order to meet business objectives or solve a business problem. Document imaging and management systems (DMS) are an example of this. In a multiple business unit project, you might be approached by two or more business units that have determined that they collectively have enough capital funding to “go in together” on a DMS that they can all use.
Now your task has gotten more difficult because you have a variety of stakeholders involved, all with different agendas, but similar interests. Gaining consensus in such stakeholder environments will be the most important item of the day.
Additionally, you’ll be forced to understand each business unit’s logical flows in order to make collective sense out of the system that you design and build. One business unit, for example, may not require quality control procedures for incoming documents, for example, because they’re already quality checked by the sender due to some regulation or another. But another participating business unit does have a quality control step that they need to continue to maintain. Solving for such stakeholder irregularities makes for interesting project management issues.
Enterprise Project
Another interesting project is one that impacts the entire enterprise. What we mean by the word enterprise is the complete array of business units—everyone in the company or division is affected.
You may not be aware of it, but you’ve probably been a part of or at least interacted in some way with an enterprise project. Two distinct examples come to mind: your organization’s email system and its corporate intranet. All persons interact with each of these enterprise systems, and yet at most probably one group of IT people is involved with each respective system’s maintenance.
|
Marvin works as an IT specialist for a business unit in a company. His business unit managers have voiced a need for a DMS in order to scan in old documents and archive them in some DMS software. Any new documents will be electronically submitted and automatically populated into the DMS software.
Another business unit with similar needs has gotten wind of the project and approached Marvin’s managers. Together the managers of both business units have agreed to partner to procure and implement the new system. The other business unit does not have an IT department, so they’ll be relying on Marvin to assist with their implementation. They will be assisting by providing some funding for the project.
Marvin is not the owner of the datacenter, where the new DMS servers will be housed. This function is handled by the central IT shop (called “Ops”) responsible for enterprise operations. He will manage the software on the servers, but Ops will be responsible for maintaining the server hardware and the database on the system.
In this case Marvin has a very complex stakeholder environment. Ops and the other business unit are both stakeholders in the efforts that Marvin’s business unit is making. Success or failure can be had at the hand of any of these stakeholders. If, for example, the second business unit drops their funding, then the project is in jeopardy. If Ops cannot or will not manage the server, the primary business unit will have to find some other workaround, potentially resulting in increased project costs or duration or both. Ops must rely on Marvin’s training in the new DMS software in order to make sure that users can reliably utilize the system.
|
Enterprise projects bring interesting stakeholder issues. Who are your stakeholders in enterprise systems? Generally, everyone will use the system. So you have to look at representatives from each group as your key stakeholders, or conversely, at certain select groups as the primary stakeholder for the system. For example, when considering a new email system, your corporate records manager; that is, the person or group responsible for setting down document retention policies, will be a very important stakeholder in any decisions you make about the retention of email items. In a new corporate intranet project, all users will be stakeholders, but most likely the content providers for each business unit will be the key stakeholder for the project.
IT Project Team Members
The IT project team has several stakeholders in various positions. The IT project team is different than a team you’re assembling for a construction project. Construction workers work within their own areas of expertise (a plumber doesn’t necessarily care, or have to care, what the electrician is doing, for example). But in an IT team, you have individuals who have specialized in their respective areas of IT and who may well have a clue, perhaps a substantial one, about the other team member’s functions. A software developer has to be fairly database savvy, for example, because he or she will be working extensively with writing data taken from user input screens to a database somewhere. Database administrators (DBAs) must be extremely knowledgeable about the things software developers do, plus they need to understand how servers work and also how users connect to databases across the network wire. Server administrators must understand that their servers are there to support business functions—that the underlying network operating system (NOS) isn’t the sum total of what the server’s about. And woven through it all are systems analysts, business analysts, business subject matter experts, and others who are participating together to bring in the project’s deliverables.
Following is a list of the kinds of people you might expect to join you on any given IT project team, depending on the deliverables you’re trying to produce:
Software developers Software developers are often called on to work on IT projects. This category of team member may also include folks who specialize in writing programs that run on application servers such as JBOSS, Microsoft BizTalk, or BEA WebLogic; user-interface developers; firmware coders who write software that works inside hardware devices; database stored procedure developers; and Internet/intranet developers and specialized module developers (for things such as printer and communications modules).
Server administrators These team members are responsible for bringing up the servers (whether Intel-, mid- or mainframe-based) that will house your project.
Database administrators (DBAs) DBAs are responsible for creating the database schema (structure) and associated requirements, plus planning out the backup and recovery methodologies for the data. DBA work includes the concept of reducing the table structures to their lowest operable form, a process called normalization.
Internetworking specialists Internetworking specialists are the folks who handle the routers, switches, LAN cabling, and WAN connections.
Telephony specialists The people who manage the company’s telephone equipment and operations are telephony specialists. It’s amazing how many systems today interoperate with telephony. Think of a telephone-based menu system, called Interactive Voice Response (IVR), realizing that a software developer had to write that code that intercepts the incoming call, provides a menuing system for the user to pick from, then routes the call back out to the appropriate party. The IVR software runs on a server but is connected to the telephony backbone.
Systems analysts Systems analysts (SAs) are people trained and skilled in IT subjects, but who operate at the functional level of taking the system requirements and boiling them down to a system design specification that the system developers can use to build the project. SAs today use very cool software such as the offerings from Rational that help them quickly and accurately model the system from business flows.
Business analysts Often one and the same as the system analyst, business analysts (BAs) are able to work at the high level of the business unit in order to understand their needs but are also able to interface with the IT folks to help them understand what it is the business unit really wants. BAs can be IT-savvy folks who come from the business unit, or business-savvy people who are in the IT shop.
System architects System architects have a very technical level of knowledge about systems and are able to draft out the “blueprint” of the proposed system. Sometimes the system analyst can be the architect; other times, a developer or perhaps even the project manager is in charge of architecture. However, in larger systems, it is not unusual for project managers to use the assistance of an actual system architect.
Budget analyst Especially in very large projects, a budget analyst is required to keep track of the project’s budget and associated expenses.
Security analyst The security analyst is a new, yet indispensable character on most systems project teams. The security analyst is the person who makes sure that all security aspects are ironed out. Security is a unique specialty and really requires, especially in mid- to large-sized projects, someone who has a firm background and understanding of the subject.
Technical writers In larger projects a technical writer is put in charge of writing all of the documentation (with the exception of the comments directly entered into the code) for the project. This includes training documents as well as user manuals, help-desk “cheat sheets” and other documentation.
All of these people must be able to understand technical jargon and acronyms, and be able to fully function and get along with one another. It’s important that these people feel a sense of freedom to be able to question something that’s being done and to work closely with one another in making sure that the right decisions are being made going forward. There is little room for superstars or “Lone Rangers” (those who prefer to work alone and not associated with project teams) in efforts such as these. The project team must consist of a group of people who understand the project’s goals and who come together with a cohesive purpose. Otherwise chaos will occur.
Additionally, people on project teams must be great self-starters, able to work on their tasks with little guidance apart from the system design specification. System project teams are usually not a good place for a beginner to start out because you need folks who have some basis of experience for what they’re being asked to create.
As the project manager of a technical project team you must realize that you’ll be working with a wide variety of personality types and you’ll have to somehow manage the psychology of process accordingly. While you need to have a firm grasp on all of the technological ramifications of the deliverables being created, you must also understand team dynamics and how humans interact with one another in high-stress settings. You should be prepared to handle grievances, to mediate arguments, to gather around a whiteboard and draw out a logical function so all stakeholders understand it, to communicate in one person’s lingo what the other person is trying to say, and so forth. Clear, concise and adequate communications are essential in IT project management.
|
By writing a good quality project description, you’ll probably have a fairly clear idea of exactly the kinds of people you’ll need on your team before you even start assembling the team. Take, for example, the project description in the sidebar, “IT Project Descriptions”:
“IT will create a set of computer programs and databases that will allow the vehicle service department to track all warranty work performed on any given vehicle. The system will be intranet-based and accessible via browser from any computer in the environment. The database will contain fields to house all relevant pieces of information for warranty work performed by the department. Reports will be generated that can be electronically shipped to the vehicle manufacturer for reimbursement. Drop-downs using lookup tables will be provided on the user interface wherever possible to minimize data entry time and incorrect data entry. Consistency checking will be performed on key fields that require double-checking of the data (such as VIN).”
Clearly you can tell from this short description that you’re probably going to need at least one web programmer. You don’t know yet whether you’ll opt for Java, C#, or some other Internet programming language—that’s not important just yet. You also know that you’re going to need at least one DBA because there are databases to be created. You’ll doubtless need the assistance of a server administrator to assist you in placing the databases and software that you’ll develop. You’ll also need a good BA to help you understand the business processes and translate them into the computer programs.
As you drill into the project a little more, you’ll discover how many of each you need, but for now you’ve at least identified the relevant technology people.
|
Stakeholder Matrix
If you have a large project with multiple stakeholders, it may be appropriate to create a stakeholder matrix to help you keep track of everyone. A stakeholder matrix should include a list of the stakeholders with the following information on each one:
-
Role on the project
-
Needs from the project
-
Involvement on the project
-
Level of influence over the project
This matrix can be a useful tool to review during project execution, as conflicts arise. It can help the project manager understand and deal with various behaviors. It is of particular value if your project has some of the political stakeholders I mentioned earlier.
Since project stakeholders can move on and off the project at different times, it is very important that the project manager reviews the project charter and the project plan as stakeholders become involved in the project.
Chapter2-2:Project Selection
Project Selection
We received a project request and defined and documented the high-level requirements, so it must be time to actually start working on the project—right? A little wishful thinking perhaps, because our project still needs to be approved. The good news is that it is time to move on to the final hurdle to get our project authorized: project selection.
Multiple projects compete for limited budget dollars and human resources. No organization we are familiar with has ever been in a position to complete all the requests for projects that it receives. The organization evaluates project requests to determine which projects will be approved to receive funding and resources. In some instances the client is the sole approver, but often approval is required at a cross-functional or executive level.
An organization can use a number of techniques to select new projects. You need to understand the basic concepts of these techniques, so that you understand how the project selection process works and are prepared to present the appropriate data for your project.
Selection Techniques
Project selection is used to determine which proposed projects are approved to move forward. It usually includes the allocation of high-level funding. Project selection may take place using formal documented guidelines, or it may be informal, requiring only the approval of a certain level of management.
Typically, a high-level board or committee will do project selection. This committee may be cross-functional in nature and accountable for corporatewide project selection, or selection can be done on a departmental basis. A committee at the corporate level is composed of representatives from all corporate departments such as IT, sales, marketing, networking, and customer service. In other companies, an internal IT committee may review and select all IT projects.
Complex projects, especially those involving new technology or a major business process change, may be required to undergo an additional step called a feasibility study prior to review by the project selection committee. This is a more detailed look at the request than what is normally required at initiation. All aspects of the request, including profitability, marketability, risks, and alternatives will be evaluated, typically by people not associated with the project request.
Project Selection Criteria
A project selection committee uses a set of criteria to evaluate and select proposed projects. The selection method needs to be applied consistently across all projects to assure the company is making the best decision in terms of strategic fit as well as the best use of limited resources. The exact criteria varies, but selection methods usually involve a combination of decision models and expert judgment.
Decision Models
A decision model is a formal method of project selection that helps managers make the best use of limited budgets and human resources. Requests for projects can span a large spectrum of needs, and it can be difficult to determine a priority without a means of comparison. Is an online order entry application for the sales team more important than the addition of online help for the customer support team? To the impacted departments, each project is probably viewed as a number one priority. The problem is there may not be adequate budget or staffing to complete both requests, and a decision must be made to approve one request and deny the other. Unless you can make an “apples to apples” comparison of the two requests, the decision will be very subjective. A decision model uses a fixed set of criteria agreed on by the project selection committee to evaluate the project requests. By using the same model to evaluate each project request, the selection committee has a common ground on which to compare the projects and make the most objective decision. You can use a variety of decision models, and they range from a basic ranking matrix to elaborate mathematical models.
There are two primary categories of decision models: benefit measurement methods and constrained optimization models.
Benefit Measurement Methods
Benefit measurement methods provide a means to compare the benefits obtained from project requests by evaluating them using the same criteria. Benefit measurement methods are the most commonly used of the two categories of decision models. Three common benefit measurement methods are cost-benefit analysis, scoring model, and economic model.
A cost-benefit analysis calculates the cost, projected savings, and projected revenue of a project. This model is a good choice if the project selection decision is based on how quickly the project investment will be recouped from either decreased expenses or increased revenue. The weakness of using just a cost-benefit analysis is that it does not account for other important factors like strategic value. The project that pays for itself in the shortest time is not necessarily the project that is most critical to the organization.
A scoring model has a predefined list of criteria against which each project is rated. Each criterion is given both a scoring range and weighting factor. The weighting factor accounts for the difference in importance of the various criteria. Scoring models can include financial data, as well as items such as market value, organizational expertise to complete the project, innovation, and fit with corporate culture. Scoring models have a combination of objective and subjective criteria. The final score for an individual project request is obtained by calculating the rating and weighting factor of each criteria. Some companies have a minimum standard for the scoring model. If this minimum standard is not obtained, the project will be eliminated from the selection process. A benefit of the scoring model is that you can place a heavier weight on a criterion that is of more importance. Using a high weighting factor for innovation may produce an outcome where a project with a two-year time frame to pay back the cost of the project may be selected over a project that will recoup all costs in six months. The weakness of a scoring model is that the ranking it produces is only as valuable as the criteria and weighting system the ranking is based on. The development of a good scoring model is a complex process that requires a lot of interdepartmental input at the executive level.
An economic model is a series of financial calculations that provide data on the overall financials of the project. A whole book can be dedicated to financial evaluation, so we will give you a brief overview of some of the common terms you may encounter when using an economic model: discounted cash flow, net present value, and internal rate of return.
Discounted Cash Flow (DCF) Discounted cash flow (DCF) compares cash inflows and outflows over the life of the investment. It uses the concept of opportunity cost in discounting the cash flows. There are several measurement methods associated with DCF.
Net Present Value (NPV) Net present value (NPV) is the discounted value of future cash flows associated with a business activity. NPV measures increase in wealth and assumes that cash inflows are re-invested as capital. It is a measure of marginal return.
Internal Rate of Return (IRR) Internal rate of return measures the rate of return earned on money committed to a capital investment. IRR states the profitability of an investment as an average percent over the life of the investment.
Constrained Optimization Models
Constrained optimization models are mathematical models, some of which are very complex and require specially trained resources. They are typically used in very complex projects and require a detailed understanding of statistics and other mathematical concepts. Further discussion of these models is beyond the scope of this book.
Expert Judgment
Expertise may be sought regarding the requested product. A project sponsor, key stakeholders, other departments, consultants, or industry groups can provide this expertise.
Expert judgment can be used in conjunction with one of the decision models. We have frequently seen a combination of decision models and expert judgment used if the top project request rankings obtained from a decision model are very close to each other.
Companies with an informal project selection process may use only expert judgment to make project selection decisions. Although using only expert judgment can simplify the data required to complete project selection, there are dangers in relying on this one technique. It is not likely that the project selection committee members will all be authorities on each of the proposed projects. Without access to comparative data, a project approval decision may be made based solely on who has the best slide presentation or who is the best salesperson.
Political influence can also be part of the expert judgment. An executive with a great deal of influence may convince the selection committee to approve a particular project.