Save up to 10% of your total IT costs - for sure!

I know, I know. Been there, done that… You had a project to trim IT costs last year, didn’t you? And your company took off 8.9% or 12.6% or something. There was a lot of clapping afterwards. Targets hit! Success! But how are things now? Better or worse? I’d hazard a guess, but then it depends how you want to measure success.

Whether you did or did not have an IT cost-saving initiative in the recent past, there are very few companies world-wide where it would be impossible to save up to 10% on like-for-like IT costs. Very few.

How so? Because total IT costs are probably greater than you realise. Because we never consider 'the whole'. And because we tackle IT cost-saving initiatives in a 'traditional' way. Actually in the wrong way. In the standard approach we tend to apply Neanderthal methods - and this after we have set our shaky foundations by asking the wrong questions in the first place. Like "What is the IT budget?". That’s not the totality of where you should start.

So where do people typically go wrong? What are the common mistakes? How about these:

• Let’s start with the "What is the IT budget?" question. The IT budget is NOT the total cost of your IT. It’s just a convenient sub-set with a suitable label. It ignores the 'non-IT' IT costs: the cost of guerrilla IT, the financial benefits IT can bring, the impact elsewhere of poor processes, the opportunity costs missed through doing IT badly… So, Fundamental Mistake Number 1 => the IT budget is $x, therefore 'Success' = 90% of $x.
• People - and Fundamental Mistake Number 2. You have 100 people in IT; if we’re saving 10% of cost, then we need to lose 10% of the staff. QED = Redundancy programme. As a default position, complete rubbish. It ignores what people do - and what people could do, and the value they could bring. It ignores the impacts of morale, productivity, organisation etc.
• Closely allied to FM⌗1 comes Fundamental Mistake Number 3: we’ll go to all our Suppliers and tell them we want 10% off their bills - or else! Simple. And being tough makes us feel good too! Against playground bully threats, why should they be inclined to help us?
• A fourth common thread to a cost-saving initiative is to cancel stuff, typically Investments, Programmes and Projects. Never mind if these will eventually deliver financial benefits to the business overall, they are labelled as 'IT costs' not business costs, and therefore are fair game. Fundamental Mistake Number 4: throwing the baby (and potential benefits) out with the proverbial bathwater.

Underlying all of these are a couple of additional core failings. 

The first relates to measurement. A bit like the "What is the IT budget?" question, unless we get the measurement parameters correct up front, then we cannot possibly hope to get an accurate answer out of the back-end. We get an answer, yes - and one that we can probably manipulate to paint whatever picture we choose - but almost certainly not the whole truth.

And the second relates to duration. More often than not cost-savings initiatives are undertaken in too short a timeframe. This is because it is believed an impact is needed now; evidence is needed now; success is needed now; someone needs to look good now. Even if it really isn’t success at all…

Thus, Fundamental Mistakes Numbers 5 and 6.

At the end of the day it doesn’t take a genius to come up with an IT cost savings plan. Just write the first four fundamental mistakes as bullets on a single PowerPoint slide, give it to the IT Director or a Programme Manager, and tell them they’ve got six months to deliver. In fact it definitely doesn’t take a genius to do that.

And the impact of all this slash and burn? Probably two years later when IT is in an even worse mess, when service is dreadful, when nothing is being delivered, when business people outside of 'formal IT' are going off and doing their own thing even more than before - and when, to put it right, costs twice as much as was 'saved' in the first place.

There is a different approach. And it’s an approach that involves asking more questions up-front than just "What is the IT budget?". It demands a different way of thinking about IT costs and IT benefits. It needs all Execs and functions in a business to engage collaboratively and to avoid the traditional 'IT is the Bad Guy' approach. And it requires acceptance that you can cut like-for-like total IT costs in ways that might actually increase the 'formal' IT budget or the IT headcount; that you can potentially save money overall by paying a few suppliers more, or by increasing investment and not cutting projects…

How to move from Chaos to Simplicity...

All too often we can be so beset by things that, to use a well-worn phrase, “We can’t see the wood for the trees”. Often the scale of our problem is not simply in an inability to distinguish timber, but also in that a great deal of it appears to be on fire! In any walk of life - professional or domestic - such situations can be overwhelming.

If we were to seek them, helpful words of advice would be abundant, and some more helpful than others: “Pull your socks up!” - a little demeaning; “Get a grip!” - a little too dismissive; “Focus!” - what else?!

But recognition of the true situation is the first key step - but then so is the final one, that state to which you are trying to aspire. On this journey from where we are to where we want to be - from ‘Chaos’ to ‘Simplicity’ - there are two other logical steps; Order and Completion. The secret of the journey from the dark to the light encompasses these four steps, and there are worst ways to navigate from an unwelcome and unhealthy situation than to use these as your guideposts.

Chaos: The situation where something is essentially out of control, non-optimal, impossible to predict, manage and steer. This is where you are and where you no longer wish to be. And to move ahead, something has to change. Remember the definition of lunacy? Doing the same things over and over again, yet expecting a different outcome…

