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...
The operational view such as an OV-1 diagram. Saving Changes...
Lijo JosephAdvisor to Government Technical Office | Civil Services and Government Development BureauDoha, Doha, Qatar
Operational View Diagram as suggested would be ideal. ROI and Scope Review document. Most importantly I would recommend a project team sit down with client team to review the signed off scope against the product produced/features, seems more to me in lines of expectation setting or adoption than a documentation exercise. Saving Changes...
You may find the requirements in the contract, statement of work, project charter, etc. Any document which relates the required spec with features can be shared as well. Saving Changes...
A requirements traceability matrix. Saving Changes...
Ruth Marina Lopez PerezResponsable TI| INSTITUTO DE PREVISION SOCIAL MILITAR - NICARAGUAMasaya, Los Madrigales, NindirÃ, Nicaragua
You must be show the Scope of Project and the Scope Management Plan, the WBS, and over all the Project Charter. The Project Charter contain the business case and the deliveries. The Scope Management contain Enunciated of the work to execute.
Also, must be show Benefits Management Plan. Furthemore, the EVA.
I think that don't exist a good recopilation of requeriments. Also, many stakeholders was not consulted. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Can also incorporate a benefits realization map - Elizabeth Harrin wrote an article on it on her blog. Saving Changes...
If a customer tells you that a certain product or service does not bring any value to its business then it means that the product simply is of no use for the customer, end of story.
Even if you bring "evidence" that the requirement was in the scope or in the contract the customer would still have no use for that software or for parts of it.
Also in many projects that involve software development is the vendor's responsibility to work with the business users to identify the requirements. The customer would trust the vendor to identify the correct requirements so even if the requirement is in the scope that does not mean that the vendor has done its work properly. Saving Changes...
Tamer Zeyad SadiqAssistant Cost Manager| Turner & TownsendRiyadh, Ar Riyad, Saudi Arabia
Requirement tracetability matrix is ensure the deliverable is matching with business requirements. 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.
...
1 reply by Adrian Carlogea
Mar 23, 2019 5:12 PM
Adrian Carlogea
...
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.
