You'd think that we'd be smarter about IT projects by now.

You think that we'd be tired of the horrifying rates of failure, and the crushing consequences of those failures.

But if you are not spending more time understanding your customers - and developing tightly scoped requirements to make great software to meet their real needs, not some imagined "needs mash-up" cobbled together by the squeakiest wheels in your organization - you're part of the problem, and you're accepting failure as an ever-present option.

It's time to stop the madness.

It's time to reduce the waste of multi-million dollar projects that get scrapped^1, it's time to reduce public IT scandals (see a recent lawsuit claiming racketeering by SAP and Deloitte)², it's time to step away from billions in cost overruns inpart from "inadequate requirements management."³

Most IT executives are familiar with the data on project risks, including overages and failure to meet business needs.⁵ But it's even worse than that. The risk described by Bent Flyvbjerg and Alexander Budzierin the September Harvard Business Review is that one out of six IT projects incurs "a cost overrun of 200%, on average, and a schedule overrun of almost 70%"⁶ - overages significant enough to cause austerity-inducing budget deficits for government, put corporations out of business, and end careers.

It's time to get smarter about great software, and one way to do this it to take a strategic view of requirements. A strategic view ofrequirements is not merelyconcerned with improvingrequirements or improvingprojects; it incorporates a direct connection between customer needs, IT spend, and strategic initiatives.  It's requirements for grown-ups, and it involves maturing requirements.

The maturity model isn't just for app dev - it's for requirements as well. While most organizations follow an ad hoc methodology for portfolio management and controlling project scope, a "requirements mature" organization will find that all of IT understands the strategic  value of every project (which means that IT is aligned with internal AND external customers) and can make daily decisions based on those values.

So, just what might this maturity process look like?

It might look like a Requirements Center of Excellence. Here's one model for the increasing stages of maturity:

Stage 0: Ad Hoc. There is no requirements maturity. Requirements are created ad hoc, project scope is based on "squeaky wheel"direction. The RCOE vision is laid out; influencers and strategy stakeholders are identified.

Stage 1: Individual. Although individual efforts may align with business strategy, there is no consistent measurement of business return.

Stage 2: Team. Teams now share an understanding of business objectives; some individuals may share an awareness of strategy. While individual projects may be measured for return, there is no organization-wide validation of project return yet.

Stage 3: Business Unit. There is strong portfolio management across multiple teams. Teams and finance consistently define and evaluate the project return across the portfolio. More than one business unit may be at this level of maturity.

Stage 4: Organization. Throughout the organization, there is strong portfolio management based on organizational strategy. The scope of projects is aligned with the strategy, and the entire portfolio is regularly analyzed for business return.

The end game: maturity, and iterating on nirvana.

I've talked about IT failures, and how knowing your customer leads to better requirements leads to better software leads to better business outcomes. It is possible to get there. By making requirements strategic and by incorporating business strategy into requirements, not only will requirements mature faster, but those more mature requirements processes will lead to consistent business benefits.Which means great customer experiences, which come from great software.

Resources

http://www.seilevel.com  "Requirements Defined"

http://methods-and-tools.blogspot.com/

http://enterprisesto.blogspot.com/

http://requirements.seilevel.com/blog/

References:

¹ http://spectrum.ieee.org/computing/software/why-software-fails

² http://www.enterpriseirregulars.com/33555/marin-county-claims-racketeeri...

³ http://www.zdnet.com/blog/projectfailures/department-of-defense-it-years-late-and-billions-over-budget/11123

⁴ http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think...

⁵ http://spectrum.ieee.org/computing/software/why-software-fails/0

⁶ http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1