BUS605: Strategic Project Management

Once the project's scope has been defined and verified, the work of the project can be organized into phases and subphases in order to complete all of the project's deliverables. Phases are logical stages that organize the project work to reduce complexity and risk. In many cases, it is easier to focus and concentrate the project team's effort on the pieces instead of the whole; however, it is important to keep an eye on the big picture.

Each phase of the project should focus on providing at least one specific project deliverable - that is, a tangible and verifiable piece of work. Examples of deliverables include the business case, the project plan, and, most important, the project's product - the information system to be developed or software package to be implemented. In addition, a milestone is a significant event or achievement that provides evidence that the deliverable, phase, or subphase has been completed and accepted by the project sponsor.

Phases are largely determined by the project methodology and the approach chosen for carrying out the systems development life cycle (SDLC). As discussed in Chapter 1, the SDLC can be implemented by using a more structured approach, such as the waterfall method, or by using a more iterative approach. The selection of an approach to implement the SDLC is an important decision that will affect not only how the system will be developed and implemented, but to a large degree outline the phases, deliverables, and tasks defined in the project plan. The appropriate decision depends on how quickly the system needs to be delivered as well as how well defined and stable the requirements of the system will remain throughout the project life cycle. For example, the waterfall model would be more appropriate for a project where the requirements are well understood and complex, but it would not be appropriate for a project following the eXtreme project management paradigm. On the other hand, an iterative approach for carrying out the SDLC would be more appropriate where the project is characterized by uncertainty, change, and tight deadlines.

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 - that is, have to be completed in a particular sequence - while others can be completed in parallel - that is 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.