The Business Analyst is confronted with the stakeholder’s desire to modify features, functions and requirements “just because” resulting in scope creep. Why are the stakeholders asking for changes and what can a Business Analyst do about it?
Introduction
Project scope defines the extent of the project; “scope creep” is the tendency to add features, functions, business rules or other requirements which expands the effort beyond the project scope and has an impact on resources, time or budget. Some scope changes are explainable, but others appear to be the whim of the stakeholders. Why do stakeholders appear to be dissatisfied and how can a Business Analyst address the stakeholder requests?
Project Scope
Project managers define the “project scope” of the effort as part of project planning. The project scope outlines the boundaries of the effort, identifies and describes each of the project deliverables and the project requirements, features, and functions of each of the deliverables. There is often a scope statement to identify measurable objectives for the success of the project.
The project scope is a high-level description developed before work has started, and there are “known unknowns” yet to be uncovered. In addition, there may be changes to the organization, regulations or competition which could affect the requirements, boundaries of the effort, and changes to the project scope. These changes are recognized by the team and can be managed.
However, a project may be affected by uncontrolled and un-managed changes identified as “scope creep”. Scope creep is usually blamed on the a poorly defined project, or one with little supporting documentation. This is can be remedied with clarification and reworking deliverables. But there is another root cause for scope changes which is rarely addressed: the stakeholders simply want “more”. A business analyst can benefit from understanding why the stakeholder is expanding the requirements and have a remediation strategy available when this occurs.
More
“Please sir, may I have more?” Oliver Twist’s innocent request, on the behalf of starving orphans, is met with a resounding knock on the head. The orphans felt they had a right to ask for more, and so do the stakeholders. From the stakeholder’s point of view, they are paying for the effort, and they are not asking for much: just change this button from yellow to blue, add a message here, put a link there. These requests seem as reasonable as Oliver’s request for a second helping of gruel. It can be very disheartening to a Business Analyst, who expects the stakeholders to be “wowed” with the current application but faces stakeholders asking for undocumented “more”.
Diderot’s Effect
Denis Diderot was a French philosopher who published an essay entitled, “Regrets for My Old Dressing Gown, or a Warning to Those Who Have More Taste than Fortune” (1789). Diderot lived most of his life in poverty and then received a large sum of money late in life. With this sum, he purchased a new robe, but the robe looked out of place with his other shabby clothing, so he bought new clothes, which clashed with his old furnishings, so he bought new furniture, and so on, until he had spent his wealth. This is the “Diderot Effect.” The introduction of a new item results in the desire for more new, ancillary items. The stakeholder has a new application, but rather than be satisfied, they inflate the requirements with cravings for “more”.
Emotional Contagion
All Business Analysts have experienced the successful review that quickly turns into a disaster. One stakeholder begins to point out some minor deficiency related to the desire for “more”, “…why doesn’t it do this”? Suddenly the stakeholders turn into vultures tearing the application apart for lacking non-existent requirements. What happened?
“Emotional contagion” occurs when one person can trigger similar emotions in a group, negativity will spread like wildfire. Before anyone realizes what has happened, the mood of the group becomes toxic.
Emotional Intelligence is the ability to be aware of and manage our emotions and recognize and influence the emotions of others. When the stakeholder’s attitude turns negative, the Business Analyst (BA) must move quickly to turn the mood positive by:
- Slowing down the discussion.Negative emotions trigger the “fight or flight” emotions which releases a flood of adrenaline into the body. By slowing down the pace of the discussion, the mind reduces the release of these hormones and provides the opportunity to change the mindset.
- Being humorous.Recall an incident where the team shared a positive and funny experience to remind them of the existing achievements and the success yet to come.
- Invoking realistic optimism. Realistic optimism recognizes imperfections but projects a positive attitude toward the objective. Don’t focus on what is wrong or the stakeholder complaints otherwise you appear to be defensive or critical. A better strategy is to acknowledge their comments and redirect the conversation to the positive aspects of the application.
Psychologists estimate that it takes three positive emotions to offset one negative one, so understand that combating negativity takes time.
Never Agree or Disagree
Business analysts normally wish to please their clients, and there is a strong desire to agree to these minor changes requested by the stakeholders in real-time. However, all business analysts should make it clear to stakeholders that all change requests will be collected and reviewed later. Even if a business analyst is 100% sure the change will be accepted, never agree or disagree to the request in a meeting due to:
- Precedent. The best predictor of future behavior is past behavior. If a member of the IT team agrees to stakeholder change requests in one meeting, then stakeholders will expect that for all future meetings. That one meeting when a BA decides not to decide will be met with stakeholder frustration and anger. Generally, it is preferable to set the expectation that any requested change will be taken back to the development team and project manager for level of effort estimation and decision.
- Technical Limitation. In a meeting when all eyes are focused on a business analyst, it is tempting make promises when they should not be made. Business analysts are not developers, and every BA should remind their stakeholders of this point. Do not make commitments for the development team. The BA can return to the development team with the collection of all requested changes for assessment and estimates; this makes it easier to examine the requests that are based on desire for “more.” Another benefit: viewing an entire collection of change requests at one time draws a larger picture to allow the team to infer stakeholder priorities. For example, one demo resulted in a barrage of “picky” change requests that seemed like “more” and outside the scope of the application. However, by reviewing all the change requests at one time it was clear these were all related to graphics. It became evident that this group of stakeholders had common domain knowledge and shared specific undocumented visual standards. It was easy for the development and testing teams to adjust, much to the delight of the stakeholders.
- Role Boundary. Business analysts are not project managers, and do not have insight to the budget or schedule flexibility. Neither are business analysts IT managers, so they do not control resources. By not deciding immediately on a change request, a BA does not put management in the awkward position of having to renegotiate with the client.
- One challenge in dealing with a “more” change request can be that some requests are simply trivial and should be discarded. If asked for an immediate response, some business analysts will note how silly the request is. It is better to adopt a more respectful path of having a conversation with the stakeholder privately to explain why this change request was not accepted. Training can support a business analyst in developing this respectful tone and language.
Conclusion
Dealing with the scope creep due to stakeholder desire for “more” is challenging for a business analyst, but remember:
He who is not satisfied with a little, is satisfied with nothing.
Epicurus
