Chapter 6: Project Control

 < Day Day Up > 



OVERVIEW

start sidebar
Key Points:

Using measurement based techniques to help manage projects

Metrics to help assess feasibility

Metrics to help manage risk

Data based progress tracking

end sidebar

The final chapter of this section looks at the topic of project control. This is often seen as being outside of the scope of a metrics initiative or it may not even be considered during the requirements analysis stage of implementing a metrics program.

If the reason for this is that the organization has projects under control then I have no argument with the position that this is not part of the remit for a metrics program. If, however, the organization has a requirement for project control that is not being addressed by another part of that organization then it makes sense to me to put project control within the program's terms of reference. I believe that I can justify this position with one sentence: Software Metrics initiatives are there to improve the quality of products and PROCESSES, and if that means enhancing the project control mechanisms then so be it. This concern merely demonstrates the difficulties we face in defining clear functional boundaries for "metrics."

And talking of boundaries I should define what I mean by project control. Consider this situation: you receive a customer's statement of requirements — the wish list — and you carry out your initial estimation and submit the bid. Notice that you still have not managed to convince the customer or your own organization that you should actually bid for the requirements definition phase first but you are already working on it! Now, despite all expectations to the contrary you get the contract.

What happens next? Usually a whole group of people start beavering away on that requirements definition. Hopefully you also get some sort of a project plan together with the obligatory milestones. Oh yes, this is a "Quality Organization" now because the top man said so a couple of months ago so we had better have a quality plan. OK, that has got the overheads sorted out now let's get those people cutting code! Let's just hope things go better than last time. Remember what happened, two weeks before delivery and we had to tell the customer there was a six month delay. That was embarrassing. Especially as we had spent two years, elapsed, on the project!

The chances are that you do not have a situation that is as bad as that, do you? Let us run a slightly different scenario: We have won the bid and we have got first-cut project plans which we will refine after we get more information from the requirements definition stage. The first-cut plans have been through a feasibility check and the refined plans will also be checked in this way. We have also pulled in the standard quality plan for this class of project and made any modifications we feel necessary. Of course, these have been checked and agreed to by our project control people and, perhaps, the customer. After all, we do talk to the customer more these days since the quality initiative made us realize we had such a thing as a customer. We have also put together our risk management plans and prepared contingency plans and, of course, all of the team leaders know how progress is going to be monitored across the life of the project. Now we have increased overheads, or have we simply increased the chances of success, and we have also increased the probability of delivering on time.

This is a scenario in which project control is operating. Looking at the components that go to make up the picture, we see the following. There is project planning and feasibility checking of those plans, quality plans, risk management and progress checking.

Project planning is a well established discipline and I do not intend to address it here. There are many good reference books that deal with work breakdown, scheduling, logical task linkage and critical path analysis, for example Project Management, a Managerial Approach by Meredith and Mantel (2003, John Wiley and Sons). Your own organization may well have standard approaches to these areas. There are also numerous commercially available project planning tools.

Quality planning is also an area that is relatively well established especially in organizations operating a Process Improvement policy. If not fully established, at least the concepts are well understood and I could do no better than to direct you to Humphrey (2) , and for the view taken from the software engineer's perspective to Humphrey (3) .

The areas I would like to discuss, quite briefly, because each is a subject in its own right, are feasibility checking, risk management and progress checking.

Before we go any further I would like to touch on the implementation of the techniques we are about to discuss because a common reaction is to throw ones hands up in horror at the additional costs implied. If your situation is that you operate with, effectively, one project at a time over long durations, typically between five and ten years, then these techniques are certainly applicable and justifiable. In fact, they are almost mandatory. However, this type of environment is very rare outside defense work.

More commonly, you will be operating in a mixed environment of maintenance, which includes enhancement, and development. New developments typically take no more than two years elapsed time or even much less but the majority of the available effort is spent enhancing existing products through new releases once or twice a year. Within your IT function you could easily have one hundred projects on the go at any one time.

You do not reinvent the wheel every time you start a new project. Standard approaches to feasibility checking, risk management and progress checking should be implemented and, after a bedding-in period, the deviations from these standard approaches should be minimal. Note that justifiable deviations should be allowed and are the responsibility of the project manager.



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

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