Article Menu

Tuesday, 12 October 2010 10:16

Don’t be a Business Analyst Bully!

Written by 
Rate this item
(0 votes)

Kupe_Oct_12-finalI was involved in a conversation a few weeks ago with a group of business analysts.  The topic was around how to get reviewers of requirements to be engaged and get the necessary sign-off.  I noticed two schools of thought emerged.  One was an advocate approach and the second was a bully approach.  The advocate approach was geared towards truly receiving buy-in, where the bully approach consisted of assuming buy-in and using pressure to get sign-off.

Although similar to a bully on the school yard making you give up your lunch money or face being beaten up, the bully BA approach consisted of fear tactics.  The ideas suggested consisted of sending a document out for review and if there were no questions by a certain date that meant approval.  Silence was an approval.  The bully approach also consisted of escalating to the reviewer's management if sign-off was coming too slowly.  What good comes from the bully approach?  In my opinion...nothing.  All it does is push off the inevitable which is the stakeholders' finding issues in UAT or in the production environment.  The stakeholders do not take accountability when the bully approach is used.

If stakeholders were comfortable with the requirements presented for sign-off there would be no issue obtaining sign-off.  The main reason reviewers don't want to sign-off on requirements is because they don't know for sure what was captured will meet their need. Therefore, they don't want to be held accountable.  Forcing them to sign-off just moves back the time when they'll see the solution and really be able to give their input and approve.  If that time is in UAT, it's too late. 

What value is there in getting buy-in on written requirements, both textual and models?  For the development and QA teams there is definite value.  Things like use cases are used as the basis for test cases.  The requirements give the development team necessary information to design a solution.  But, do they really help the business stakeholder get a crystal clear picture of what that solution will look like? It helps somewhat, but it does not give the stakeholder the comfort they need to sign-off.  Think about a home builder giving you a list of requirements for your new home.  They may include details like three bedrooms, two baths, a two car garage, finished basement with a media room, etc.  Even if they gave you extreme details related to each room, you would still not feel comfortable signing off and letting them build your home.  You would want to see pictures.

Pictures were the essence of the advocate approach discussed.  Along with the textual requirements and models you need to add pictures and possibly a way for the stakeholders to touch and feel a potential solution.  These pictures can be anything from hand drawn prototypes on a piece of paper to a working simulation.  These pictures give your stakeholders a much better idea that the solution team is headed in the right direction. 

I want to share how I used prototypes in the past to give my stakeholders the comfort level they needed to obtain signing off on requirements.  The examples I want to share are related to process change and data integration.  I assume many of you have done prototypes of user interfaces and are hopefully incorporating them in your daily work.

Process Change

I worked on a project where we analyzed the business areas process for managing inventory. During our analysis the consensus was the system supporting the process could work with the updated process.  So no system changes were being planned as part of the solution.  Before we finalized requirements and moved forward with the solution we set up a prototype or simulation.  We set-up a test environment for the application and sequestered a conference room where we simulated the new process.  We went through every scenario and saw the new process in action.  Two things happened. One we realized the application did need some slight modifications and, with those modifications the process would work and meet the goals of the project.  After this simulation the stakeholders felt comfortable signing off on the requirements giving us the go-ahead to design and implement the solution.

Data Integration

Another initiative I worked on included updating the method used for data transfer between two systems.  In this case there were no changes to the source or target system.  The goal was to improve the speed and accuracy of the data transfer between the two systems.  A large textual doc was created with data mapping and rules. This was perfect for the development team and overwhelming for the user community.

In this case we created screen shots for each scenario triggering the data transfer.  For each scenario we had a screen shot of the source system triggering the transfer and a screen shot of the target system once the transfer was complete.  This allowed the user community to see the cause and effect which gave them the comfort to sign-off.

There are many options available to you to help with prototyping and simulation from free solutions to various levels of fee based solutions.  If you want to be an advocate you need to be creative and give your business stakeholders reason to feel comfortable with the solution requirements.   

Don't be a bully!

Kupe

Don't forget to leave your comments below

Read 4934 times Last modified on Tuesday, 27 March 2012 13:46
Published in Kupe Kupersmith
Kupe Kupersmith