Order: The situation where there are some controls in place; where we can measure and prioritise. We may not necessarily be doing the ‘right’ things at this stage, but at least we have established control of what we are doing.

Completion: The situation where things get sorted and finished, and where we begin to thin out the trees in our metaphorical wood. Of course completion can lead to the spawning of new things, initiatives, projects and so forth - but this will happen on our terms because we have established control.

Simplification: The situation where we have attained our ‘to be’ goal. We are no longer standing in a burning forest, but rather overseeing a well-managed, neatly laid out plantation; and where we can look forward to planting those new saplings with confidence.

Perhaps this is not particularly radical, but then common sense most often is not. Recognising the situation and the potential journey to be undertaken is at the heart of the battle. 

How do you get from Chaos to Simplicity? What it involves is focus - and probably ‘getting a grip’, the ‘pulling up of socks’, taking ‘baby steps’ and so on. It also demands clarity of thought, the bravery to prioritise and to tackle a small number of burning trees at a time rather than the whole forest.

There are tools to help on the journey, inevitably, but perhaps one of the key ones is the ability to plan - and to plan appropriately. There is a symbiosis between the Chaos to Simplicity journey, and the planning approach I have suggested in a previous post [Plan ahead, yes - but how far can you actually see?].

Chaos = What you can see now.

Order = What you expect to see next.

Completion = What you think you will see after that.

Simplification = What you hope to see in the end.

Try it. Think of one thing that for you represents chaos right now. Write it down - just one line or phrase to describe it. What it would need to look like to be under control? Again, note just one line or phrase. Then how might completion be manifest? And finally, how would you hope the simplified end-game appeared?

If you can do this, then you have the basic DNA of your plan. You can now plan forward from where you are (and there are probably things you simply must do now! What do you need to do to bring Order etc.?). And don’t be afraid to work backwards a little from the end-game too - otherwise you run the risk of being totally constrained by your present situation i.e. you may put the fires out, but never leave the wood!

Whichever route or method you choose to take to escape the burning forest, devising a pragmatic, planned, measurable approach is fundamental. As is doing something different. Don’t fall into the trap of lunacy - be brave and make a change!

*

About the author / copyright

Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1

Management blog: http://cioscrapbook.blogspot.co.uk

This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

Plan ahead, yes - but how far can you actually see?!

I once drove across Indiana. At one point the land was so flat and the weather so clear, I swear I could see the curvature of the Earth on the horizon. I have also driven in less clement weather in the Alps. The way the roads turned then, you were lucky to see 100m in front of you!

In terms of mapping out the road ahead, business can be a bit like that - though more often closer to the Alps than Indiana in terms of visibility! Yet why is it, when faced with such a variety of commercial terrain, we persist in planning for the mid-term under almost any circumstance?

Using the visible horizon as the extent of what I could reasonably foresee, my US drive would have allowed me to plan for the next several hours with a high degree of confidence; but in the Alps, I didn’t even know what was around the next corner!

Businesses  - and especially ‘projects’ - spend an awful lot of time planning. Some plans at the strategic level are of necessity longer-term, aspirational, more vague; a bit like saying that once we’d made it through the Alps our goal is to eventually get to Milano. But the vast majority are focussed on specific outcomes or deliverables; quite naturally, they attempt to define the who/what/when of those outcomes. However, often these plans are created without any reference to how far we can actually see. They attempt to predict activities and results miles into the future, and we kid ourselves that because the plan ‘looks right’, then it is a fair representation of the future and one accurate enough to navigate and be measured by.

All too often, however, we need to re-plan because we haven’t hit the dates in our original schedule. Sometimes this will be down to forces outside of our control, but often it will be because the plan was never achievable in the first place. We’ve planned as if we were driving across Indiana and not about to tackle another twisting mountain road in Europe. Claims that a project has ‘failed’ often misrepresent the truth; the planning may have failed, not the project. I’m sorry, but a constant 65 mph just isn’t possible heading south on the SS33 towards Italy…

Where we have a choice, what should we do? Obviously you need to apply valid context and goals to this. Some objectives will lend themselves to supremely low-levels of planning detail - but most will not. The key is to try and make as much of your plan about the achievement of real and tangible things; things you can see or touch. Time frames will vary too; many of us will have seen the 30-, 60-, 100-days type plan from a new Exec. Whichever approach you take has to be appropriate and work for you, but the scenarios will in most cases by broadly the same: 

Define what you can see ahead of you now - and focus on the key deliverables at the edge of your horizon, mapping out all the tangible and relevant steps in between. If these become increasingly subject to assumptions, risks, constraints and such like, then are they truly on your immediate horizon?

Define what you expect to see next - and concentrate on what the next large deliverables should subsequently be (clue: these will be just over the edge of your current horizon; those things about which you cannot be certain, where risks, assumptions etc. are playing a major role). Spend less time mapping out the individual steps here. As this time frame shifts from what you can expect to see to what you can actually see, then you can build the detail i.e. when the horizon shifts sufficiently to clearly include them.

Define what you think you will see after that - and outline only the major things you expect to deliver at that point (perhaps the 100-day goals in the 30-60-100 example). There is little point putting too much detail in at this stage; as the horizon shifts, the deliverables will gain greater focus as they come towards you.

