Experience Is What You Get When You Didn’t Get What You Wanted: Lessons Learned Review For Estimating
Another reason to measure and record lessons learned…. Even is a project is not successful, lessons learned and measurements can teach valuable lessons for the future.
Real lessons learned that are applied to imporve processes and decision making for the future are paramont to estimating and project management overall.
Each time you have arrived completed an estimate and again at the end of the software development, you should document the pertinent information that constitutes the estimate and record the lessons you learned. By doing so, you will have evidence that your process was valid and that you generated the estimate in good faith, and you will have actual results with which to calibrate your estimation models. Be sure to document any missing or incomplete information and the risks, issues, and problems that the process addressed and any complications that arose from using the process. Also document all the key decisions made during the conduct of the estimate and their results and the effect of the actions you took. Finally, describe and document the dynamics that occurred during the process, such as the interactions of your estimation team, the interfaces with your clients, and tradeoffs you had to make to address issues identified during the process.
Also, if you had to replan the project or restart it for any reason, record the circumstances so you can avoid similar problems in the future. Cost models, which are based on the actual costs of past projects, can be calibrated and their accuracy can be demonstrated by comparing the costs of your current estimates with both past project data and the actual costs of your completed project, thereby adjusting the model input parameters to improve its future accuracy.
Conducting a Lessons Learned Review
You should conduct a lessons learned session as soon as you can after the completion of your project while the participants’ memories are still fresh. Lessons learned sessions can range from two team members meeting to reach a consensus about the various issues that went into the estimation process to highly structured meetings conducted by external facilitators who employ formal questionnaires. No matter what the form it might take it is always better to do a lessons learned meeting than not, even if the meeting might be a burden on those involved.
Every software project should be used as an opportunity to improve the estimating process. To document the lessons learned, follow these steps.
- Conduct a post-mortem in order to identify the reasons for significant estimating variances.
- Identify the major cost drivers.
- Log each reason for project growth as well as the cost, size, schedule, and effort impact.
- Compare actuals to that of the similar systems used for estimating.
- Identify any differences in estimating rationale and reality.
6. Assess the difficulty and complexity of the problem, technical staff and management team characteristics, product and process characteristics, and environment and user characteristics[1]
The most accurate lessons learned session would encompass three reviews; one that is conducted after the estimate has been accepted and two that are conducted upon completion of the project. The post-acceptance session employs a questionnaire similar to that provided in Chapter 3 “Estimating Process Questionnaire”, to rate the estimation process against a standard set of criteria. The purpose of this step is to capture the experiences and views of the analysts in a structured framework and to compare what actually occurred during the project with the model used. The second meeting uses the same questionnaire to assess the effect of the ratings: high, medium, and low on the accuracy of the estimate process and on the project as a whole. The third meeting uses a different process to collect the information needed to improve the modeling process.
These sessions are important for answering questions that are critical to the organization and for providing the information needed to validate the accuracy of the cost models used.
1. Cause Segment. What did we do and what tradeoffs did we make?
2. Effects Segment. What were the effects of the shortcuts, tradeoffs, and assumptions we made and should the changes to the process be incorporated into the standard process?
3. Modeling Improvement Segment. Based on the results of the estimate, how should the cost and schedule models be applied to more accurately reflect the process followed, the results of the project, and the quantitative values of key model factors at the completion of the project?
[1] Randy Mathis, Metric-Based Scheduling and Management, Crosstalk Magazine, July, 1997
What if people don’t want to hear lessons learned
This can be a very real problem. Many times lessons learned point to fact free planning or other requirements that put the project in the impossible zone. Even so I believe the lessons learned should be captured. Perhaps they can be used later. Or at least not forgotten.
Related posts
Comments
Leave a Reply