Kupe Kupersmith, President, B2T Training, possesses over 14 years of experience in the business analysis profession. He has served as the lead Business Analyst and Project Manager on projects in the utility, television and sports management and marketing industries. Kupe is a Certified Business Analysis Professional (CBAP) through the IIBA. Kupe is a trained improvisational actor and performed for years in clubs around Atlanta.  He is a big believer that we can work and learn while having fun. Kupe is a connector and has a goal in life to meet everyone!

Latest from Kupe Kupersmith

More in this category: « Business Analysis Love Fest at BBC How a Business Analyst Becomes an Advocate »

Comments  

 
0 # Chris 2010-10-12 07:30
I think 'silence is sign off' is not come from trying to bully, but rather a) get a response, or more than likely b) the stakeholders that are engaged and active will provide their feedback/sign off anyway, those that are not involved or not interested in project are not responding anyway. So by setting the hard date, basically the go ahead comes after receiving all sign-offs and not trying to track down and get the others to give an "official" word even though they don't really have any comments or feedback. It probably goes to who is responsible for signing off and how many stakeholders have been identified. Probably it's better to revisit who has been identified as hoving to sign off on the project. I haven't seen that approach in quite awhile and I think it may be linked to the fact fewer people are being asked for sign-offs and more ownership of the project from a business perspective is being taken.
Reply | Reply with quote | Quote
 
 
0 # Jeremy Bowden 2010-10-12 08:45
c5brown, I totally agree with you. I think the difference here is that customers understand the requirements but they do not respond in a timely manner. We all know the people in our organizations who will respond 5 minutes later and the ones that will respond 5 days later...if they respond at all. It is tough obtaining sign-off from these types of people. I agree with Kupe also in that customer should not be bullied into a sign-off if they do not fully understand the requirements. The examples and techniques you outline are great...I will have to try the screen shot/trigger one. Does anyone have a suggestion on how to obtain sign-off from stakeholders that are too busy to respond?
Reply | Reply with quote | Quote
 
 
0 # Cecilie Hoffman 2010-10-12 09:01
Kupe, your statement, "If stakeholders were comfortable with the requirements presented for sign-off there would be no issue obtaining sign-off." is the key. The people who are trying to manage the process for the project request need a date for requirements sign-off so that they can manage the overall project. Some stakeholders take the date seriously, others don't and there's another group of stakeholders who won't sign off until someone else signs off first. Your solution, creating a prototype, is a fine example of taking the initiative to make it easy for people to publicly sign off. There's an important step that comes prior to requirements gathering that involves profiling the stakeholders - this activity is usually a shared activity between the PM, the BA and the project champion. These profiles can be used predict where the stakeholder's concerns are going to be - if you know what the concerns are you can plan for the extra effort, e.g., a prototype, or some other trust building artifact or representation that will enable the sign offs to roll in like water off a duck's back. If you know which stakeholder needs to approve first to release the log jam, you can use your time wisely and concentrate your efforts on that person. The bully approach is a reaction to circumstances, typically time-pressure. The more clever business analyst anticipates, analyzes and plans. Great article, Kupe!
Reply | Reply with quote | Quote
 
 
0 # Annie McGlade 2010-10-12 09:29
Agree to a point however I think the statement that "if stakeholders were comfortable with the requirements etc.etc." is naive. In a large organisation, the stakeholders are not just the business units wanting the change (and they usually are happy to sign off the business reuqirements) it is other related business areas such as Risk and Compliance, and some of the technology areas have pre-solution requirements such as architecture & support. Testing and development also have a stake in the requirements from the perspective of their understandabili ty and completeness. We have introduced a responsiblity matrix that clearly indicates WHY a stakeholder is reviewing/signi ng off a spec and WHAT they are responsible for, e.g. testing is singing off that the requiremetns are testable not that they are correct from a business perspective. Even given this, we still have repeat offenders who will not sign-off. We also have a situation where governance does not allow passive approval. These recidivists are engaged, have frequently commented (verbally) favourably on the content and style of the deliverable, but getting that last actual approval is denied. In this case it has nothing to dop with confidence or reluctance to commit the responsiblity and everything to do with avoidence. Then escalation is the only option.
Reply | Reply with quote | Quote
 
 
0 # Diana Ryan 2010-10-12 13:06
Kupe, you touch on something fascinating here... which is that stakeholders must sign off on requirements so you have written agreement on scope and functionality, but at the same time, stakeholders rarely read or understand every detail. No matter how carefully they read it, there will be some logic or flow or some functionality somewhere that they did not understand they were agreeing to. Sure, mockups and prototypes, pictures, etc. help a lot, but those will not visually represent every requirement. They know it, and we know it too. I think that's what is often behind stakeholder reluctance / slowness to sign off (and maybe they are not evil and trying to throw off your schedule). However, we can't wait forever with developer resources on standby, so something has got to happen, and that's why we have to poke and prod a little bit. That's not bullying, it's reminding them to make a move or step aside, because life goes on.
Reply | Reply with quote | Quote
 
 
0 # Marc Schmandin 2010-10-12 22:15
Using screen mock ups has definitely helped us achieve sign off. As you say Kupe, the stakeholders can then see what the final solution could look like and helps to ensure we're all singing from the same hymn sheet. Balsamiq is quick and very easy to use - not to mention that there is no chance of stakeholders mistaking a prototype as the final product.
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-10-13 00:03
This conversation was exactly what I was hoping for. Thank you all for the great comments. @c5b rown - I agree that the silence technique is not intended to "bully", but it can be perceived that way. If people are not interested or involved in the project then should we even be requesting their sign-off. If their approval adds no value to the project then they should not be included. @jabowden - A conversation needs to happen with the people that are too busy. How important is the project to them if they can't find the time? You should work with them in a manner @cecilie.hoffma n suggests to understand what will help them get to the approval. @cecilie.hoffma n - Great to hear from the "Bad Ass" BA! @Anniemac - I think we agree! Yes, the business side is not the only stakeholder. You outlined the different groups you need approval from. I love your responsibility matrix trying to make it very clear the why and what from their perspective. What I don't understand from your comment is why the people that verbally approve, don't physically sign-off. What is holding them back? @dianage ek I agree with you that prototypes are not the end all be all, but at that stage it gets them closer. So what else do your stakeholders need at that stage? My point of bringing up this topic is to help reduce the risk of surprises late in the game. @marcsch mandin - Thanks for sharing the tool you are using. You bring up a great point about the users expectations. The higher quality simulations definitely raise the potential for users thinking the final product is complete. Than ks again everyone for sharing your thoughts and experiences!
Reply | Reply with quote | Quote
 
 
0 # Amanda Dixon 2010-10-13 03:05
jabowden, Here is a sucessful technique I have used when working with a team that I had issues with in the past due to their workload: I prepared my approval tracker and had it minimized on my desktop. After presenting my finalized requirements to show that any updates had been made from the previous review and ensuring no one had further questions - I pulled up the approval tracker with them looking on and sent for their sign-off. Since I had scheduled a little more time than was needed for the review, time to complete their approvals was blocked off on their calendars. All of their questions had been answered and the information was fresh on their minds. Approvals came back in rapid fire...and approval was completed by the end of day. Kupe, Great article. One BA Bully can undo months of work to gain a trusted working relationship with our business and IT partners.
Reply | Reply with quote | Quote
 
 
0 # Akarsh MG 2010-10-13 21:39
@Kupe - Great Article. Your statement, "If stakeholders were comfortable with the requirements presented for sign-off there would be no issue obtaining sign-off." is necessary but all the stakeholders usually do not respond in timely manner. Once i gather the requirements most of the time i capture in a visual format using "powerpoint" with mockups, prototypes, pictures, etc; few stakeholder usually agree to sign-off immediately but few stakeholder do not repsond at all even though you give them the prototypes. Also there are times you discuss show casing the presentation/pr ototypes in the call they love it and agree but getting written sign-off usually takes a longer time
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-10-14 01:25
Thanks @akarshmg - So why don't the stakeholders sign-off? What's holding them back? I must say, I am surprised no agile comments have surfaced. I know you are out there!
Reply | Reply with quote | Quote
 
 
0 # Dominic C. Matteo 2010-10-14 02:06
@jabowden - I face the same problems and have also used a hard date to assume sign off in the past for stakeholders who "don't have time". However, over the past couple of years I have moved away from that practice and instead I follow another practice similar to @SRbaa...It is a fine line trying balance individual's time and making them aware of their responsibilitie s. I block off an hour for two consecutive days (sometimes more, sometimes less depending on the volume of material being reviewed) in the stakeholders calendars with instruction that this time is for them to read and review the requirements on their own and identify questions they may have. When I send the invite for the review, I then set some ground rules for the meeting... -I do not read each requirement word for word, instead I summarize or better yet, have someone else summarize each requirement. -T he stakeholders are expected to have reviewed and understand the requirements in the time I created for them. The purpose of the review is to address questions and issues and to obtain sign off. -In some cases we agree if a stakeholder is unprepared, the meeting will be cancelled. -Pri or to all of this taking place, at the beginning of the project, I meet with the PM, the stakeholders and sometimes their managers to set expectations regarding the sign off process @Kupe. ..Agile projects tend to avoid this issue because of the "pig" stakholders. The simple selection of stories for a particular iteration as well as the UAT take the place of formal sign off in most cases. By selecting the story to be worked on, the sign off is partially implied. The rest of the implied sign off comes with the completion of UAT. During the iteration or sprint, conversations are taking place around the stories and the details are refined.
Reply | Reply with quote | Quote
 
 
0 # Alex Papworth 2010-10-14 02:07
Great article and discussion. So metimes I think it is all about positioning. T here is something about asking people to 'sign off' that causes some people to put the brakes on. Giving feedback is one thing, signing off shows commitment and, worse still, taking responsibility. If you never make a decision, you can't be wrong, right? That aside, signing off should be positioned as the final step in a review process. The stakeholders should be engaged in a form that is easy for them. I use prototypes (and scenarios) alongside my use case model as a matter of course. I also ask the stakeholders to help me build realistic prototypes to help them engage with someting that deals with scenarios that would happen in 'real life'. The prototypes would evolve alongside the use case model. When you ask for signoff, where possible, it should be in workshop environment with the stated objective of signing off. Give them the document with sufficient time to review in advance and use the session to resolve new issues, NOT walk through the entire model again. It should be more like a final review as all the issues should have been raised and resoilved by that stage. Just a few thoughts ;-)
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-10-14 06:31
I love your approach @alex_papworth. I wrote a post last year along the same lines, http://www.batimes.com/jonathan-kupersmith/the-three-most-important-ba-factors.html
Reply | Reply with quote | Quote
 
 
0 # Simon Papson 2010-10-15 11:42
Kupes, Maybe the reason that Agile-type BAs aren't responding is that this isn't an issue for us. Sure, I had to get some sort of verbal agreement to the list of user stories I wrote (one line for each to start with!), but I continually made the point to all the stakeholders that this was NOT a final commitment - any and every story could be changed at any time, and new stories could be added at any time. This gives the stakeholders less of a sense of panic. Less of a feeling of signing their life away without hope. They're much happier to commit to an up-front "best guess" when they know they can change their minds later without being attacked with "scope creep" and other such blocking responses. Of course, the other side of this is walking the talk. When they/we discover new or different requirements, I make sure to readily add them to the list without complaint. On the shorter time-scale, I do use prototypes when new screens are involved, but this becomes less necessary when the next requirement being worked on is merely an increment to the system they're already familiar with through UAT and demonstrations. They can see the screen we're changing; it's just a new button THERE, with an extra column over HERE. So, I haven't encountered this reluctance to sign-off in the Agile project I'm currently on. (Although, I did once work with a project manager who believed in the "silence equals acceptance" philosophy, as a tool to get reticent stakeholders to speak out if they didn't agree with something. If they think you're going to proceed with something they don't want, the "silence equals acceptance" method forces them to speak up rather than silently hope for derailment another way. And, I have since used this method myself when necessary - with a jocular tone, not a bullying one. It works.)
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-10-16 11:06
@simontheba - That's exactly what I wanted to here from the agile side of the house. Agile development methodologies don't have an issue because for the most part the solution is being designed, developed and tested virtually at the same time. All BA's need to work with all stakeholders so there is, as you say, "less of a sense of panic".
Reply | Reply with quote | Quote
 
 
0 # Akarsh MG 2010-10-17 16:23
@Kupe - I am not sure whats holding them back to sign-off; but its the problem most of the time with mid-level SME's. Well btw visual presentation has helped me atleast 80% of the time for getting sign-off. Also currently customer prefer prototyping method so i am not using Agile methodologies.
Reply | Reply with quote | Quote
 
 
0 # Mary Gerush 2010-10-18 01:04
This is a great discussion. I love the energy coming from the BA community these days! We haven't mentioned the importance of the BA's soft skills. Strong soft skills are key to building trust with stakeholders (both business and non-business) - and that goes a long way to improving the way that those stakeholders respond to our requests. Adaptive communication, active listening, strong verbal skills are all important tools in the BA's tool kit. (As is an understanding that often "you catch more flies with sugar than with vinegar.") Per haps we need to ban the word "signoff" from our vocabulary. It's ominous! What would we replace it with?
Reply | Reply with quote | Quote
 
 
0 # Nathan Caswell 2010-10-24 05:38
The notion of eliminating the word "signoff" is very attractive. One alternative might be "funding decision". :) That would shift the semantics in a way the keeps business involvement rather than an hand off. But probably not solve the problem. One of the signoff techniques I've seen is the old "good question -- it's in here" with a point to some random box on a process chart trick. I.e., say what you have to to get the signature. There is a certain 'we know best' arrogance that works if the implementation works. Very effective on very large projects that are likely to fall of their own weight anyway. Having watched a few other examples of difficult signoffs, I think they spring from the same basic assumption that this is an IT project, and the business needs to understand and approve the IT perspective. Carly Simon expresses the problem as "I bet you think this song is about you , don't you" "Easy" signoffs have more to do with "are we satisfied we know what we need and can tell if IT delivers it?". Of course this means having done the work to align all the business stakeholders. Springing 100 pages on the business controls person 24hrs before the due date is an effective way to generate push back. And there is always the last minute stakeholder defection. It may be a design gap or political maneuver and can be resolved by rework, immediate bargain, or cutting the defector out of the scope. But in any case it requires business level resolution. An other characteristic of "easy" signoffs is the public concurrence of the solution architect, project manager, or other role that will be accountable for the implementation. The BA, not the business, needs to be able to communicate the models, processes, and detailed requirements. It is also quite helpful if the BA has to sign off that the solution design from the IT side satisfies the documented business need. To connect with agile, I think that whatever the degree of iteration, the notion of "product owner" is a pretty good way to capture the BA. In enterprise situations where integration and coherent architecture are more important "product" may need to be de-constructed to focus on business need, but the role wrt IT remains.
Reply | Reply with quote | Quote
 
 
0 # Tony Heap 2010-11-08 05:19
Another comment from the agile camp... The last project I worked on was semi-agile, in that we delivered small chunks of functionality (aka stories) in short (3-week) increments, and we were very open to change. But I *did* maintain a document I called the Functional Specification, and I *did* have a sign-off process, although it was somewhat hidden from the stakeholders. Here's how it worked. The Functional Specification was a spreadsheet. Simplistically put, each row in the sheet contained an acceptance criterion for a given story. I also had one "sign off" column for each stakeholder. I ran twice-weekly requirements workshops with stakeholders and in each workshop we would cover off the next most important requirements. I would explain a given feature, maybe demo the prototype (get them nice and engaged). When everyone in the room agreed on the feature, I inserted today's date in the relevant "sign off" cells in the Functional Specification. Job done there and then - no request for sign-off, no need to wade through a fat document, no chasing people. One of the key benefits of this was that we signed things off as we went along, and whilst they were fresh in people's minds. At any time I could also see what had already been agreed and what was still outstanding (colour-coding helped with this). Plus I could also appear to have an amazing memory by saying things like, "well guys we all agreed that it would be 3 widgets per page back on 12th November - are you saying you want to change that to 4 now?" :) And finally, a blatant plug - I've just started blogging about this project - the first instalment is available at http://www.bridging-the-gap.com/how-i-became-an-agile-business-analyst/
Reply | Reply with quote | Quote
 
 
0 # Kupe Kupersmith 2010-11-08 06:46
@tony.heap - Great story. That's what I mean about not being a bully! Thanks for sharing and I'll check out your post on Bridging The Gap.
Reply | Reply with quote | Quote
 
 
0 # B Allen 2011-07-08 20:56
I like Tony's approach - I am going to give that a try. Seems like more often than not when sign-off is the issue it is not the stakeholder it is the analyst.
Reply | Reply with quote | Quote
 

Add comment

back to top