Skip to main content

Author: Keith Ellis

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.

It Ain’t Easy Being Agile

You have to admit – agile folks are conflicted. On one hand there’s the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We’re facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, “can I write down this non-functional requirement?” Agile is still a storm of mixed messages – and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.

 

itainteasy1

Let’s get away from the hype and look at the facts of performance – meaning development efficiency, timeliness and stakeholder satisfaction. I recently looked at all of these variables in a large scale research study – The Business Analysis Benchmark. What I found is that Agile, Waterfall, Iterative, Prototyping/visualization-centric approaches all performed identically. Statistically there is absolutely no difference between any of them. What creates the performance difference is the level of requirements discovery and management maturity behind the primary SDLC selected. Any hype that says agile practices are universally better is simply wrong and detrimental over time. It will lead to very large scale and eventually public failures – and a counter-movement away from these practices. This would be a real shame. Agile is great stuff when used correctly.

Methods and practices of business analysis have to follow the mantra of “the right practices at the right time.” You can’t use OLTP analysis practices/techniques and expect to produce effective requirements on a data warehouse. It’s silly! Similarly, you want to target agile practices to the right projects where agile makes the most sense and have enough corporate requirements discovery and management maturity to know the difference. Anything else is like trying to blast a square peg through a round hole. If the stakeholders don’t want to participate in scrum meetings every day… get onto another track! If you’re dealing with something data driven or with very high numbers of transactions in a regulated system – run away… don’t walk. Yes, you could do it… why would you? I could run around on the freeway too, but I’m suggesting there are better ways to use some roads. In the long run, using the right techniques at the right time will pull far more momentum to the movement than creating hype and watching the carnage.

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.

Requirements ATTACK!

In my job, I get to hang out with a lot of very senior people and talk with them about requirements and business analysts. The one complaint I hear over and over: “Our BAs are not proactive”. Maybe some in the organization are being a bit passive, but the executives I talk with are most concerned that the BAs are order takers, rather than being seen by the business as really driving the process. You need to ATTACK requirements. Be proactive! And, know the right questions to ask to motivate stakeholders to get you the right kinds of information. Here’s the problem – many analysts get in the way of their own success.

Remove the Barriers

It’s easy to fall into the role of order taker and think the customer can drive the requirements process; particularly in the face of an assertive executive with a fairly clear vision of what they want. I humbly submit, if you roll-over and become an order taker, you’re dead. The requirements on the project will likely be incomplete with significant functional areas missing, and there is likely to be no consensus between executives in the areas of interdependency. Think value-add! The analyst is the one that needs to fill the gap between what the business can articulate for itself, and what the technology department needs as input for successful development. Get people on board with the idea that there is a gap in content that needs to be filled, and remove both the barriers to participation and the barrier to being proactive. If you show you can add value to articulating business needs, you are taking the bull by the horns and being proactive.

Have a ‘Go To’ Process that Always Works

Analysts get caught up in self-flagellation because they have no personal expertise in the business process they are reviewing. Get over it! You cannot possibly be expert in every process and system in the company. Candidly, it’s a fool’s game to try! Even the SVP operating the division must rely on their experts running the subcomponents of the business, as these in turn rely on their subordinates. How can an analyst portray themselves as more expert in every area of operation of the company than these executives without annoying their stakeholders with their arrogance? The analyst is not there to define optimal business practices for the business. The analyst is there to optimize the process used by business leaders to achieve consensus in their practices. The analyst also knows how to take concepts from high level understanding, to clear, accurate and complete documentation.

Before everyone gets angry at me…you absolutely can be expert at doing requirements and getting executives to consensus without being a business area subject expert. Analysts can absolutely be successful where they have a ‘go-to’ process for eliciting business requirements that is easy for participants, and adds value to their thinking process.

