---------x---------x---------x---------x---------x---------x---------x---------x---------x---------x--------
There's so many people in this group with a great deal of experience in this area, so I thought this question would generate a rich discussion here.
I'm about to start a project that has the intention of "rescuing" a new extranet feature that automates a workflow based on an external client's request that is currently handled manually by the internal team. The feature has been defined by people who are no longer in the organization, and is already coded. I need to validate the requirements with the current stakeholders, and identify eventual changes that may be required to fulfill business and stakeholder needs before the enhancement goes live (assume that the external client's interface won't change, only the internal handling of the request).
Plenty of documentation was created in the beginning of the project, including use cases and data models, in addition to other technical documents. I was told that the new stakeholders refused to look at these documents, as they are too long or too technical for them.
Considering that the project requires formal sign off on the requirements from stakeholders from different areas (customer service, operations, compliance) so the solution can be finalized, tested and implemented, what would you do to facilitate the validation process?
(By the way, this article by Laura Brandau: http://www.bridging-the-gap.com/how-to-align-stakeholders-around-project-scope-without-a-review-and-sign-off-process/ already provides excellent advice applicable to this situation, but I am curious to learn which particular strategies may have worked for you in the past or you would be likely to try under these circumstances).
---------x---------x---------x---------x---------x---------x---------x---------x---------x---------x--------
There were many replies, I will recommend to read them all from LinkedIn. But the suggestion I like most is from Mr. Gary Smith, and in the addition of Adrina to that suggestion.
Mr. Gary Smith Suggestion
I suppose that I would do the following:
1. I would read all of the originally produced documents - use cases, data models, requirements docs, technical specifications, UI definition docs, etc...
2. Since there is working code, I would then sit with the code and correlate what was implemented with what was specified/requested and I would produce a gap analysis.
3. I would then call a checkpoint meeting with the stakeholders where I would present a summary of the original requirements (that nobody read) as well as the gap analysis. In this meeting I would push to obtain concensus on the original requirement summary and the identified gaps.
4. Following the checkpoint, I would determine what was required to close any identified gaps that remain of concern with the "enhanced/rescue" goals. Verify management's commitment to continuing and layout a new schedule to get the job done.
5. With a new plan in hand and management's buy-in I would reconvene a meeting with the stakeholders to identify the course correction and obtain their buy-in (or negotiate an agreed upon solution that everyone could live with).
Ms. Adreana's Addition to Gary's Suggestion
Great advice all around. Somewhere in this process I would incorporate a demo of what has actually been built with the new stakeholder group. This should come after initial trust has been built in the one-on-one meetings and may be done as part of #3. I actually think once their is working software, your stakeholders will care less about what the original requirements were and the gaps (though this might be necessary to present to save the reputation of the technical team). They are going to care about what exists, how they can use it, and having a forum to express any new requirements that they see as necessary.
ReplyDeleteMy two cents.
Laura Brandenburg
Very True.
ReplyDelete