Business Requirements – we all want them, but how do we get them?

Background

One of the often sited reasons why IT projects fail is not having well defined and understandable requirements. In our decades of involvement with the IT industry; project teams, IT staff and business stakeholders have remained at odds over what constitutes “requirements”. It appears that IT Project teams don’t know what to ask and business stakeholders don’t know what and how to provide the needed information. While many industries sprouted to address this chasm, in our opinion, little has changed.

The focus of this blog is to identify how other disciplines such as manufacturing engineering have been able to address similar challenges successfully and how to apply this mindset to IT. Most importantly is to find answers to the question of what can be done to resolve the endless chasm of requirements.

A Look at the Manufacturing Engineering Discipline

Before I came into the IT industry, I worked as a manufacturing engineer for 12 years. By the time I left this industry, I was head of re-engineering in a global organization. From this experience I can attest that in manufacturing engineering – at highest level – we separated requirements into two broad categories:

• Identify characteristics that define the problem space. For example – if a current assembly line produced 100 units per hour and we needed the line to product 250 units per hour, holding all other parameters constant, except for raw material inputs. We defined requirements as those “things that prevented the line from producing 250 units per hour”, such as machine speed.
• Identify characteristics that define the solution. Generally, there is more than one optimum solution for a given problem. For example, increase the spindle speed on the machine to 750 rev per min in order to pack 250 units per hour. One requirements was to increase spindle speed, second, a by product, to protect the worker at such speed we will need addition safety curtains and possibly upgrade the existing safety controls.

Advantages of this approach

• First, the approach clearly defined that it was the opportunity owner’s RESPONSIBILITY (I am using a RACI terms here) to define the business value of producing 250 units per hour and obstacles that must be overcome in order to achieve the new production targets. This conversation was always facilitated by the engineer; in addition the engineer brought deep understanding of manufacturing capabilities to the discussion.
• Second, once the obstacles were defined and agreed upon by all relevant stakeholders, it was the engineer’s RESPONSIBILITY (via consultation with subject matter experts – SME – and consumers) to identify characteristics of the solution, communicate these characteristics to opportunity owners and subsequently to build and support team members. It was the engineer who had the RESPONSIBITY that the new capability was able to produce 250 units per hour.

Disadvantages of this Approach

• The opportunity owner must be able to define the business value of 250 units per hour and identify all relevant obstacles.
• The engineer must then accept RESPONSIBITY to define, develop and exploit the new capability to enable the production of 250 units per hour and respect all constraints.

Application to Information Technology

In IT, we have a similar approach; we decompose requirements into two broad categories – architecture requirements and other requirements. The other requirements are developed through TOGAF ADM (The Open Group Architecture Framework – Architecture Development Methods) and further get categorized into business, information, data etc. The categorization criteria is frequently based on who develops and consumes these requirements.

• Architecture Requirements define what obstacles must be removed in order to transition the capability from the current state to the new state. Thus, it is a prerequisite that the capability’s performance must be unambiguously measurable. Architecture requirements then are explicitly stated by the capability owners and SME. These are frequently solicited through facilitated sessions by the architect who brings deep business domain and architectural thinking expertise.
• Other Requirements are developed by the architect and the project team through business, data, application and infrastructure architecture process that is executed iteratively. The iterative stages include – instinctual, contextual, conceptual, logical and physical and enable the just in time requirement definition and consumption.

Similar to the manufacturing engineering discipline, roles and responsibilities are explicit and performance of each stakeholder, be the capability owner or capability developer can be explicitly measured.

Challenges

We have several challenges in applying the manufacturing engineering approach to IT.

• Our business stakeholders as well as IT do not think in terms of capabilities. Capabilities are very rarely explicitly defined and agreed upon. A collage of noise from various stakeholders – some defining problem and other defining a solution – gets packed into “requirements”.
• Lack of a process to explicitly elicit and validate capabilities and architecture requirements. We are often happy to take whatever business provides, i.e. noise and start defining systems from it.
• No clearly defined RESPONSIBILITY for the capability. IT frequently assumes it is their job to provide systems that meet the nebulous business requirements knowing full well that system and business capabilities are mutually exclusive. Unfortunately the status quo process is too powerful to stop or adapt to change.

How do we overcome this chasm?
In order to overcome this challenge , we need to develop new skills in business and IT to elicit and analyze:

• What is the Enterprise’s Strategic Intent?
• What Value Map, horizontal and vertical capabilities will enable the intent?
• How do we define the transition roadmap and business case for each capability by understanding the architecture requirements and engineering all other requirements?
• How do we define the organization change requirements so we can effectively manage the impact of change on the people of the organization?
• How do we measure the performance of the transitioned capability?
• How do we explicitly relate the new capability to Enterprise Strategic Intent?

We at QRS have developed a Business Architecture course that will provide you some practical insight and tools to help close the indomitable Requirements Chasm.

Business Architecture Course Outline and Schedule