Why You Shouldn’t Worry About Change Requests — A guide For Product Managers
“Everything flows, everything changes” — said Heraclitus implying that the only stable thing in life is change. There was no project management back in ancient times, as far as we know, but the above-mentioned saying is quite relatable to software development projects today.
People do live in a state of permanent flux, so harnessing an endless stream of changes is what many entrepreneurs attempt to do. Finances Online reports that 63% of companies involve change management activities in their projects, while 70% of businesses opt for the Agile methodology to effectively manage the change of priorities throughout the project life cycle.
Still, people perceive change as something bad because we feel uncertain whether the upcoming change is for the better. In this article, the JatApp team will explain why you shouldn’t be afraid of changes in a project and why embracing them won’t harm your business at all.
How does a change request work?
A change request is a client’s official statement of a desire to amend the present scope of the project by adding/changing the development of a particular feature or any other element of the software.
In other words, a client can just change their mind about any aspect of their digital product and ask their software development agency to follow their new requirements. However, why would they want to change anything in your software solution? What should happen to force them to consider scope changes in the project? Let’s find out.
Why do changes happen?
Stability is a myth, and it is becoming even more unrealistic today when business environments are so disruptive. Globalization puts companies in a position where emerging technologies, pandemics, economic crises, armed conflicts, Elon Musk’s purchase of Twitter, and so on play havoc with any business in the world.
Consequently, a fast adjustment of the business to new environments is the best thing a client can do. Nobody would use a digital product that is unable to solve their today’s problems. That’s why business uncertainty and global disruptions are the first and foremost reasons why it’s important to make changes to your project’s scope.
The second reason relates to the ground level of the project. When you develop a software product, you have a segment of target users in mind. It means that you aim to build a solution that will manage the users’ problems and pain points. You may even release a minimum viable product (MVP), but then you get feedback from your product’s early adopters that they would like to have this or that feature.
And, of course, you’ll do everything to get these features delivered with the next release because every reasonable product manager wants their product to be successful on the market. For that reason, you’re likely to abandon or postpone the scope you planned for the next release and focus on developing features your customers would like to see in your application the most.
The third reason is also quite plain. Investors and stakeholders may wake up in the middle of the night with the idea that seems to disrupt the market and turn the whole competition upside down. A desire to pioneer a new solution surely outweighs the “don’t change the horses in the midstream” mentality, and you have nothing to do but message your software development vendor about making a change to the project’s scope.
For now, you definitely see that making changes to the project’s scope is okay and even for the better, especially when good change management is in place. Amending the project scope is inevitable because you can’t predict what the future holds for all of us, which is why feeling fine about project change requests is a healthy attitude we recommend you foster yourself and promote amongst other team members.
JatApp’s approach to change management in software development projects
Even though a total avoidance of uncertainty is impossible, JatApp’s product managers (PMs) try their best to keep a project progressing without major hiccups. That is why we always run a discovery stage before starting the project in order to gather as many details as possible.
Based on these details, our PMs write a detailed specification that describes all processes, tasks, or individual features the product should include. If something isn’t included in the specification but yet plays a vital role in the product, a client just needs to inform our PMs, and they will clarify any issue. When our PMs see that there are alternative ways to approach their request, they’ll surely describe all possible courses of action.
Thus, the main goal of the discovery stage is to gather as many details about the software as possible. As a result, when the project begins, there are fewer chances that the client will have to change something in the project’s scope, except for some little nuances that won’t affect their initial project plan.
Nevertheless, we would like to highlight once again: changes do happen all the time. In case a client would like to request a change in the project’s scope, they just need to reach out to our PMs and tell them about their ideas. Our PMs will provide them with an estimate of time, cost, risks, risk mitigation strategies, and potential impacts on the product’s quality associated with making the change they asked for.
Additionally, clients can always count on our PMs to provide them with alternative decisions if any viable scenarios are possible. In such a way, effective change management performed by our project team helped our client to timely deliver an autonomous power bank rental platform.
Power bank sharing platform user interface
The project faced an unexpected problem with the hardware delivery because of COVID-19, and the client had to find a way how they could test the product without any delays. Our team came up with an idea to design a digital emulator that will be used instead of hardware to test the product.
During the test, numerous problems popped up, and the client requested changes to the product’s backend several times until the solution reached a high level of quality. We’ve implemented all changes fast enough to deliver the product within the tight deadline.
Today, JatApp keeps supporting the product and developing new features for it, and the startup’s CTO left the following feedback on Clutch: “Professionalism was noticed from the first conversations with these people. They knew what exactly we needed and provided us with the best options for its implementation”.
Whatever changes the client requests, they need to confirm that they acknowledge changes in time, cost, and risks to let our team start working on new product requirements. At the same time, every single change is recorded in the change log. It is a document that includes details about each change made during the project’s life cycle.
The client and our team can always refer to this document in case any confusions arise and trace what and when has been changed. We document every change and every confirmation in order to avoid disputes in case something goes wrong with a software product.
Example of change log document
By the way, we inform our clients that disputes can occur as well. That’s the reason why we document any change and other project details. If they see that some of their app’s features don’t work properly, they just tell us. Our PMs will double-check whether it’s a bug or not.
When we identify that it is a bug, we’ll run the quality assurance process once again. A client is the one who makes the final decision before our developers start working on changing anything in their software. Again, clients can expect our PMs to warn them that some changes can backfire with a product’s quality drop. But if they realize all the risks and insist on making this change, we’ll do whatever they’re craving.
Final words
Being able to change rapidly is one of the main characteristics every business should have today. Even though you may have an open mind to accept any changes, you need to make sure that any change is always for the benefit of your project.
