Q: How many “death march” projects are because of poor management, and how many projects spiral downward due to lack of support from senior management? Sometimes project managers mean well but have their hands tied?and get blamed for the failures. Do you have statistics of this nature?
A: Edward Yourdon believes death march projects exist because people are essentially idiots. If you take the time to review his more detailed analysis of the reasons for death march projects (including politics, naive or overly aggressive promises and optimism, and unforeseen pressures due to competition, regulation and so on), it is easy to see that there is plenty of blame to go around?at senior and junior levels, both in and outside of IT. Rather than placing blame, though, I think it’s the job of senior managers to summon the courage to get their hands dirty, avoid the allure of unreasonable leadership edicts, and exert the influence necessary to bring projects back to reality.
Q: Your trump-the-time-frame suggestion suffers from a general management fallacy: to give an end date for a deliverable rather than produce a reasonable estimate. Your suggestion will result in project personnel saying they will do what management wants, and then five months into the time box, they’ll tell the bosses that they are going to miss by three months.
What I expected to see in your column was an emphasis on planning. In my more than 20 years in IT projects, I have found that projects fail due to a lack of planning at the beginning. Project disasters occur because managers are not honest with the project teams, or with themselves. Tricks on the time line or the business case will not change an executive who is not willing to listen. A: Project scope is often determined subjectively?more like a popularity contest rather than a fact-based, rational business decision process. If we take the approach of letting scope be the input and time the output, then project scope will always be too big and the time frame too long. But if we let value and time be inputs and scope and resources be the outputs, then we give the project team the opportunity to tell us what the alternatives are (given different assumptions).Q: When a project gets out of hand, how does one manage to get to a solution, with no change in resources and budget? Is a down-scoped solution viable?
