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.
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.
There are no products in your shopping cart.
| 0 Items |
Membership at BAInstitute.org includes access to our other communities.
