In this section, a project planning framework will be introduced. This framework is part of the IT project methodology and provides the steps and processes necessary to develop the detailed project plan that will support the project's MOV. A project plan attempts to answer the following questions:
The project planning framework illustrated in Figure 3.5 consists of several steps and processes. We will now focus on each of these steps to show how the project's D-
schedule and budget are derived.
Project Name or Identification Project Stakeholders
• Phone numbers
• E-mail addresses Project Description
• Description of the challenge or opportunity
• Overview of the desired impact
Measurable Organizational Value (MOV)
• Statement or table format Project Scope
• What will be included in the scope of this project
• What will be considered outside the scope of this project Project Schedule Summary
• Project start date
• Project end date
• Timeline of project phases and milestones
• Project reviews and review dates Project Budget Summary
• Total project budget
• Budget broken down by phase
• Specific quality requirements Resources Required
• Resources to be provided
« Name of resource provider
• Date to be provided Assumptions and Risks
• Assumptions used to develop estimates
• Key risks, probability of occurrence, and impact
• Dependencies on other projects or areas within or outside the organization
• Assessment project's impact on the organization
• Outstanding issues Project Administration
• Communications plan
• Scope management plan
• Quality management plan
• Change management plan
• Human resources plan
• Implementation and project closure plan Acceptance and Approval
• Names, signatures, and dates for approval References
Terminology or Glossary Appendices (as required)
Figure S.4 Project Charter Template
The first step of the project planning framework entails finalizing the definition of and agreement on the project's measurable organizational value or MOV. Although an in-depth discussion of a project's MOV was provided in Chapter 2, it is important here to focus on a few salient points. First, it is important that the project's MOV be defined and agreed upon before proceeding to the other steps of the project planning framework. The project's MOV provides a direct link to the organization's strategic mission; however, as Figure 3.5 illustrates, a project's MOV links directly to the project plan. Therefore, a project's MOV acts as a bridge between the strategic mission and objectives of the organization and the project plans of individual projects it undertakes. The MOV guides many of the decisions related to scope, schedule, budget, and resources throughout the project's life cycle.
Define the Project's Scope
Once the project's MOV has been defined and agreed upon by the project's stakeholders, the next step of the project planning framework is to define the project's scope.
The Project Management Body of Knowledge defines scope as the product or services to be provided by the project and includes all of the project deliverables. One can think of scope as the work that needs to be completed in order to achieve the project's MOV. Project scope management is one of the nine project management knowledge areas and entails the following processes:
• Initiation—Once the project's MOV has been defined and agreed upon, the organization must make a commitment, in terms of time and resources, to define the project's scope in order to create the project plan.
• Planning—The project team must develop a written statement that defines the work to be included, as well as the work not to be included in the project plan. The scope statement will be used to guide future project-related decisions and to set stakeholder expectations.
• Definition—The project's scope must be organized into smaller and more manageable packages of work. These work packages will require resources and time to complete.
Verification—Once the project's scope has been defined, the project team and stakeholders must verify it to ensure that the work completed will in fact support the project in achieving its MOV.
Change Control—Controls must be in place to manage proposed changes to the project's scope. Scope changes can either move the project closer to its MOV or result in increased work that drains the project's budget and causes the project to exceed it scheduled deadline. Proper scope control procedures can ensure that the project stays on track.
Once the project's scope has been defined and verified, the work of the project can be organized into phases in order to deliver the project's product. Phases are logical stages. Although the IT project methodology defines five high-level phases, IT projects should be further divided into subphases that follow the phases of the systems development life cycle (SDLC).
Breaking a project down into phases and subphases reduces complexity and risk. In many cases it is easier to focus on the pieces instead of the whole; however, it is important to never lose sight of the big picture. More specifically, each phase should focus on providing at least one specific deliverable—that is, a tangible and verifiable piece of work. In addition, a milestone is a significant event or achievement that provides evidence that that deliverable has been completed and that the phase or sub-phase is complete.
Tasks—Sequence, Resources, and Time Estimates
Once the project is divided into phases, tasks are then identified. A task may be thought of as a specific activity or unit of work to be completed. Examples of some tasks in an IT project may be to interview a particular user, write a program, or test links in a Web page. When considering tasks, it is important to consider sequences, resources, and time.
Sequence Some tasks may be linear—i.e., have to be completed in a particular sequence—while others can be completed in parallel—i.e., at the same time. Performing parallel tasks often provides an opportunity to shorten the overall length of the project. For example, assume that a project has two tasks—A and B. Task A will require only one day to complete; task B requires two days. If these tasks are completed one after the other, the project will finish in three days. On the other hand, if these tasks are performed in parallel, the length of the project will be two days. In this case, the length of the project is determined by the time it takes to complete the longest task (i.e., task B). This simple example illustrates two important points: (1) A project is constrained by the longest tasks, and (2) any opportunity to perform tasks in parallel can shorten the project schedule.
Resources Resources on an IT project may include such things as technology, facilities (e.g., meeting rooms), and people. Tasks require resources, and there is a cost associated with using a resource. The use of a resource may be accounted for by using a per-use charge or on a prorated basis—that is, a charge for the time you use that resource. For example, a developer earns $50,000 a year and is assigned to work on a task that takes one day to complete. The cost of completing that particular task would be prorated as $ 191 (assuming an eight-hour, five-day work week).
Time It will take a resource a specific amount of time to complete a task. The longer it takes a resource to complete a specific task, however, the longer the project will take to finish and the more it will cost. For example, if we plan on assigning our developer who earns $50,000 a year to a task that takes two days, then we would estimate the cost of completing that task to be approximately $400. If the developer completes the task in one half the time, then the cost of doing that task will be about $200. Moreover, if the developer were then free to start the next task, our schedule would then be ahead by one day. Unfortunately, the reverse is true. If we thought the task would take two days to complete (at a cost of $400) and it took the developer three days to complete, the project would be one day behind schedule and $200 over budget. However, if two tasks could be performed in parallel, with our developer working on Task A (one day) and another $50,000/year-developer working on Task B (two days), then even if Task A takes two days, our project schedule would not be impacted—as long as the developer working on Task B completes the task within the estimated two days. While this parallel work may save our schedule, our budget will still be $200 over budget because task A took twice as long to complete. Understanding this relationship among tasks, resources, and time will be important when developing the project plan and even more important later if it is necessary to adjust the project plan in order to meet schedule or budget constraints.
Schedule and Budget—The Baseline Plan
The detailed project plan is an output of the project planning framework. Once the tasks are identified and their sequence, resources required, and time-to-complete estimated, it is a relatively simple step to determine the project's schedule and budget. All of this information can be entered into a project management software package that can determine the start and end dates for the project, as well as the final cost.
Once the project plan is complete, it should be reviewed by the project manager, the project sponsor, and the project team to make sure it is complete, accurate, and, most importantly, able to achieve the project's MOV. Generally, the project plan will go through several iterations as new information becomes known or if there are compromises with respect to scope, schedule, and budget. In addition, many of the details of the project plan are summarized in the project charter in order to provide a clearer picture as to how the plan will be carried out. Once the project plan is approved, it becomes the baseline plan that will serve as a benchmark to measure and gauge the project's progress. The project manager will use this baseline plan to compare the actual schedule to the estimated schedule and the actual costs to budgeted costs.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.