When is a software development project successful?
Is it when funding is approved for the project?
No, because that’s a first step, but nothing has actually happened yet in executing the project.
Is it when the requirements are successfully defined?
No, because nothing’s been built yet.
Is it when the development is done?
No, because nobody has used it yet.
Is it when the testing is done?
No, because no real-world benefits have occurred yet.
Is it when the product launches to users?
No, because users haven’t used it in their process yet.
Is it when the product achieves 100% user adoption?
No, because 100% adoption does not mean it has done any good for anybody.
Is it when the product has been in use for a year?
No, because just using it does not ensure that it has achieved any benefits.
Is it when the product achieves its success metrics?
Maybe.
That’s only true if the success metrics are still relevant to the organization’s bottom line. As time goes by, many strategic directions are often abandoned or changed, and the benefits of the project don’t matter anymore.
Is it any wonder why so many projects fail? They have to run a long gauntlet of steps, are passed through hundreds and sometimes thousands of people, and years may go by before any modicum of success can be realized. All this time, tons of money and effort are being spent in pursuit of an uncertain result. This is why agile development and agile requirements are so critical.
What are the chances that something significant will change in the industry, or in your organization, during the period of time before your project becomes a success? Virtually 100%. That’s why agility is essential, why agile development and agile requirements help, because you’re almost guaranteed to miss the mark if you don’t change your project to reflect the ever-changing current situation.
Having a successful project is not impossible. However, do not underestimate the value of agility to save a project from failure long before it’s had a chance to succeed.