Define what you hope to see in the end - and in many cases this may end up being the ‘single big thing’ that you need to achieve: cost saving, greater efficiency, a new product, double-digit growth etc. Here there is almost no truly detailed planning needed.

By taking this horizon-based, tree-like planning approach, you can align your plan in accordance with what you can ‘see’, ensuring that you make the most of your precious planning time and deliver a plan that is suitably realistic. And as time shifts, so does your horizon; this makes the plan a constantly moving, living thing - and not just in terms of tracking progress against a fixed set of tasks. It can never be a one-off. Risks change; assumptions are proven true or false; constraints fall away or new ones arise. You plan should reflect all of that.

At the end of the day, planning is like budgeting (which is essentially a plan for cash); it’s just a snapshot in time, and something, when produced, that is almost immediately wrong. 

*

About the author / copyright

Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1

Management blog: http://cioscrapbook.blogspot.co.uk

This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

“Think-Build-Run” - and Insource or Outsource?

For some people the concept of splitting an IT function into logical components of “Think” (or “Plan”), “Build” and “Run” will be nothing more than a fashion statement. There will also be those who are, for personal or philosophical reasons, totally opposed to the concept. For many, especially where the IT function is small, achieving such a delineation may be impossible given an absence of critical mass in one or all areas. 

Yet for others, “Think - Build - Run” will be a logical move, allowing a sharper degree of focus for them, their people, and their business; giving them the chance to drive up quality and drive down cost. It will be, more or less, the IT equivalent of an efficient production line paralleled with some kind of interpretation of ‘Lean’. For these people, likely to be in larger organisations with larger IT functions, it might simply be ‘the right thing to do’.

For those that adopt T-B-R, there is often a follow-on question when looking at the organisational shift to the new model: Insource or Outsource? Whilst this question is, for CEOs and CIOs always there in the background anyway, T-B-R can throw it further into the spotlight, especially if there is a working assumption that the “Run” part is more or less akin to commoditised computing services. And make no mistake, much of it is. But there is a danger in falling for a too simplistic view of the world. Many people might draw an equation between T-B-R and Insource/Outsource in the following way:

But not only is this a lazy interpretation, it is also flawed. The true line of transformation we should be looking at is something like this:

And why is that?

1 - Because you should never outsource very much of your “Think” activity. This is the area where you are closer to the business, where the relationships between IT and its Customers are most critical, and where in-house expertise can add the most value. If you can truly add differentiating competitive advantage to your organisation as an IT function, then in “Think” is where you will do so.

2 - Because, whether we like it or not, a large proportion of the ‘systems’ IT functions “Build” is likely to be unique to that organisation. Either they are bespoke, one-off solutions, or they are customised versions of commercial software offerings - and sometimes very customised! (And don’t forget all the Excel Warriors..!) It is only when you start to get to homogenous, non-differentiating, more ‘vanilla’ kinds of solution that a greater degree of outsourcing begins to make more sense (and Software as a Service [SaaS] can play a role here).

3 - Because you should never outsource all of “Run”. Even if it is only the management layer that you retain, responsibility for the service still resides in-house, and CIOs need people on their teams who hold that passion and accountability. Again the question of the service being truly commoditised comes to the fore, as do things like scale, practicality etc. There are some elements of “Run” that you simply will not be able to do as well as a third party provider (or at all, come to that: think of networks…), but there may be others where there is enough local differentiation to suggest that keeping it in-house just makes sense.

Of course, other factors come into the equation such as cost differentials and arbitrage, the overall size and philosophy of the company as a whole, appetite, previous experience, in-house expertise and talent, and so on. And the feast is a moving one too, with ‘Cloud’ becoming ever more mature, and the whole notion of Bimodal ’Mode 1’ / ‘Mode 2’ projects adding another new dimension to the mix.

Inevitably the equation is a very complex one, and to which the solution is rarely simple.

Being Agile...

Fashion is everywhere. Fashion introduces new things to us - and recycles the old! Fashion creates product and demand; it generates sales and profit; it breeds need. Even in Information Technology, we love fashion. It gives us the opportunity to create new notions and processes; it is a natural bedfellow with the rapid changes in technology that we are now seeing, inventing new ways to use those technologies and creating new ‘products’ from them.

Yet what we actually do in IT is the same as ever: we teach machines (computers, now of various favours including mobile phones) to take the data we give them and then manipulate and store that data for future processing (more manipulation) or reporting. Occasionally the data is used to control other things, like traffic lights or machinery - or even spaceships and cars! 

Ensuring that we do a good job in building the systems that make those manipulations effective, IT professionals have always invented rules and processes around the development cycle in order to try and make the end product as good as it can be. As technology moves on and the pace with which development can be carried out quickens, the volume of changes and the speed with which results are needed both increase, and hence new models of development are needed.

And so we have seen a progression of methodologies like ‘waterfall’ through ‘rapid application development (RAD)’ and on to ‘Agile’, the current IT panacea for this decade it seems.

Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. (Wikipedia)

