So, what is the point of a project review?
It may be obvious, but I will say it all the same: the point of any review is to look forward by taking the time to look back.
And …
Don’t be fooled, any review that isn’t about the future is probably going to be about vanity and blame.
But …
Learning from your mistakes is important … for you.
What can You learn from Your Mistakes?
I’m a firm believer in learning from my mistakes … and I have to say that I’ve learned loads!
However, that’s not really the point, is it? Learning from your mistakes, individually or collectively, at the end of your project might well help you to learn and to improve your approach but learning from your mistakes can do nothing to benefit the project that’s just finished!
At best, reviewing your project at the end might provide some insight into the reasons for any apparent failures, which could then be avoided should you encounter the same circumstances in the future.
But remember, for your future project …
- the team is likely to be a different team
- the project is going to be a different project
- the timing is different and external circumstances will have changed
You have to ask yourself what you think you are going to learn that’s going to be of any use to the projects that you’ve not yet started. Most of the team that you would want to involve in the review process will be moving on to better things and are likely approaching the review process as a box-ticking exercise.
Also, an end-of-project project review is going to use project resources at a time when project resources have more than likely been used up in the final delivery push that a lot of projects are likely to demand. Whose budget?
When is the best time to review?
Waiting until your project has been done and dusted before spending your time on the review isn’t going to deliver a better project, so don’t spend too much time on a post-project project review … unless, of course, you are going to be assessed on the quality of your “Project Done” document.
It makes sense to make sure that every minute of the time you spend on your project is time well spent, and that means spending it where it can make the most difference.
Whether you have adopted the waterfall approach to development or you are treading the agile path, there comes a point when the proposition (or that little bit of the proposition you are currently looking at) has been defined and it’s pretty much now time to deliver.
Let me say at this point that the difference between waterfall and agile is really one of scale rather than application. All development processes need an element of thinking that precedes the element of doing – unless you’re approaching the development process as some sort of hackathon and you’re coding on the fly.
If you are using the waterfall model as your guide, then what you are essentially saying is that you will be doing all the thinking up front; if you have adopted the agile model, you are saying that you have a vision and you are approaching it one step at a time.
In both cases, and for all the cases in between, that time at the end of the thinking process, just before the doing process, is the right time for the reviewing process.
Reviewing the proposition – whatever it is – once the analysis has been done is the point at which the most benefit can be gained … because there is still time to change.
Establish your review process
Ultimately, “agile” and “waterfall” are just different approaches to delivering projects and they are primarily associated with the delivery of software-related projects. However, these are not the only projects you will encounter, there are other projects that do not pave the way to the development of software. The value of the review process is equally valid for these non-software developments.
There is no absolute right or wrong project approach and your project methodology should reflect the needs of your project rather than any pressure to conform to an approach that is more fashionable than functional.
In any approach, you need to understand what you’re going to be doing before you do it. There are numerous analysis and review methods to choose from and I make no recommendations here, other than for you to make sure that you do it whilst you can still make a difference.
If you are going to be spending time, effort and budget on a process to help deliver products and services, it makes sense to spend that time, effort and budget in a way that can yield results … now. Don’t leave the review processes to the end, try to review your product at the point of greatest impact: at the end of the thinking and before the doing.
Most project delivery methodologies you might buy into will sell you the value of a review process, but they tend to be designed for the benefit of the process rather than the product. They will tell you to review your processes at the end, learn from your mistakes and do better next time. This definitely isn’t without value but it isn’t the best approach if you are developing a one-off product. There is more value in picking up errors before they are built into the product than there is in reducing the risks associated with the next product!
What’s the Point?
The point is to make the most of what you’ve got and to use it to deliver the products and services that your customers and clients want … and to do it cost-effectively.
Don’t let people tell you that agile eliminates the risk. Whilst the agile delivery method does mean that you don’t need to understand everything before you get started, it does not mean that you don’t need to understand where you’re going.
And remember, no amount of skilled developers can fix the underlying logical problems if they’re there in the basic design.
It’s not like reviews aren’t expected, it’s more about shifting the timing. Instead of think-do-review, make it a point to think-review-do, no extra cost, no extra effort but a whole load of potential improvement.
You can’t spend the same shilling twice and you can’t revisit that time you should have put aside for review, even though you now know that you probably should have.
Ironically, it may be that in your end-of-project review, you conclude that you should have held the review process earlier – maybe next time you will.
Learning from your mistakes is important … but so is learning from the mistakes of others.