First and foremost you cannot get hung up on problem definition. You can do all the problem definition, analysis of issues and look-back reviews in the world and still have massive problems articulating a solution, especially when dealing with something complex. Watch out for the trap people fall into all the time! You cannot consistently jump from problem to solution so spending too much time on getting better resolution on the problem will not get the business closer to solution.

Situation or problem definition can be insightful, but only in so far as it helps bring clarity to the correct needs, objectives and goals. With a solid understanding of objectives and goals, it is not a large step forward to ask: “To achieve these objectives and goals, how must the business process change?” Discovering, eliciting, and describing the processes that change in response to meeting an objective business is the goal of an analyst. The ability to be a great analyst is to have the right kit bag of techniques to draw on to help the business articulate these changes in a systematic, clear, accurate and complete way.

ATTACK the Detail

There are lots of ways to break down projects into reasonable chunks using scenarios, user stories, use cases, or any number of techniques. These only get the surface information. To be a proactive analyst, you need to attack the detail and ask the questions that proactively pulls this information out of stakeholders. To attack the detail, think SIPOC (SIPOC stands for suppliers, inputs, process, outputs, customers). It’s a concept the six sigma folks hijacked, but it’s a great tool for business analysts when you use it to describe how information moves in the business process:

For the scenario “price an order” (starts with confirm item details, and ends with provide quote to customer) ask SIPOC in this order:

  1. Input: What information do you need to know to be able to price an order so you can provide a quote to a customer?
  2. Process: What do you do with that information?
  3. Output: What typically happens once you’ve priced the order?
  4. Customer: Does anyone else need to know about the priced order?
  5. Supplier: Is all of this information coming from you, or do you need input from someone else?

Uncovering how information needs to move to support the business process and ultimate business objectives motivating change is the detail an analyst needs in order to get clear, accurate and complete business requirements. We’re in information technology remember!

Ponder Points

Here are some closing thoughts to consider – or maybe comment on – as you get back to the daily grind:

  • As the analyst, YOU are accountable for the process of getting the requirements. If you are accountable for anything, it is to be proactive.
  • Being proactive doesn’t require you to be an expert at all things business. It does mean knowing techniques that add value and can take you from problem to solution.
  • There are a lot of blind alleys out there! Be sure to that you select and adopt techniques that accelerate you along the path from problem to solution in incremental steps, rather than requiring you to take giant leaps from problem to solution.

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.

FAT REQUIREMENTS; How to Lose Weight and Enjoy the Sunshine

Have you noticed the obesity epidemic plaguing North America? Hey, I’m not talking about the kind you get when eating the wrong foods – I’m talking requirements obesity. Generating fat, hulking, documents that look terrible on the shelf gathering dust is not at all conducive to enjoying the summer fun. Here are a few ideas for slimming-down those requirements. Not only will you experience the joy of actually being ‘done’ and getting into the sunshine, people will better understand what the business wants, and projects get to be more successful. How cool is that as a win-win for everyone?

  1. Split requirements documents into three: scoping, business requirements, and detailed requirements. Most people don’t make this separation and end up spending way too much time detailing functionality that will never see the light of day, or in detail levels that are completely unnecessary for the task at hand. Remember – iterate.
  2. Separate the WHAT from the HOW. Get clear on WHAT the business wants to do before you start to detail HOW it is going to do it. Over and again, I find myself mired in a review of details that are not only clearly inappropriate, but inconsistent, because there was just too much about how some technical aspect of the system was going to be ____________ [fill in the latest technical jargon term]. Get people back to basics here and you’ll find both faster cycle times on projects, AND, vastly simplified requirements documents.
  3. Concentrate on just the right information. Business requirements fall directly out of understanding the desired state of the process flow, data flow, and business rules of the business. The actual ‘requirements’ are the structured statements describing the gap between current state and future state in these areas. Can we agree that this is Business Requirements? If so, why blather on about business case, or get into interface design, or have an opus on the history of compliance. It’s not really necessary. Sure, you need to have some additional pieces like a data dictionary if you hope to have everyone on the same page when you use the term “Customer”, but we’re not dealing with a lot of additional information.
  4. I’m willing to bet, in North America, more projects have managed to kill their intended benefits by failing to identify and manage interdependency than pepperonis have been killed to make pizzas. Business professionals need to have interdependency drawn out for them because this is the stuff where executives actually have to make decisions and love you for bringing it to their attention. Get into using context diagrams – every line on that diagram is an interdependency; or, at least have a section for this in your documentation
  5. Negotiate the details. Every project is different and needs different detail to bridge from business requirements to system design. It’s natural that a system selection/implementation will have fundamentally different dynamics than an off-shore design/build. In the face of high quality business requirements, the nuance of what detailed requirements should be for this project at this time can be negotiated amongst the project team. You’ll invariably end up with a tighter definition of what is needed, and better project momentum with recipients when you deliver what they’ve asked to receive.
  6. Remember – ALL YOUR STAKEHOLDERS ALSO WANT TO BE IN THE SUN TOO. Make the process efficient for everyone.