Like many ‘next great things’, Agile will only be as good as the people and organisations that adopt it However, we might be missing a trick here. Should ‘Agile’ not be a state of mind, a philosophy, rather than a methodology or series of formal IT processes? For one thing, if a development team is working in ‘an agile way’ but the rest of IT is not, or the culture of the business as a whole is slow and ponderous, will ‘Agile’ not inevitably fail to deliver as much as it might promise to?

Take the Wikipedia definition above. The “collaboration between self-organizing, cross-functional teams” requires everyone involved to be able to work in the same way. “Rapid and flexible response to change” needs to be in the DNA or culture of the whole organisation; what’s the point in producing IT systems quickly if their prospective users do not readily embrace change?

If we think of being ‘Agile’ as being “the answer” and that it relates just to IT software development, then we are deluding ourselves. ‘Agile’ needs to be part of the corporate culture.

Agile is a cultural philosophy as a result of which decisions, actions and business solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary and incremental progress, early delivery, continuous improvement and the elimination of waste (in all its forms), effective and prompt decision-making, and encourages a rapid and flexible response to change.

OK, I know this version isn’t perfect - but doesn’t it sound much more like the kind of business we would all like to work in?! Isn’t it more inclusive and relevant to all our staff, rather than that minor percentage employed in the rarified world of IT application development? Yes, it might increase risk a little; and yes, it will demand better delegation, more accountability and so forth. But in the end, those are probably good things - and any negatives should be outweighed by overall commercial benefits.

And I expect each of us can think of real, every-day examples of where being ‘Agile’ can bring true improvement - in bottom-line, morale, responsiveness etc.

Why not change the format and content of that monthly departmental meeting so that we can focus on just the critical points and get through it in an hour instead of the four hours it currently takes?

Why not reduce the number of people needed to take a decision to those who are really affected by it so that the decision is made more quickly? And why not make decisions when a) you have 80% of the data needed rather than search for the 100%, or b) when everyone knows what the ‘right’ answer is anyway?!

Why not redesign our organisations to facilitate teams whose sole purpose is rapid response or firefighting?

Why not cull the hundreds of documents and reports we produce and focus on the very few we actually need?

Why not, why not…

Agile as a software development methodology is all well and good, but until we broaden our thinking to embrace more than just IT, we will never get the full potential benefit of taking such a pragmatic approach.

*

About the author / copyright

Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1

Management blog: http://cioscrapbook.blogspot.co.uk

This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

What can we in IT learn about Business Systems from ‘Minecraft’?!

From an IT applications’ perspective, you could argue that there is no way ‘Minecraft’ should be a success. After all, in these times of high-powered and sophisticated devices with their stunning graphics capabilities, a game colloquially recognised as “blocky” and without a single non-straight line in the game perhaps should not have taken off at all. Indeed, it is an interface, one might suggest, that is at least fifteen if not twenty years out of date!

But it has been a success - and a raging one at that. Millions of people play it - many addictively. A whole industry and sub-culture has arisen because of it, and we now find some of its exponents - particularly in the world of the on-line video - gaining ‘Star’ status, appearing on TV chat shows, and with more followers than Presidents, Prime Ministers, and Philanthropic and Commercial giants.

So why is that? If we strip ‘Minecraft’ back to some basic level - that of an ‘application’ with ‘functions’ and ‘users’ - then what might we uncover that can be usefully and profitably reflected back into the world of commercial business systems? Where does it ‘work’, and - more importantly - are these factors applicable to our company’s finance or logistics or ERP systems?

Take perhaps the three of the most salient points:

• It is inherently simple. The components on which Minecraft is predicated - the cube, the straight line, the interface - are consistent and universally adhered to. Whether you are working with bricks, carpet, snow or foliage, the way you work with them is the same; and, with a few exceptions in the area of ‘redstone’, what you can do with them is even more limited. You either put them in place or remove them. Left click or right click.
• Because of its simplicity, it is easy to learn. Once you have mastered just a few basic concepts, then you are ready to roll.
• On one level, this simplicity and ease of use could point to a lack of sophistication - but how you play the game and what you can do within it is massively sophisticated, and that is the more important thing. This ability to create your own world from a blank canvass, where no two buildings need be identical and where no two games will ever be the same, give ‘Minecraft’ the addictiveness that comes from seeing your personalised world rise in front of you. “Just one more brick…”, “just one more minecart track…”, “just one more tree…”.

Do the business systems’ we tend to implement in our professional lives mimic these traits? Hardly. We tend to make systems that are massively complex - and as a result, difficult to learn. In areas such as financial transaction processing or warehouse management, the things businesses do - buy stuff, sell stuff, pay bills, raise invoices, put stock away, pick it out again etc. - are, at one level, simple and homogeneous. And yet company after company believes it is “different”; that systems need tweaking to fit their processes. The end result is that we tailor and customise and seek out those final few percentage points of “perfect” alignment - and in doing so, we create a monster.

And it becomes a monster even before the system is ready to use. It takes too long to build; it costs far to much money; and, in taking this approach, we are creating something that, when the software vendor releases the next major upgrade, may once again take an age to re-customise, and again cost a fortune in doing so.

