There’s one thing that is inevitable for even the best project or product managers out there, and that’s “change.” This single word is packed with a ton of power: some good and some bad. Change is a gate. Think of a gate to a military installation or the White House. It must be controlled and monitored all the time and throughout the life cycle of a Minimum Viable Product (MVP) or else all hell breaks loose.
In agile development, change is often not controlled formally which could lead to some serious ramifications such as waste of resources (money, time and effort) which is likely to impact the triple constraints: time, budget and scope (some would argue quality as the third constraint).
There are 3 things you should keep in mind regarding the triple constraints:
- They are typically not adjustable without the approval of the project sponsor.
- They will likely tie back to the product roadmap or project Statement of Work (SOW).
- All the constraints are balanced by each other. Meaning, if any one of them change it is likely to impact the others negatively or positively.
Therefore, it is imperative that all change orders requested are run through a formal change control process to validate its priority, impact and associated cost if any.
Time is something that you cannot get back in life let alone a project; therefore, it’s important to do the necessary activities to manage the timeline. In mobile app development, following agile methodology best practices such as sprint planning, backlog grooming, and activity/tasks estimation sessions will better assist with monitoring and controlling the time constraints. These efforts will allow for a quicker response time to evaluate project changes and decrease potential impacts. Time is also very expensive as it relates directly to the budget constraint. If schedule variances are too large, it could indicate a possible work performance or planning issue that may require an impact assessment to determine the next steps.
As previously mentioned, the project budget is typically not changed unless there’s an urgent need that requires an increase in budget. This request would come through the change control process which includes approval and integration. It is often found most changes that appear “urgent” are not a priority for your MVP or release; therefore, they can be backlogged so they are not forgotten and reprioritized. This will not only save you money, but it will also ensure you are getting the most important features of your app now.
Changes are directly related to scope whether directly or indirectly. If you have specific features or functionality that must be included in the MVP or current release, it is important to avoid making unnecessary scope changes because it will likely negatively impact both the budget and timeline which could lead to premature project closure or termination. If you must… consider de-scoping items to accept the new changes to keep the budget and timeline intact unless you have an unlimited budget (never ever heard of such a thing).
If you are reading this and just realized that your company or project does not have a change control process in place… there’s no need to panic. There are several solutions that can be implemented quickly to get back on track. One solution is not necessarily better than another, and there is no one size fits all. Solutions should be managed case-by-case with experts to have the best outcome. It’s recommended to update any roadmaps when significant changes are approved to keep all stakeholders informed and better prioritize future work.