Many organizations have rules in place that every project has to have certain roles assigned, and many people in the business analysis community suggest those kinds of rules should exist.
That can only get you so far.
Having those rules in place may help a Business Analyst get on a project, but unless you can demonstrate the value you add to a team, you stand a good chance of getting sidelined, and not invited back to the next project.
Here are some ways I have found to demonstrate my value to teams and organizations.
Build a Shared Understanding
In the article “Your Job is Not to Elicit and Document Requirements” I discussed a few lessons I have learned when working with teams. The times that I have had the best relationship with a team is when I follow those lessons. I do not view requirements as my ultimate deliverable, rather I see them as a means to the end of building a shared understanding. Everyone on the team knows what need we are trying to satisfy and the solution we are building to satisfy it.
What I am doing is managing risk - primarily the risk that the team forgets about key stakeholders or overlooks some important data or process relevant for the solution. If you keep your team informed about important data and process, communicate that information in an easy to consume way and help your team maintain their pace they will want to work with you again.
Point Back to the Need You're Satisfying
You need to keep the team and your stakeholders focused on why you are doing the project. When you start a project, suggest the problem statement exercise I described in the article “Projects Tend to Be Described in Terms of Solutions” or some other technique to make sure you drive back to the real need you are trying to satisfy and how you’ll know when you’ve met that. Then take the output of that exercise and post it where everyone can see it. Then take the output of that exercise and post it where everyone can see it. Then, we you find yourself involved in the inevitable discussion (argument) about whether some feature should be included, or how to go about doing it, point to the problem statement and ask “will what we are talking about help us do that?” Decision Filters can provide the same type of guiding star.
When you are in the process of creating a backlog, do not just dive in and brainstorm a bunch of things to do, but start with your outcome - the need you are trying to satisfy, and then identify what specific things will position you best to reach that outcome. This is the general idea behind feature injection, and a helpful technique for structuring that conversation is Impact Mapping.
If you are in the midst of a project and you sense that the team does not all share the same understanding of the need you are trying to satisfy, or realize you are trying to satisfy a need, suggest that you stop for an hour and create a problem statement. The goal is not necessarily the problem statement itself, but the conversation that comes with it.
Remember that other members of the team are focused on other aspects of the project:
- How will we build it? (developers)
- What happens in this case? (testers)
While they all may have the reason for doing the project in the back of their heads (and the good ones can hold multiple concerns front of mind at the same time) they are also probably subconsciously counting on you to keep an eye on those things.
They may act annoyed when you bring these questions up, but trust me, in the immortal words of Col Jessup (A Few Good Men) “...because deep down in places you do not talk about at parties, you want me on that wall, you need me on that wall…”
Drive Decision Making
I was talking to a friend the other day about her day at work. She had a rather stern conversation with her client because the project she was working on was falling behind; not due to a capacity issue on the team, but rather an inability of the client to make and stick to decisions. To make matters worse, the client frequently hid behind process (oh, well if we have not made those decisions yet it must be because the due dates on the decision log are wrong) rather than taking steps to get decisions made.
She faced a situation that many BA’s face - you do not directly make decisions, but you are certainly impacted when those who are supposed to make decisions do not.
If you want to be in high demand, even if you are not the real decision maker, take it upon yourself to be the person to make sure those decisions get made. There’s a variety of ways to do this. For those of you who like to look at things in terms of a process, here are the key steps in the decision-making process:
- Determine the decision maker. Before decisions need to be made, encourage your team to discuss who is going to make what type of decisions. It is often helpful to adopt a RACI matrix to remember what you discussed. Having this discussion before the decisions have to be made will increase the chances that decision making is distributed to the people who will have sufficient information to make that decision.
- Select a decision mechanism Each decider is going to have their preferred decision approach. Know what those are, and also know which situations are better suited for one mechanism over another. Help the decider determine that mechanism.
- Determine what information is needed. When a decision comes up, ask the decider what information she needs to make that decision, then pull that information together for her. You can have a lot of influence in the way you pull this information together, so be aware of cognitive biases.
- Make a timely decision. Discuss when the decision needs to be made making sure you are not deciding too early without a good reason or procrastinating too long without a good reason.
- Build support with peers/ stakeholders. Sometimes the choice of decision mechanism can help build support - the more collaborative the decision mechanism, the more likely you will build support in the process of making the decision.
- Communicate the decision. Help the decider spread the word about what she decided.
- Enact the decision. Help the decider determine the most effective way to enact the decision.
If you follow those proactive steps and still don’t see timely decisions happening, you can always revert to polite nagging backed up with a clear explanation of the consequences of a delayed decision. Sometimes people delay making decisions because they do not realize the consequences of not deciding in a timely fashion.
Be a Good Team Member
As I mentioned in my last post How To Learn New Techniques, you often get the opportunity to expand your toolkit by helping your team members out when they get overloaded or hit a bottleneck. Ask “how can I help” more often and try to eliminate the phrase “that’s not my job” from your vocabulary. Keep in mind that anyone can be the bottleneck at any given time. Sometimes you help someone else out, and sometimes you are the one who needs help. Part of being a good team member is admitting when you need help and helping your team members help you by coaching them in analysis skills when they pitch in.
Another aspect of being a good team member especially applicable to BA’s is do not make commitments for your team.
We have all run into this. You are in a meeting with stakeholders, the rest of your team is busy developing and testing, and you get asked: “When will this be done?” Unless your team has already plotted that out, resist the urge to make a commitment to your team.
Wait, you may be thinking, what if you say “well I think we can get that done this week” surely the stakeholders will realize that is just your guess and will treat it with the proper grain of salt. They will not. The minute you, as the team’s representative, indicate any time frame, it is viewed as a commitment, whether you intended it that way or not. It is perfectly fine to say “let me check with the team and get back to you.”
How Do You Show Your Value?
Those are some of the ways I have found useful for demonstrating my value. What have you found that works? Leave your experiences in the comments.