Some people might argue that they are building-in sophistication; that in taking this approach, they are driving value, efficiencies and so on. If that were truly the case, then why is just about every core business processes and major business applications dependant, at some point or other, on data being manipulated in Excel? If we had done such a great job with our highly customised and ‘sophisticated’ applications, we wouldn’t need Excel. Right?

Think about it. Excel is much like ‘Minecraft’. A blank page; a relatively limited number of rules; easy to use - and the chance for us to be creative and build something that a) fits ‘us’ as individuals, and b) meets the needs of ‘the process’ as we see it. Never under-estimate an individual’s desire to make their mark. As in ‘Minecraft’ worlds, no two Excel spreadsheets will ever be the same! [There is a potential pointer here to the future of business applications - but let’s save that for another article!]

So, keep it simple; change / build as little as possible; focus on what’s really important (and what commercially adds value); and engineer something that people actually want to use.

*

About the author / copyright

Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1

Management blog: http://cioscrapbook.blogspot.co.uk

This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

Man Management Lessons from the Badminton Court

I have started playing badminton with my two youngest children. At this stage they are, let’s say, ‘enthusiastic’ rather than proficient - and certainly not as good as they are going to become one day. If we can all stay keen and keep practicing, then there’s no reason why they shouldn’t become decent players.

It’s interesting seeing what motivates them when we play. My Daughter’s goal is to try and build the longest rally possible. She gets excited when she beats her last record, and immediately sets her next goal. My Son doesn’t care about long, tippy-tappy rallies; he wants to become ready for battle, and has started to practice mixing smashes with drop shots, even though he’s not that great at either just yet. His motivation is to make his Dad run around; to take him by surprise; to win a point.

They are competitive, of course, but in different ways. Yet it occurs to me that there is much that is similar in what they strive for - and much in this simple example that is directly transferable to the working world and how we interact with the teams and colleagues in our professional lives. These common threads are: achieving goals and self-esteem; feedback and communication; encouragement and praise.

Achieving goals and self-esteem

Both my Son and Daughter know where they want to get to, even if one’s goal is slightly more concrete than the other. They know what good looks like, and - more importantly - they know what it feels like too. It’s probably not the achieving of the goal that is paramount here, but rather how it makes them feel. When my Daughter beats her longest rally by just one shot she is over the moon; she smiles; she bounces. She wants to do it again; to beat it by two shots more, or three. If I can’t reach one of my Son’s drop shots, it’s the same story. That self-esteem is critical. Who doesn’t want to feel great?!

Feedback and communication

They know, of course, that they’re not that good at the game yet. My Daughter knows, instinctively, that she should be achieving much longer rallies; my Son knows that he should be getting more of his drop shots over the net - and that those that make it, should be so close as to make it impossible for me to return them. Because they’re not perfect yet, they need feedback. They need me to make suggestions about how to hold the racket, when to flick and when to power, when to hit overhead and when not. They need me to fire shots at them in different places, at different speeds and angles, in order to give them the experience and challenge to which they can respond and through which they learn - although they might not acknowledge this part just yet! If I did nothing, if there was no communication, no variation, then their improvement - solely by trial and error - would simply take much longer.

Encouragement and praise

And even though they’re not great yet, in order to feed that good feeling and self-esteem, they need to be encouraged. At this stage, they need praise for even the small things - for trying something, even if it is not executed perfectly. It keeps them enthusiastic, bouncing, looking ahead.

Why should the working world be any different? Why shouldn’t these simple considerations apply to the people in our teams, and our peers and bosses?

And of course they do.

Our professional challenge is in part born from the fact that we don’t know our people as well as we know our children, so recognising some of the key drivers is harder; in part, we are compromised by homogenous approaches to HR - through job definitions, appraisal regimes, lack of time, poor communication - which force a uniform engagement model upon us; and in part our problem comes from the fact that we may not be very good at all this people stuff anyway.

So surely, our goal as managers has to be to understand our people better:

• to work out what their individual professional goals are, what floats their boat, what makes them feel good - and then align that to what we / our business needs from them
• to work out how best to communicate with them, and what we can do to provide them with the feedback, challenge, and stretch that better equips them to be successful
• to work out when to give encouragement and praise - and what to give it for

And just maybe we should do this for ourselves too. Who knows, one day we might just be able to produce some decent badminton players!

-*-

About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and a broad International exposure. 

He is also the author of management books on the topics of IT strategy and project management, the impact on IT of e-business, and the IT organisation.

This material is copyright of Ian Gouge © 2015. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional. 

Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1

Management blog: http://cioscrapbook.blogspot.co.uk

Any redistribution or reproduction of part or all of the contents in any form is prohibited. 

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.

How Do You Take Your Coffee?

Analogies are fantastic. They allow you to portray difficult concepts against a set of real world comparators thus enabling someone to better understand and interrogate ideas. In theories of management, analogies occupy a key station in this lexicon. Let’s take coffee…

In most organisations, ‘Management’ and coffee go hand-in-hand; most meetings start with coffee, are punctuated by coffee, and end with coffee. Often, the most important conversations are those held at the coffee machine. But thinking about coffee in the round provides us with a means of interrogating management styles.

