Requirements at the Speed of Business

Registration is free. Login or register to view/download this content.


Owner, Frank Fabian Group
Frank Fabian is an entrepreneur, business architect and management consultant. He has worked in the IT industry for over 25 years in various architectural roles from commercial energy management systems to government logistics and supply chain systems. Frank understands the business side of an enterprise as a former co-owner of a manufacturing and retail company. Frank is an active member of the Business Architecture Guild. He is considered a big-picture thinker who can dive deep into a problem with a laser-focus to discover the cause and model an innovative solution. He has a proven track record of 149 successful projects and products that span a multitude of markets realizing evolutionary and revolutionary designs. Frank’s current start-up, the Frank Fabian Group, aids companies that want to apply business architecture practices to their real-world problems.

How many of you have heard the statement “The project failed because we didn’t have good requirements”? I’ve heard it dozens of times. It doesn’t matter whether it’s from seasoned project teams or ad hoc teams. The single biggest reason for project failure is a problem with the requirements. Even with agile processes in place, I see the same things repeated over and over. In doing post-mortems on projects that failed and projects that succeeded I have found some common traits.

  • The understanding of the expected outcome of the project.
  • Stakeholders providing input in their own best interest.
  • Assumptions made on the business side that prove to be false.
  • The desire of the project team to get started doing something “worthwhile”.

If you start to ask questions related to these four traits, you will begin to see where project difficulties arise. So many times the technology teams expect certainty to be created out of uncertainty and decry the requirements as being bad. Let me share with you what should be considered up front before any requirements are ever gathered or a single user story is written.

Understanding the Expected Outcome

Projects don’t get created for the sake of keeping project teams busy. They are created to solve a business need whether it is a problem to be solved or to take advantage of an opportunity. According to Henry Mintzberg, many executives communicate the business needs verbally, which leaves the desired outcome somewhat nebulous. That desired outcome is further corrupted and embellished as it is communicated through layers of managers who impart their own biases, desires and needs onto the projects.

The key to moving forward is for the business architect to realize that customer needs are translated into business objectives. The desired outcomes from meeting these business objectives become the focal point. The raw customer input needs to be maintained, but the desired outcomes focus on meeting the stated objectives. It was Henry Ford who is often quoted as saying “If I gave my customers what they wanted, they would have gotten a faster horse.”

When supporting a given project team, it is important to ensure that everyone understands the expected outcome. Ask your current project teams what their expected outcomes for their projects. Scope is not the same as the expected outcome. Scope defines the expected breadth of coverage of the output of the project. Outcome is the business gain achieved by the project output.

So, if the objective was to implement an e-commerce solution for the organization, the scope of the project would be to implement an online shopping cart, which is the output of the project and the expected outcome is an increase in profits through a new e-commerce channel.

Stakeholders have Their Own Interests

Most requirements “gathering” events are with the stakeholders. Just who are the stakeholders and what can they provide? If you look at the typical make-up of a group of stakeholders for a project, many of the teams worked with chose managers who would be the owners of a new system. While we all like to believe we are unbiased, most stakeholders provide “requirements” that fit their own self-interests. Let’s face it, we all are most concerned with our own work first – we’re human.

Using the e-commerce solution above, if the company was looking to supplement their current direct mail sales with an online presence, the direct mail sales manager may want the shopping cart to collect the complete address of a contact so they can bombard them with direct mail. Most online users don’t like to give that much information up front just to look at a website. Instead of accomplishing the expected outcome of more overall sales, the website sales perform poorly because customers abandon the website as soon as they are asked for too much information.

Keeping stakeholders focused on the true outcome is not easy. But as requirements analysts, all those “requirements that don’t support the project’s outcome have to be listed as wish list items and be very carefully scrutinized.

The next issue is getting the right group of stakeholders together. Capability maps and value streams are extremely useful for framing project scope and identifying the right set of stakeholders – not just the important stakeholders.  When you know what capabilities of the business are affected by a project, the list of stakeholders are from the affected capabilities. The producer and consumer stakeholders are obtained from the value streams, which also provide cross-mapping to the relevant capabilities in the context of stakeholder value delivery.

Assumptions made on the Business Side

Let me start by saying that ALL projects are from the business side. If you separate IT projects from business projects you are headed for disaster. Going back to outcome-based solutions, the output of any project, IT or otherwise, is to support a business gain.

For those of you who follow Eric Ries and his “Lean Start-up” methodology, many business objectives are based on assumptions. We assume that if we build a shopping cart, customers will want to use it. Or that if we capture website user’s clicks on our website that somehow we can predict what they will do. Assumptions make for really bad requirements.

Let’s follow that by what most project team’s want – hard, specific requirements. So how do we jump from the soft, squishy objectives based on assumptions and get to reasonable requirements? For example, I need to generate $5 million this year from our website. That sounds pretty solid, but it’s wild assumption. No set of shopping cart requirements in the world is going to make that happen without some help.

Architects need to assist analysts in separating out the soft squishy stuff from the fairly reliable hard and fast needs in order to help define the system requirements. It’s easy to see how a site that accepts credit cards must be PCI-DSS compliant (Payment Card Industry Data Security Standards), unless of course you like being in the news.  However, how products are sorted and displayed is squishy stuff. By knowing it’s an assumption, the analyst can better prepare the team to deal with that feature either by designing into it the ability to rearrange items at the drop of hat, the ability to do A-B testing, or at least expect that requirement to change as the project moves forward.

