Scenario : You are in an application development project, Where you
have completed your UAT along with the sign off. However a key stakeholder comes with a critical change which has to be incorporated for Go Live and without any cost impact, This was not a part of your BRD and FRS and You are client side and development Vendor has delivered the final build and the signed off BRDs and FRS. what is the best way to ensure that the change is also incorporated and cost is not impacted ? Saving Changes...
Sort By:
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Ajitsingh - A couple things to consider. First, there is no avoiding additional cost, and most likely, the impact will be magnified with the cost of delay on go-live and incurred costs from development, testing, time, etc.
The consideration is to determine if the 'critical' change must stop the go-live or can be incorporated post go-live as an enhancement, feature request, hot-fix, etc.
And the question would also be, where has this 'key' stakeholder been with this concern? This is a significant benefit to operating with a culture of inclusivity, not in a vacuum, so as to ensure there are visible and tangible assets for key stakeholders to inspect throughout the process.
To be clear, the answer could be 'yes', but with the caveat of 'but not right now', with an explanation of the intent to address logically with the least amount of risk.
There is a way to address the needs without blowing the whole thing up. Identify the why, what, and how; then determine the best, most logical course of action, i.e., enhancement effort, etc.
We have to remember that project management does not make miracles happen. Can stakeholders be unreasonable at times? Absolutely! But educating stakeholders on understanding the impacts of a change so that they can make the best possible decision is our responsibility.
If this is truly a "must have" requirement and the vendor's contract has been completed, then there is no way that this can be an "no" cost impact. There will likely also be a meaningful time impact as some subset of the testing done to date will need to be re-done in addition to the incremental new testing for this change.
Sounds more like the stakeholder is becoming or may already be an existing/increasing shareholder in the project.
Agree with Kiron, by virtue of good governance a must have is a must have, hence all I could think of is the above scenario - in which case in some organisations no cost means they are actually being ‘absorbed’ but subject to future considerations/decisions. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The key point here is the definition of "cost". Cost is not monetary only. So, the first thing to make visible is there is an associated cost always. With that on hand, what we do, is follow our project change management process where the project manager is accountable for assure that all the information to decide is available and published. Saving Changes...
I would approach this scenario with a lot of thought before making a decision. First thing first I would instigate a bit of push back to see if this last minute development is really essential for the release of the final build or if instead its a 'would be nice' change. Also I would see if its an integral change to the final build or if its an incremental developed (even though also called a change) and see how much of an impact it would have on the need to test all the systems of the final build instead of just the module that is been developed. Also I would see if I still have the available resources on the team to manage this late change to the final build as some of the project team may have moved onto other projects. Also I would see if the final release date could be delayed (part of the push back) in order to incorporate the change. Also see if there is sufficient time to completely test the module and systems. Also see if the client would assume some risk in the event of the entire system failing as a result of the late changes to the final module. Like any project manager, there is a lot of moving parts that must considered before you make a decision and this could really test your leadership skills and your individual confidence as there is a fine line between delivering the final product and doing your job while also satisfying all the clients requirements. Also cost is part of the push back as a client will pay for the change if its truly essential to the final build as it should have be caught way in advance and included on the project documentation. Saving Changes...
How are your, or your sponsor's, negotiating skills?
In an application development project, new requirements equals new development and testing. This equals more time. If this is all internal, you might be able to ignore the time that your developers and testers spend, as far as cost is concerned. In my experience, if UAT is complete and you have everything signed off, you already have your launch planned and are days away from going live. Adding new features will delay the launch.
If you have effective change management processes, you can adjust your schedule, but time is money. Unless your developers and testers are going to work for free, you can't avoid additional costs.
I just had a thought that is on topic, but a little bit of a tangent, and more of a question. If you're in the cloud, (AWS, for example), and you have to spin up a new test environment for the new features, or extend the amount of time you will need the environment you have been using for testing, will this add cost to the project? Saving Changes...
Community Champion
