There is an abundance of stories of failed projects. Research has shown the reasons for IT project failure in the USA, indicated that project success rates were only 34%, with the rest of projects being either “challenged” in some way or failing outright.
The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million. In the 8 years since, things probably haven’t changed much.
From the project management perspective, technology projects fail when they do not meet the following criteria for success:
- Project delivered on time
- Project completed on or under budget
- The delivered solution works as required by business stakeholders.
A number of factors are involved in any particular project failure. The most often quoted factors are listed below:
- Lack of stakeholder involvement
- Unrealistic time scales
- Poor requirements
- Scope creep
- Uncontrolled changes
- Insufficient testing.
The quality of requirements can have a lot of impact on the outcome of the project. One high profile project which was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87,000 employees but was shut down after several years of development.
The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.
Here is a visual summary of the impacts:
korbanIMG01 April30
Project impacts
Projects are undertaken by the business to satisfy a strategic goal. Poor requirements have the following effects on projects (and subsequently impact the strategic goals of the business):
- Scope creep negatively affecting budget and completion time
- Low utilzation of resources and higher overheads
- Inadequate business process design (due to insufficient details about activities)
- Poor design and ergonomics of the user interface, resulting in lower productivity
- Inadequate software specification, resulting in lower developer productivity
- Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
- Time-consuming and costly code rework
- Difficulties in solution integration.
Business/organization impacts
More generally, the business as a whole is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:
- Lost opportunities for the business
- Lost advantage relative to competitors
- Breaches of regulatory compliance
- Poor stakeholder engagement and loss of trust
- Reduced business process efficiency due to poor solution design
- Negative user experience due to cumbersome UI design
- Lack of cohesive IT landscape due to poor integration
- Negative impact on the bottom line, generally speaking.
How to prevent poor requirements
In my experience, there are two ingredients in any given project which help me deliver quality requirements. One ingredient is what I know about the business and the project. The other one is the techniques I use to ensure that I deliver great results.
It probably sounds quite vague at this point, so let’s dive into the specifics.
Knowledge needed for quality requirements
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?
- Know the context in which the business operates
- Understand the business problem or opportunity
- Identify gaps to be bridged
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 organizational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organizational culture and overall pace of changes within the business you work for.
This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that solves that problem.
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 the business can get as a result of the project.
Extra value can be delivered when you have a clear understanding of changes going on in the organization, and how the project you are engaged in fits into the change landscape.
Techniques for better requirements
The techniques I’ve settled on in my practice enable me to use stakeholders’ time efficiently and get a clear picture of the current state. Let me share them with you.
- Do your homework
- Power up communication with visuals
- Use templates to support your work
- Avoid common pitfalls
Before engaging stakeholders in 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 organization, as well as other projects that may have dependencies with the project I am in.
I also explore information relevant to the industry as a whole to identify possible good practices that I can re-use.
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.
There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time savings due to using visuals can be enormous. How much time do you spend to define the future state? If you don’t use diagrams at present, you could probably save a significant portion of that time.
Outline organizational 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.
Any business analysis task has to be organized to save your valuable time. Templates are of great help here as they let you re-use the common parts of documentation, and customize as necessary. They also serve as a kind of 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, visualized current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.
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 and business requirements for supporting technology services. You always need to tweak a business process if you change software used to support the process.
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. These will guide the development and implementation of the solution. Don’t forget to describe business data (along with data types) to be used within the solution.
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. Functionality that is poorly specified, implementing something that isn’t needed, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of impacts can go on and on.
I believe that we as 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 to improve requirements. I’ve tested these approaches in many projects and they always produce positive results.
I hope they will help you, too!
Don’t forget to leave your comments below.
Views: 2,649
