Brief tip 7: Choose your checkpoints

In my current job at PA, we have checkpoints, forms and procedures to ensure quality and avoid taking too much risk. That is all very fine if you have the machinery to handle that, as is the case with PA. But what if you don’t? I think you still need some sort of checkpoints (often commercially focused), even when you operate using agile methods.

I’d like to share with you what we ended up with when selecting some checkpoints for our projects at Inspera and hope you will find it useful. These are, more or less, the mandatory checkpoints we ended up with:

• Starting work on a proposal
• Delivering a proposal
• Project initiation/kick-off
• Periodical reporting of progress and budgets (here it was monthly, YMMV)
• Project sign-off, with a simple client satisfaction survey and handover to maintenance

What if you are not ready even for this level of formalism? If I should keep just two checkpoints, I think I’d go for proposal delivery (Who approves this in your company? Rules of thumbs for estimate breakdowns? Have cross-project coordination of resources been taken into account?) and of course sign-off. This would probably be in a very small environment where surveillance of risk and project status would be done rather hands on by the general manager anyway.

I guess one wording of this tip could be:

Establish checkpoints that you follow in each of your projects, even if operating in an agile way

“Even in an agile way” might sound strange, but while the almost automatic checkpoint built into many agile processes (such as the sprint review) can be combined with commercial ones, that does not happen automatically.

That was my tip #7, written at Bremen airport in Germany - traveling to Belgium this weekend with my wife who currently works in the Netherlands. If you don’t agree or have something to add, please leave a comment.

Contract templates as project placebo

There was recently an article in the Norwegian (and Norwegian language) publication Computerworld claiming that the legal framework, which was based on a template from the construction business, had helped making a large IT project successful. I wrote a response to this, together with colleague Jakob Markussen, that you can read here (Norwegian).

We put forward that project management techniques including risk management, well-defined processes, iterative development, and last but not least the collaboration and communication is more important than the legal framework template that is chosen for a project. After all, as any of us that have struggled with contracts know, the real work is in the appendices – and if you don’t have to revisit details of the contract to resolve conflicts, even better!