This is not about being lazy – this is about being hyper-efficient when it comes to projects. In candor, executives respect analysts that can make them, and their project team, more proactive and productive. Driven to extreme, you can wallow in requirements detail until the winter months start blowing frozen air over the corpse of your project. But, is this valuable – or can you get to the right information more efficiently; get better process around developing the information, and yield successful results faster? I’ll tell you – absolutely, yes, you can! Take a look at the base of www.iag.biz research – you can be iterative, reduce time to get requirements by 58%, AND STILL have documentation quality high enough to drive down change requests by 75%. So, what do you do with the 58% less time? Why, it’s summer. Go to the beach!

I bet every experienced analyst out there knows where to chop out fat without sacrificing requirements quality. I’d encourage you to share your stories of obese requirements – or fat-chopping solutions.


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.

Business Analysis Benchmark

How Business Requirements Impact the Success of Technology Projects

The Business Analysis Benchmark report, conducted by IAG Consulting in late 2008, presents the findings from surveys of over 100 companies and definitive statistics on the importance and impact of business requirements on enterprise success with technology projects. The survey focused on larger companies and looked at development projects in excess of $250,000 where significant new functionality was delivered to the organization. The average project size was $3 million.

The study has three major sections:

1 Assessing the Impact of Poor Business Requirements on Companies: Quantifying the cost of poor requirements.

2 Diagnosing Requirements Failure: A benchmark of the current capability of organizations in doing business requirements and an assessment of the underlying causes of poor quality requirements

3 Tactics for Tomorrow: Specific steps to make immediate organizational improvement.

In addition to the full text report, these sections have also been published as stand-alone white papers for ease of use. All can be accessed from www.iag.biz.

The study provides a comprehensive analysis of business requirements quality in the industry and the levers for making effective change. The following issues are addressed in the report:

  • the financial impact of poor quality requirements;
  • the information needed to identify underlying issues critical to success; and,
  • the data necessary to target specific recommendations designed to yield performance improvement.

The report finds two basic scenarios for companies:

Scenario 1: Project success is ‘Improbable’. Companies might be successful on projects, – but not by design. Based on the competencies present, these companies are statistically unlikely to have a successful project. 68% of companies fit this scenario.

Scenario 2: Project success is ‘Probable’. Companies where success can be expected due to the superior business requirements processes, technologies, and competencies of people in the organization. 32% of companies fit this scenario.

babenchmark1

Almost everyone understands that requirements are important to project success. The data above demonstrates that while people understand the issue, they did not take effective action in almost 70% of strategic projects.

Effective Business Requirements are a process – not a deliverable. The findings are very clear in this regard – companies that focus on both the process and the deliverables of requirements are far more successful than those that only focus on the documentation quality. Documentation quality can only assure that investment in a project is not wasted by an outright failure. The quality of the process through which documentation is developed is what creates both successes and economic advantage. To make effective change, companies must rethink their process of business requirements discovery.

The following are a few key findings and data from the study:

