Project Management in Practice: When You Have to Kill a Project Please provide an initial response to these questions by the end of the day on Wednesday 12/07. Please continue the discussion by providing your thoughts and feedback (at least 3 in total) on your classmates' responses throughout the remainder of the week. All responses should be posted by the end of the day on Friday 12/09. From Project Management: A Managerial Approach - Chapter 13 It takes courage to kill a project, but sometimes you know it has to be done. Some common symptoms of a failing project are ill-defined initial requirements, constant changes in scope, excessive changes in resources and personnel, and extreme stress/tension over anticipated changes. Yet, a project may have followed the "book" and done everything right, but still need to be terminated. This was the case with a project in the United Kingdom, where the client was highly committed to the project, contributing time, resources, and prompt decisions. The scope was clear, completion criteria agreed upon, the budget and timeframe acceptable to all. Early on, however, an unavoidable scope change had to be made, requiring a 20 percent increase in time and a 10 percent increase in cost, agreed to by the client. As the project approached the end of the first phase, it was clear that the quality and schedule were both deteriorating, as indicated in progress reports to both the client and senior management. A quick review showed that the results were not going to be acceptable. With the agreement of the PM, an outside Expert was called in to review the effort to date and make a recommendation. Then a joint meeting was held with the Expert, the PM, the Program Manager, and the primary contractor where it was decided that the best thing to do was to work together to complete phase one and then terminate the project, with a clean handover to another team to tackle phase two. Although disappointing to everyone, the close and frequent communications of both progress and concerns throughout the project with upper management and the client, offered in timely, digestible amounts, reduced their expectatior is and protected the client from a surprise at the end. Honest, consistent communication throughout the project life cycle resulted if improved trust, integrity, and confidence in the vendor and their team. Questions: What are your thoughts about doing everything right and the project still failing? Does the admonition "Never surprise the boss!" now make more sense? Why? Do you think the scope change at the beginning was the problem here, or was there going to be a problem anyway