When I have been in the position of monitoring a number of projects there is something called the (Harmer) Safety Index that I use to decide which projects are most dangerous (ie most likely to be challenged).
Its a pretty simple idea, give each of the following areas a ranking of low/med/high and then focus upon the projects that have the lowest overall ranking.
- Experience of the team - this is obvious, the more experienced the team in the problem domain and tools being used the safer the project.
- Appropriateness of methodology - if the methodology being used by the team doesn't fit the project then things are more likely to go off track. For example, if a two people for three week project is using a heavy-weight methodology with multiple sign-offs, etc. then they will be placing their project at risk. Similarly, if a two year fixed-price project with a customer who is afraid to make decisions uses XP then again project safety is compromised.
- Constraints of the tools - some tools allow almost anything to be build (think Java, C++, etc). Others allow only certain types of projects to be built (Excel, Cold Fusion, vertical application customisations, etc). If the tool being used restricts the types of applications that can be built (and the needs of the project are met by the tools) then safey of the project is increased. I’ll repeat that - the more constrained a tool the safer a project is.
- Skill of the project manager - this is a vital measure. I believe that almost all project failures are caused by poor project management. This is through missing important warnings signs, being incapable of leading the project towards completion or being unable to gain the resources needed by the project.
- Discoverability of requirements - its okay for a projects requirements to be unknown at the start of a project. What is important is how easy it is for the requirements to be discovered. Compare a project where there is a customer who is easy to get along with and who has a list of things she wants fixed with a project with nine customers from three different companies who change their mind constantly. Obviously the project with requirements that are more easily discovered will be safer.
I know these are simply potential risks and can fit into a risk management process. I don’t know many risk management processes that actually work but if you have one that does, then check that these potential risks are considered. Regardless, these make great headings on a project brief/progress report or good discussion points for project managers to discuss with their own “bosses” or project sponsors.