Monday, October 22, 2012

Software Development Consulting Madison WI? Persuading an ...

Posted by Robert Merrill on October 22, 2012 under Business Analysis and Requirements |

This post came out of a long thread on the LinkedIn IIBA Group, entitled ?A development manager uttered, ?Adding a Business Analyst simply adds an extra layer in the SDLC, which creates a gap in the development work and keeps the developers away from stakeholders.? Is he right??

It was a great discussion, and I wanted to summarize for anyone who faces this attitude and wants to change it.

  • Don?t let the skeptic put you into defensive, fight-or-flight mode, because then they will probably respond in kind. Listen long and carefully.
  • Don?t assume that a Business Analyst really is the solution, and certainly don?t try to force it.

Encourage the skeptic to tell the story of their experiences with Business Analysts. Skeptics may not always be right, but they nearly always have a point. Even a group of Business Analysts who felt strongly enough about the value of what they do to contribute to a long LinkedIn Group thread admitted:

  • Business Analysts who are not competent and properly trained actually can be a burden.
  • Every project needs Analysis, but not every project needs an Analyst.

Understand the skeptic?s problems?all of them, and not just the ones that concern you, the Business Analyst advocate. Elicit all of them. You know how to do this. We know that Business Analysis deficiencies usually present themselves as problems elsewhere, but help the skeptic do their own systems thinking. Help them identify possible root causes of their problems. There can be many good teaching moments in a conversation like this. We BAs are used to dealing in abstractions, but a lot of people aren?t. Talking about how a specific problem got started, and how the work you do probably would have caught that, can sometimes open people?s eyes.

  • Has the skeptic seen solutions that were incomplete or incorrect because of a misunderstanding? Sometimes the process of talking through requirements, especially with a person who does that all the time, can make requirements clearer and more accurate.
  • Has the skeptic seen situations where developers said things to stakeholders, especially senior management, that caused problems that the manager had to straighten out? Not all developers work well with stakeholders, especially senior management. (Not all BAs do, either, but I think this is a great skill to develop. As a BA, you?re often the first on the scene, and therefore best able to begin managing expectations before they solidify into something crazy).
  • Has the skeptic seen situations where the stakeholders weren?t available, so the developers assumed what they would want, or went off and built something fun, or did nothing? Sometimes stakeholders and SMEs aren?t available whenever the developers need them, and there needs to be someone who can work on the business?s schedule and rhythm so the developers don?t run out of useful things to do.
  • Has the skeptic encountered ?business analysts? who were really just translators or order-takers? That?s not what business analysis is really all about.
  • Has the skeptic ever seen a team or stakeholders misunderstand the problem, or jump on the first solution that came to mind. A good Business Analyst lives to keep that from happening.

If you and the skeptic agree that lack of effective analysis is causing some of their problems, but they still don?t think a separate Business Analyst is ever the solution, ask some ?how would we know? questions.

  • Help me understand this ?gap.? Is there evidence that the BA is slowing things down?
  • Or is it that information is getting lost or garbled on the way from stakeholder to developer because of the BA?
  • Or is the BA actually improving the quality of the information going between stakeholders and developers?
  • In our process, dear skeptic, how would we know which of these things are happening?

If there are other problems that aren?t rooted in a lack of a Business Analyst, help identify solutions to those, too. That way, you can demonstrate that you?re not just a self-serving sales person. Examples we came up with are expectation management (perhaps better handled by a development manager or project manager), and testing.

If there is a current project that you?re confident could benefit from an effective Business Analyst, ask for an opportunity to do an experiment, especially if they?ve only seen it done poorly. But don?t be surprised if even a smashing success doesn?t change things. Unless they trust you a lot, you might never hear about these.

  • Maybe they have a political opponent who?s been advocating for a Business Analyst team (under the opponent?s control), and your manager doesn?t want to admit that their opponent is right this time.
  • Maybe there?s someone with authority over them who thinks that Business Analysts are a waste, and your manager feels they have to go along. That can be a self-fulfilling prophecy. Because business analysis isn?t that important, we?re not going to hire and develop good analysts and free them up to do their jobs. Then, when they?re ineffective or worse, the skeptic can say, ?See, Business Analysts are a waste of money!?

If it?s a bigger, organizational change you?re trying to bring about, this is just one encounter of one type in a long, long process, and success is not certain, no matter how well you do your part. I highly recommend ?Fearless Change: Patterns for Introducing New Ideas,? by Manns and Rising.

Source: http://www.ufunctional.com/2012/10/22/persuading-that-bas-are-worth-it/

obama open mic jefferson county colorado extenze tenacious d steve smith zou bisou bisou tim tebow press conference

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.