The main purpose is to review all testing activities, the effectiveness of the testing and allow comments to be made on the development procedures. The primary purpose of the Post Project Review (PPR) is to see improvements made on future projects – to learn from our mistakes and also to recognize aspects of the project that were good.
General Principles
The following general principals will be adopted, in order to ensure the success of these reviews.
The whole team contribute
It is important to involve the whole of the project team in this exercise. Large team meetings will not be encouraged, as this can become intimidating for certain team members and therefore they do not contribute. Also long meetings – longer than one hour – should not take place, as they can be unproductive. Therefore it is recommended that small teams from each area get together for a meeting that lasts no more than one hour, with a set agenda/questions as suggested below. This way everyone feels part of the improvement process. Representatives from these meetings will then come together to discuss/compare findings and report to the Management.
Measurement criteria is logged
At the meetings people must come prepared – any measurement criteria which helps establish facts must be recorded. Key metrics are:
- Defect Detection Percentage (DDP)
- Number of faults V’s priority/severity
- Fix rate for faults/turnaround time
- Schedule estimates V’s actuals
- Number of iterations/builds of the system with timings
- Helpdesk call log statistics
Blameless culture is adopted
It is important for people to realise that this is not a ‘finger-pointing’ exercise. If problems occurred during the project we must learn from them and attack the procedure – not the person!
The right balance between the ‘good’ and the ‘bad’
Part of the meeting should be dedicated to looking at what went well on the project (the good) and what did not go so well on the project (the bad). In order to adopt a process improvement regime, we must concern ourselves and focus on the important things/best things to improve upon.
There is an expectation from the team to change
Once we have established the ‘good’ and the ‘bad’ we must recognise and keep hold of the good aspects for the next project and be prepared to change the ‘not-so-good’ aspects. These changes must occur relatively quickly after the project so that the same mistakes do not occur again. Key areas to look at are:
- Standards
- Procedures
- Processes
- Communication (process of information)
Phases of testing (Review, Design, Implementation)
Action plan
The key to success is an “Action Plan” being written, there must be a single point of responsibility for this action plan. The fact that everyone has contributed to this document means that ownership is shared. But by having a single point of responsibility for these actions means that changes will be brought about in the most expedient and efficient manner.
Key questions for each group:
Customer Services
- How could I have contributed more to the success of this project?
- Was I involved at the key stages of the project in order that I could do my job more effectively after implementation?
- What have been the key issues raised, so far, by the customers on this project?
- What is the confidence level, so far on this project (what are the measures for this)?
- How could my manager have helped more in the improvements to this project?
- Helpdesk responsiveness / Problem Management responsiveness
- Training satisfaction
- Customer Comments
- Development/Testing
1. Did I have the right information at the right time so that I could develop/test the project most efficiently?
2. How could I have been more efficient with the use of my time on this project?
3. How could I have contributed more to the success of this project?
4. How could my manager have helped more in the improvements to this project?
5.Where did ‘bottlenecks’ occur in the development process and how could they have been overcome?
- Basic Error Metrics
- Errors per Man Day Testing
- Ratio Internal / External errors (DDP)
- Modifications raised by customer
- Results of end of Project reviews
- Completion date Metric
- Statement of delivery deadlines / slippage
Development Team Productivity.
- Results of initiatives aimed at reducing cost.
- Results of initiatives aimed at improving performance.
Business Analysts
- How could I have contributed more to the success of this project?
- How could the team have contributed more to the success of this project?
- Was the system built right (Verification) and did we build the right system (Validation)?
- How could my manager have helped more in the improvements to this project?
- Were the requirements clearly understood by all and easily tested?
- Were there communication issues with development?
- How easy for developers to interpret the requirements documents?
- How appropriate was the requirements document in the testing process – particularly where testing not carried out by author of requirements document?
Executive Management
- How could I have contributed more to the success of this project?
- How could the executive management have supported the team more?
- Did we receive timely information that allowed us to make key decisions in the appropriate manner?
- Did the Project deliver its objectives to the organisation?
~~~~~~~~~~~~~~~~~~~~~~~~~The End~~~~~~~~~~~~~~~~~~~~~~~~~
Recent Comments