What the Business Analyst often does is stop here, thinking they have the whole picture and are good to go. Analysis begins and then the task moves to IN PROGRESS.
What the Business Analyst seldom does is talk to other BAs about their challenge. They have a task to do, an aggressive, often crazy ETA and a story committed to THIS iteration so heaven forbid it should not be tasked out for success. Stopping to talk through the challenge is seldom seen as a valuable use of precious bandwidth. GET IT DONE!
Any of this sound familiar?
While mentoring some new Technology BAs, there were a few challenges where I assumed they knew what I considered to be basics. Why did they proceed without more information? Why did they think their requirements were complete when they were clearly (to me) not? The newbies went on to teach this oldie a lot when they said “Stop assuming we know this. We don’t think you know what you know.” What?
After chewing on that statement and some crow for a while, I came up with thoughts that may be attributed to experience – a lot of failures, trial and error and other learning paths. I will share them with you in case you too think every BA knows this stuff, and you don’t have anything special to offer. If you want to, pass this on (plus the things you didn’t know you know) to your mentees. I promise you will be happily surprised that this most basic knowledge share can make a difference in their growth and stress level whether the BA is in IT or in the Business.
Dear fellow BAs, What I didn't know that I know …
Don't assume Team Members (TMs) know what they are talking about when they ask for a change. They may be new users and new leaders. Help them out by diving deep. You may get some pushback, but either leave the meeting confident that your business partner is an expert or know who might be and ask that expert to a second meeting.
If you are dealing with changes to a previously automated processes, that automation may have been built with TMs who moved on. A thin understanding of an automated process can lead everyone down a rocky path. This means you will want to understand that current automated process, behind the scenes, to add your understanding to the “How It’s Done Today” discussion.
Start at the beginning and get to know your partners. As we are in an email, IM, HipChat, Conference call, Live Meeting world we have to work harder than in the past to get the whole picture. We don’t have the added advantage of body language to help us (the TM who looks down or away can speak volumes about not having a clue or disagreeing with what their Leader is saying) Don’t minimize the importance of reaching out and meeting your partners face to face or on one-to-one phone calls.
Expect your business to walk in the door with a technical solution. Everyone has a great idea, but requirements gathering needs Sherlock Holmes-type experience. Don't be afraid of being the dummy in the room. I have been that dummy so many times I’m amazed the business still contacts me for help. Everyone started learning about your business at some time, and your partners will tell you everything about what they do and feel good about doing it.
Even if nothing else is clear, make sure you totally ‘get’ the business need. Why the heck are you in this meeting and not at lunch? What are you solving for? Wait! Hold firm. Tempted to talk solution? NO technical solution without requirements! We might be good at guessing, but without requirements, that's all we can be, a good guesser. Actually, there might not be a technical solution. Maybe if your partners complete step A before step B, they won’t need an automated solution to find step A data while completing step B. Get it?
Who will be impacted can be a rattlesnake behind a rock. Assume your partners don't know who else uses the same functionality. Ask. Send out a message to a wide distribution, if necessary, but watch out for those cool automated processes that other parts of your business jumped on for themselves and neither you nor your task partners know it You don’t want the noise from other TMs asking “Who changed our stuff?”
Now, the fun part, The Technical Solution!
There is a pro and con for every technical solution I have ever delivered. Remember to convey the ‘cons’ clearly for all parties and relay these cons when you officially announce the technical solution. Everyone knows what to expect. Right? Own it. The BA owns the solution, be prepared to explain the “why it is the right thing to do for everyone” – the business, technology, the company. P.S.: This is a great time to share a prototype or demo if you have something this early. Requirements may change (like you didn’t know that, but I had to write it down.), re-evaluate the technical solution when that happens.
Expect thorns in the roses. Knowing who needs to approve things can be tricky. Who really has the last word on saying the technical solution is good to go? Really. Nothing is worse that feeling you have a plan and find out someone read the email a week later and has the power to say “Well, I was thinking …”.
The same is true for when to start the tasks PLUS when technology prioritization says you can start. Don’t promise a start date until you have the date from the business and the date from whoever is tasked with making the changes. Everyone has different priorities and bandwidth.
I found that the sooner you can start talking to trainers and testers the better off you would be. Trainers and Testers, in my experience, are valuable commodities, and you want to pencil in their time early. Nothing is worse than making a big change and finding no one knows how to perform the new process. Don’t rely on your business to have training on their checklist. Have it on yours too.
ETA is the monster that the BA needs to battle. This is a truth. Once someone hears an ETA whispered over the wall, the BA is handcuffed.
- Avoid verbalizing or writing an ETA if at all possible.
- Since this is not possible, don’t act like a superhero. Be smart and keep a list of potential roadblocks (sunny days when everyone is always sick, etc.) on you at all times.
- Be very clear about what will be accomplished by the ETA!
I don’t want to come off totally negative here, but more people than just the BA care about the start and stop. Even with the best planning software, the BA needs to tread carefully when talking about the ETA and be prepared for plan B and sound reasons for any delays.
Documentation – We hate it until we need it.
Simplify task names
Name your Project/Feature/Story/Task/Whatever using keywords that you can search on to find out why the change was made. Then, don’t forget to include the business need in EVERY task you create. The Why will make your life easier today and tomorrow.
Give a high-level explanation of what the task will do to reduce the questions you’ll get from interested, but not participating, parties.
Don’t forget to share your Task number(s) with all the business partners who will care about the changes. This MAY stop some noise about the status of your task(s).
Identify Go-To People and SMEs
Who asked for this change anyway? You know, that person now tied to you at the hip. Add their name to the list of Go-To people! Don’t forget to include a list of your SMEs too. Remember the tasks floating around yours. Is anyone working on a task that is needed by you or waiting for you? They deserve to be in your documentation. Keep them in the loop and you have a BA BFF.
One last thing about documentation – Know Your Audience. Write for the reader.
I admit I am Test Plan Challenged.
My BA friend, Marie, is crazy meticulous with her test plans, but for me, any test plan is better than none. Create a test plan and look at it daily while you are working on your task(s). You will be glad you did. You want to know when a step or task is “done.” Nothing feels better than getting to this moment so know how to recognize the moment!
If you make fancy test plans like Marie, you are special.
One more thing:
You know this documentation we were talking about here? Update it when you have any progress or road blocks. Be clear and concise. When things get hairy, your own notes will save you. I promise.
To make your Write Up the greatest story ever told. Here is the formula I wish someone told me about years ago:
- Spend 1/3 of your time writing down the current situation.
- Spend 1/3 of your time writing and re-writing why you are doing this.
- Spend 1/3 of your time detailing the technical solution.
Lastly, if you found yourself saying “Duh” or “Pleeeeeze, everyone knows that” while you were reading my article, then you are a smart BA that assumes, as I did, every person with BA or Business Analyst after their name has as much experience as you have. Remember, some of our BA friends are just getting started (as I was kindly reminded) and can benefit from knowing what you didn’t know you know. Pay it Forward!