A recent study shows how a disturbing number of development projects still fail due to poor upfront analysis.

I think that this oversimplifies – the devil is in the detail. From experience it is about far more than just “the wrong scope” (I’m referring to the project requirements as the “scope”) – it is also about “scope creep,” “scope change” and underlying business change which inevitably results in “scope change.”

If you want to scope a big development at the start of the development, you are going to have a tough choice when the inevitable scope change requests come. Either, enforce the “letter of the law” by referring to the brilliant/bullet-proof requirements documentation you created upfront OR allow the changes and “donate” the work required to the paying client.

Neither option is reasonable. Someone is going to lose out in either case.

There is an answer. It’s called Agile Development. At WWW, we use a particular methodology called “SCRUM.”

The Agile Manifesto puts the issues squarely on the table.

In simple terms: Work in smaller chunks. Deliver business value often. Collaborate with the software owner/sponsor very closely throughout the process. Accept that change is inevitable in software development – accommodate and encourage it. Ensure that everyone on the development team trained and mandated to maximize business value on behalf of the software sponsor/owner. Everyone on the team is both developer and analyst.