Project Post-Mortem
Project Post-Mortem
By Deanna Chaney
For two decades, I worked as both a technical writer and an instructional designer in the IT industry. My projects always supported a hardware or software rollout, rather than being the core deliverable. Rarely have I seen a project completed on time. Typically, the rollout is late and fraught with problems. Gartner Research, noting that “failure” is a subjective term, puts the failure rate for IT projects at 24 percent (Handler, 2011).
Background
One particular project involved rolling out a hardware and software solution for a large retail company. I was responsible for writing the product documentation, developing a series of e-Learning modules, and creating and teaching instructor-led training (ILT) at the pilot store. Within two months of the pilot, the equipment was pulled out and the project went back to the drawing board. This occurred for two reasons: (1) rejection of the new concept by a large number of the store’s customers and (2) buggy operation of the hardware and software.
Project Planning
Both my company and our customer had project managers carefully overseeing the project. They produced all the typical documentation, schedules, and contracts. The customer’s PM and business analyst developed a detailed requirements document that laid out exactly what the product should do. Changes in scope, of which there were several, were agreed to in carefully written change requests. When it came time for the pilot, all the hardware and personnel arrived on time. For my part, I worked with the account executive to submit SOWs for the e-Learning and ILT. These documents outlined deliverables, scope, risks and assumptions, a timeline, and costs. Although the project was eight months behind schedule, overall, the PMs did their job by the book. So, what went wrong?
Needs Analysis
This project introduced a new self-payment process at a retail store. Although the store touted the benefits of the new system with colorful signs and banners, the actual business goal was to reduce labor costs. The new payment method might very well have appealed to a younger demographic. However, on the day of the pilot, we (including members of our customer’s team) were all surprised to see a much older group of people walking through the door. These customers were highly displeased with the new system, and, quite frankly, many of them found it physically and mentally challenging.
Projects often fail because of “unrealistic and mismatched expectations” (Krigsman, 2012, para. 10). The project initiation phase should include building a business case, which may include a market analysis (Zaval & Wagner, 2011). Our customer clearly overlooked their customers’ needs in pursuit of cost savings. At the very least, they did a poor job of selecting a pilot store.
Resources
Although I blame our customer for the rejection of the new system by the store customers, the hardware and software problems were clearly the responsibility of my company. Murphy (1994) emphasizes the need for senior management to allocate adequate resources to a project. Success would have potentially opened up a new market for my company, but our group was understaffed all along. Nearly half of our small team resigned just as the project began, and we did not replace them. Most notably, we lost a QA person at a critical phase in the testing.
Methodology
Adding to our woes, our customer demanded that we follow a “waterfall” method of software development and testing, which is equivalent to ADDIE in the instructional design world. West (2013) suggests that the model “is risky and invites failure” (para. 3). Unlike Agile methods, our process was linear and time-consuming, injecting redundant work and delays into the QA process. In the end, the released product was fatally flawed.
Conclusion
If senior management has a flawed vision or declines to allocate adequate resources to a project, it will fail despite the best efforts of the project manager.
References
Handler, R.A. (2011, September 11). To Improve IT Project Success, Focus on Partnership, Requirements and Resources. Retrieved from http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&resId=1781845&ref=QuickSearch&sthkw=it+project+management+failure
Krigsman, M. (2012, April 16). Who’s accountable for IT failure? (part one). Retrieved from http://www.zdnet.com/blog/projectfailures/whos-accountable-for-it-failure-part-one/15451
Murphy, C. (1994). Utilizing project management techniques in the design of instructional materials. Performance & Instruction, 33(3), 9–11.
West, R. (2013, March 17). Everything you think you know about Waterfall development is (probably) wrong. Retrieved from http://changearc.wordpress.com/2013/03/17/everything-you-think-you-know-about-waterfall-development-is-probably-wrong/
Zaval, L.K., and Wagner, T. (2011). Project manager street smarts: A real world guide to PMP skills (2nd ed). Indianapolis, IN: John Wiley & Sons, Inc.
Deanna Chaney is an instructional design and technical communications consultant. You can connect with Deanna via LinkedIn. You can read more from Deanna on her blog.