I was very, very surprised to find that CIO.com, the flagship website for "Business Technology Leadership" (that's from their site), didn't automatically detect my iPod Touch and re-skin accordingly. Now, CNN, ESPN and most other "mainstream" sites do this automatically so I don't have to be inconvenienced with constant strolling, but not CIO.
Reread their tagline - it's interesting (and ironic).
Monday, January 19, 2009
Tuesday, January 13, 2009
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.
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.
Subscribe to:
Posts (Atom)