So, your <checkwriter> has determined you can’t afford an analyst for your technology project. Instead, they want you to do it. (You? Have they met you?) After Googling “business analyst,” and “elicit” you realize you’re even more clueless than you thought. Worse, your PM and development team just asked you what the team should start working on….
I can’t teach you to be me, but I can tell you a few things I definitely would NOT do…..
Don’t Become Immersed in Current State
Resist the temptation to become (another) subject matter expert (SME). Chances are you’ve got lots of people in the weeds. Ask them about the swamp; do not get in there with them. You’ll learn along the way…
Too often novice analysts (and insecure project managers) focus on mastering (and tirelessly documenting) the current state – as if having a Visio now makes it okay to finally get rid of it! Business process owners are also guilty of the “let me show you ….” instead of providing an answer to your question. Steer clear! If not, you’ll find yourself burning week(s) learning and flowing out someone’s job when all you really needed was agreement on a data set for the cloud architect.
Unless current state flows and docs are a specific deliverable in the project’s SOW, don’t waste time documenting system’s past. Focus your efforts on eliciting the information you need from your SMEs to define, build, and document future workflows, future components, future interfaces, the future.
Don’t Be Afraid to Assign Deliverables
One of core responsibilities of the team’s analyst to provide the infrastructure and artifacts needed by the appdev (and devops) team so they can build (and test) software. That doesn’t mean that the analyst is the only person who has to write stuff down.
Every team has a different division of labor, and each analyst has a different style and approach. Style notwithstanding, we can all agree that I cannot do a Vulcan mind-meld with the DB architect. I need a schema and component diagram (regularly updated) regardless of how busy you are. Similarly, business process owners aren’t exempt from writing stuff down, either. I need a list of the exact data points everyone wants retained. Another demo of “how I do it now,” isn’t a deliverable.
The beauty of a Waterfall effort is that there are clearly defined inputs and outputs. The Gantt is not forgiving. It shows everyone in the room if a gate is open/closed, and who/what is keeping that gate from closing. The beauty (and curse) of Agile is that it’s much more flexible. Things requiring more discussion, bigger decisions, “grooming and refinement” can easily be re-prioritized in favor of backlog items upon which there is violent agreement. As an analyst, you offer insight and best practice advice, but at the end of the day, deliverables codify key business decisions. I can’t make those for you.
Don’t Forget Whose Side You’re On
Whose side are you on? The Development Team. Period. Why? Because that’s the team you’re actually a part of, and they’re the people doing the work (for you.)
If you’re new to being an software analyst, you will quickly see that your seat in the development team is to articulate the client/business vision. That doesn’t mean you’re the client. Conversely, when you sit in client meetings, your role is to be a relentless advocate for the development team. But, that doesn’t mean you can make decisions or agreements on their behalf. Being the “creamy filling in the Oreo,” can be difficult. Empathy, and helping others to have more of it, is an essential skill.
The reality is that no matter how smart you are and how much you’ve thought about something, you’re going to make a mistake or mis-assumption. Analyst’s mistakes are built into the code, seen in public – sometimes in really big meetings. You can’t let your client blame the “stupid developers,” when you know full well your poorly written acceptance criteria was the cause. If you throw your team under the bus – even once – you will quickly regret your lack of courage.
Final Thoughts
There’s a certain amount of frustration involved in the analyst psyche. You’re usually on a steep learning curve, and time is not endless. You have to accept ambiguity (sometimes a lot of it) and push forward despite unknowns. Learn to say, “I haven’t gotten there yet,” “That was my mistake,” and “We can do it, but it will take more time and money,” and you’ll be just fine.
+++++++++++++++++++++++++++++++++
Copyright 2017 Pierce/Wharton Research, LLC. All rights reserved. No part of this post shall be reproduced without permission. info@piercewharton.com.
When I'm Not at Work.... 
Leave a Reply