There are a number of different styles of coffee, and - although fanciful - we can parallel them with approaches to management.

Ristretto - a very short, dark, and intense hit, possibly with a bitter after-taste. In management terms, perhaps we can see ristretto as a rapid, no-holds barred, hard-driving, decision-making style, often adopted in extreme circumstances. From a management perspective, advantages of the ristretto approach is that it is ultra-dynamic and things get done in the shortest time possible - but running the risk of doing so in the least elegant or ideal way. Disadvantages? A lack of compromise, perhaps; no prisoners are taken; and perhaps, like the ristretto itself, you can only take so many before you are ‘eyeballs out’, completely hyper, out of control, and unable to relax.

Espresso - also short, dark and intense, but not to the extreme of a ristretto. Espresso management would promote dynamic decision-making also, moving with pace, but in a slightly more refined manner than the extreme and condensed ristretto. The approach still gets things done quickly, with execution the priority above all else; but perhaps there is a little more flexibility and longevity in the approach, although again, after too many espressos, sleep can prove elusive.

Americano - essentially a ‘watered down’ espresso, and with the option of a little milk. On the scale of hard driving, the americano manager will allow the troops a little extra time compared to its condensed parent, and the addition of milk suggests a management style that offers the option of flexibility; more the carrot-and-stick approach than being constantly driven by hard imperative. If quantity is the killer with the ristretto and espresso (in terms of how many hits you can take before it harms you), with the americano it is likely to be volume that is a problem - from a resolution viewpoint, there is only so much you can actually take-on within a given timeframe.

Macchiato - an espresso in a dress. The short, intense hit is still there; results can be dynamic and reasonably rapid; but there is a considerable amount of froth disguising the style. So the macchiato management style can take some time in building up that froth before the ‘wham!’ of delivery. Perhaps slightly less genuine than an americano, the macchiato manager might be in danger of being seen to be just a little duplicitous or inconsistent by the troops.

Latte - here the espresso is bathed in warm and creamy milk. Essentially things still get done, but inevitably they will take a little longer to get over the line. The experience will be softer, less intense; no bitter after-taste; no shock from the coffee hit. In management terms, this would be the most collaborative and engaging style of them all perhaps. But it’s still coffee; there’s still an espresso there at the heart of it, and the manager must ensure that he or she doesn’t lose sight of it if they are to ensure that things still get done.

Cappuccino - the most complex and indulgent of all; espresso, milk, froth, and a sprinkling of chocolate! One of those management styles you probably either love or hate; a mix of hard, soft, bitter and sweet. When it comes off, a cappuccino can be wonderful - but a bad cappuccino is just unpleasant. You need to be an innovative, self-confident and somewhat machiavellian manager to be able to pull off this style effectively. Things will still get delivered, but you might polarise or alienate people along the way.

And finally, cafe au lait - all milk, no substance. A management style like the coffee: at its worst, weak, wishy-washy, bland. Some people would say that this wasn’t coffee at all…

All very fanciful, of course. But the analogy does offer a lens through which to view management styles, to depict or grade how these styles compare to each other, and - crucially - to understand how we prefer to work ourselves.

And the parallel gives us more than that. If you think about coffee, we probably each of us have our favourite from the short list above. In the same way, we each of us have our preferred way of managing - and being managed. If your natural style is perhaps espresso, but your line manager is much more a latte kind of manager, then it is quite likely that you will get frustrated with them because they won’t move fast enough for you. And they are likely to find you reactionary, threatening and perhaps not a little unpleasant or difficult to handle.

Whole organisations can have a ‘coffee culture’ too. Why is this important? Well, it is highly likely that someone who loves their cafe au lait approach will struggle in anything stronger and more intense than a latte organisation. A mismatch of styles, a clash of approach, will be bad for company, manager and employee in various measures.

There are many management definition tools - such as Belbin or Myers-Briggs - that can help to illustrate styles and predict how divergent ones will interact with each other. In all cases, recognition is the first step; tactics to handle disparities follow after that. The simple parallel offered here allows us to start on that analysis journey with a really easy question: “How do you take your coffee?”.

-*-

About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT Strategy and Project Management, the impact on IT of e-Business, and the IT Organisation.

This material is copyright of Ian Gouge © 2015. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional. 

Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following: 

·         you may print or download to a local hard disk extracts for your personal and non-commercial use only; 

·         you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material. 

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.

Flat Structures - Really?!

As Managers, what is our job? Once, many years ago, when I was promoted into a senior management role, my then boss informed me that “I didn’t have to ‘do’ anything”. It took me some time to realise what he meant. He didn’t, of course, mean that I sat around, drank coffee and read the papers all day! There were things to ‘do’ – but more in the sense of taking the lead, of helping others to 'do the ‘do’'.

At the end of the day, a Manager’s job is to create an environment which maximises what can be delivered from those components (people, money, capital items etc.) for which he is accountable, however it is appropriate to measure that delivery: profit, service, quality... Which is fair enough, isn’t it?

