Tuesday, September 29, 2009

Challenging Situation For Business Analyst [Situation # 1]

The discussion was started by Ms. Adriana Beal on LinkedIn. The topic of the discussion was "What would you do?"  . Below is the detail discussion by Adriana Beal

---------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

Gary, your plan is very similar to what I'm planning to do! The only thing I would add is a one-on-one conversation with each stakeholder before step #3, since in my experience it provides a great opportunity to establish rapport with the stakeholders and allow them to express opinions that they might be reluctant to express in front of the others. Thanks for sharing your list of steps. 

 And at last, Abubakar Munawar's ( my )Suggestion to handle the situation

I like Grey's advice and Adriana's add on to that advice about 1 to 1 meeting with stakeholders, it was very good point of view by Scott to identify the gap with current requirement first, rather than doing the solution assessment & validation in that case.

I would like to add a small suggestion to that discussion, if that was the situation to me I would also include the Sponsor [Client Company's Executive, to which the solution will help in achieving strategic goal]. I must have update him about the situation along with the chances of identification of Gap in currently developed solution [that will lead to extra effort / rework and will cost extra as well], I also have update the sponsor about the disputes that will come in the way during gap and should have ask for his contribution in resolution of those disputes.

Actually, as we are external consultants we should have a very clear understanding of completing project, in most of the cases; new users reject the most of the requirements given by previous users and try to give you the same requirement in other new ways. Good BAs can handle this, but it really costs time. If the sponsor is in confidence and knows that disputes will arise, than he will must act in some way to help External BA achieving the solution in effective way, because its his objective that is linked to that solution.

2 comments:

  1. 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.

    My two cents.
    Laura Brandenburg

    ReplyDelete

Popular Posts