Think First: Strategic Planning Having done a great deal of SharePoint implementation work in recent times, it’s been a welcome change to spend the last couple of months working on strategic plans, roadmaps and reviews. Developing or refreshing any strategy is always interesting and intellectually challenging, and the diversity of requirements, expectations and issues that manifest from one company to the next is endlessly fascinating. Given I’m a consultant, you’ll probably expect me to declare my fondness for a good strategic model.  Well sure, but it’s not a lazy preference for diverting diagrams – I expect a framework or model to work hard, providing much needed structure and clarity in assessing current and target states for complex, interconnected domains of people, process, content and technology. In previous strategy work I’ve used maturity modelling but, for a recent IT strategy engagement, an IT maturity model was judged too esoteric.  I considered several alternatives in my search for another framework, but ultimately I found Gartner’s Demand – Control – Supply structure offered the best means of evaluating the client’s IT environment. I’ll leave it to Dave Aron to explain why: structure is absolutely critical in large scale strategy exercises. (And medium and small ones too!) Being able to separate and link demand, control and supply-side issues, and further into subcategories (for example on the demand side: business context, business success, business capabilities and IT’s contribution) that are consistently used is a valuable exercise in itself – and helps to bring some clarity to the wicked problem that strategy setting is. Dave delves further into consultant-speak in his post to describe the framework as follows: A MECE structure/framework covers the whole problem space (the CE part) and has pieces that do not overlap (the ME part), similar to the pieces of a jigsaw. The ME part helps you divide and conquer the issue at hand, and the CE part gives you confidence you aren’t missing anything Put rather more simply, the thing I liked best about the Gartner framework over others I considered is that it facilitated a full assessment of IT in the context of the overall business. Those of us who spend our working lives with a foot in both camps frequently get to experience the entrenched divide between “IT and the business” – the Mars and Venus of organisational practice it would seem (notwithstanding the few stellar exceptions that prove the rule.)   At its worst this divide can lead to significantly increased costs and overheads that can stymie business profit, growth or agility; and so eliminating the silo approach as far as possible when developing an IT strategy seems to me an important objective.  The buzzword is achieving strategic ‘alignment’ though there are some provocative souls out there who claim that the best IT strategy is no IT strategy.  It’s a thought, though if you ask me it sounds like a technique with a high degree-of-difficulty score, best performed at Maturity Level 5. Just by the by, I discovered Richard Rumelt’s recently and actually read (or, if I’m being honest and oxymoronic, thoroughly skimmed) his book Good Strategy Bad Strategy: The Difference and Why It Matters recently.  Particularly liked the examples that distinguished the good from the bad. Of Rubber and Road If the Strategy is the why and what, then the Roadmap of recommended projects, initiatives or tasks arising out of the strategic rationale is the when and how. Unsurprisingly, this is what most clients focus on, and fair  enough too since “plans  are only good intentions unless they immediately degenerate into hard work” as Peter  Drucker has said.  And that ‘degeneration’ from plan to activity seems to be problematic much more often than it should be.  One of the reasons I like to work across the spectrum from strategy through to implementation is that ultimately I prefer to produce something tangible out of all that hard  brain yakka.  And surely a strategy is  only as good as its realisation?  That  said, I believe the strategic rationale for implementation – the context – is equally  important and maybe that witticism “we have a strategy: it’s called doing things” isn’t quite as smart as it sounds.  We all want to avoid analysis paralysis, but charging ahead into activity without due consideration of the why and what is reckless. On a recent  IT strategy job, we developed the usual IT roadmap-on-a-page, mapping out phased initiatives over three years.   But for the highest priority / highest impact initiatives – particularly those with a remediation component – the client required an even greater level of detail than that provided in the table accompanying the roadmap.  So we agreed to produce a series of Action Plans. Details included: objectives, risks and issues, dependencies and assumptions specific to the proposed initiative the principal / recommended tasks comprising the initiative indicative timeframes and resource requirements the anticipated degree of difficulty and ROI impact Overall,  the concept worked very well and gave the client greater confidence in their ability to implement after their strategy consultants had left the building. I’ll reuse the idea and the template wherever appropriate to assist clients move from strategic plan to execution. Think Again: Strategic Review I’m now on a strategic review engagement, doing a sort of ‘health check’ of a client’s online collaboration environment on its first birthday (or near enough) and making recommendations for improvements. They’ve done a particularly great job thus far, but they’re to be congratulated for not resting on their laurels. They’re wide open to assessing what’s worked and what hasn’t, thus far, and are still looking for ways to build further upon their success. They want some Action Plans too. If, as Rumelt claims, “organizations experience significant entropy—the continual drift towards disorganization”, then online collaboration environments may well be the most entropic of all business information management tools.  There’s always room to improve.  Rather importantly, that necessitates checking back with the business to establish what improvement should constitute – there’s that ‘strategic alignment’ again. (I’ve been doing staff interviews for this job, as I did for the previous, and probably the five before that, and I’m reminded yet again just how much of my working life involves questioning people.) *What’s This Got To Do With SharePoint? Absolutely nothing. With that title I was just trying to indicate there’s more to me and the work I do than SharePoint expertise ;-) But also that there’s more to SharePoint than just deploying SharePoint, if you get my meaning.  I suppose this post could be a sort of Tip #0 in my series Top Ten Tips for Success With SharePoint.  Don’t go rolling out SharePoint to your enterprise unless you’ve assessed the platform to be a good fit with your business / IT Strategy and Roadmap that will meet your business requirements. And having done SharePoint, appreciate that it’s never finished, and plan accordingly.  How about a roadmap!  Whatever you’re using SharePoint for, make sure you deliberately review the platform, and explicitly plan to refresh and enhance it in line with your business / IT strategy. (original author: Lynn Warneke) Life Before, During and After SharePoint*

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s