As PM, I religiously followed practice of all phases - Requirements ( Sign-Off by Client), Prototype(Sign-off by client), design were discussed, demo / allowing client to play around software application & sign-off) & confirm on Go Live On Go Live, if the same client says "This feature(Main) is not performing the way I expected to do when features Goes Live" . What is best way to handle this situation ? How do you react when you have taken utmost care to ensure on client agreement? What are ways in which i can prevent such situation in future? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
This situation is impossible to avoid. Why? Please take a look to "Lehman's laws of software evolution" something that I have applied to other fields and it works. On the other side, what I ever said is "what is not written does not exist". As project manager you have to perform the Scope Validation activity in order to gain stakeholder approval. And here is where the process becomes critical because, in a well created process, the acceptance criteria is written in the requirements specefication itself. What not matter where you have to agree with your stakeholders the acceptance criteria before the product/service/result is created. Saving Changes...
If we have agreed on Acceptance criteria in the beginning and then there will be no way that customer can reject it. It was build as per his specifications. Saving Changes...
If the requirements, prototype and demo phases have been signed Off by the right set off stakeholders, then the delivery team cannot be held responsible for this last minute change.
-See the impact of this change and decide whether it can go live today with the existing features or after a week or so by adding the additional functionality.
-Have frequent short demos with all the stakeholders, so that in case of any misses from both sides can be figured out earlier. Saving Changes...
Walter PilimonCEO| Web Dev Experts SRLBuenos Aires, Buenos Aires, Argentina
I assume you showed the client all demos in the same server or same device/operating system, same install than the production version. Otherwise, can you swear that the development server and the production servers are "identical". If they are not identical, the list of "little missing components" is countless.
Assuming the environment is identical, then come the features. Is the client complaining that the software does not achieve what it did achieve in the demo, earlier on? Is it the same feature but when he ran the test in production he used different data, so he made some unhandled exceptions pop up? That would be your fault. You should cover all exceptions or gracefully handle them.
Otherwise, if the client signed off the demo but then in production he asks the software to do something different than in the spec, you should bring this up to him, as out of project scope.
The best way to ensure end to end compliance in my experience is to define the functionality, all interface elements, all field and data values, ranges, validations and then devise the functional tests, right from the specification phase. This is good for the developer, the PM and the client as well. Saving Changes...
