You have probably seen the scary statistics of failed projects. They often reveal that the major cause of project failures is poorly defined requirements.

I’ve talked about the effects of poor requirements before. They have a negative impact not only on the current project, but also on the business as a whole:

poor-reqs-impact-poster
Download PDF
If business analysts provide subpar requirements, it causes a wide range of negative consequences not only for the current project but for the business as a whole

In this article I’d like to examine some of the things you can do to prevent poor requirements.

Putting ducks in a row

The foundation for creating the future solution is a good level of understanding of the current state. Regardless of the methodology you are following, you have to start here. What do you need to know?

1. Context in which the business operates

The business operates in two contexts. One is the external context where market forces define how the business operates and maintains its sustainability. This includes regulatory requirements, competitors and partners.

The second context is internal. It is actually more complex as it includes organisational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organisational culture and overall pace of changes within the business you work for.

2. Business problem or opportunity

This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that resolves that problem. Be sure that you understand what actually drives the project and what problem has to be resolved.

3. Gaps to be bridged

Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value that the business can get as a result of the project.

The extra value can be delivered when you have a clear understanding of changes going in the organisation and how the project you are engaged in fits into the change landscape.

Techniques for better requirements

The tools I use in my practice enable me to use the stakeholders’ time efficiently and get a clear picture of the current state.

1. Do your homework

Before engaging stakeholders into requirements gathering activities, I read all available documentation on business processes, business applications in use, regulatory requirements (if any), internal communication about changes in the organisation, other projects that may have dependencies with the project I am in.

I also explore information relevant to the industry the organisation is part of to identify possible good practices that I can re-use here.

I call this exercise my “homework”.

The benefits of the homework exercise are that I know the “language” I will use when talking with stakeholders. I also know what to articulate to confirm information that is unclear. I feel confident about my part in the project and I know that I can help the business.

2. Power up communication with visuals

There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time saved because of using visuals is enormous. How much time do you spend getting the future state defined? If you don’t use diagrams yet, you could probably save a significant portion of that time.

Outline organisational boundaries, processes and data they use, add used applications, process and technology interfaces where required, and finally add roles involved in the processes. Now you have a snapshot of the current state.

3. Use templates to support you

Any business analysis task has to be organised to save your valuable time. Templates are of great help here as they allow re-use of common parts of documentation and customising as necessary. They also serve as a kind of a checklist of required documentation and ensure that you don’t miss anything.

My favourite template is the Current State Analysis. It includes analysis findings, identified business need, visualised current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.

(Don’t have templates? You might want to check out ours).

4. Avoid common pitfalls

Requirements become poor and vague when they mix project related tasks, statements about the future state, applied rules and solution design.

A good way to avoid these common project pitfalls is to plan business analysis, and to document the planned activities and deliverables in the Business Analysis Plan. It’s an integral part of the project plan. However, the Business Analysis Plan does not deal with project tasks.

A hierarchical approach has to be taken to the future solution. Firstly, list the required solution capabilities. They can include both changes to business processes and technology services supporting these processes.

Secondly, translate these capabilities into a business process design (you always need to tweak a business process if you change a tool used to support the process) and business requirements for supporting technology services.

Thirdly, add relevant business rules to justify future business logic.

Next, validate the business process design and specified business requirements with the stakeholders.

Finally, transform the validated requirements into functional requirements that will guide the development and implementation of the solution. Don’t forget to describe business data to be used within the solution, their data types.

Adding prototypes of the user interface will make the functional requirements more precise and also help establish new terminology to be used in the solution.

These steps are executed in an iterative fashion so they align well with modern “fast” methodologies such as Agile and Scrum.

Summary

Poor requirements may lead to project failure. Not required or poorly specified functionality, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of causes can go on and on.

I believe that we, business analysts, can do our job well and contribute to business success. Sometimes we don’t have enough time to stop and consider why our requirements are poor.

In the article above I listed the key ways from my experience to improve requirements. I hope these ways will help you improve your deliverables because these approaches were tested in many projects and always produced positive results.

I hope they will help you, too!