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

Why Continuous Requirements Are Critical To Agile IT Project Success

Requirements Management is going through a lot of change lately. As large enterprises truly scale and adopt Agile methodologies for big, complex, global rollouts, they have traditionally been focused on the people and processes that are necessary to make this happen. 

When it comes to technology the focus has traditionally been on Rally, Jira, VersionOne and other Agile Task Management solutions. With the ability to produce more and to iterate much faster, the pressure quickly fell on the testing functions as this was the next bottleneck in the process.

Many organizations are now finding that the age-old problem of building the right solution, at the right time is still somewhat elusive. Improving the 'front-end of the process' has not been prioritized with adequate time, focus or energy. 

We know that putting all the burden on a Product Owner is difficult, if not impossible. We need to find a better way to manage the front end of the Application development process. Going back to the 'document and freeze' formal BRUF/BRD process will not keep pace with the needs of modern business. 'No requirements', 'it is in the backlog' and 'the code is proof' don't work for large complex projects. We, at Blueprint, believe that the notion of Continuous Requirements is the right direction for these enterprise Agile initiatives.

We are funding research on this topic, which we expect to have at the end of April, but it's great to see Kurt Bittner at Forrester, and Tom Murphy at Gartner, both articulating a position that it's time for more analysis, dialogue and action in this area.
Tom Murphy blogged about this just yesterday http://blogs.gartner.com/tom_murphy/2016/03/23/updating-requirements-market-guide/