Project Management Book

...chapter 9 continued

Health check - benefits

Do project managers ever lie about project status? Of course not. But occasionally they do forget to mention certain things and inadvertently leave the wrong impression in the sponsor's mind. However, if the project manager knows a health check is coming in 2 months time he is more likely to report the problems himself today: if he hides them and the review flushes them out the sponsor is going to ask: "why didn't you tell me...?" Health checks should reassure the sponsor that the project really is as healthy as the project manager says it is.

In the couple of weeks before a health check the project manager will often get around to dealing with things he has been putting off. Indeed, it may well be that half of the corrective actions get taken before the review team even shows up.

Even if you are your company's best and most experienced project manager you will learn something by reviewing another project. You'll spot some really elegant technique they are using. And what will you do? Steal it and use it on your project.

And sometimes another member of the review team will highlight a problem with the project being reviewed and you will realise you have exactly the same problem and you'll nod sagely and then scurry back to fix your own project.

Inviting a novice team leader to sit in as a 4th member of a review team provides a great learning experience. He is forced to see in great detail how all these project management things are done in reality.

Health checks are a good way of spreading best practice and good ideas across an organisation.

Bottom line, though: health checks save money. Sometimes a health check brings to light a problem that would otherwise have lain dormant. The sooner you spot them the cheaper it tends to be to fix them.

Health check - project managers' reactions

The project manager should be obliged to write a comment in the report about how useful the review was to him. One hopes they might write things like this:

• encouraging to see real problems identified
• health check helped me focus on problems in estimating and controlling
• very sensible recommendations, I would like to express my appreciation

But that isn't quite always how they react. Occasionally there is a dispute. The review team says it's C or D the project manager says the project's fine and should be A or B. Who would you put your money on? Back the review team. Sometimes the project manager can't see the wood for the trees and sometimes they are in psychological denial - they won't even admit to themselves it's a mess.

Review teams are not infallible, they don't always spot all of the problems. Project support need to develop a checklist of things to look at, questions to ask, etc. Where a project fails despite recently scoring an A or B rating, project support do need to take a look to establish why the project went wrong, whether warning signs could in fact have been picked up at the health check and if so to update their processes so they don't miss similar things in future health checks.

Compliance monitoring

This is something quite different from health checks or informal reviews. Compliance monitoring involves spending half an hour with the project manager making sure he is adhering to the company's project management rules:

• Have you got a signed off PDD? Yes? Tick.
• Have you got a signed authorisation to be spending this stage's budget? Yes? Tick.
• Have you got a stage agreement signed by resource providers? Yes? Tick.
• Have you got a risk register? Yes? Tick.

This is largely a waste of time so project support should only do these compliance checks very occasionally if they believe too much backsliding is creeping in. This type of compliance check tells you next to nothing about the project's health.

Project support's attitude may be summed up thus:

• If you're breaking all the rules and going to succeed that's interesting and we'd like to know how you're doing it.
• If you're following all the rules and failing that's a shame and we'll come and help you.
• If you're breaking all the rules and going to fail you're in deep doo-doo.

Safest bet: follow the rules and succeed.

Technical Reviews

The health checks described above do not, by and large, look at work products to gauge their correctness (they look at whether the team is doing the things they planned to do to ensure their work products are correct).

Technical reviews do look at a project's work products. For example, in a leading edge IT project, a technical review team may spend a week or more examining in detail the system design to assess whether it will work, will give the desired performance, etc. Whereas health checks are conducted by people with project management skills, the technical review team will be technical experts. However, a technical review finding that says: "The XLQ to TDQ link object will not allow transference of TIF image data" will have non-technical senior managers' eyes glazing over. They will have no idea whether individual technical review findings are showstoppers or minor suggestions. So, for technical reviews, the review team rate each finding A, B, C or D as well as giving an overall rating.

Other things project support should do

