Hi,
I'm a Snr Business Analyst and have recently joined a team where the business analyst role is pretty limited i.e. just deals with gathering and documenting requirements in a 'list' format.
I'm looking to introduce in some in-depth functional analysis via techniques like Data Flow Diagrams, Entity Relationship models etc. The challenge is that the business users / shakeholders have no understanding of these tools; hence how do we get them to buy into this concept and most importantly, be happy to sign-off the Business Requirements Documents?
I'd be interested to know any experiences and successes in this area!
Thanks
Roy
Roy,
I just finished a contract where I experienced two successes and failure to introduce this style of working: the differentiator between the 3 experiences seems to be the people I was trying to convince as I tried exactly the same method with all three.
I used a template Terms of Reference to docuement the drivers, objectives, principles, scope and functional requirements as far as I could, then I arranged a sign-off meeting sending out the TOR and an agenda that laboured the imprtance of the TOR - that to get this wrong would cost them big time in terms of time and money.
At the meeting I used a worked example on a presentation to show how they all link together and labour the point again.
For two groups I got sign-off and for one I got rebellion.
I hope these attachements help. Let me know how you get on.
Guy
Roy, Guy
for me, there are two ways to tackle this:
i) business case - demonstrate the value of these techniques. You need to identify the problems with current/historic projects and provide a business case that demonstrates how things would have worked better. I think this is good practice anyway - we shouldn't just use an approach because we always have - we should understand and be able to demonstrate its value. I recognise that sometimes you don't have access to this sort of information. In this case, you could provide an illustrative project to support the business case.
ii) stealth - don't use any scary names and don't make a big deal about the techniques you are applying. You should probably avoid making a formal deliverable as well. Just introduce them as things you find useful in exploring the problem from different angles. I would consider 'dumbing down' the diagrams as well to make them more approachable. The value of these should become apparent from your usage and support the business case.
I'd be interested in hearing of your success, or not ;-)
Alex
Alex,
I completely agree with your 2 points (apart from the "dumbing down" suggestion - if any part of the analysis can be dumbed down without losing content and usefullness it should be and if it can't then it must not be).
Guy, Alex,
Many thanks for your advice. I will be progressing this over the next few weeks and will report back on progress and the issues that I'm sure will arise!
brought to you by enabling practitioners & organizations to achieve their goals using: