Section 10.7. Summary

10.7. Summary

After you've defined, organized, and planned your project, you're ready to begin project work. The process of implementing your project involves starting work, monitoring progress, managing variance, and reporting status. These are iterative processes that continue until all project work is complete. For the most part, these activities are described in your project processes and procedures at the outset of project planning.

Project status can be monitored through the use of team meetings, status reports, and issues logs. Throughout this process you should capture lessons learned so you and the team can learn in real time. When problems do arise, they can be handled through standard project processes including team meetings, status reports, issues logs, bug tracking and escalations. Progress can be stated as percent complete, but it's important to use the percent complete of tasks, time, and cost in order to get a balanced view of progress.

Variances to the plan will occur as things move and shift. Managing these changes is one of the jobs of the IT project manager. Variances can be measured by percent complete versus expected at any given point in the task. At the halfway point in any task, the time and cost should be roughly 50% of total. Significant variances (over and under) should be investigated thoroughly.

When change occurs in a project, you have four possible responses: do nothing, repair the problem, revise the plan, or terminate the project. If change occurs to your schedule, you can choose to crash or fast track your schedule. Both techniques deal with schedule problems, but both introduce their own unique set of risks to the project. Each method should be evaluated prior to implementing. Changes to budgets also can occur and there are four sources of budget changes: flawed estimates, anomalies, permanent variance, and minor variance. Each has a different impact on your project and some may end up causing the project to be terminated. The reserve created for schedule or budget can be used for minor variances, but larger variances may have to be treated as more separate, discrete elements depending on their size and impact to the project.

Change to the scope is the most dangerous because it often creeps in unnoticed (hence the term scope creep). Managing the scope is another important job of the IT PM. Scope is defined through the Work Breakdown Structure and the task details, so keeping an eye on changes in this area will help avoid scope creep. Define and enforce change control procedures so that work is not added to your project without the team knowing and accepting these changes. Remember that increases in scope almost always result in a change to the schedule, budget, or quality.

Change requests are prompted from four primary sources of change: errors/omissions, risk response (implementing your "Plan B"), value-added, or external events. All change is a risk to your project, so it's important to evaluate the impact of change on project parameters (scope, time, cost, quality) as well as the impact on the functional and technical requirements.

During your planning phase, you should have worked with the project team to identify and plan for risks (based on likelihood of occurrence and impact on the project). During the work phase, you may run into those risks or other unexpected risks. When these problems occur, you have four possible responses: workaround, corrective action, change request, or risk response. Since each of these involves some change to the project, each should be evaluated before being implemented to avoid introducing secondary risks and new problems.

Managing the project team can be a challenge for first-time IT project managers and for those who would rather talk to computers than to human beings. Honing your people management skills will help you become a better IT project manager. Keep your manager, project sponsor, or HR department in mind when looking for assistance in dealing with team personnel issues. The success of the project is dependent upon the skills, talents, and motivation of the IT project team. If performance or quality issues exist, look for the root cause. Determine if the person has the skills, time, and resources to properly do the job. If the problem is one of attitude or motivation, you face a different challenge, but you must deal with the issue if you want your project to succeed. Keys to managing your team well are to delegate, share information, and provide the authority commensurate with the responsibility so team members can effectively do what's asked of them. Deal with team communication, performance, or interpersonal issues quickly because they will only flare up later and put your project at risk.

When you and the team have completed all project work, you're ready to announce project completion, deliver it to your user/customer and begin the project close-out phase. We'll discuss project close-out in Chapter 12 after discussing a few more technical ways to measure project progress and ways to troubleshoot common project problems in Chapter 11.