• Collect, collate and disseminate lessons learned (this will be covered in the stage and project end chapter).
• Write, own, update, publicise, explain and help projects intelligently adhere to the company's project management rules and guidelines.
• Organise project management training.
• Run a project management forum. A quarterly open house meeting at which project support, project managers and team leaders share experience. For example: "we're finding in health checks that this... is a very common problem, this is how you can avoid similar problems..."
• Maintain an intranet forum for project management hints, tips, rules of thumb, etc.
• Write an annual report to senior management summarising how projects went over the past year. For example: "Over the past 12 months 63 projects had this problem... Board of Directors, you need to take this action... otherwise it'll happen 63 times next year..." Tell senior managers what needs to be done to make the company a more project-friendly environment.
• Be a free consultancy resource. Arguably this is the most important role of all. See the next paragraph.

Who fills the project support role

Who are these paragons who inhabit project support?

The most junior team leader must feel able to consult project support and ask the dumb questions they may not want to ask their boss. They won't do this if the project support person is too senior.

People in project support must be seen to have been there, seen it and done it: they must have been involved in projects and so have that credibility.

They do not need to be experts in everything, but they do need to know who the experts are so they can point enquiries in the right direction. "You want to know the best way of reporting system testing stats in a games development project? Have a chat with Lara Homestead, she's the expert on that."

Project support must be seen to be 'us', part of our family. So, if 'we' are an IT shop, project support must reside in IT and be staffed by IT people. If 'we' are marketing, project support is in marketing and staffed by marketing people.

In some companies project support begins life within IT, and they own the rules that govern how projects are run. But when senior business managers begin to appreciate that projects are not IT things but are the way the company makes it future, they decide that project support should move and report to someone other than the IT Director and be staffed by people with relevant project skills whether they be from IT, marketing or wherever.

Project support should not be part of an Internal Audit function. The "when the auditors come and see you answer honestly using only the words yes or no but don't volunteer any information" mentality will not result in project health checks that add value. Internal Audit might perhaps audit the processes used by project support to satisfy themselves that the project community has in place appropriate self-policing procedures.

The best people to have in the project support role are team leaders who have been personally involved in major disaster projects: they know the problems, they know the warning signs (which were probably ignored on their project) and they know the pain. And they should be naturally helpful people who want to help their fellow human beings avoid similar pain.

As a rule of thumb there should be one person in project support for every hundred people involved in projects. In a large company with two thousand people in projects perhaps project support will be 15 strong comprising a couple of heavyweights to lead health checks of major projects through to several team leaders who are assigned to project support for eighteen months or so. In a small company with only 20 people doing projects one of the PMs may be nominated to spend, say, one day a week doing some of these project support things but obviously much less formally.

Project support do not assist in the day to day running of projects. Project administration and reporting is the job of the project manager and his project team. And do not populate project support with methodology theologians.

Reviewing project plans and conducting health checks requires judgement, the ability to offer useful advice and the ability to formulate and present controversial conclusions. This can be difficult. Compliance monitoring - checking projects have the right bits of paper in place - is easy. But plan reviews and health checks add value.

When the first health checks are done in a company it is possible that they are almost all Ds. Not because all projects will fail but because project planning and tracking is so poor the review team conclude they have no idea whether the project will succeed or not and they conclude the project manager hasn't either. A better way to improve project governance is to embark upon an education programme to teach project managers and team leaders how to manage projects (don't send them on courses that teach them how to pass a methodology exam), write a starter set of in-house project management rules and guidelines (which takes days not months), put in place start-of-stage plan reviews, and then start doing formal health checks.

Project support must be empowered by senior management - Directors, sponsors, etc - to conduct reviews on their behalf.

The Appendix contains a sample project support job description.

In conclusion

Project support is there to:

• Help project managers
• Reassure sponsors of large projects
• Help identify problems early - ideally during project planning
• Make it more likely that more projects will succeed

Please click here to go to Project Management Book Chapter 10

Privacy Policy and Cookies