Tag Archives: Strategy

What does “Always On” really mean to us?

A couple of years ago I gave up my Windows Mobile based Smartphone for the greater good, and in return joined the Blackberry “crew”. For weeks I was lost, the WM device may not have had all the bells & whistles of the Blackberry but what it did do, it did properly. I used it for getting my email on the move and the email functionality had none of the quirks that afflict the Blackberry, even today.

I now have one of the better Blackberry devices, have loaded a few more applications, and it’s now usable-ish but typing on that little keyboard is a pain. It’s great for senior managers sending one word emails, but if you’ve been asked a detailed question then sitting at Leeds railway station on a frosty morning trying to type a detailed response takes some doing.

It’s my choice to use the Blackberry, a colleague insists on using his massive laptop with a 3G connection but hoisting that lot around defeats the object of mobile devices. I have a netbook that I use when out and about and that works well plus I don’t have to annoy fellow travellers with my wheeled briefcase that gets in the way in crowds and won’t go through the ticket barriers.

Now I’ve been given one of Mr Job’s new tablet devices to use, we’re testing security software to see if we could use them as corporate email units.

Where I work I wrote a tongue in cheek blog entry about versions of software. In it I commented that early versions are rushed out and don’t do everything; later versions are better but push the limits on the technology; and the final versions (if they’re worthwhile) get swallowed up by the big companies.

The iPad feels very much like V1.0 software: there are lots of applications but, like the Blackberry, they don’t do everything. This got me thinking about where we are going in future, something dangerous for a strategist to do, eh?

If I look at the telecommunications space with the emerging standards around IP based services, the whole telephone concept is going to change. The multiple telephone numbers that you have today will, I believe, disappear. Instead you will have a SIP contact point that is always there, and you will connect to it with whatever device you have to hand. Of course the device will dictate what you can & can’t do when you connect, but then translation services will help. Find a voice message left for you but you’ve only got text access so your phone service will translate the voice to test and show you the transcript.

This isn’t a particularly wild prediction, much of this is around today, it just needs stringing together and making commercially viable. But the main barrier to adoption is our acceptance of this style of communication, it doesn’t fit with our current views of how our world operates.

Back to the iPad, and the same will apply. We talk about “Cloud Computing” but in essence it will be the same model as our telephony. I like Zoho, an online office suite which is now getting mature. Want to word process, point your browser at Zoho and fire up Writer. That’s how we’re going to work in future: you’ll use one service in place of your PC today, and simply access it from whatever device you have at that moment. Again the barrier to adoption is simply the mindset we have today.

My current frustration with the iPad is the fact that it doesn’t give me full PC capabilities, but it’s not meant to, it’s my thinking that is wrong. If I adjust to think of it, and the Blackberry, as connectivity devices of varying capability then it starts to make sense.

So back to the question asked in the title. Always on is the service we’re going to use, and the fact that contacting someone, or using compute services will become a 24×7 offering that we will choose to dip into at our choosing. At the moment we’re in version 1.0 which is why I get one word email answers, but that will change come the next version. Promise!

Advertisements

Why did you do that?

One part of my day to day life is that I research into areas and try to make sense of them, often against the clock. I’m either good at it, or the fool, because I’m frequently asked to do it.

To be honest “making sense of them” actually means deciding if what I’m looking at is suitable & beneficial, be it a technology or solution that my organisation could derive value from, or on the OU module I’m currently taking it’s more about how I can usefully use what I am learning about.

The thing about trying to make sense of something of interest is that its not just understanding it and how useful it could be, its about being able to articulate that to others, and it’s only when you try to communicate your understanding that you actually realise how little you actually do understand.

It’s interesting when presenting to others to see the various prejudices that are carried along with peoples thinking, which is generally made visible in the challenges that come back. Geoffrey Vickers came up with the idea of the Appreciative System which really applied to understanding why people think the way they do, which in turn means looking at their past and what events and values have shaped that view (their “Appreciative Setting”). So run back in history & see the key events and learning that someone, or a group, has been through and you can start to understand why they are thinking like they are and thus why you’re getting the specific challenges.

I’d suggest the same methodology would be well applied to some artifcacts as well. When I analyse a solution or technology, I often find things that at first glance leave me asking “Why on earth is it like that?”. A good example here is a project I’m working on around a major ERP deployment. One option we have is very mature with a large market presence running into hundreds of thousands of sites worldwide. Look underneath the covers at the way it works in some places, especially the integration between modules, and you find a regular muddle that makes little or no sense at first glance, indeed it almost suggests a lack of architectural governance. And speaking of the architecture, it also looks very strange in these days of objects and service oriented architecture.

