Large Scale IT projects and Continuous Requirements

There has been a lot written about large scale IT projects and the desire to transition

to Agile. Organizations driven by the need for speed are adopting Agile in increasing numbers for their projects.   There hasn't however been enough study done on Agile success in large complex projects.   I came across this article from some experts at Boston Consulting Group who looked at a large projects and they have developed some sound recommendations for business leaders embarking on large IT projects.

The article references the famous Standish Group Chaos report that says the odds of delivering success on a large scale project are 1 in 10.  There are a number of key factors that they identify. Some of the key ones are:

• lack of engagement from key stakeholders
• not paying enough attention to risks
• requirements that are too unclear or too complex relative to the business need.  

Regardless of the approach and methodology you use for these projects, organizations must face these realities head on or risk being another failed project statistic.

The article goes on to offer some excellent advice on setting projects up for success. One of the things they talk about is the need for a methodical way to design and validate the solution and deliverables. Project teams must make sure teams spend time up front to get agreement and clarity on the project business requirements,benefits and costs.   Even if you are adopting Agile - resist the temptation to quickly launch the project and show quick success - as lack of clarity is a root cause for many failures.  

We see teams argue that BRUF (big requirements up front) doesn't work and can't keep pace with the pace of business.  We also hear -'we don't do requirements as we are Agile'. In my opinion the answer lies in a pragmatic approach.  There are aspects of the project that are well defined, unlikely to change during the life cycle of the project.  Many of these known outcomes and constraints fall into the category of business needs and nonfunctional requirements. These should be captured, communicated and understood by all involved in the project before coding begins.   There are other desires and outcomes that cannot be determined before the project begins, and are likely to change during the project.  These need to be handled on a continuous basis. For many large projects there is a need to keep historical records of decision and changes in requirements after the project concludes.  This concept of managing requirements before, during and after the project is what we refer to as continuous requirements.


The original article from BCG that inspired this blog post is  Large- Scale IT Projects: from Nightmare to Value Creation - by Jon Brock, Tamin Saleh and Sesh Iyer.  

This article is well worth reading for any project team embarking on a large scale IT Project   http://bit.ly/BCGLargeScaleITProjects