Work
Home | Work | Play | Photos | Contact | About
Review / Post Project Analysis
Home > Work > IT Consulting \ Post Project Analysis
Introduction
Project reviews. In other engineering disciplines (civil, electrical, chemical and so on) they're part and parcel of maintaining one's professional standing. In software development they're one the most neglected practices. There are quite a number of reasons why the software development industry doesn't like them.
Top of that list is ego - software development, as a discipline, seems unwilling to admit to failure or shortcoming, let alone a misstep. When they do happen, reviews are often politicised, rather than being seen as oppotunities to learn, or as a time of reflection. Some agile projects I've worked on do retrospectives. Unfortunately all of them limit themselves to discussing the backlog, and studiously avoid talking about the important stuff (see below).
The benefits of reviews are worthwhile to the organisation, the team and to individuals. For each it's an opportunity to learn, improve, and to do it better next time. You could also use the opportunity to identify the the project's unsung hero (there always is one) and thank her with a bottle of wine - especially when the project failed, resulted in a death march or was otherwise difficult.
So what does a useful project review look like, exactly? And how does one conduct a post-project assessment whilst keeping it constructive?
Overview
A post-project analysis is a review that records the results of a depth and breadth assessment of the project from its inception to completion. The assessment captures successes, challenges and failures, and identifies what should have been done differently on this project and what could be done differently for the next project.
Use this table to determine the recommended time frame for a project review:
| Project Characteristic | 2 weeks after completion | 5 weeks after completion | ||
| Project scope | Small | Large | ||
| Project duration | Short (days to 3 months) | Long (3 months or longer) | ||
| Team morale | Low | High | ||
| Team member availability | Some (team reassigned) | Available |
As a guidline, a useful project review might include the following topics:
- The solution
- Project planning and resources
- Project management and scheduling
- Architecture/solution design
- Tools and technologies
- Testing
- The team
The topics above are discussed in a little more detail below. However, for each of the topics, also consider:
- Accomplishments - What was successful about the topic? Describe what contributed to that success and why it was successful.
- Challenges - Describe any problems that occurred with the topic. Why were they problems, and what contributed to those problems?
- Lessons Learned - Describe what was learned about the topic and how it should be done the next time. A recommendation could be to use the same approach, or it could suggest significant changes.
When conducting a post-project analysis, try to:
- Be constructive and supportive
- Be precise and specific
- Focus on challenges and suggestions for improvement surrounding process rather than specific individuals
Avoid:
- Using people's names.
- Being negative or hostile.
- Asking permission.
- Explaining or justifying your comments and recommendations, unless specifically asked to do so by someone else.
- Repeating comments and recommendations made by others.
- Expressing agreement or disagreement with comments and recommendations made by others.
The Solution
Describe aspects of the solution that was delivered. This should include:
- The team's understanding the customer’s business objectives and requirements
- The team's understanding the user requirements (or stories)
- The team's understanding the system requirements (or stories)
- The team's understanding the operational requirements (or stories)
- If applicable, determining the need for and deploying a pilot
- Readying the operational environment for deployment
- Developing a solution concept
Also include customer satisfaction metrics, and metrics on business value delivered.
Example questions to answer to develop this section’s content:
- Was the business objective met? State the metric used to measure project success. If not, why?
- In retrospect, could the team's work have been done better? How?
- What needs to happen so that the team can avoid problems in the future?
- Is the team satisfied with the solution it shipped? If not, why?
- What could the team do to improve the process of creating the solution?
Project Planning and Resources
Analyse the planning processes used for the project, who participated in the planning processes, and the quality of the plans (reliability, accuracy, completeness, etc). Include information regarding the availability, quality, and application of resources.
Example questions to answer to develop this section’s content:
- Were the team goals clear to you?
- Were the marketing goals clear to you?
- Were the development goals clear to you?
- How complete do you think the planning was before the actual commencement of work?
- How could planning be improved?
- What recommendations would you make for the planning process for the next release?
- How can we improve our methods of resource planning?
- Were there enough resources assigned to the project, given the schedule constraints?
- What could have been done to prevent resource overload?
- Do you think resources were managed effectively once the project started?
Project Management and Scheduling
Describe project’s project management and scheduling aspects. This should include information regarding:
- The integration of planning
- Scope management
- Budget management
- Schedule management
- Resource allocation
- Quality assurance
- Stakeholder management
- Risk management
Example questions to answer to develop this section’s content:
- Was the schedule realistic?
- Was the schedule detailed enough?
- Looking over the schedule, which tasks could you have estimated better and how?
- If you used pre-determined milestones, did having them help in making and monitoring the schedule?
- What were the biggest obstacles to meeting the scheduled dates?
- How was project progress measured? Was this method adequate? How could it be improved?
- Was contingency planning apparent? How contingency planning be improved for the next release or project?
- How could scheduling have been done better or been made more useful?
- What would you change in developing future schedules?
- How were changes managed late in the cycle?
- Were the trade-offs between schedule and features handled well?
- Was communication within the team efficient and effective?
- Was communication between teams efficient and effective?
- If they were used, were the status meetings effective?
- Was communication with external stakeholders (component suppliers, content suppliers, OEMs, support, and others affected by the project) effective?
- Was the team effective in resolving risks and issues?
Architecture/Solution Design
Describe the project’s development aspect. This should include information regarding the architecture, design and development processes used (methods, versioning, approval, and so on), who participated in the architecture and design processes, and the quality of the designs and specifications that were used during development (reliability, accuracy, completeness, etc).
Example questions to answer to develop this section’s content:
- Were there issues in the feature-set and ownership?
- Were there issues in the architectural design and ownership?
- Were there issues involved in using components or with code sharing? How could this be done more effectively?
Tools and Technologies
Describe the project’s experience of the products, tools and technologies used. This should include the specific application of the products, tools and technologies, the usefulness of those tools, any limitations of the products, tools and technologies, and if known, any recommended alternatives for future projects.
Example questions to answer to develop this section’s content:
- What improvements can be made for tracking bugs that will make the process more effective for use during development of the next release or project?
- What improvements can be made to document, source code, and source asset control?
- Can any comments be made about the build process and compilers?
- Can any comments be made about coding standards?
- Were there any products, tools or technologies the team needed but didn't have?
- What other improvements can be made to, or on the choice of existing products, tools and technologies?
Testing
Describe the project’s testing aspect. This should include the testing processes used, who participated in the testing processes, and the quality of the test plans and specifications that were used during testing (reliability, accuracy, completeness, etc).
Example questions to answer to develop this section’s content:
- Were there issues in test interaction?
- Were there issues in test case design and coverage?
- Were there enough testers?
- Was the quality of the solution shipped acceptable?
- Did developers work well with testers?
The Team
Describe aspects of the project’s team work and roles. This should include information regarding leadership, any sub-teams and their structure, and the quality of the integration among teams. It could also include information about the scope of each team’s work, the performance of its designated role on the project, and the balance among the teams regarding decision-making.
Example questions to answer to develop this section’s content:
- Did each team member understand who was on the team and what each member was responsible for?
- Were the roles of the different groups (development, test, user experience, project management, logistics/support) clear to each team member?
- What could be done to alter the project team's organization to more effectively deliver the solution? What functional changes could be made?
- Did the different groups fulfil their roles?
- What was deficient in each group?
- Did each team member have all the information needed to do his or her job? If not, were they able to obtain the information?
- Did the team work well together?
- Were management decisions communicated to teams? Did everybody understand how decisions were made?
- Were external dependencies managed effectively?
< Back to IT Consulting | ^ Back to top
All content copyright © Michael Wittenburg 1995 to 2024. All rights reserved.
Merch (t-shirts designed by my twin)