7.5 Checking Status Against the Project Plan

 < Day Day Up > 



7.5 Checking Status Against the Project Plan

Now that we have dispensed with most of the worst-case scenarios, it is time to look at the less challenging but important daily project management duties once implementation is under way. In reality, you should probably be tracking things before the actual build phase, particularly if the project is of the design-build nature or has other long, task-laden lead times.

Obviously, you reference the schedule as you monitor progress. Gantt chart programs have that nifty little "percent complete" feature that graphically depicts progress and can be used to automatically adjust completion dates. The question you need to ask yourself is whether this feature has value other than satisfying curiosity or providing hypothetical schedule changes. Just because dates start slipping does not mean that you can push everything back proportionately. If you use "must start by" or "must end by" constraints, you can control this. Also, you can view the implications of slippages on downstream activities, resource requirements, and the likelihood that final tasks have far less time to complete if you are having a tough time getting the show on the road.

The problem I have with this is that it is more like the dull sort of video game you would expect process-oriented project managers to play. The fact of the matter is that you need to take more care of your precious time than managing it by blocks of time as represented in project plan software that uses percentage completion as a status establishment tool. I am never quite sure how that algorithm translates into effective project management, because very few information technology (IT) project tasks are repetitive such as installing windows in a skyscraper or attaching bumpers to new cars. In other words, our kind of progress does not necessarily translate effectively into arithmetic chunks. Exhibit 5 displays a common example; you can see where the holes may exist in the percent completion of status methodology.

Exhibit 5: Using Percent Complete as a Status Monitoring Tool

start example

click to expand

end example

This illustration suggests that the router project is 77 percent complete - a status shown to the left in chart form and to the right with graphics. If you run your finger down the table to the first incomplete task, it shows the test task as one-fourth done. That would be great if that task consisted of 12 subtasks of equal merit or value, meaning 3 of them have apparently been successfully concluded. The next task, change control, shows as 0 percent complete, even though the start date coincided with the project start date.

My concern with the approach revolves around the weight of completed and incomplete tasks. If the project is to move a pile of dirt, and if ten dump truck loads are assumed as the task, including three that have been moved, then it is probably okay to call that project 30 percent done. When it comes to testing routers or doing change controls on the network, I have experienced far too many nonquantifiable tasks and bureaucratic or technology hassles that defy quantification, or that necessarily track reliably against the calendar. Therefore, my review of the illustration is that the routers are installed and being tested with no known issues to date; however, I would go looking for that team lead and find out the status of the change control and documentation processes. If they really are at 0 percent, I smell big trouble coming.

It is not that I am opposed to asking someone if they are halfway done, other than to wonder how to define the midpoint of most IT project deliverables. To me, it is far more effective to get periodic word pictures from team leads and distill them into a few terse words that reference project impact in terms of status. Normally, these observations will be binary. That is to say, you want to report that progress toward Milestone Z is on track, or that progress is lagging behind schedule with the possible impact of delaying a downstream event, including project completion. This requires some intuition, but more important, having the kind of relationships with team leads that allows for the exchange of relevant information. In a perfect world, these folks are at least as motivated as you are to meet the schedule, and should be able to give you honest assessments as to their performance against all targets, including completeness, quality, compliance with standards and requirements, and, of course, the project calendar.

Your status should never be ambivalent. If you cannot make a positive or negative pronouncement, acknowledge that status of a certain component needs further investigation or evaluation. Provide a follow-up date along with this admission, and stick to it. This approach has many names, two of which are "truth telling" and "managing expectation." Hopefully, neither phrase requires further elucidation.

The next two sections illustrate what is being said here.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net