6.3 PROGRESS MONITORS

 < Day Day Up > 



6.3 PROGRESS MONITORS

How you measure the risk factors is an area of great interest to those in the metrics discipline but what it really comes down to is setting in place monitors with which you are comfortable. In many cases these will be subjective and you should remember that there is nothing intrinsically wrong with subjective measures. Certainly, the last time I purchased a car, a not insignificant personal investment, the only hard measure involved was that of price. The rest of the decision was purely subjective.

Looking at a couple of the risk factors I have claimed are fairly common across projects you might decide to measure morale by having your project team members fill in a questionnaire each month. When I first ran this as an experiment to see if it was feasible to collect soft or environmental data in this way I was pleasantly surprised that I was able to detect changes in morale across the team by asking about things like promotion prospects and training. I was also surprised at how happy the team members were to take part in the exercise. They felt it gave them a chance to point out the good things and the bad things in their working environment and, hopefully, to have an effect on that environment.

Complexity could be handled in much the same way. You could ask each of your designers to simply state if they think recognized complexity is now less than it was last month, the same, or greater than last month. Add in a couple more options to give them more scope and if 50% or more of them say it has grown you could have a problem. Watch out for creeping growth. If you get a small increase each month you can end up with a big increase over the life of the project.

Wherever possible it is best to use hard measures and this is certainly possible for some risk factors. The occurrence of many risk factors shows itself in a reduction in progress. Monitoring progress against plan is one of the most effective ways of controlling a project — especially when this is tied into an effective Risk Management strategy.

There are a number of ways that progress can be monitored. If your milestones operate at a fairly low level (normally this means that milestones are being passed with no more than a fortnight's gap on each major plan stream), then milestone monitoring can be an effective progress check. All you need do is monitor the milestones that should be achieved during a particular time slice against what has actually been achieved.

Another, somewhat more complicated, approach is to use Earned Value Analysis. This is well described in most project planning books but the basic principle is that by the time it is delivered a project will have spent a certain amount, say in terms of engineering hours. At a particular point in time you compare what has been spent to what should have been spent, also building in how much is still to be spent. The formulas get a bit messy but most project planning tools that allow for the recording of actual effort spent will calculate Earned Value for you. Earned Value is fine as far as it goes but it does assume that the plan is realistic. This is not always the case.

An approach I particularly like is known by the inauspicious name of the RAG Technique. RAG stands for RED, AMBER and GREEN which gives a good clue as to how this approach works. The principle is one of project classification and one of the major benefits of the approach is that it allows managers to concentrate their efforts where they will do most good. The technique works where there are a number of projects running simultaneously or where a large project can be subdivided into smaller elements or sub-projects.

Each project should have a project manager and this individual is tasked with filling in a questionnaire each month, or perhaps fortnightly. The questionnaire can be as long and complex as it need be but remember that someone has to spend time filling it in. Personally I believe ten or twelve questions should be ample for most environments.

Question and answer pairs are of the multiple choice variety and the responses are run through a very simple scoring algorithm. If for example you had a question that related to resource usage things might look like this:

  • Q: Compared to planned budget expenditure for this project, how much has actually been spent to date?

    > 20% Underspend

    Scores 5

    < 10% Underspend

    3

    As planned

    0

    < 10% Overspend

    1

    > 20% Overspend

    5

and the score is added to a running total.

When you have a final score you simply use this to classify each project as being at status GREEN, AMBER or RED.

The nice touches in this technique are that GREEN projects are allowed to go on their merry way because, after all, everything seems to be fine with them. They are hitting milestones on time, spending what they said they would and the project manager is happy. Why should a more senior manager waste time formally reviewing a project that is running well? Of course, that manager should make sure that the truth is being told.

AMBER projects do not have serious problems but should be watched. The easiest way to do this is to have a rule that says projects at AMBER for two months out of three will go to RED status. Again, the system can be abused, but what system can't?

RED projects get special attention. Where this approach works is when the project manager whose project has gone RED is not hit over the knuckles like a naughty boy. The chances are that the problems are totally beyond his or her control as they may stem from another department or they may be the fault of, for example, more senior managers. Having recognized that a problem exists the thing to do is to contain and remove it, not to make someone feel bad. To do this the project manager, his manager and someone from the project control office who administers the RAG system should get together. Of course, if someone continually has projects that perform poorly and the fault seems to lie with them then that is a particular type of senior management failure: the wrong person may have been put in the wrong job.

You should also note that a project manager should always be given the option of asking for the project to be made red even if everything currently looks okay. Typically, RAG questions relate to progress and could include the following examples:

  • What percentage of milestones due have been achieved?

  • Are any deliverables due from external sources behind schedule?

British Telecomm is possibly the largest private business operating within the UK and it would be foolish to say that RAG is used in every part of the organization but they have presented did some interesting claims for the success of RAG including dramatic reductions in re-plans and late deliveries.

One of the best things about RAG is its simplicity. It costs little to administer and can really give you a handle on project control.



 < 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