Simple truth of successful projects

After decades of technology implementation experience and wisdom, the evolution of a range of methodologies, amazingly great tools to manage programs and remarkably superior software development platforms, why do we still continue to see project failures?

What differentiates a successful technology project from an unsuccessful one?

In my experience, project success i.e. original scope, in time/budget, boils down to some fairly simple things. Ohh...and these observations are mostly inspired by CRM and business technology implementations - not sending people to Moon etc. So, here goes...

1. A shared sense of accountability tied to career success - "We can tell you our policy, how you implement it is up to you."

Unless the Technology, Business, and other leaders share a sense of accountability (which is typically tying project success to career success at various levels), these projects are the first one to die. Often this is a cultural issue, but the opportunity to apply this at a small scale exists in most organizations.


2. Singular clearly understood theme and timeline - "Implement Web-based Self-service for European customers by Q4."

When a project's mission is something that everyone on the team can understand, the omnipresent scope creep can be effectively managed. Projects that have a vague or expansive theme run into successive scope adjustment that eventually takes its toll.


3. Time-boxed and repeated delivery - "We ship every quarter to (a handful of) actual users."


I am yet to see a project that did this and failed. Sure, the scope changed as actual usage drove the evolution of the roadmap, but that kind of change is totally worth investing in. Perhaps the simplest to understand and yet, the most missed.


4. Recognizing that we are not a special snowflake - "This won't work for us because..."


Packaged software implementations that spend Millions of dollars on customization are often caused by the 'Business as usual' mentality. Successful projects learn from Subject Matter Experts, prudently change business processes and justify custom development ROI.

Do these sound familiar? Are there others that you were expecting to see? Please comment. Thanks.