The Business Analyst Toolkit – Technical Skills

3 Step process to start with:

When trying to understand the present state we have to question what the organizations current technical capabilities might be. After all, we might have a strategic idea from our analytical research of what it is we seek to accomplish what exact capabilities will we need in order to go from here to there?

• To begin with, we have to understand what we can do right now because that'll give us a better idea of what might be possible, what we'll need to change in order to get to that desired state, and what that desired state might be.
• We need to think about what technical factors might be responsible in whole or in part for the challenge or opportunity that we're facing
• Third, what technical prowess do we need to have in order to fully grasp the situation?

As a business analyst we aren't expected to have the same level of expertise as many of the subject matter experts and key stakeholders that we might need to be able to speak with intelligently, however, we do need to have at least a baseline understanding of our area in order to appreciate what these underlying technical challenges might be.

For example, if you're working within software development area you want to at least have some understanding of what might be a hard or easy problem to solve from a technical perspective. Rather than simply waving your hands and saying, well you're smart, you can figure it out, we need to have an appreciation for what they need to go through in order to bring that solution to life. Doing so will help us ensure that our end solution is effective and efficient in meeting whatever problem or opportunity is that we might be investigating.

When it comes to defining the desired future state, what changes and how technical capabilities are expected following completion of work, we need to be able to speak about this at some level of detail, so that we have objectives that are clear and measurable. We can't just say that we want our systems to be faster. We need to be able to say that we expect to deploy this type of solution, using this sort of architecture, resulting in x percent improvement, based on these sort of facts or evidence that lead us to believe that that will be possible. Without that level of detail, even at this relatively early part of what might turn into an extended project, we're simply not offering much value.

We also need to think about what new technical skills will or must be acquired by stakeholders along the way. It may turn out that while attacking this problem or opportunity on its own might not be terribly cost effective, we're in fact learning so many new things, both in terms of what our key stakeholders and other resources might learn, that it's worth undertaking simply for that educational process. Think, for example, about how much was learned by the aerospace community during the Apollo project sending men to the moon. There were so many different challenges that had to be met, and so many things were learned that didn't just apply directly to the space program, but also to a wide variety of industries that touched it in some capacity during that initiative.

These technical skills cascaded through a wide variety of different areas, providing untold benefits into the future. Perhaps your project or the type of analysis that you're looking at right now might lead to the same sort of cascading effect at a smaller flow, of course, of new skills that can be valuable throughout the organization. When it comes to determining how to get there portion, bringing that past or that present into the future, we have to look at what capabilities need to be developed in order to reach that future state.

Now we did this when it came to the future state, but now we need to put steps together that can get us from here to there. We need to think about the skills that have to be developed in order to reach that desired state, and who needs to develop those skills in order for that future state to be accomplished.

Finally ,as always, we need to also question once again, whether the expected benefit exceeds the expected cost. If not it's entirely possible we should not take any action at all.

If so, then we need to continue pursuing this. The key tools and skills from a technical perspective will vary widely based on the type of work that you are undertaking. You're in a software development environment versus a building construction environment versus an aerospace engineering environment. It might be very different in terms of the tools and skills that you need to bring to the table or the type of underlying technical concepts that you need to have an understanding of. However, having technical awareness and systems thinking abilities will be useful in all endeavors, so always seek to understand the type of work that you're analyzing. If nothing else, it'll provide you with the value context you need to do your job effectively.