But often there are other criteria that, whilst we may not realise it at the time, cut completely across that ‘enabler’ ambition and can critically compromise what we can contribute – and therefore, most likely, what others can contribute too. Take the notion of the “flat hierarchy”.

Logically very sound: not too much management; clear line-of-sight between ‘top’ and ‘bottom’; people feeling ‘more connected’ somehow; less bureaucracy, and so on. But in practice?

If you accept the Manager’s role as an enabler, then this means that he or she has to have the time and capacity to help their team: to mentor; to suggest; to coach. Essentially, through the distribution of their experience and expertise, they must enhance what their direct reports can achieve. It fits with the maximisation of the delivery of the 'components' they have at their disposal. If we compromise that, then surely what a manager can contribute is diminished somehow – and if he or she gives less to their team, then those next down the line already start at a disadvantage…

So let's assume we have a flat structure with 111 people and just three layers, top-to-bottom. To achieve this, every one of the eleven managers (the top man and his immediate team) needs ten direct reports to create that organisation.

Perhaps you are one of those managers, and that you are lucky enough to work just a 40 hour week. Depending on your role, you may spend 50% of your week on projects, initiatives, administration. Then there will be the meetings you have to attend outside of your function or team, perhaps with customers, or Finance, or HR. Say another 15%. Then there’s that unplanable ‘stuff’ that crops up (usually from email!) that takes away another 10%.

Where does that leave us? 75% gone, 25% left. That’s just 10 hours in a week to share with your direct reports. If you have ten of them, that's just one hour per person, per week. Is that enough to help them, their teams; to mentor, suggest, and coach? Really? Not only are you stretched as an individual, your people don't start with the full boost you could be giving them.

There is a 'multiplier effect' at work here too. From the top manager to the middle management layer, and then - with those 'middle managers' being at less than 100% effective - down to the real 'doers' in the team.

But what happens if the 111 team has four layers? Then each manager might have just four or five direct reports. Suddenly those free 10 hours per week now gives you around 2 hours for each of your direct reports. If your input is of value (and you would hope it would be!) then all your people should benefit accordingly.

It would take a scientific study to prove the point, but I would be confident that the overall measurable loss of 'effective input' or productivity cascading downwards from management layers would be greater with the former case - two layers only, ten direct reports per manager - than with the second - three layers, more managers, but only four or five direct reports per manager.

You might object that in the 'fatter' organisation, there is a greater level of man management admin and/or non-productive time from a greater percentage of the 111 team (i.e. 21 'managers' vs. 11 'managers'). This ignores the greater effective loss from the flat organisation as suggested above. Also, the truth is that there is no reduction in man management admin delivered by the flat structure: for example, appraisals for all 110 people don’t just go away. They still have to be carried out, and with fewer people to execute them, those eleven managers can only be less effective in this area - and their output of poorer quality.

And it is worse than that of course. In the flat structure, bottom to top needs only 2 promotions – which effectively means that the top 11 positions are ‘blockers’, and the remaining 100 people are looking upwards, seeing no possibility of progression and advancement – unless of course you make the ratio of middle managers to the top guy maybe 1 to 12…

And don't forget, the extra time for managers offered in the deeper structure will more likely be ‘quality’ time. And the “dead man’s shoes” scenario in the second organisation isn’t quite so prevalent.

Are you working in an organisation that's 'too flat'? Of course, you can go too far the other way. A 111 team with six levels of management would clearly be inefficient. There is a reason that 'best practice' suggests the optimal number of direct reports for any manager is between four and seven.

In any event, don’t assume that a flat structure is a good structure; it may not always be the case…

-*-

About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT Strategy and Project Management, the impact on IT of e-Business, and the IT Organisation.

This material is copyright of Ian Gouge © 2014. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional.

Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following:

·         you may print or download to a local hard disk extracts for your personal and non-commercial use only;

·         you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material.

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.

The Seven Cs of Exemplary Management

Many of the components designed to provide an effective and results-oriented management framework are actually based on relatively simple concepts. The problems that we encounter most often are not related to the understanding of or endorsement of these concepts, but to their execution. This execution is often compromised by an unhealthy mix of inappropriate or inadequate use of tools, pressure or volume of work, and sheer human fallibility.

 

Inappropriate or inadequate tools?

• The addiction to e-mail
• The pathological dependence on spreadsheets
• The abdication of results based on such inadequate, inappropriate or poorly used software…
• ...or blaming failure on missing software!

 

…And the absence of good quality, simple processes that work for us as managers – because we each work in subtly different ways, and one of the tricks is to unlock those things that allow us as individuals to contribute the most.

 

Pressure of work?

• —Because we all have too much, don’t we?
• —Because often we can’t see the wood for the trees?
• —Because, no matter what we say, we actually aren’t very good at time management / prioritisation / communication / delegation (delete as appropriate!)

 

…And our failure to give ourselves an effective and simple management framework only makes matters worse, deepens the spiral, forces us to cut corners, make mistakes, take inappropriate risks, make shaky assumptions or decisions.

 

Human fallibility?

