One of the key features of anything that qualifies as a project is that it has a definite start and a definite end. In ancient days, the Egyptians and Romans were the champions of project management. Their projects primarily consisted of construction of architectural structures that had no precedence to follow. And almost all of their projects were long haul projects. But still they carried out those projects with acute precision and accuracy.
It would have been simple for them to achieve all that probably because they divided a whole project into many smaller projects and conducted on-going project reviews. Don’t you agree?
In software project management too, project managers should allot some time in their project schedules for reviews where they ask the following fundamental but important questions:
- What is the objective of the project?
- Have we allotted the best possible resources?
- Is this the best approach or does anyone have a better solution?
- Do we need to incorporate requirement change?
- Do we need to revise the project plan and schedule?
It is also recommended that the project managers get an “alligator” peer review done to catch any hidden alligators lurking to pounce at the end of a project. To get an alligator review done, it is advised that the project managers find a fellow project manager (reviewer) who can spend a day or two to review the project and is not afraid of giving a brutally honest feedback. It will then be up to the project manager to take a call on his peer’s review feedback.
Getting a peer review done can be really helpful. A peer review is usually an unbiased and a fresh perspective which can identify risks that you may have missed out and/or provision for any event that has already occurred but the results of which have not yet surfaced.
Experts advise that any project that is longer than a year should have more than one on-going review.
Post project reviews are more common. It is important for project managers and team members to take stock of things that went well and those that created bottlenecks at the end of a project. The project managers must make a list of ‘lessons learned’ and document it too. Broadly, some of the typical elements of a post project review are:
- To prepare a feedback mechanism for gathering the team’s response
- To identify things that went well
- To identify things that struggled and created bottlenecks
- To identify things that met with failure
- To compare requirement specifications with the end result and measure the deviation
Just like the post project review, on-going project reviews are highly recommended so that the same ‘lessons learned’ can be implemented within the same project to minimize project issues pertaining to:
- Software quality
- Delivery schedule
- Deviation from the requirements
- Overall impact on business
So much said and done for the projects which have a definite start and a definite end. But not all software projects may have a start and an end date. Many projects turn into long-term maintenance projects after the development stage is over. Such projects also need reviews at specific intervals so that the team members have a clear picture of what is expected of them at different stages. Reviews will help team members to put in their best performance.
I believe, unless reviews are done often, and ‘lessons learned’ are documented and conveyed properly, the complete process of doing a project review is a waste of efforts. Whereas post project reviews are more common, on-going project reviews should be given high priority too. As Winston Churchill said, “All men make mistakes, but only wise men learn from their mistakes.” So, isn’t it better if the lessons learnt can be implemented earlier for avoiding project issues in a current project?
If you liked this post, and came to reading this far, you should follow us on Twitter or ‘Like’ us on Facebook. You can even subscribe to our blog and be the first to receive future write-ups like this one free. Also, you will help us by sharing our articles and spreading the word. We need you!