Update: This post refers to the concept of a failing project, not any particular project.
No, I didn’t misspell the title. I am trying to convey the horrendous nature of watching a project hurl itself into failure. I’ve been hired by management several times to reverse a failing project. My optimism about being able to rescue a project from hell quickly fades on that first day.
No users involved in the project – We don’t need no stinkin users.
Scope of project is off – We aren’t quite sure what we’re making.
Poor Change Management – Oh they just tell us what’s wrong and we fix it.
Technology Choices – Our team lead likes that tool, so that’s what we use.
Changing Business Needs – They don’t really need it anymore, but we’ve already started.
Unrealistic Deadlines – The first release is due in two weeks, we started yesterday.
User Resistance – We don’t want it, we don’t need it and you can’t make us use it.
No Sponsorship – The spearhead for this left about a month ago…
Team Member Skill Level – We’re just finished training on X this morning.
No Best Practices – The Y team is different, we don’t use their methods.
J.S. Reel writes about Ten Signs of IS Project Failure via K.D. Maxwell and R.J. Custer. Robert Gordon writes about Projects that Succeed: 7 habits of IT Executives that know how to succeed. Gopal K. Kapur is quoted on his Management’s Seven Deadly Sins via CIO magazine. CardboardNU has checklists that help a project stay on track.