When I consult with organisations, train their staff or help review their processes, I’m often told that they don’t get around to formally review their projects. There seems to be so much pressure on businesses and teams today t​hat many rush from one project to the next without taking the time to learn from the experiences they have just been through.
 
When we omit to review a project, not only do we miss out on the opportunity to improve our processes, our working patterns and our team behaviour. We also fail to assess if the project was an overall success or failure and whether the benefits have been realised. Many organisations are not able to tell me how many of their projects succeed or fail and for what reason. The first step in helping a team or an organisation improve is to understand where they are currently succeeding and where they are going wrong. Project reviews can help us gather this information and do something about the situation – and they are really easy to carry out. 

​One way of carrying out a post implementation review (PIR) is to get the team together after the project has been delivered and to first list everything they feel went really well. Then, as a second step, they list all the areas where they feel they can improve. This is not about laying blame but about identifying more effective ways of working. The post implementation review should also answer the question of whether the project was successful and if it delivered what it set out to – including the benefits. When a review is completed, the project manager will typically write up the findings and circulate it to all stakeholders. So yes, post implementation reviews do have merit, but the problem is that organisations often fail to learn from them, as many of the reports are never read after they are produced. In addition, the team only learns the lessons after the project has been delivered..
 
What would be more effective is to adopt one of the agile methods of reflecting, learning and course correcting as the project is being implemented. Why wait until the end? Why not review the project after each phase or iteration so that the team can learn the lessons, identify actions, adapt and improve straight away? Even if you’re not running an agile project, you can still carry out a retrospective after each major milestone.

I once heard researcher Susan Pritchard speak at ICCPM’s Research and Innovation seminar. She said that we must learn through rapid cycles of action and reflection in the moment and that it’s all about learning in the experience rather than from it. At the same event Tim Banfield, a previous director at the Major Projects Authority, also argued that lessons-learnt papers have limited value. He said that it’s far better to get people to talk and share their experiences across projects by giving them the space and opportunity to learn from each other as the project progresses. He also emphasised the importance of asking people outside the project for input in order to continuously learn and improve.

What is your current situation? Do you review your projects? Do you learn from your mistakes and do you get a chance to course correct in the experience? 


If you liked this post, you may also like:
Project Leadership - 20 essential tips  
​When projects go wrong and it's the worst possible moment
Why do projects continue to fail - and what can we do about it?
Innovative leaders ask powerful what-if questions
Is the Ion Triangle Outdated?

If you are running a software project, one of the questions you are likely to come across is which development methodology to use. Some like to stick to a traditional waterfall approach whereas others are keen advocates of an agile methodology. In reality many projects end up somewhere in between; with a methodology that is neither extremely agile nor extremely rigid.

Compared  to waterfall, these “middle-of-the-road”methodologies can seem flexible as they allow for changes to take place from iteration to iteration. Compared to agile, however, they are likely to appear rigid and far less  collaborative.

When deciding on the right development methodology for your project, think about how much flexibility it should contain and which aspects you can employ from different types of approaches to best suit your needs. Examine the size of your project, the make-up of your team, the organizational culture and what you want to achieve. Then piece together the methodology to your specific needs. Even if your organization advocates a certain approach, there will often be opportunities for you to improve it and adapt it to your specific project.

To help you decide which approach is best suited in your situation, take into consideration the below aspects. The questions will help you decide how flexible your methodology needs to be on a scale from very flexible (agile) on the one hand, to very rigid (waterfall) on the other. 
 
1. How clear are the project’s objectives and requirements? 
On some projects, the clients know exactly what they are looking to achieve and what the success criteria of the project are. On other projects, it can be difficult to pinpoint what the project needs to achieve or what the requirements are. When the requirements are difficult to define, or likely to change significantly, you need an approach which is relatively experimental and flexible; an approach which allows you to speedily demonstrate and prototype ideas to the customer and incorporate changing requirements.

2. How clear and well-defined is the solution? 
You may find yourself in a situation where the desired outcome of the project is clear, but where the solution for achieving that outcome is not. When the team is faced with difficult and risky choices around technology, design and  implementation, your software development methodology needs to be flexible enough to cater for this and iterate through various stages of prototyping, development and roll-out.

3. How easy or difficult is it to access the end users? 
Are the users, domain experts and product owners likely to be available to provide feedback and help test deliverables at short notice, or do you anticipate that they could be difficult to get hold of? Would it be easier to engage them for a pre-planned test cycle where lots of deliverables can be tested at once? The more constraints there are around your user’s availability, the more rigid your methodology should be.

4. What is the size of the project? 
Is your project on the larger side or is it reasonably small and lean? The larger the project, the more difficult it might be to incorporate lots of changes at short notice and refocus the team in a different direction. Small tight-knitted teams which work closely with the customer and end users are more flexible and better geared to quickly incorporate changes. 
 
5. How  dispersed is the project team? 
Do you have several project teams situated in different geographic locations or is the team more homogenous and located together? When the team is geographically spread out it can be difficult to quickly coordinate new work and adapt to changing priorities. Teams which sit together, and even share the same room, are much better placed to working in an agile environment with changing priorities. 
 
6. What is the team’s and stakeholder’s experience with these  methodologies?
Are your team and stakeholders already accustomed to working with a specific methodology? If so, bear in mind that it takes time to change a team’s working practices. If your project is time critical, be wary of making too many drastic adjustments to the existing methodology as it may jeopardize the timescales and success of your project. 

7. What are  the project’s success criteria? 
Which is more important for your sponsor and client? Having a relatively firm estimate and schedule which must be adhered to, or ensuring that the end deliverables add value and match the user’s needs and expectations? Is your client ready to embrace a more flexible and quality-conscious approach at the expense of fixed costs and schedules? 

8. How much value would incremental feature driven development add? 
Does the project lend itself to being delivered in an incremental way and would this add real value to the stakeholders? Must the products and features be delivered at once in order to provide tangible benefits or would it be a real advantage to deliver them gradually?    
 
 
If you liked this post, you may also like:
Top Tips for Gathering Requirements
Initiating and Planning your Project
Risk management is how adults manage projects!
10 guidelines for estimating project effort