9.1. Introduction Up to this point, we've done a lot of work to define the project clearly. If you've done all of this work diligently, your project is now resting on a very solid foundation. If you've skipped any steps, take time to go back and go through them to ensure your project doesn't have any gaping holes before we get into the detailed project planning in this chapter. The only way your project can complete successfully is if it starts off successfully. In this chapter, you'll learn how to break the project down into manageable components so that you can not only plan the work, but you can develop a more realistic schedule and budget. By breaking the project down into its components, you can also verify your project scope and take this opportunity to make sure you don't have any missing elements. As you develop these more detailed plans, you may come across new project risks that you were not previously aware of. As with other steps, some of these risks may be so significant that your project sponsor chooses to hold or terminate the project. More often though, the risks you identify give you the opportunity to figure out what you and the team can do to avoid these risks or what you'll do if these risks occur. Many IT project teams come in with average to failing scores when it comes to project communication, so we'll end this chapter with a review of the communication plans you should have in place and how you should be progressing on those. This will help ensure you communicate appropriately (effectively and timely) with the necessary people to help make your project not only be successful, but to help it be perceived as successful as well. As in other chapters, we will start with an overview of the IT project management process to keep track of where we are, as shown in Figure 9.1 Notice this is the final step before actually initiating the project, so you want to ensure you've got everything set before you pull the trigger. Figure 9-1. IT Project Management Process Overview 
In this chapter, we'll introduce many new concepts and related terminology, so let's define some of the language we'll be using. Completion Criteria The standards or measurements used to define when a task (work package) is successfully completed. Critical Path The longest, least flexible path through the project. Any delay to tasks on the critical path put the entire project at risk of delay. Critical Path Method (CPM) A network technique using one time estimate for the calculation of the duration of the critical path. Earned Value The value of work completed based on the budget for that work. EV = % Complete * Budget At Completion (BAC). Earned Value Management (EVM) Integrates scope, schedule, and cost to give an objective, scalable, point-in-time assessment of the progress of the project. It calculates performance against plan and can be used to evaluate the project and identify serious problems earlier than other methods might. Entry/Exit Criteria The standards or measurements used to set the conditions or circumstances required to enter into or exit from a particular milestone or work phase. Mitigation Strategy A plan devised to avoid or reduce identified risks to the project. Network Diagram A graphical representation of the workflow of the project along with dependencies and constraints. Program Evaluation and Review Technique (PERT) A network technique using three time estimates for the calculation of the duration of the project. Each task has three duration estimates: best (B), worst (W), and most likely (ML).These estimates are used to determine the expected time using the formula: Expected Duration = (B + (4 * ML) + W)/6. Percent Complete An estimate of the amount of work completed compared to the total amount of work required. Precedence Diagramming Method (PDM) A method of creating a network diagram (mapping project work tasks) to indicate dependencies, constraints, and sequencing. Some variation of PDM is used in most project management software programs. Slack (also called Float) The amount of time an activity can be delayed without delaying the rest of the project. Task The term task and work package are used interchangeably. A task is defined as the smallest, most manageable discrete unit of work. Some organizations define tasks as units of the work package. Triggers The specific set of circumstances that must occur for you to put your alternative plans into action as part of your project risk mitigation strategy. Work Breakdown Structure (WBS) The hierarchical breakdown of the work in a project that starts with the highest-level deliverables and breaks them down into small, manageable work components (tasks or work packages). Work Package The smallest, most manageable, discrete unit of work within the WBS.
Enterprise 128 …
Things are More Likely to go Wrong… | Here's another project management saying: "Things are more likely to accidentally go wrong than to accidentally go right." It's like a perfect golf shot or a perfect hit in baseballit seems we can hit a horrible shot over and over exactly the same way, but when we hit that one absolutely perfect shot, we can't seem to repeat it (unless, of course, we're in the ranks of Tiger Woods, Annika Sorenstam, Derek Jeter, or A-Rod). Strange, but true. In IT project management, things will go wrong, that's a fact. The more time you spend in the planning stage (to a point), the more likely you are to see some of the bumps along the road and avoid them. You won't be able to avoid every single problem, but this phasethe planning phaseis often skipped or abbreviated and that means lackluster results for some projects and abject failure for others. This is time well spent and it doesn't have to take an inordinate amount of time. In fact, the amount of time you spend in the planning stage should be appropriate to the complexity, scope, and importance of the project. That said, don't short-change this step. It will improve your results substantially. |
Now that we've defined a few terms, let's turn to the process we'll discuss in this chapter. You can see in Figure 9.2 the inputs, actions, and outputs from this step in the IT project planning process. We'll discuss each of these briefly here and then delve into more detail in the remainder of the chapter. Figure 9-2. Inputs, Actions, and Outputs for Project Planning Step 
INPUT The inputs to this step in the IT project management process are twofold. First, the initial project plan must be used in order to ensure that the planning steps you take meet the project requirements including scope, time, cost, quality, and functional and technical requirements. The other input is your project team, meaning that at this point you should have identified and created your project team. While members of the project team may change over the course of the project, your initial team should be ready to go to help you with the planning stage of this IT project. ACTION The action is to perform the IT project planning processes discussed in this chapter. These actions will help you create a detailed project plan from which you can develop a much more realistic and manageable schedule and from which you can develop your project's final target budget. OUTPUT The output of this step is an updated and detailed project plan that includes your initial target schedule and budget. In some cases, the schedule and budget resulting from this process will be your final targets. In other cases, further refinement may be needed. CHECKPOINT The detailed project plan, schedule, and budget should be reviewed with the project sponsor at this point to make sure you and the project sponsor are in agreement. Any areas of confusion, disagreement, or contention should be resolved before moving forward. If there are any known problems in the project plan at this point, they will only be magnified in the future, so they should be satisfactorily resolved now. If any modifications are made, the project plan should be reviewed briefly to ensure other elements aren't impacted by the change. DECISION POINT If the project plan is approved, you'll be ready to actually launch the project itself. If the project plan is not approved, you may need to make revisions to the plan or be prepared to terminate the project (or perhaps place it on hold). NEXT STEP If you have an approved detailed project plan, schedule, and budget, you're ready to begin project work. Once project work begins, your job is to manage the project and keep in on track and we'll discuss those tasks in Chapter 10.
|
