Why Do Business Analysts Miss Software Requirements?

A project that ends with a deluge of change requests once operations have started can only signify one thing—missed requirements or unmet expectations. While it is not always possible to account for every requirement or satisfy the needs of every stakeholder, proper management of requirements (communication, prioritization and controlled changes) can make a huge difference.

Requirements may be missed for many reasons on business projects. This article explores the reasons why requirements can end up being missed and some best practices to keep in mind for successful software implementation. 

1. A Lack of Understanding of System Capabilities

Even though some stakeholders may understand their requirements and be able to articulate them, when these requirements are translated into system functionality, their fulfilment relies on the ability of stakeholders to use the system correctly and understand its limitations.

When stakeholders do not have a full understanding of what a new solution will bring to the table, they cannot know for certain whether or not it will meet their needs. While there are benefits to showing stakeholders prototypes of the system, getting them to read requirements specification documents and signing off on them before implementation, these activities cannot provide complete insight into what it will be like to actually use the system. Until stakeholders have had the chance to use the system, they may not fully understand what they are signing up for. 

Projects don’t always have the luxury of allocating a sufficient amount of time to hands-on training. In some cases, by the time end-user training is scheduled for those that will actually use the system, implementation is already in its final stages and go-live is round the corner.

Key Takeaway: Whenever a new software system is to be implemented, stakeholder training should begin as early as possible to ensure that stakeholders have sufficient time to get used to the system and understand how it works. Such interaction can form the basis for identifying requirements that may have been missed and finding acceptable workarounds or solutions before go-live. This can also ensure that stakeholders’ expectations are managed. If sufficient training is given beforehand, stakeholders will also be better prepared to begin work from day one and will be less prone to complaining that the system does not work or making mistakes that will be difficult to fix further down the line.

2. Work Overload

There are some organizations where business analysts are expected to do everything else in addition to analysis. Analysts involved in other activities, for example, software testing, training, change management along with requirements elicitation can get easily burnt out.

When the analyst is continually overworked, requirements can easily be brushed aside or missed. This can lead to dissatisfaction on day one for stakeholders.

Work overload can happen when:

1. There are few experienced hands available to get the work done. Working on a project where team members do not have the experience or even worse, the motivation to deliver, is like trying to fit a square peg into a round hole. This situation can put pressure on those that are capable of getting the work done.
2. Requirements continue to be identified long after they have been signed off and after the analysis phase has been concluded. This situation can extend the analysis phase longer than necessary and puts the BA under pressure to catch up.
3. The project is not properly planned or the plan keeps changing. Without a plan that works, almost every task will become an emergency, leading to demotivation, work pressure and burnout amongst team members.

Key Takeaway: As much as possible, project work should be split across project team members so that requirements and their fulfillment are given adequate attention. Where necessary, possible and when it adds value, extra qualified hands should be enlisted into the project team to avoid over-stretching team members. Organizations where analysts are required to do everything else in addition to their core job functions will reap reduced benefits from the project if requirements are missed.

3. Costs

When meeting stakeholders’ requirements requires customisation or extra development effort, some requirements may be missed, albeit unintentionally. Not every out-of-the-box (in fact, very few) application, will meet the needs of the business. In situations where extra tweaking is required, it is often necessary to weigh the pros and cons of using the standard software as it is or investing more resources in meeting those requirements. At the end of the day, some requirements will end up being missed.

Key Takeaway: In such situations, stakeholder expectations need to be actively managed to ensure that they understand well ahead of time, which features will be immediately available to them and which will be scheduled for future development/releases.

What other factors can lead to missed requirements? 

Stay tuned.

Picture Attribution: “Business Man And Cross Mark In Check Box” by 1shots/Freedigitalphotos.net