Table of Contents
Being on the same page with stakeholders during the whole software development process defines the project success. It is crucial to dedicate much time and attention to outlining their level of interest, requirements, and expectations, ensuring mutual understanding. There are lots of potential risky occurrences that can happen during the development life cycle, one of which is scope creep.
Scope creep requires constant and qualitative communication between the team and stakeholders to discuss the ongoing needs and requests due to the software solution. Hence, these changes need to be weighed, approved, and planned within the project roadmap.
In this article, we would like to take a closer look at the best stakeholder management practices that help our team to cope with scope creep risks. We also will share the cases of how we addressed scope creep issues and what stakeholder management plan applied to the software projects.
How scope creep influences the project
As we already figured out, scope creep can have a negative as well as a positive impact on the software delivery process, but it all depends on the case and its specifics. Let’s dive into details to outline what pros and cons of scope creep actually exist.
The negative side
Foremost, scope creep has a direct impact on project timeline and budget. When the team gets additional requests, meaning tasks, from a client and approves all of them, both sides need to understand that it surely requires more working hours from the entire engineering team, thereby more money. So let’s dive into detail.
Budget
When the project goes beyond the budget, it not just requires more investment from stakeholders but also eliminates the profit that the software could get. Let us explain. Each software project has an entire roadmap that divides the project into sprints and outlines actions for each sprint, including the approximate project estimation if we are talking about time & material contract type.
Hence, there are cases when all project tasks are completed, there is still an available budget to go back to some functionality parts and make some improvements or rework some features, etc. This will improve the overall software feasibility and code quality. But scope creep completely removes this profit, as the probability of expanding the budget right before the delivery stage is low.
Timeline
Make it clear that unexpected jobs will result in scope creep that in 100% of cases turns into a delay in the project delivery. Of course, it negatively influences customer expectations and satisfaction, as the original deadlines do not correspond to reality. But if the consequences of scope creep were thoroughly discussed with stakeholders and still approved, then this disadvantage can be addressed, what we cannot say about the business profit of the client.
Due to our experience, businesses decide to integrate their inner processes with software for the purpose of efficient and quick scaling of the business and streamlining internal workflows to boost the overall productivity of the company.
Hence, when the software launch is delayed, eventually it delays the business growth strategies leading to missing the yearly business plans, lowering income, etc.
Client
It is not difficult to guess what scaled project budget and delayed deadlines result in—complete client displeasure. Going over the project scope will surely lead not to what the client initially wanted and expected, instead of whether the changes were approved and are positive, it still doesn’t show the desired outcome of the development process.
Scope creep appears for a range of reasons, especially on fixed-price projects. The dissatisfaction with the completed solution leads to decreasing the credibility of the software development team.
The positive side
Despite the numerous threats that scope creep can bring to the software project, there are also some positive facts about this occurrence, when it is partially restrained, depending on the project specifics.
Client retention
Foremost, when the development team shows the willingness to approve and include the client’s requests in the project scope, it shows their professionalism and readiness to make an effort to satisfy the client’s needs. It certainly increases client retention, meaning the customer will probably continue cooperation with the software provider and adds credibility to the development team in the industry market.
Software relevance
The software development life cycle lasts at least 3 months if we talk about MVP development, and lasts more than 6 months if we talk about building a complete software solution.
During this period of time, the market will dictate new trends in the industry the solution is built for, for instance, the customer demands will change, the range of features will be not enough to compete, the used technologies will be irrelevant, etc.
The limited number of scope changes can mitigate risks by including the most expected features in the software solution during the development phase.
Why we say the limited number is because the team and the client need to decide on the priority features and include them, expanding the budget and deadlines to the highest border.
Altamira’s examples of scope creep on projects
Further, our business analyst will share the real Altamira cases of having scope creep on the project and what solutions and stakeholder relationship management techniques our team applied to decrease its amount or eliminate it completely.
Case #1: Fitness application
This is a software project that was based on the fixed price type of contract for the purpose of getting maximum for less money. We started without the discovery stage, it was a preliminary estimation, and the description was also done on a high level.
During the implementation stage, we faced a lot of misunderstandings and different translations of the words.
So here comes the most complicated things:
- Fixed price project
- Different expectations from the project
- Scope creep as a result of the issues mentioned above
Firstly, what a company has to do is to understand what exactly was estimated and in what way. A session with the developer and BA will help us here. Be a very buzz killer in order to understand all the steps.
Additionally, invite a developer who is going to develop everything, in order to know whether he is able to do the development in the indicated time frame.
Secondly, during an interview with a client, highlight her/his main expectations, so in the future, you will be able to prioritize between her highest priorities and differences in expectations.
Thirdly, being able to correctly prioritize between what is important to the customer, and what is important for us to provide high-quality code
Case #2: Mobile app for local businesses
It is often a mistake during development “forget your initial goal” and give into development everything you want and think will be important for users. When you do not follow your goal strictly, you can build the transformer of everything.
This project was on time and material, so the main argument “this was not estimated in the initial scope” usually does not work.
That’s why we are moving to the following practices that may help you.
Option 1
Each feature has to be validated for “business value”. Together with the client, you should always indicate why this or that feature has to be in the scope and what value it will bring to customers.
Option 2
After being studied using focus groups/surveys, time-consuming ideas that do not have a significant positive impact on the current project are documented to be used as insight for future product development
Option 3
Prioritization is also a key to success. For this case, we would like to recommend using the Kano model, or “Value vs Effort” prioritization, which can help teams determine which features will satisfy and even delight customers.
Option 4
Each time shows how the changes impact the deadlines. One of the ways is to have a roadmap/Ghant diagram and to visually show the client how the changes impact the deadline.
Option 5
Do not be afraid to say “No”. Use arguments, as to why this feature is not good for the first release or for the product at all. But always show care for the ideas. According to our experience, the best way is to have “Future Backlog Release” document.
When we discuss the idea, understand that priority is not the highest and put this idea into the backlog. When the requested feature is negotiated and assigned with a minor priority, it is added to the backlog for future releases. ”Nice to have“features are not taken into the current scope in order not to expand the timelines. This is one of the aspects of caring about business needs and expectations. Using this document you do not take “nice to have” features into scope, you do not expand timelines, you show care to the client, and, also importantly, you have features that can be developed in the future.
Best stakeholder relationship management practices to address scope creep
Software development projects have a few main threats, and scope creep is the most common. We’ve already discussed ways to avoid it in the previous article.
Certainly, the software vendor team is responsible for preventing unexpected changes in scope that may bring distorted business goals, however trust-based stakeholder relationships and active collaboration with project managers shouldn’t be underestimated in keeping stakeholder engagement in product development.
Here are the fundamentals of the key stakeholder management process that are recommended to be followed:
Preventive measures
The business analyst or product owner conducts brainstorming sessions, workshops, or surveys preliminary before the start of development during the requirements elicitation stage to figure out all business needs and requests from all external stakeholders.
This will significantly decrease the number of future CRs and the risk of the scope creeping directly from the start of the partnership. Thus, every customer idea or expectation is considered in the scope document and planned beforehand.
No one remains unheard. Both vendors and businesses benefit from this.
Analyze change requests
Later every change request that was initiated by external (business) or internal stakeholders (dev team) should be analyzed, discussed with key stakeholders and decision-makers, and assigned a priority level. The market is extremely flexible, and business follows it. The main point is that CR processing shouldn’t be postponed but scheduled if they were selected for development
Make a commitment
The Dev team should commit to those CRs and requirements matching the main product vision and strategy. This is preliminarily discussed with business and has to be 100% clear for everyone.
If the change request doesn’t match the main business goal, all key stakeholders including the vendor side should consciously select them for development and separate those requests that occur according to some changes in the market / unexpected business needs and those that can be kept as out of scope.
Create separate documentation for scope creep cases
All new requirements and change requests marked out of scope are kept in separate documents or in related specifications and are usually gathered and analyzed together closer to the end of the project lifecycle.
This may significantly help business and product owners to figure out the future direction of the product and even highlight innovative business ideas to be brought to life in the next stage of the project.
Summary
To sum up the fundamental stakeholder management practices and ways to escape scope creep, we can say that both internal and external stakeholders are responsible for unexpected scope creep.
But the main task for the software vendor team is to document all new requests and ideas coming from the business and categorize and prioritize them correctly. Thus, the trustful partnership will last for long productive years.
FAQ
What is the best stakeholder management plan to manage scope creep?
Among the most efficient stakeholder management practices regarding scope creep, we would like to mention prioritizing the scope change requests, and discussing the scope creep consequences with external and internal stakeholders. We also would add making a commitment for changes and documenting the scope creep changes.
What is the influence of scope creep on software projects?
Scope creep delays the software development timeline and requires more budget investment to deliver the approved scope changes of the project qualitatively. If the changes are overwhelming, it can lead to a complete project failure. However, if there is a scope change control process, then the changes are limited and can profit the software.
