Overall Project Measurement Overall Project Measurement allows you to determine if the project was estimated properly, risks were identified and mitigated, requirements were correctly identified and documented, and if the project was delivered on-time and on-budget. From this, we learn to provide better estimates, collect better requirements, and do better risk management. Below are some best practices for measuring overall project success:
Review Estimate vs. Actual for the Project - Prior to beginning a project, it is important to estimate each task that must be performed for the project. As the project progresses, team members should keep track of how much time it took to perform each task. It is also important to identify an allowable variance. For example, upon completion of the project, if our actual hours/costs were within 5% of the estimate, we will consider it a success. Once the project is completed, run reports that show whether the project was successful (based on your variance allowance). How do you do this?
FFirst, you must detail each of the requirements and develop a list of tasks for the delivery of each requirement (if you need help developing requirements, click here). With a good set of requirements, the project manager can work with the project team (programmers, testers, etc) to develop a list of tasks that must be completed for each requirement, along with the estimated effort of each task. Once this is done, record your list of tasks, assign them to team members, and track their progress. As tasks are completed, record the number of actual hours it took to complete each task, as to allow you to determine the correctness your estimation process. Upon completion of the project (all tasks are 100% complete), run reports that show you how well you did. You can use this information on future projects, to create a buffer for improving the estimation process.
For example, let's assume we started a project for a new release of our Widgets product (Widgets Release 4.1). At the beginning of the project, we collected the requirements, identified and and estimated each task, and we decided that a 5% variance on the project was acceptable. As the project progressed, our team members logged time toward each task. Upon completion of the project, we analyzed the project results. See the Basic and Advanced Approaches below to see how the project turned out. Basic Approach - If you do not have a software development lifecycle tool, a low-cost and simple approach to this is to create a spreadsheet that contains a list of your tasks and assignment information. As your team members work on items, each day you should make note of actual hours and costs thus far, and percentage complete. As items are finished, update the spreadsheet with Actual Hours, Actual Costs, and Completion Date. After all tasks are completed, analyze whether the project was successful, see attached spreadsheet to see how we did it.
EExample: ProjectOverview.xls
Advanced Approach - A better approach is to utilize an SDLC tool that allows tracking of project tasks, assignment of the tasks to team members, tracking of hours and costs, and allows the team members to update their percentage complete. For ease of update, the software should be web based, so that it can be accessed from any location. To do this, you can use Software Planner, Microsoft Project or some other project management tool. The disadvantage of using windows-based tools (like Microsoft Project) is that they are not web based, so individual team members can not easily update their hours, costs and percentage complete the project manager is forced to update that information. Software Planner (and other web based tools), empower the people doing the work to update this information, and has email alerts that alert the Project Manager as items are updated. Once the project is completed, run reports that analyze whether the project was successful, see attached reports so you can see how we did it.
Examples:
A) Project Tasks By Project Report - By reviewing this report, we can quickly see that our project went OK. The cost overruns were 5 hours of work, relating to $1,035 in costs. At the beginning of the project, we had agreed that if we were within 5% of our hours can and costs, we would consider the project a success. Based on reviewing this report, we were within 2% variance, which is OK. However, it would be good to drill down a little further and determine what tasks and what resources (people) contributed to the overage. See the next report to determine that.
B) Project Tasks By Assignee Report - By reviewing this report, we can see that a couple of team members really excelled. Notice that Jennie Jones, Mary Jones, and John Tester actually finished their tasks under budget. However, John Doe and Joe Millionaire finished their tasks over budget. We may want to analyze their tasks further to determine why they had overages, and if we need to change our estimating techniques when assigning tasks to these individuals.
Post Mortem - As projects are completed, you must perform a "post mortem" to identify the things you did well, and the things you did poorly. Use this information to improve future projects. How do you do this?
Plan Your Post Mortem Review - Upon completion of a project, the Project Manager should conduct a "Post Mortem" review. This is where the Project Manager invites all the major players of the team (Analysts, Lead Programmers, Quality Assurance Leaders, Production Support Leaders, etc) to a meeting to review the successes and failures of the project.
Require Team Participation - Ask the attendees to bring a list of 2 items that were done well during the project and 2 things that could be improved upon.
Hold the Post Mortem Review Meeting - Go around the table and have each person to discuss the 4 items they brought to the meeting. Keep track of how many duplicate items you get from each team member. At the end of the round table discussion of items, you should have a count of the most popular items that were done well and the most agreed upon items that need improvement. Discuss the top 10 success items and the top 10 items that need improvement.
List Items Done Well and Things Needing Improvement - Upon listing of the 10 success and improvement items, discuss specific things that can be done to avoid the items that need improvement upon the next release. If some items need more investigation, assign specific individuals to finding solutions.
Create a Post Mortem Report - The best way to keep this information organized is to create a "Post Mortem" report, where you document your findings. Send the Post Mortem report to all team members. Before team members embark on their next project, make sure they review the Post Mortem report from the prior project to gain insight from the prior project. We have created a template that you can use for the document, download it by clicking here.
Helpful Templates Below are some helpful templates to aid you in developing software solutions on-time and on-budget:
About the Author Steve Miller is the President of Pragmatic Software (http://www.PragmaticSW.com). With over 20 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software. You can read other newsletters at http://www.PragmaticSW.com/Newsletters.htm. Steve's email is steve.miller@PragmaticSW.com.
Disclaimer: All information on this site is provided for informational purposes only! By no means is any
information presented herein intended to substitute for the advice provided to you by any health care or other professional
or organization.