Of course, at that point trying to present this to colleagues I got the same responses from them, and these unanswered challenges leave a feeling that doesn’t help with trying to present a benefits case. You end up with a senior exec saying “How can it be good for my business when everybody around you has these questions (that I don’t actually understand) that you can’t answer?”

Now try to use something like an appreciative system and run back through history – the integrations didn’t all come about at once, they appeared over time and in some cases represent the state of the art at that moment. Secondly they were probably developed in phases, so some represent must-haves that had to delivered in a first wave as quickly as could be done, later phases probably had the benefit of more time. And when you have a global base of that size, the cost & risk of rewriting older technology code to a newer technology just doesn’t make sense. These are conjecture on my part initially, but I can now ask questions to confirm or disaffirm my thinking.

I had a similar experience looking recently at the C++ language, based on some technical developments being done at Microsoft that could impact our development team. As a BCPL man myself, C++ looks way OTT: types on variables? objects? the referential model? Yuk! But then I found a paper written by Bjarne Stroustrup about the background and the design decisions made when evolving C++ and a lot became much clearer, as did positioning why you would want to use C++ in soem case and not in others.

In both cases, knowing why something has been delivered the way it has helps me to put it into context. No longer am I looking at face value and making decisions on that alone, but by tracking the past decisions I get an understanding of what underlies how what I’m looking at came to be, and that way I can make more sense of it.

The problem then comes in making compromises, as a strategist I want to reduce complexity and go for purity wherever possible. Yet in understanding as much of “Why?” as I can, I then understand where and why I need to make compromises on that. Fundumentally I move the messy problem from the technical domain over towards the business domain which can only be a good thing

Roadmaps challenged

In my previous post I asked some questions about the validity of producing detailed strategic road maps for organisations at the end of the supply chain. I ended by saying that when I found the answers I would share them.

After publishing the post I picked up The Design of Design by Frederick P Brooks and started reading it from where I had previously left off (like a lot of people I have several books on the go at the same time). Brooks is famous amongst computer science students for writing a book of essays on software engineering, The Mythical Man Month which, in my day at least, formed the core of any course on the subject. His later book covers the essence of Design, not just in software but in the wider world and some of his essays can be taken to be a touch contentious and thought provoking. Either way both books make for excellent reading & I cannot recommend them enough for anyone dealing in architecture or software production as they contain many useful lessons applicable to either field

The essence of my previous post centred around the fact that as strategists we’re expected to produce road maps giving detailed guidance to the next steps to be taken to deliver our strategic intent. I don’t disagree with the intention at all, but when the future hangs on a number of different factors over which you have no control then providing instructions on whether to code the next project in C# or Java, and which method classes to use can be a bit difficult. My questions centred around being able to deliver strategic direction almost on demand to reflect the current view of the future, and then having effective & continual communication so everyone knew what to do and why.

Enter Mr Brooks. In an essay entitled The Divorce of Design he writes about how designers need to understand their products from a user viewpoint, and how cross training users in design techniques; and conversely training designers in the user domain provides a shared language that enables richer and faster communication with reduced ambiguity.  I’d suggest that the same lesson can be applied between strategists and the designers, and developers, downstream in the overall delivery process. By sharing knowledge of each others domains, then it is possible to enable the quicker communication medium that supports the flow of information in both directions.

Later on in his book, Mr Brooks writes about the process of documenting design rationale. He refers to two companies in the same industry, one with a culture of formally documenting how designs evolve and the second where this doesn’t happen; and then looks at the long term effect it has had on the designs of their products. Again,  I’d suggest that this too should apply to strategy planning & road mapping. A couple of years back, I produced a strategic roadmap detailing how we could develop a comprehensive online managed services capability, but subsequently my company changed how it delivers a fair portion of this capability. The detail of my original roadmap in terms of release levels of products is now irrelevant; and yet the strategic intent of what we are trying to do is the still the same and the rationale for selecting each step along the roadmap remains as valid now as it was then.

I only wish I had recorded the rationale for those steps so that the people using the documents had a clearer understanding of what we were aiming to achieve. So I haven’t answered all of the questions, but I’ve made start

Can you really “roadmap” at the consumption end of the supply chain?

