How to Cheat at IT Project Management

9.8. Finalizing the Project Plan

The time has come to finalize the project plan so work can begin. Though you've put a lot of work into your project up to this point, the actual tasks of the project have yet to begin. This is your last checkpoint before work on the project commences, so this is the point at which you finalize your project plan and take it to your project sponsor for approval. If you've been bringing recommended elements to your project sponsor along the way, your final project plan should be approved with few, if any, changes. Keep in mind, though, that things change constantly. It's possible that since your planning began, your company has a new strategic mission, a new customer, a new priority, and a new problem, and your IT project's priority fell from 2 to 200. It happens and there's not much you can do about it. Your project sponsor may be pleased with the plan but not ready to begin project work for a variety of reasons.

Your project sponsor may also want minor or major changes made to the project plan. If that's the case, you need to go back through the necessary steps to make the required changes. Remember, your job as IT project manager is to ensure the successful completion of the project. If you believe your project sponsor is requesting (or demanding) changes that put the project at risk, you need to say so. Sometimes the project sponsor may think his or her idea is marvelous when in reality, it would tank the project. While you need to be diplomatic in your delivery, it is very important that you voice these concerns now, before the project work is officially underway. If your project sponsor insists on changes you think create serious risks to the project, do the same type of risk assessment we discussed earlier in this chapter. Assess the likelihood and impact of the risk, develop alternatives (including the costs to the budget and schedule) and present this to your sponsor so he or she can make an informed decision about the requested changes. Don't just blindly agree to changespush back if you think you should. You were selected to be the IT project manager because someone (usually the project sponsor) thought you were the right person for the joband that includes using your skills, knowledge, and expertise to push back against ideas or changes that put your project at risk. Of course, some project sponsors just don't want to hear it, so push back to the degree necessary, but also know when to back down. You should note exceptions, risks, and other concerns about proposed changes then do your best to make them happen if that's the final decision.

If you refer back to Figure 9.2 at the opening of this chapter, you'll notice in Step 5 that there is the option to terminate the project. While it might seem like a big waste of time or a huge disappointment to cancel the project at this point, the upside is that you will have spared your company the time, cost, and sometimes embarrassment of embarking on a plan that shouldn't have gone forward for any one of a number of reasons. You might also be freed up to work on an even better project, especially if your planning efforts are recognized and appreciated. Though it may not be likely the project will be cancelled at this point, you just never know and if you're mentally prepared for that possibility, you'll handle it like a champ if it does occur.

You should also take a moment to go back through your project plan and make sure everything is set. Sometimes data is missing or some portion of the plan needs to be revised or reviewed prior to finalizing. This is also a good time to get your team together to finalize the project plan and to update or revise project procedures. Many of the procedures you defined at the outset may still be perfectly fine for the project, but you may have identified needs for changes to procedures or additional project processes needed to bring this project to a successful conclusion. Review processes and procedures in light of all the project detail you now have and make any needed adjustments before finalizing the plan and proceeding.

Once you've completed your review, the project plan should go to the project sponsor for approval. If modifications are necessary, make those changes and resubmit your plan with changes. In a perfect world, the approved plan is the final project plan where no further modifications are made except to the schedule once work is underway and perhaps to the budget. The project problem, mission, and solution statements should be set. The project's functional and technical requirements should be clearly spelled out and set. The project's quality plan, communication plan, and operational transfer plan (if applicable) should be set. The risks should be identified, alternatives should be created, and trigger points should be set. The project schedule and budget should be set as baselines so variances from these plans can be measured and managed. You should be ready to get started on your project's tasks. The final result, then, is an approved project plan, depicted in Figure 9.14 We use the word "final" rather looselyon one hand, you must set a baseline; on the other hand, many elements will change. So, we'll assume the "final" project plan is what is used to set the baseline and we'll agree that changes of one kind or another will more than likely occur.