You Didn’t Ask For That – Prevent Project Failure With Better Requirements

Image Credit: Boy by Servicelinket (Pixabay.com)

Without clear requirements, projects fail. Most of us know that principle. Yet, poorly thought out requirements continue to be a problem. Incomplete requirements mean upset customers, expensive change requests and delays.

Here are a few different scenarios where projects fail due to poor requirements:

• No Quality Requirement. Professionals generally appreciate the importance of quality. Yet, there are widely divergent quality definitions. Your project might adopt a Six Sigma style quality definition: “3.4 defects per million opportunities.” You may also choose to use a proxy approach such as a customer satisfaction survey. Assumptions about the definition and measurement of quality is a major problem.

• Ineffective Reporting or Incomplete Data Requirements. Reports serve several useful purposes in projects. For example, reports show how decisions were made and KPI (key performance indicator) reports help managers and executives gain understanding over the project. Keep in mind that reports can be both a deliverable (i.e. you are building a system that has reporting capacity) and a project management tool.

• Incomplete Training, Documentation and Change Management. In the excitement to build a new product or service, the supporting deliverables such as training and change management are sometimes forgotten. I can think of several open source software applications that fell short on this criteria. The lack of training and documentation means users will not get maximum value from the project.

Why “Gather Requirements” Is Doomed To Fail

Many business analysts describe their project role as “gather requirements,”: this phrase has a fatal flaw. Why? Gathering implies that requirements are simply out there in the open and need to be picked up. Instead, you have people to work with. At a minimum, you have a project sponsor and users. They may have some big picture ideas about the project’s purpose – “upgrade to Windows 10” or “integrate a new acquisition .” That’s a starting point. Let’s go further to develop requirements by looking at strategy and problems.

Three Ways To Discover Real Develop Requirements: Strategy And Problems

There are two approaches to developing requirements: top down strategic and bottom up studies. A highly effective project will combine both approaches. The top down approach looks at the organization’s strategy and seeks to map the project to that strategy. The bottom up approach looks at the current state to find problems. Here are some examples of how to apply this discovery process.

• Analyze The Organization’s Strategy. In this approach, you simply read the organization’s strategy document and look for ways to map it to the project purpose. The challenge with this approach is bridging the gap between a CEO’s vision and reality on the ground. The strategy conversation provides another approach.

• Have A Strategy Conversation With The Project Sponsor. Rather than starting at the very top of the organization, the strategy conversation connects the project to the project sponsor. That means sitting down with the Vice President, COO or or the manager who is sponsoring the project and asking them about their goals. The organization’s overall goal may be to define the customer experience. A VP’s goal might be to define customer experience by providing best in class system reliability. If you have a good relationship with the sponsor, you might consider asking them about their performance goals and how you can help them to look good.

• Look For Problems In Existing Data and Reports. Many large organizations have a wealth of reports and data available that attracts little interest or use. Early in the project, you can ask your analysts to review this data and look for the most commonly reported problems. For example, the organization may have customer satisfaction survey results, system reports and/or a lessons learned database from past projects. All of these are useful resources to review.

These three processes offer a way to discover problems that people in the organization care about solving. Delivering against these requirements will help you achieve the Holy Grail of project work: customer satisfaction. After all, if you go over budget but the customer is happy with you, then you can still achieve success. On the other hand, if you deliver on time and on schedule but fail to meet the customer’s real requirements, your reputation will suffer.

Further Reading On Requirements and Business Analysis

This article draws on my professional experience and extensive study of the field. To continue your development, here are other resources to continue your professional development. I emphasize innovation because it is exciting and bound to add energy to your project.

The Ten Faces of Innovation by Tom Kelley with Jonathan Littman

IDEO is a legendary industrial design company known for creating new products and experiences. IDEO’s portfolio includes Apple’s first mouse, the Holiday Inn Express Europe, and  education technology. Whether your project is about creating a brand new product or updating an existing product, this book offers fresh approaches. Kelley shares ten personas that professionals can use to improve innovation. Two of my favorite personas include the anthropologist and the the storyteller (“the Storyteller captures our imagination with compelling narratives of initiative, hard work, and innovation”)

Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry by David Robertson and Bill Breen

I learned about David Robertson‘s work and research on LEGO and innovation at the PMI Global Congress 2015 in Orlando, FL. What’s the connection to business requirements and success? In my view, much of LEGO’s recent success and innovation concerns understanding the need for story and narrative. For example, LEGO created a highly successful series of toys and products related to Star Wars and the Lord of The Rings (as well as LEGO developed stories). Rather than focusing on technical requirements like brick size and design, LEGO discovered the true requirement – toys that connect with powerful stories.

Business Analysis Fundamentals with Haydn Thomas (Lynda.com Course)

When the Toronto Public Library announced access to Lynda.com, I was excited to get started here and earn some PDUs. I started off with this two hour online course provides an excellent introduction to the art and science of business analysis. I like the instructor’s analogy of the project manager as the ship’s captain and the business analyst as the navigator.