Great Analysts Do Solution

“Just tell us what you want and we’ll tell you how” - the old adage of “what” vs. “how” in the IT mantra.

Today I was reminded that effective (great) solution analysts do both.

[I think the architects just threw something at my head from down the hall]

Let me clarify a bit…

I don’t think that solutions analysts need to know the extreme interworkings of a solution but they had better understand the conceptual aspect of the solution, and, most importantly, know what it can and cannot do. You must be cognizant!

Take for example a custom-development system vs. one that is available off the shelf (SaaS more specifically). When eliciting requirements it is critically important not to lead stakeholders down a path that will be impossible to fulfill with the defined solution. (read: you’re solutioning with the team) So, if the winner ends up being a pre-built package then it’s important to know the boundaries as you’re dance with the stakeholders. Otherwise, there’s a solid chance that you’ll never be able to fulfill requirements that you pulled out of the stakeholders.

[I think the PM just threw something at me – we wasted time and irritated the stakeholders because we’ll never be able to deliver this functionality]

So, in summary, understand the capabilities and constraints of a solution early in the game – even in the requirements phase.