Skip to main content

Maturity is More than Looking for Grey Hair and Wrinkles

The concept of capability maturity has been around since Deming first started the quality movement in the 1950s. So what’s a “mature” business analyst? Are we really looking for grey hair and wrinkles to determine that individuals or collective organizations are consistently going to perform at a high level of quality? Is there some measure of “prune-i-ness” that you can use to pick out top performers?

I think not.

Overall, if an organization wants to change the performance level of its business analysis function, it has to focus on six underlying capabilities: processes, practices, people, technology, organization and deliverables. Sure, you can get a short term bump in productivity by being draconian, but it is simply not possible to make material, sustained change without systematically addressing these six capability areas. The question in each of the six areas is not whether you have, for example, processes or not. The question is the degree to which an organization accepts and adopts that process as the best possible way of doing things. This means that some organizations think they have a process for requirements definition and management … but admit it’s actually quite ad hoc. At the other end of the spectrum, organizations have institutionalized the process, and can describe their efforts to continuously optimize this process so that it’s alignment to delivering stakeholder value is maximized. These two examples are the extremes of requirements definition and management maturity.

As an organization gets more mature (getting less ad hoc and going more institutionalized in processes, practices, skills, etc.) it radically changes its overall productivity. This productivity is a real, tangible thing you can measure. In fact, the maturity of business analysis capability dramatically reduces things like time-to-market for IT centric services, and makes little problems like over-runs and project failures start to go away. What people tend not to realize is that maturity – and the overall level of value delivered by an analyst organization – is also measurable. Maturity of requirements definition and management within organizations is a real, tangible thing – and no… it’s not based on looking for grey hair on the leadership, or seeing especially wrinkly analysts.

A funny thing happens when organizations suddenly wake up realize that poor requirements are killing their business (and likely careers). CIO’s think that fixing the problem of poor requirements can be solved purely by hiring smart people. I call this, “attempting to adjust the overall performance of your organization purely through the ‘prune-i-ness’ of your analysts”. Its results are as bad as it sounds and the CIO eventually takes the fall for having such expensive people on the payroll. In fact, lower skilled people in high requirements definition and management maturity organizations will VASTLY outperform highly skilled people in low maturity organizations. Getting performance is not strictly about adding grey hair, it’s about addressing the underlying issues that cause poor requirements: poor processes, lack of techniques, poor organizational support, lousy technology, incomprehensible requirements deliverables, and yes, there also might be an issue with skills.

Don’t forget to leave your comments below


Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.