Learning from a Project “Post-mortem”
In May of 2008 I was hired for Northrop Grumman Information technology defense group as a training specialist. My specialty was the development of Interactive Electrical Technical Manuals (IETM) and Computer Based Training (CBT). I had worked for other employers for the last 10 years. Not long after I was employed we were contracted to develop a project for the military using a new development tool which had to be S1000d compliant. We had a learning curve that had many problems. The server would do down. We were continually having updates. They would send patches to fix this problem and the patch would break another. It was a viscous cycle. Finally the project was delivered and everyone seemed happy with this successful project.
In 2009 we won three new projects, with due dates one right after another. We will call them Project A, Project B, and Project C. Just to keep them straight. Now, back to the story. We were confident that we would prevail. Project A , B, and C had new business rules and the S1000D had been upgraded and added to the Software Company. We went back to the Software Company with the new rule and upgrades that were needed. Their response was, “No problem”. The new software was delivered and installed and we went to work. We finished the first of the three, Project A. Sent it off for quality control and the clients review. So, we started the next two, Project B and Project C. We were moving forward. Life was grand. NOT. Our first, Project A was reject. What!
What Contributed to the Project’s Failure
The project was reject by quality control and the customer. It was not compliant to the S1000d and the new business rules. Someone had dropped the ball. We were told that certain parts were not an issue and we could proceed. These rules would not go into effect until after this project was completed. They would apply after upgrades were made by the customer for the next build. To make matters worse, all three projects were designed with the same set of objectivities, look and feel.
We were in the dark until the final delivery of Project A. We were given the results and told to fix them, while incorporating the new business rules and S1000D matrix. To add to this we have a development tool that is being phased out. We had all kinds of technical issues, that could not be fixed. There was no more support and we were on our own. We had to do some serious rework and the project was accepted. Could we have prevent the problem? Maybe. Maybe not, uncontrolled changes play havoc with a project under development and this one almost caused a project failure.
Which parts of the PM process, if included, would have made the project more successful? Why?
In this case, it was an unforeseen development. We had no idea that we would be changing software companies and our support from the old company would end. If anything, “the detailed plans to describe how the project team will make it happen failed’ (Portney et al, 2008). Any one or all of the following was the problem and could be fixed with the next project. In the future, the following items will need to be addressed in-depth.
Detailed description of results
List of all work to be performed
Roles of all team member
Schedules
Assumption
Identified risk and possible response.
All phases of the project life cycle must have equal deliberation for the project to be successful. I believe we have learned our lesson.
References:
Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.
Patricia
Hi Patty-
I enjoyed reading your post concerning the experience you had with a failed project. You bring up such a great point regarding planning for risks and establishing a plan on how to deal with them. The failed project experience I described for this week’s assignment also demonstrates what can happen when risks are not taken into consideration. The outcome is usually disastrous!
Risk management is often learned through past experiences. In order to plan for risks, a list should be made of reasonably frequent disasters that strike projects similar to the one being undertaken (late subcontractor deliveries, bad weather, unreasonable deadlines, equipment failure, complex coordination problems). Plans of how to deal with crisis if/when they arise should also be made in hopes of either preventing or softening the impact in some areas (Mantel, Meredith, Shafer, & Sutton, 2008).
Thanks again for sharing your experience!
References:
Mantel, S., Meredith, J., Shafer, S., & Sutton, M. (2008). Project management in practice: Third edition. Hoboken, NJ: John Wiley & Sons, Inc.
Patty:
I enjoyed reading your informative blog post. I had not previously heard of the S1000d standard. I found some additional information about it at this site: http://public.s1000d.org/Pages/Home.aspx. Obviously, you already know all about this standard. I decided to include the link for the benefit of those of us who are not familiar with it.
Your position at Northrup Grumman sounds like an interesting and challenging career. I must admit that I have heard of this company many times but was not familiar with what all they do. Here is a link to the company web site for those who are not familiar with this organization: http://www.northropgrumman.com/.
The situation you experienced with the development tool that was being phased out reminded me of one of my previous employers. That previous employer is OhioHealth. The IT department at OhioHealth had been using an incident tracking application called PowerHelp since the early 2000’s. PowerHelp was used to document all requests for assistance received by the IT department. Unfortunately, PowerHelp was being phased out. Other incident tracking applications were evaluated and Service-now was selected. Planning for the implementation of Service-now had been going on since shortly after I started working for OhioHealth in November of 2006. Very little Service-now training was provided to the almost 300 staff members in the IT department prior to it going live. The result was a temporary backlog of requests for assistance in the IT department. As a result of this backlog, the leadership team decided to provide the IT staff with additional training on the Service-now application. The Service-now application was more feature rich than PowerHelp. Unlike PowerHelp, Service-now had robust reporting capabilities. However, Service-now actually ran slower than PowerHelp. As a result, several of the IT staff began referring to Service-now as “Service-later”.
In retrospect, I would refer to the Service-now implementation project as a failure. This is due to the fact that this project failed to meet specification goals. One of the key measurements of success is whether or not a project meets the agreed-upon specifications to the satisfaction of the customer (Mantel, Meredith, Shafer, & Suton, 2008). The IT department was looking for an incident tracking application which was as fast or faster than PowerHelp. Unfortunately, this was not delivered.
References
Mantel, S., Meredith, J., Shafer, S., & Sutton, M. (2008). Project management in practice: Third edition. Hoboken, NJ: John Wiley & Sons, Inc.
Patty,
Your project sounds like a very technical, but interesting one. I have never heard of that company or that product, but I enjoyed reading about your challenge and I think you provide some good insight as to what the issues were with the project. Your project sounds like mine where on paper it appears that all went okay, but in reality, someone dropped the ball. When you state at the end that if the risks and possible response had been identified earlier it would’ve helped the project succeed, I agree with that. I think that preparing for possible issues or risks really helps everyone be more prepared for when that happens. The “Situations and Issues Suggest in the Linear Responsibility Chart” in our textbook (97) would have been a great form to utilize for this project to help everyone be more prepared. It would provide certain situations that the team would think of and then possible issues. To further develop the form than what is in the textbook, you could add another column of possible solutions so that if one of those issues were to arise in that situation, the team could refer to the chart and see what a solution could be. It would certainly help the team be in control of the project throughout. Of course not every situation and issue can be thought of, but this would be a good chart to utilize to prepare for what you can and help the project be more successful.
Thank you for sharing your experience!
References
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., $ Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.
Hi Patty,
First your blog is very nice to read and look at. The inclusion of graphics is nice. Second, I like David did not know there was a S1000D. It was interesting to note the reasons behind it and I did a search and actually found a blog totally dedicated to making “sense out of confusion” about S1000D at http://s1000d.blogspot.com/. Do you find it better to have a matrix to work from rather than having to create one yourself? I would think it would be easier to plan since the standards are in place and you would know what the industry would expect. Having worked in the IT field for 29 years I understand the phasing out of software. It seems that the minute you get a reliable, somewhat bug free software the company producing it comes up with a new “improved” version where the process starts all over again to get it to the reliable stage. Do you think talking to the software people about the life cycle of the product you are using is the way to go? Then you would know maybe if they were planning on phasing it out in the next six months or not.
Sheri