• The desire for the path of least resistance perhaps…
• Or that we just pay lip service to core principles…
• Or the assumption that ‘people know what we mean / think / want’…
• Or the belief that it will all come right in the end…
• Or the conscious decision to ignore that really bad feeling we have somewhere in the pit of our stomach…
• Or the aversion to conflict and challenge…
• Or the difficult decision…
• Or the inappropriate trust / mistrust in others…
• Or the profound challenge of honesty…

 

So how can we capture the core components of a good management framework? How can we elucidate them simply, and in such a way that we can fashion a mode of working that fits us, suits our style, and gives us the best chance of success?

 

What are the ‘Seven Cs of Exemplary Management’?

1. Commitment
2. Clear Expectations
3. Clear Actions
4. Control
5. Commerciality
6. Communication
7. Change

Commitment

 

…in the sense of belief; of believing in what you are doing.

 

The premise is simple: if you believe in what you are trying to do, achieve, deliver, then the commitment will follow. But the converse is true, of course: if don’t believe in it…

 

…maybe you should ask yourself if you should be doing something different, taking a different approach, aiming at a different goal.

 

Or maybe someone else should be doing it for you!?

 

If it’s right but not working and you can change it, then change it.

 

You will be more committed – and successful – if you strive to do three things you believe in, as opposed to eight things you do not.

  

Clear Expectations

 

…in the sense of knowing what the overall objectives are.

 

Do you believe that your people understand what you need from them, and what their scope of responsibility is?

 

…because if they don’t, they can never deliver what you need.

 

Ask yourself, if you were in their shoes, would you be clear?

 

And a suggestion: brief your team members on what you need them to do for you – then two days later, have them come back and present their interpretation of those expectations to you! This has the advantage of establishing firm mutual understanding, and in their presentations you have a better record of expectations than in any out-dated job description.

  

Clear Actions

 

…in the sense that actions – when they are written down at all! – are rarely that clear. And why? Because we are lazy, we make assumptions that everyone knows what XYZ means – and because most of us hate producing (or reading!) minutes.

 

So an action needs to have: one owner, a deliverable, potentially a description of the format or content, and a date. If it does not, how can you possibly have any confidence it will be delivered – and in some cases, how will you know when it has been? How can the action owner know what he or she has to do?

 

Oh yes, and if you aren’t going to bother to check and chase actions and make them mean something, then don’t even bother in the first place…

  

Control

 

…in the very narrow sense of knowing what your people are working on, what the pipeline of demand is, what the unused – or over-committed – capacity is…

 

It’s all about Demand and Resource planning.

 

Your job, as a manager, is to get things done with the resources you are given. If you have no control over that one critical, elemental, finite component, then what chance have you got to be successful?!

 

You will under-commit and waste money; over-commit and miss deadlines; make poor judgement calls, erroneous decisions – and perhaps worse than any of these things, your team will see that you are not in control, and you will lose their respect and commitment.

  

Commerciality

 

…because one way or another, everything has a cost – and hopefully a benefit.

 

Which means that everything you and your team does must have an impact, somewhere…

 

Cost is easy when it’s money out of the door, but it could be time, an impact on risk, diversion from strategy, the opportunity cost of doing (or not) something else – and then the more intangible things like impact on staff morale…

 

…and for each cost, there must be benefits that could be articulated in the same language.

 

For the big things, think cost & benefit. Try and articulate them. Often, when you are in two minds about something, this might just sway you in the right direction

  

Communication

 

…that old chestnut! But let’s face it, communication is almost a ‘no win’ topic, because different people want different things: monthly, weekly, paper, email, Town Hall, detailed, personal, high-level, data-based, informal… So:

• Rule #1 – do it!
• Rule #2 – choose what works for you in terms of format & timing
• Rule #3 – make it relevant
• Rule #4 – ensure the quality is good (poor quality communication is unforgivable in a manager!)
• Rule #5 – don’t let it slip!

Adhere to these rules and, after a while, most people will come to accept what you are trying to do – and then they will start to expect it, and if the quality and relevance is there, maybe even come to look forward to it!

  

Change

 

…in the sense that most of what we do is predicated on making change happen – and for the manager, in initiating and driving change.

 

Even in the most stable of environments things are constantly changing – and so they should be, as this is the only way we can make things ‘better’. The good manager can identify those things that need changing, and can the implement the change in a controlled and positive fashion.

 

‘Change’ is one of the things we need to believe in, and should always be on the agenda.

 

And don’t be seduced by notions of innovation. Innovation is just a marketing word for Change…

  

What are the ‘Seven Cs of Exemplary Management’?

 

Commitment – believe in what you do

 

Clear Expectations – know what the objectives are

 

Clear Actions – who, what, when – and chase!

 

Control – demand and resource management

 

Commerciality – everything has a cost and benefit

 

Communication – do it how it works for you

 

Change – now, tomorrow, always..!

 

 -*-

About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT Strategy and Project Management, the impact on IT of e-Business, and the IT Organisation.

This material is copyright of Ian Gouge © 2014. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional.

Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following:

·         you may print or download to a local hard disk extracts for your personal and non-commercial use only;

·         you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material.

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.