Global Project Development Team 2
Version 1.0
Post Mortem
Revision 1.1
April 24, 2008
GPDT2
Revisions
Revision / Author / Description / Date1.0 / Janakiram Dandibhotla / Initial Draft / 04/18/2008
1.1 / William Larson-Garcia / Updated and Revised / 04/24/08
Table of Contents
1 Introduction
1.1Purpose
1.2Scope
2 Metrics
2.1Survey Analysis
2.2Risk Analysis
2.3Earned Value Analysis
2.4Requirements Analysis
2.5Defects Analysis
3 Lessons Learned
3.1Project Strengths
3.2Project Weaknesses
1 Introduction
1.1Purpose
The purpose of this document is to analyze the success achieved, problems faced and lessons learnt from the project. Other details like the risk analysis, EVA charts etc. would lead us to formulate what lessons were learnt and what could be improved.
1.2Scope
This document presents the metrics we have used to track the status of the project. These details would lead us to know about the shortcomings of the techniques used, how the project can be even better performed and improved. The document will also contain the lessons learnt along with discussion of how to improve the pitfalls.
2 Metrics
2.1Survey Analysis
Figure 2.1 Team Survey Results
Based on the survey results, most of the questions were answered uniformly. The team basically said that most of these issues stemmed from communication problems that surrounded the entire team. Coordinating this project has been an utter nightmare with different student internationally
2.2Risk Analysis
Table 2.x Severity of Risks on Weeks 1 Through 12
The table above shows the status of various facets of the project throughout its lifetime. An almost a constant yellow-level severity persisted in Risks as various project artifacts were completed later than planned, which in turn increased the risk of the schedule. Week 6 shows a rise in severity across schedule, risks, and weekly activity as this was the lowest period of productivity in the history of the project; that week follows Spring Break and may have been a case of ‘post-vacation lethargy’ where everyone is slow to return to work mode. As a result, artifacts fell behind in completion and the schedule was jeopardized. Severity decreased across the chart at around week 10 when the report generation requirements were de-scoped.
2.3Earned Value Analysis
Figure EVA Chart showing weekly task costs and variances
Figure EVA Chart showing Earned Business Value
The earned value analysis shows the trend of the project as needed by the customer. From the EVA chart for the weekly cost variances, it can be seen that the project has made a good progress only in the third iteration, since we had the requirements froze on by the end of iteration 2. From the Business Value Chart, we can say that the project has lost all the business value built before second iteration as the requirements have changed and could cope up within third iteration.
2.4Requirements Analysis
Poor requirements were one of the largest problems in this project. Due to the structure of this team, and it’s multiple locations and partners, design changes were a constant problem throughout this project. In fact not until after three meetings and conference calls was a design finally settled on in late 2nd iteration. This held up product development of any kind until the third iteration.
Also an architecture was initially chosen for this project then that architecture was decided not to be used so we took a gigantic step backward, then it was decided that due to the amount of time it took to acquire an agreed upon design that we should revert back to the former architecture, which was an earlier release of it. Although this was a de-scoping of a requirement the team felt it necessary in order to implement the required functionality of other requirements in a timely manner
This team was also lacking a solid Software Requirements Specification, and due to the constant changing of requirements the SRS was not finished until mid 2nd iteration. Lack of communication and the inability to arrange timely meetings was the overall down fall of this group when it came to requirements completion, and although we implemented most of our requirements. Lack of verification has been a persistent problem.
The graph shows our expected requirement fulfillment versus our actual production throughout the iterations. Due to the design difficulties and lack of communication our expectations fell behind. Resulting in our team fulfilling requirements in the transition iteration.
3 Lessons Learned
3.1Project Strengths
3.1.1Greatest Successes
The team members were nearly unanimous in the assertion that the team’s greatest success was the large number of requirements that were successfully implemented, especially when compared to the competing teams. Despite the workload, nobody had felt that the team attempted too and agreed that the requirements chosen were the ones that needed to be complete in order to most satisfy the customer. If another project were attempted by the same team, a similar proportion of requirements would be selected again.
A secondary success was how often every team member attended the weekly Tuesday online meetings as well as the few emergency meetings. Only a two instances occurred where everyone was not present, which shows a respectable amount of commitment. In addition, the meetings were deemed quite productive. In particular, everyone was able to bring ‘something to the table,’ at each meeting.
3.1.2Greatest Team Attributes
Enthusiasm, humor, and a willingness to get-along were considered the three best attributes of the team upon discussion. Although tensions ran high during a few critical stages, everyone kept cool and remained receptive to input and ideas. Nobody felt as if they were being completely shoved aside or ignored. Our ability to use each members strengths and recognize their weaknesses so we can plan activities to take advantage of those aspects was also a great attribute.
3.1.3Strategies to Keep
The weekly online meetings were unanimously voted as the best strategy employed by the team and one that should be used in any future project. The information gained from each session was considered valuable to the progression of the project. Foregoing these meetings would have ultimately hurt the project as a whole.
Tailoring tasks to each individuals strengths and knowing our team members was a great
strategy. A team should know who is best at completing what task and that served our team greatly throughout this project.
3.2Project Weaknesses
3.2.1Greatest Shortcomings
The massive delays on the SRS document, lack of a quality assurance document, and hemorrhaging progress on user-interface design were considered by the team to be the greatest failures of the project. The delays on these artifacts really put a stranglehold on some of the progress and made testing difficult. It was agreed upon that if these artifacts were handled properly then a 100% requirement implementation may have been achieved; nonetheless, these three artifacts were considered important and would not be dropped in future projects.
3.2.2Weakest Team Attributes
Interestingly enough, one of the weakest attributes in the team was considered to be lack of clear communication or at the very least, a misunderstanding in what is considered clear and what is not. This was due to the fact that multiple teams involved in this project and the survey shows the greatest variance in responses on this particular matter so it’s evident that this was a sticking point. Team members felt that if the design would have been solidified earlier or had been locked in at the end of last semester, rather than making design changes in the beginning of construction then we could have had more time to test and validate our code.
The second weakest attribute in the team was considered to be skill, specifically a lack of skill in the tasks required of various team members. The consensus was that the team as a whole wasn’t unskilled, but rather needed skills were concentrated in only half the team members. The team agreed that if skill levels were sharp across the board that the project would proceeded at a much more efficient clip.
3.2.3Suggested Improvements
Improvements to the team centered primarily upon improving communication and communication methods. The weekly team meetings were considered to be fine, but the follow-up communication was deemed to be lacking and team members suggested making required tasks clear to a level that’s acceptable to the team member in question. In addition, written requests that specified exactly what needed to be done were also suggested. Also not changing the design and agreeing upon one at an earlier date would have also made a big difference in the overall completion and quality of this project.
Page 1