After delivering a release, the client is adamant that certain features of the software do not provide any business value. Which document can you share with the client to show how the features directly correspond to business needs and requirements stated at the being of the project? Saving Changes...
Well Noted.Thanks for sharing your views.
The Requirements Traceability Matrix ensures that whatever is built is directly related to the requirements and business needs. Mostly time , this document is very useful in this type of case.
As I said in my previous comment nothing will help in these kind of situations as even if you demonstrate that the software was build as per requirements it would still be completely useless for the client and as such the project has failed, at least from the point of the client.
What I've seen is that the users can't tell for real if a software or some features of the software are really useful for them until they use the software. For them what it is said in the "documents" may look good but once they start using the software they can't do it as it does not do what they want it to do.
I have been involved in such projects in which the software passed testing but was rejected during UAT. The users simply said that they can't use the software as it does not do what they need it to do.
If the customer tells you that the software brings no value to them then you know that you have failed as PM and bringing evidence that the software was built per requirements would not help.
The only thing you can do is to involve from the beginning the users or business analysts that have the same experience as the users to use the software from its early stages. If you got to the point in which the client tells you that the software is of no use then I am afraid that it is simply too late. Saving Changes...
Hi, can advice , the purpose of the scope matrix between owner and vendor and why? if vendor reluctant to provide how to tackle this subject.
thanks in advance!
Hi, can advice , the purpose of the scope matrix between owner and vendor and why? if vendor reluctant to provide how to tackle this subject.
thanks in advance!
Thanks Ravi.. Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
My friend Adrian here seems like he is a current or a past software developer or customer who has been at the receiving end of some very bad Project Managers who either did not respect his opinion or looked like they were clueless in stakeholder and customer engagement . While I empathize with Adrian's views , A Project Manager still has to do a job at putting fires , just as a fireman does.
and While a PM can do a lot to pacify customers , it must be understood that they are human beings too . If the customer can have a rant , then a PM also can sometimes not be able to engage customers at every point and customer must sometimes give in a bit too , not because they are paying , but because they understand that PMs are doing their level best.
I completely agree with the part where Adrian says that customer engagement is paramount from the start of the project.
Assuming that you as a PM have done that , and still the customer is unhappy , then you would have to apply a different tact.
Therefore , in the current situation , merely showing a document like a Trace-ability Matrix will not cut the mustard. The Project Manager also needs to show concern and empathy and try to understand why the customer feels as though the Product does not provide them value. For that they may need to:- 1) Revisit The Business Requirements , Trace Matrix, Scope statement , Charter, meeting minutes , project reports etc with the customer and show them that the software is built according to requirements. They need to do a walk-through of the journey and ask the customer to comment where the customer thinks that the product does not provide value.
2) It may be that a feature is not correctly understood by the client. Why not get your developer or application expert to walk them through the functionality and features and make sure that your developer understands the customer's pain points ?
Showing empathy is more likely to soften the customer towards you than merely throwing a document over the fence.
If it is revealed that the product does not meet the requirements and is completely missing a critical feature , even at the late stage, you as a PM can go back to your Manager and see how you can accommodate the customer. Saving Changes...
Milena IlievaProgram Manager Global accounts| VMWareVienna, Austria
I totally agree with Deepesh. Documents are important baseline, for the project planning, delivery and closure, but the project success comes by working closely with all stakeholders, especially customer.
All that was outlined by Deepesh are very good steps to follow to get project to a successful acceptance by the customer. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Dear Shadav
I would use Requirement tracetability matrix Saving Changes...
Ashleigh Kennett-SmithICT Project Manager| Australian Red Cross LifebloodAdelaide, South Australia, Australia
I have worked on a couple projects where the customers were not able to fully articulate their requirements, and this caused similar issues. In these instances it was not recognised (business and project at fault) that the requirements gathering was not helping the customer move from expectations to real requirements.
My approach these days is to try to reach an agreement with customers to deliver an interim (approved) requirements document, then Proof of Concept "product", and then iterate refinements in both. This then allows us to identify the gap between customer expectations and requirements very early, but have time and $$ to deal with it. The BA, SMEs, senior stakeholders must all be 100% behind this approach. Saving Changes...
