The key viability question at this scope-refinement stage isn t "should we do this project?"—that was asked and answered in your feasibility analysis in the project concept document. Assessing project viability now means detailed questions such as "when should we do this project?", "why are we doing this project?", and "how will we do this project?" All are valid questions; answering them requires objectivity, a conviction to meet the corporation' s goals, and a view that encompasses short- and long-term perspectives. A project that doesn't have a lot of urgency may very well be important to develop toward the day when it does.
Project viability is measured against a variety of constraints, some of which are discussed here. Projects also face constraints that the PM may have no control over. A company may have a list of dozens of projects it wants to accomplish in a set timeframe, yours just one among many. A committee is charged with reviewing the projects and prioritizing them in the order that s deemed the most logical. Your project may wind up nowhere near the top of the list—a constraint that ' s out of your hands.
A clearly defined project end date A hard deadline decides many questions. It may be one that somebody pulled out of the air, but if the deadline is agreed upon by all concerned parties, it' s the project manager' s responsibility to do everything in her power to make sure the project is finished by then.
Monetary allocations Project managers may be tempted to try to increase a project' s budget based on "we' ve gotta have this" exclamations from the technicians who are constructing the must-haves for the project. If a PM doesn' t have a technical background, adhering to the budget is especially difficult, because he ' l l never be sure whether smoke' s being blown his way. The bottom line is that a project has a defined money pot from which to draw, and it' s the PM' s job to make sure that other decisions are adapted to that limit, not vice versa.
The PM, if nontechnical, would have to resort to whatever resources were available in order to estimate the allocations. This is where PMI ' s methodology plays in more handily than PACE or other, less-complex systems. Using the more rigorous methodology, you don 't get to the phase of time- and work-estimation until project planning, at which point you 've also assembled your team and have technical expertise on hand to go forward with your estimations.
Thorough understanding of required hardware and software By decomposing the system into its fundamental parts, you can get a pretty good idea of what kind of hardware and software is required in order to make the system work. Project changes that would add to the shopping list should be suspect because they could signal reduced project viability.
and software is required in order to make the system work. Project changes that would add to the shopping list should be suspect because they could signal reduced project viability.
Don't Fall for the Easy Integrated-Systems Idea
Don't Fall for the Easy Integrated-Systems Idea
You or your technical team members may be tempted to simply integrate systems. For example, you have one system on a big Unix computer and another on a Windows-based client/server system. You need the two to talk to each other. The temptation may be to try to put a "homegrown" system together by coding to integrate the two. This might be successful and might not. When considering integrated systems, it' s key to make sure that you completely understand the nature of disparate systems, that there is adequate documentation about integrating them with the "outside world," and that you have the technical capacity on staff to handle the integration. Systems integration is a highly specialized genre that requires complete understanding by very capable technicians.
Completion criteria What do we need in order to call the project finished? That' s the goal of completion criteria. They should be specific and clear: "All users will be moved from the old system A to the new system B," for example. Well-thought-out completion criteria are helpful for PMs who would otherwise be tempted to tinker with the project to get it ""ust right." If your project is moving into tasks, deliverables, or spending that don ' t address a completion criterion, the project ' s viability is in question. Priorities The priorities of the project need to be elucidated not only in such a way as to let all participants know what the aim and intent of the project is, but also to keep in their minds how the project contributes to the corporate effort. "We' re going to send paratroopers onto Normandy Beach." "Why?" "Because it ' s going to assist us in winning this war."
Cost, schedule, scope This is just another way of saying that time, quality, and budget balance against each other in putting boundaries on a project. The quality of a project may be forced to be reduced when the budget and time available are too low—not that you want quality to be reduced, but sometimes it ' s inevitable. Often, in situations such as this, instead of an overall reduction in deliverable quality, you' l l leave out extras you may have added in a fully staffed and funded project (graphic arts on a web page, for example).
Project ownership The owner of the project may be different, though not usually, from the user of the project ' s deliverables. You buy a car for your son. You' re the owner (because you pay the car payment and put gas in it most times), but your son ' s the driver. The telecommunications department may desperately need for the satellite services group to get their Iridium satellite telephone system going, because then the department can begin issuing satellite-based phones to people who travel to areas where a regular phone isn ' t available. The telecommunications department is both the customer and the user, in this case. But the owner of the project is usually the financer—typically, the project sponsor. The owner is the one who can, if politically powerful enough, influence the project' s priority. Project viability can be influenced by this person—the kind of person who might say, "I really think this project should go, even if it does mean we have to invent a component." The owner guides the decision-making process. Owner essentially equals sponsor and may often also equal customer. Conversely, an owner ' s employees may be the end users of the system, whereas the owner never touches it. Dor example, a vice president in charge of customer relations, one who manages many call centers, can be the owner of a new call-center system whose mission is to drastically improve customer care. The VP will never utilize the system— her call-center folks will—but she owns it and sponsors it nonetheless.
Mandated tools, personnel, and other resources Typically, this constraint exists because the company already has a good, strong system in place and the managers would rather not stray from something that ' s working into a system that utilizes unfamiliar hardware or software. A strong Oracle shop isn 't likely, for example, to readily accept a system that uses Microsoft SQL Server, and vice versa. Tooling up, in terms of training, licensing costs, and other preparations, would be very time-consuming.
This category also includes personnel who are must-haves as project team members. Suppose Sherry ' s a tremendous software engineer with an awesome background in XML coding. Your project requires extensive XML development. Sherry may be a very logical choice that managers, not you, recommend for placement on the project team. The point of this constraint is that the PM must understand what tools, personnel, or other resources must be used for satisfactory conclusion of the project.
Change-management requirements This is one of the constraints that the project manager must lay down—a constraint that likely will not come from the lips of the project sponsor. It is the job of the PM to put together a comprehensive change-management system and mandate its usage with a decree like, "There will be no changes made to the project unless we go through the change-management process to thoroughly evaluate the need and cost of the change." This reduces scope creep.
Vendor terms and conditions This constraint can arise as a result of a vendor ' s ability to deliver a needed product or service in a certain way at a given time. You need ten servers, configured in a specific way, for example. The vendor is able to deliver six now but won ' t be able to deliver the rest for two weeks. How does this affect the project? The statement of work (SOW) that a vendor provides is a document that the project manager must clearly understand and interpret before the project sponsor signs it. In the SOW, the vendor clearly delineates what they will do and, more importantly, what they will not do. Therefore, it' s important to make sure the SOW aligns with the scope of the project.
Company terms and conditions How does the company ' s situation affect the scope and viability of your project? Suppose that your corporation has offices throughout the world. What security requirements might your company put on the project due to its international nature? The phrase "terms and conditions" most often implies the company' s rules regarding work, projects, spending, and so forth.
Best practices life cycle Looking at other projects of this scope and nature, how long did they, on average, take to complete? Of these projects, which utilized practices that are known to lead to successful completion (fostering a rigorous change-management paradigm, for example)? By reading the lessons learned from other projects, you learn what not to do to facilitate a successful project. The project life cycle is the average amount of time that you' d expect a project to move through its phases toward completion; it is shortened and improved by using best practices.
Tip Lessons learned, an important part of a project ' s completion data, is something that ' s hard to extract from project team members, because they often don' t want to admit that anything went wrong in the course of the project. Nevertheless, gathering and publishing lessons learned data can lead to useful information for similar projects.
Required reviews and approvals of deliverables The scope document should also stipulate which stakeholders will review the project ' s deliverables and that the sponsor is required to sign off on the readiness and completeness of the deliverables. It' s very important that you have a document that clearly illustrates who reviewed and accepted the deliverables. Part of your effort here is to tone down the "blamestorming" that happens when deliverables aren' t what users thought they' d be and get the monkey off of the project team' s back. Knowing who will approve the result helps keep the project focused on that result.
When users sit down and thoroughly test the deliverables in a live scenario, this is called acceptance testing. In the case of code, you' re testing to make sure it does what was requested and that it works well. Upon finding that the code is acceptable, the deliverables can be approved. Acceptance testing is very often a formal phase of the project. By making sure you' re adequately reviewing the quality of the deliverables from time to time, as well as performing a final review at closure time, you are assuring the sponsors up front that the project is viable from a quality standpoint.
All of the above elements should find their way into a well-written scope document. Note that the project' s size dictates the elements that you might choose to include in a scope document. For example, "corporate terms and conditions" might not find its way into a little client/server project that affects a small group within the company. Likewise, your project might be something for which there ' s no industry precedence to guide a "best practices project life cycle," or small enough that you don ' t feel it merits the research to find such precedence.
Was this article helpful?