How Frequent Requirement Changes Derail a Project, and How Business Analysts Avoid Them

Our Director of Business Analysis, Andreu Harris, walks us through how our business analysts work hand-in-hand with project managers to keep projects on the rails.

Whether you’re working in a traditional Waterfall, Agile/Scrum environment, or some combination of both (commonly referred to as Wagile), there will always be a need for requirement modifications. That’s just the nature of projects in an a fast-paced agency setting.

Managing the the requirement modifications against the project delivery is a real balancing act, and that’s where Business Analysts and Project managers have to work together seamlessly to spearhead difficult objectives.

Frequent requirement modifications, unknowns most commonly referred to as risks, can impact a project’s execution, delivery, and budget. While a successful project in today’s world requires you to work with a certain amount of unknowns, when there is a lack of agreed upon strategy for how to manage risks you might find yourself in trouble.

Most major IT project failures are caused by frequent requirement changes and could be prevented. It’s especially dangerous because requirements touch every aspect of the project from the design approach to the technology in use to the relationship with the suppliers and vendors to the resourcing to the–you get the picture.

I’ve experienced several projects that had frequent requirements changes that made the projects so unstable, we almost had major financial consequences. In one instance, senior leadership had major differences and visions of the project more than 60 days into development! It ended up costing us 100 hours of refactoring and even more countless hours of throwaway code.

As business analysts and project managers, we’re extremely concerned with requirements changes. These events, in isolation or in combination, can clearly have detrimental effects on projects that will persist regardless of software development methodology (Agile, Waterfall, Kanban, Lean, etc.) or the requirements management process in place. No methodology or process guarantees there will be no requirements change.

Often we assume when requirements move to the design phase, they are “complete” and not subject to change. However, that isn’t always the case. In fact, most times it isn’t! There always some changes in requirements throughout the development lifecycle. Although Agile “welcomes change and allows you to easily pivot” and claims their “collaborative” approach facilitates unpredictable changes, this will be challenged when there are many requirement changes.

I should emphasize that frequent requirements changes is not “scope change.” They are two different things.

Frequent Requirements Changes: Here, the scope remains static, whereas the requirements are dynamic. This is a micro-level change that eventually impacts the subsequent phases of designing and developing a solution.

Scope Change: Scope change manifests through, “I want more.” This is a macro-level change that impacts the whole end-to-end solution. It is a redefinition of the initial agreed outcome.

In agency life, we usually have a couple days of discovery with the client to identify their requirements and formulate a strategy. As much we try to get all the detailed requirements from the organizations leadership and SMEs, there will always be undiscovered business needs. To transform unknowns into knowns, the best way to address the issue is to use a Business Analyst’s expertise of discovering and analyzing requirements and data thoroughly.

When you move into the design phase with too many unknowns, your potential for frequent requirements is high.

A business analyst’s primary responsibility is to ascertain and define requirements through an analytical process, known as requirement analysis (aka Discovery). Requirements documented in this phase are only as good as the BA’s ability to draw out the key requirements based upon inputs provided by multiple stakeholders. Business analysts add value to this process by using their expertise and past project experiences to facilitate the gathering of clear and concise requirements that cover all possible scenarios/use cases.

Every organization has its own set of values and practices that contribute to the organization’s overall identity. The identity can impact the requirements analysis process both directly and indirectly. Attitudes toward requirements management can be a reflection of the organization’s culture.

Unpredictability and unknowns have major effects on project budget and timeline. Requirements are the necessary foundation needed for developing any solution whether it’s a website, retail experience, or product. Requirements provide the baseline for scoping and schedules and are used as “gospel” for future phases of the project, when it comes to design, development, and testing.

Agile methodologies (Scrum, Kanban, XP) are the most suitable forms of the software development lifecycle to manage frequent requirement changes. However, that doesn’t mean that the ability to adapt quickly doesn’t impact the project budget and schedule. It makes a difference to have an experienced delivery team and seasoned business analysts that can clearly identify and manage the project unknowns.

Andreu Harris is the Director of Business Analysis at FortyFour.

FacebookTwitter
Written by on August 8th, 2018 in Insight