Section 5.4. Validating the Project Proposal


5.4. Validating the Project Proposal

When a project is assigned to you, it often comes with additional project information. A project proposal may be complete or not, but a thorough project proposal will contain all or most of these elements:

  • Business case

  • Financial analysis

  • Market factors or requirements

  • High level scope and requirements

  • Assumptions and exclusions

  • High level resources

  • High level schedule

  • Success criteria

  • Risks

  • Alternatives

  • Recommendations

Whether you're given a project proposal that has some or all of these elements, you'll need to spend a bit of time validating the project proposal. The intent is not to second-guess anyone but to validate the information in the project proposal for which you'll be held accountable. Sometimes project proposals are developed and the project is placed on hold for month or sometimes years. Sometimes project proposals are developed and the cost of the project components changes dramatically or the required resources or expertise are no longer available or the technology itself has changed. Validating a project proposal is critical because things change constantly. If the project proposal is up to date and was developed by those with enough expertise to develop a valid proposal, you're probably in good shape, but we all know the danger of making assumptions. Rather than assume things are fine, spend time validating the project proposal. How? In two ways: first, by following the project definition steps discussed in this chapter you'll be able to validate the project at a high levelare we solving the right problem, have we selected the optimal solution, etc. Second, you may need to do research or market analysis to validate or develop a complete project proposal.

The primary difference between validating a project proposal and developing one from scratch is that with the former, you're not reinventing the wheel, just making sure the wheel has all its spokes. Using the project definition process we'll discuss in this chapter will allow you to validate each part of the project proposal and to come up with alternatives if things have changed. If the project proposal itself is no longer feasible or desirable, going through the project definition steps should result in solid data supporting the decision to scrap or redefine the project proposal you were given. Without validating the project proposal, you're essentially signing a blank check because you have no way of knowing in advance what you're actually signing up for or whether or not it has any chance of success.

One more note about project proposals before we continue: sometimes it is both necessary and desirable to create a very abbreviated project proposal. In some cases, no project proposal is needed or wanted at all. These may be cases where there is a short window of opportunity or compelling evidence that a project should absolutely move forward. An executive might say, "I don't care about these (project proposal elements), just get it done now!" In those cases, don't spin your wheels developing data that won't be used or needed. However, rather than spending time developing a project proposal, you should spend time defining your project. The lack of need for a formal project proposal does not mean you can or should skip the project management steps listed in this chapter and subsequent chapters; just the opposite. You'll need the data you develop from these steps even more if there is no project proposal prepared to support the rationale for the project.

5.4.1. Form a Small Preliminary Project Team

Regardless of the type of project you're undertaking, it would be helpful at this point to put together a small team of experts to help you define the project, including reviewing the existing project proposal (if one exists). When working through the early stages of project definition, it can be very helpful to have several people working with you. This avoids the pitfalls you might run into such as not seeing your own (perhaps faulty) assumptions and not having access to more than your own point of view. A small team can plow through these initial steps quickly and efficiently and can help build a better foundation for the project. Keep in mind that the folks you gather now may not end up working on the project when you're ready to begin. However, they should be a reliable team that you trust to help you develop these initial concepts. After you've read through this chapter, you'll have a better idea of the kinds of people you might want to ask to assist you in these preliminary tasks.

5.4.2. Review the Existing Project Proposal

The existing project proposal, if one exists, may be short or quite lengthy. The first step is to review any and all project documentation that exists. Make sure you have all the information called out in the existing project proposal including attachments, exhibits, contracts, memos of understanding, and anything else mentioned in or needed by the project proposal document. If the proposal is missing any elements, especially those discussed throughout the remainder of this book, make sure you create them. Any missing element is a potential error waiting to happen, so make sure you have all the data you need to deliver a successful project. If you recall, it's been estimated that 50% to 75% of the total cost of any project is due to errors, rework, and omissions, so validating the project proposal at this point will save time and money down the road.

5.4.3. Validate the Project Information

Now that you've got all the information you need, you can validate the project proposal. There may be some instances where the project sponsor wants to get a project going very quickly to take advantage of favorable market conditions or to address a critical need. While you may have to do an abbreviated "power planning" process (purposely choosing to shorten, condense, or skip steps in the interest of time), you should be aware of the risks of doing so. The risks include errors, omissions and incorrect data and/or assumptions that cause rework, delays, or quality problems later on. You'll have to decide how much planning is appropriate to the situation and keep in mind there are often political factors that must be taken into consideration as well. Not all projects are large and complex, nor do they all require a lot of planning and documentation. Later in this book, we'll discuss the concept of precision, which includes how much planning and effort should go into a project plan. If you are working on a short, two week project that involves three people and $8,000, far less planning is needed than for a massive project involving hundreds of hours and thousands (or millions) of dollars.

One important note here is that some companies run in "emergency" mode all the time. This would cause the average IT project manager to skip the project planning steps and jump right into the project managing steps. Again, there may be isolated instances when this is ok (or required), but don't get caught in the trap of feeling there is no time to plan. Planning now will result in consistently better, more predictable project results. If you're assigned as the project manager to a project already underway, it would be well worth your time to go back through the project, using the steps we'll detail in this and subsequent chapters, to validate your project. You may discover new data that helps the project succeed or that simply keeps you from being the captain of a sinking ship.

Enterprise 128 …
No Time For Planning?

Have you ever noticed that few people (or companies) think they have enough time to plan, but they always find time to correct mistakes, errors and omissions once the project is underway?

Take time to plan the project using the steps described in this book. Otherwise, you'll be wasting time and money when you do go back and fix the problems that occurred due to lack of planning. It is a proven fact that the amount of time you spend planning will pay for itself by reducing errors and rework later in the project, when you'll somehow have to find time to make needed corrections.





How to Cheat at IT Project Management
How to Cheat at IT Project Management
ISBN: 1597490377
EAN: 2147483647
Year: 2005
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net