It’s human nature that we want to know as much about what the future holds as we can, it helps us in making decisions as well as giving us a context to work in. However there are times when the statement “We need a roadmap” isn’t really going to give us something that actually proves helpful.

Some may argue that whatever we do, it is within our gift to define what the future will be, but really it’s the level of detail that we can assign to that future state & the steps we can take to get there that varies. If you are in the business of supplying something that you actually control the making of, say a car or maybe a software application, then you can supply a plan for your future with a high level of detail.

Of course, plans can change and frequently do but the core of the plan shouldn’t change very much (maybe the in car radio isn’t what was planned, or a planned feature cannot be in the software release) and what I said and communicated was going to happen should happen on cue.

Take one step down the supply chain, and then your level of detail diminishes as you are now in the hands of your upstream supplier. The further down the supply chain you move, then the less detail you can supply and the more changes that can be applied upstream that in turn have an impact where you are trying to plan from.

In our brave new world of increasingly outsourced supply then the chances are that we are more of a consumer than previously, so this world of detailed planning is looking less detailed than ever before

That’s not to say we can’t plan, indeed the further down the supply chain you go I’d argue the more you need plan around scenarios & then work backwards. This means that your As-Is position isn’t really worth documenting until it needs to be, then you can plan around how you move from where you find yourself to where you want to go strategically, keeping in mind the implications of whatever happens to the parts of your plan that can be affected by external events.

Some may say that this sort of planning is an attempt to dodge the real efforts of defining a strategic roadmap, but I’d argue that working on detail that gets thrown away is a waste of a good resource. An army commander doesn’t plan every detail of a specific battle before he goes into theatre; instead the planning starts pretty high level & the detail is added as the events get closer. You certainly wouldn’t expect a commander to turn up at a specific time with set weaponry if the previous events had unfolded differently & he was now facing certain defeat?

As we go forward into the ever connected, faster moving world where the supply chain is getting increasingly fragmented we need to start thinking more in scenario terms and about how we make the decisions that were formerly made in our detailed roadmaps nearer to the required decision point. This in turn needs a new form of communication, as everyone needs to understand how the “scenario roadmap” model works, and they need that information as quickly as possible.

To be honest I’m not sure what the answer is yet. Next month I finally return to being a student again (for the 3rd time) and hopefully will get to look at some of these issues as part of the course. If I get answers, then I’ll let you know!

A Time to Think, A Time to Reason

A lot of my work tends to be based around “What if….?”, which can make for interesting times, but presenting on your “what ifs” is harder as they usually need the context surrounding them explaining as well, and its here that I find I get met with resistance.

The modern business context tends not to give time to thinking, so everything has to be real-time & on the button. People’s natural thinking patterns tend to be very much As-Is, so any “What if?” thinking is put down immediately as academic or blue sky and not given the attention it may deserve. Of course there is a time and place for everything, presenting a business case to an investment commitee is definitely not the place to start presenting possible scenarios, but how many organisations even try to think about the possibilities ahead?

I’m reading The Limits of Strategy by Ernest von Simpson, a review of the major strands of history in the computer industry with reference to the organisational strategy and then what really happened. I have to confess that I originally bought it because it covered pretty much my lifetime in the industry and so it was more for my general reading, but what has surprised me is the consistency with which senior executives work on the basis of “What is now should not change so keep going on current course and speed…”.

It is so easy with hindsight to say that they should have seen what was coming, in reality you don’t have the hindsight until too late. What you can do is take some time to think of alternative futures and end games you’d like to see achieve. Sitting in the bar with the benefit of a refreshing snifter, this could potentially be a pleasant evening’s conversation: “What if Nottingham Forest got into the premier division?”, “What if BA & Iberia were stopped from their joint venture?” etc etc. Easy to do, but how do you structure it and present tangible findings that have value in the working day rather than a boozy conversation.

There is a pretty good white paper posted on the Strategy Kinetics site called New Tools for Resolving Wicked Problems which gives a good briefing in the later parts on Resolution Mapping whereby you formally describe end states (a form of predicted hindsight) & then define events & decisions that would lead you from your current position to that end state. Strategy Kinetics see it as a structured workshop process, but I’ve also used it as a way of providing an executive overview to business scenarios to try and get over the possibilities ahead.

Of course, we’ve still got to get over the dogma that spending time thinking about possibilities is wasted…back to Simpson’s book on that one.