One of the techniques I have found useful comes from Rough Set Theory as proposed by Zdzisław I. Pawlak. The main concept I’ve drawn from Rough Set Theory is that elements can be tagged with a crispness / vagueness attribute. The crisper the business architect can define the attributes for the expected outcome, the easier it is to create requirements that can be defined by the standard “The System shall…” The vaguer the attributes, the further need for more research, a prototype or anticipated changes in the project. In agile terms, you may need to do a few throw-away sprints to produce some prototypes.

In today’s rapidly changing environment creating an entire set of requirements that doesn’t change over the span of year is next to impossible. A good change process must be incorporated into projects and looked at as providing the best possible outcome instead of a nuisance. Know the assumptions. Eliminate the vagueness by dealing with the uncertainty. It’s time to stop blaming the business side for not providing hard requirements and start understanding how business really works.

The Desire to get Started

The final trait that is highly typical amongst project teams is the desire to get started doing something productive. Of course after the kickoff there appears to be two typical ways a team might go. The first type just wants to get started coding. The second gets stuck in details – the dreaded “Analysis Paralysis” Agile has really influenced the teams that want to start coding first and figure out what to do later. Building the wrong thing faster or using the theory that you’ll know it when you see it are recipes for failure.

I’ve heard teams tell me that we have our user stories, we can start. We are doing Agile, we don’t need to wait for requirements or design. I’ve seen a few teams do this right, where they determine the outcome and built to it. If every team did that, then projects would finally start to meet the business needs. In agile, the user stories are based on – wait for it – Stakeholders! I just finished going over why stakeholders don’t have the expected outcome in mind, yet we base our project direction on their words. They must know what’s needed, don’t they? Some do, but the focus really needs to go back to the expected outcome – the business sense of what the project’s output should accomplish.

Final Notes

Not every team falls into these traps. Unfortunately, I’ve seen far too many that do. The projects in the deepest trouble always seem to be the same projects that complain that they were given lousy business requirements or that the customer doesn’t understand what they want.

It’s time to reverse the mirror and have project teams take a good look at themselves. If you feel you have lousy business requirements, then you probably don’t understand what the expected outcome should be and are unclear on scope. If you think the problem is that the customer doesn’t understand what they want, then the teams need to go back to their management and obtain clarification as to what the expected the outcome of the project is to accomplish.  There is no such things as a purely IT Project – unless of course people never touch, see or interact it. The business outcome is the priority and business architect can help frame the discussion, related requirements and overall scope. Until projects satisfy the expected outcome, business leaders will continue to claim that 60-70 percent of projects fail to meet their needs.

Similar Resources

Featured Certificate: BPM Specialist

Everyone starts here.

You're looking for a way to improve your process improvement skills, but you're not sure where to start.

Earning your Business Process Management Specialist (BPMS) Certificate will give you the competitive advantage you need in today's world. Our courses help you deliver faster and makes projects easier.

Your skills will include building hierarchical process models, using tools to analyze and assess process performance, defining critical process metrics, using best practice principles to redesign processes, developing process improvement project plans, building a center of excellence, and establishing process governance.

The BPMS Certificate is the perfect way to show employers that you are serious about business process management. With in-depth knowledge of process improvement and management, you'll be able to take your business career to the next level.

Learn more about the BPM Specialist Certificate





  • Business Process Management Specialist
  • Earning your Business Process Management Specialist (BPMS) Certificate will provide you with a distinct competitive advantage in today’s rapidly evolving business landscape. With in-depth knowledge of process improvement and management, you’ll be able to take your business career to the next level.
  • BPM Professional Certificate
    Business Process Management Professional
  • Earning your Business Process Management Professional (BPMP) Certificate will elevate your expertise and professional standing in the field of business process management. Our BPMP Certificate is a tangible symbol of your achievement, demonstrating your in-depth knowledge of process improvement and management.


BPM Certification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Process Management Certification from the industry's top BPM educational organization.




  • Operational Excellence Specialist
  • Earning your Operational Excellence Specialist Certificate will provide you with a distinct advantage in driving organizational excellence and achieving sustainable improvements in performance.


OpEx Professional Certificate

  • Operational Excellence Professional
  • Earn your Operational Excellence Professional Certificate and gain a competitive edge in driving organizational excellence and achieving sustainable improvements in performance.



  • Agile BPM Specialist
  • Earn your Agile BPM Specialist Certificate and gain a competitive edge in driving business process management (BPM) with agile methodologies. You’ll gain a strong understanding of how to apply agile principles and concepts to business process management initiatives.  

Business Architecture



  • Business Architecture Specialist
  • The Business Architecture Specialist (BAIS) Certificate is proof that you’ve begun your business architecture journey by committing to the industry’s most meaningful and credible business architecture training program.

  • Business Architecture Professional
  • When you earn your Business Architecture Professional (BAIP) Certificate, you will be able to design and implement a governance structure for your organization, develop and optimize business processes, and manage business information effectively.

BA CertificationCertification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Architecture Certification from the industry's top BPM educational organization.




  • Digital Transformation Specialist
  • Earning your Digital Transformation Specialist Certificate will provide you with a distinct advantage in today’s rapidly evolving business landscape. 


  • Digital Transformation Professional
  • The Digital Transformation Professional Certificate is the first program in the industry to cover all the key pillars of Digital Transformation holistically with practical recommendations and exercises.



  • Agile Business Analysis Specialist
  • Earning your Agile Business Analysis Specialist Certificate will provide you with a distinct advantage in the world of agile software development.


  • DAS Certificate
  • Decision Automation Specialist
  • Earning your Decision Automation Certificate will empower you to excel in the dynamic field of automated decision-making, where data-driven insights are pivotal to driving business innovation and efficiency.