Reader Q&A on ‘Surviving Failed IT Projects’

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?

A: If time is an input, scope must be an output. Some people believe that an organization’s top priorities are unsolvable in the short term. As a CIO friend of mine says, if an issue is a top priority, there are a series of unknowns that prevented the issue from being addressed early on, thereby allowing it to grow to a top priority. If this is true, the only approach is to experiment until the problem is better understood and the solution is close at hand.