Section 10.1. Introduction


10.1. Introduction

If you've followed all the steps leading up to this chapter, congratulations! Your IT project should be sitting on very solid ground. Your planning activities will help everyone stay focused during the project work phase and will help make sure the scope, time, cost, and quality requirements are met. In this chapter, we're going to discuss strategies for managing your IT project. We'll talk about getting the project started and how to monitor and control project progress. We will cover more detailed, technical tracking techniques separately in Chapter 11 along with common project problems and solutions. Where appropriate, we'll mention some of the detailed tracking techniques in this chapter and refer you to Chapter 11 for more detail.

Managing your IT project is much easier when you have a clear vision of the project, developed from your efforts at defining, organizing, and planning your project. In this chapter, we'll look at how to supervise the project elements, including monitoring project progress, managing change and risk, and managing your project team.

As with previous chapters, we'll begin by taking a look at where we are in the process, shown in Figure 10.1 It is clear that up until now, no actual project work has been done (yes, planning is work, but not the actual work of the project). Though there are a lot of planning activities, they all contribute to your ability to manage your project during this implementation and work phase. As your project moves forward, you'll begin to recognize and reap the rewards of your planning efforts.

Figure 10-1. IT Project Management Process Overview


We've already defined most of the project management terminology that we'll be using, but a few new terms will be introduced in this chapter including:

  • Baseline The starting point or basis against which progress or change is measured.

  • Deliverable A measurable, verifiable work product, result, or capability.

  • Project phase A phase is generally characterized by the delivery and approval of one or more project deliverables.

  • Variance The amount or percentage a result differs from the plan or baseline.

The input to this stage of the project is your final, approved project plan and the outcome of this stage is the completed project. The actions within this stage are shown in Figure 10.2

Figure 10-2. Inputs, Actions, and Outputs for Project Management Step


  1. INPUT The input to this step in the IT project management process is your final, approved project plan. This plan should include, at minimum, the problem, mission, solution, scope, functional and technical requirements, schedule, budget, Work Breakdown Structure, task details, project processes, and procedures. Sub-plans such as training, communications, testing, and operational transfer plans should also be included as needed. This is the plan from which you'll create your baseline and against which you'll measure progress.

  2. ACTION The process of actually managing the project work-in-progress is the phase we'll be discussing in detail in this chapter. It is during this phase that the plans are used so that work progresses according to plan. During this phase you must also work to ensure that your scope does not expand (scope creep), a common problem in this phase. Changes that occur to schedule, budget, or scope must be managed so final deliverables meet scope, time, cost, and quality metrics as well as functional and technical requirements. Technical project tracking processes are discussed in detail in Chapter 11.

  3. CHECKPOINT The first checkpoint is the project progress review by the project sponsor. This review will happen multiple times during this phase and each review should result in the project sponsor approving results of the work in progress, requiring changes to the project (which flows back into the project management process and/or may require changes in the project plan), or a decision to terminate the project. Terminating the project at this point would be a very serious decision, but there are times that projects are cancelled at this stage. Cancellation at this point might be due to changes in the company, the market, or the product, or due to dissatisfaction with project results to date (above budget, behind schedule, under quality, below scope). In some projects, these checkpoints might also be used with clients or users to ensure the project is progressing as expected. You can modify this process to include client or user approval, if needed.

  4. OUTPUT Assuming the project progresses as planned and the project sponsor approves project progress, the output is the final project deliverables. These may be delivered in stages or phases or they may be delivered all at once, depending on your IT project.

  5. DECISION POINT Once the project's final deliverables are complete, the project work is complete. The project's deliverables should be brought to the client/user for approval if this is part of your project plan (some projects will not have a discrete user acceptance process). If the client approves the deliverables, this is typically the point at which client billing for final project deliverables occurs and operational transfer plans are put into effect. If the deliverables are not accepted at this point, you will most likely have to go back to your project plan to determine where you went wrong and make modifications. You'll most likely need to go through the planning and managing steps again for at least part of your project. If you have worked with your clients/users as suggested throughout this book, there is a much higher chance the client will accept deliverables without problems. If the client does not accept deliverables, it should raise a flag in your organization and within your team because it indicates there was a communication problem at some point in the project planning stages. You should look closely as where and why the disconnect occurred. This is a serious problem that should be analyzed fully.

  6. NEXT STEP If the client accepts project deliverables, your next step is to close out the project. Closing out the project is discussed in Chapter 12.

The project management or implementation phase of our process includes reviewing the plan, starting project work, and managing, monitoring, and measuring project work, as shown in Figure 10.3 If any work varies from the plan, corrective action must be taken and work (new work due to correction or repair of earlier work) must be undertaken. The final project work includes delivering the project results to the end user or customer for approval and acceptance. Once project deliverables are accepted, responsibility is typically transferred to the user/customer or to another group responsible for installation or deployment, beta testing, or operations. Periodic reporting occurs during the Work, Monitor, and Correct steps shown in Figure 10.3, but final reporting is also required. Reporting includes status and progress reports from your team to you as well as progress reports from you to your project sponsor, user/client representative(s), executive team, and/or company. The diagram shown in Figure 10.3 can represent the entire implementation (work) cycle of a project or the implementation of one phase of a project. These steps are iterative and continue until all project work is completed, approved, and accepted. We'll discuss these elements in this chapter.

Figure 10-3. Implementation phase overview





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