1 Companies with poor business analysis capability will have three times as many project failures as successes.

2 Sixty-eight percent of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any two of:

  • Taking over 180% of target time to deliver.babenchmark2
  • Consuming in excess of 160% of estimated budget.
  • Delivering under 70% of the target required functionality.

3 Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.

4 Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.

5 The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.

Almost 70% of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. It is statistically improbable that companies which use poor requirements practices will consistently bring projects in on time and on budget. Executives should not accept apathy surrounding poor project performance – companies can, and do, achieve over 80% success rates and can bring the majority of strategic projects in on time and on budget through the adoption of superior requirements practices.

Making Organizational Improvement

The survey findings made it clear that there is no single silver bullet for making organizational improvement. CIOs must look at making improvement across all the areas of people, process, and tools used to support processes to gain organizational improvement. Only a systematic change to all areas of people, process and enabling tools yields material improvement. 80% of projects from the companies which had made these broad-based changes had successful projects.

The findings of the Business Analyst Benchmark describe both the poor state of the majority of companies surveyed, and, a path to performance improvement. To assist the reader, this report also analyzes the data for alternative actions which could be taken to make improvement in order to separate myth from actions that create benefit. The top three findings in this area can be used to change business results:

  • 80% of projects where successful from companies with mature requirements process, technology and competencies.
  • Auditing three specific characteristics of business requirements documentation and forcing failing projects to redo requirements will eliminate the vast majority of IT development project failures.
  • Elite requirements elicitation skills can be used to change success probabilities on projects.babenchmark3

The above survey findings and the underlying statistics are described in detail within the report.

Overall, the vast majority of companies are poor at both, establishing business requirements and delivering on-time, on-budget performance of IT projects. Satisfaction with IT and technology projects wanes significantly as the quality of requirements elicitation drops. This report is both a benchmark of the current state of business analysis capability and a roadmap for success.

The Bottom Line

The challenges in making quantum improvement in business analysis capability should not be underestimated.

Organizations understand conceptually that requirements are important, but in the majority of cases they do not internalize this understanding and change their behavior as a result. The most successful of companies do not view requirements as a document which either existed or did not at the beginning of a project; they view it as a process of requirements discovery. Only companies that focus on both the process and the deliverables are consistently successful at changing project success rates.

For companies that have made the leap to the use of elite facilitation skills and solid process in requirements discovery, there are significant benefits. Not only were these projects rarely unsuccessful, they were delivered with far fewer budget overruns and in far less time.

The report describes the use of poor requirements process as debilitating. Using this word is perhaps unfair, since companies do not collapse as a result of poor quality analysis. In fact, IT organizations and the stakeholders involved will overcompensate through heroic actions to attempt to deliver solid and satisfactory results. However, ‘debilitating’ is an accurate word to describe the cumulative effect of years of sub-optimal performance in requirements analysis when results are compared to competitors who are optimal. Even leaving out the effect of high failure rates and poorer satisfaction with results, the capital investment in information technology of the companies with poor requirements practices is simply far less efficient than companies that use best requirements practices.

To illustrate this inefficiency of capital expenditure on technology at companies with poor requirements practices, use the average project in this study ($3 million):

  • The companies using best requirements practices will estimate a project at $3 million and better than half the time will spend $3 million on that project. Including all failures, scope creep, and mistakes across the entire portfolio of projects, this group will spend, on average, $3.63 million per project.
  • The companies using poor requirements practices will estimate a project at $3 million and will be on budget less than 20% of the time. Fifty percent of the time, the overrun on the project both in time and budget will be massive. Across the entire portfolio of successes and failures, the company with poor requirements practices will (on average) pay $5.87 million per project.

The average company in this study using poor requirements practices paid $2.24 million more than the company using best practices.

If overruns are common at your company, or if stakeholders have not been satisfied with more than five of the last ten larger strategic projects, there is definitely a problem and your company is likely paying the full poor requirements premium on every project.


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.