It's generally acknowleged that bringing a non-trivial software project to a successful conclusion is problematic. Sadly statistics confirm that few projects can be regarded as successful when one strictly applies the criteria that a successful project is one that is delivered on time, on budget and to specification. Delays, budget overruns and the delivery of solutions that aren't actually of value to stakeholders are common symptoms.
Most commonly people point to issues with the determination and management of "requirements". Certainly issues related to requirements engineering and the mismanagement of stakeholder expectations is at the core of most project failures. It's exceedingly rare that a project is jeopardised because of an inability to solve a technical issue.
Why this tour of the dark side of our industry?
Well, I've recently been exposed to (yet another) large problematic project that well meets the above definition of failure. The reason for that projects' issues are standard - no communicated project charter (vision and scope), no management of requirements or expectations, no attention to control, process or quality, no competent leadership. Truly an adhoc, anarchic CMM Level 1 (see pdf page 11) development environment evidenced by the organisations inability to ever deliver a single release to customers as advertised and scheduled.
My prescription in such circumstances? Replace
fire those in positions of authority and put in place competent professional management and technical resources that can adopt and put in place standard industry (best) practice.
What would you recommend?
Update: 30-Jul-06: It has been announced that new external senior management is to be brought in to oversee operations.