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.

Contractor Day Rates - Is there a Better Way?

So let me get one thing clear right up front. I think Contractors play a valuable role in IT functions delivering solutions to Customers. Like most people in our industry, they are professional, diligent and hard-working.

Having said that, I look at the way we reward contractors and it seems somehow out of kilter with the role they often play. Our approach – agreeing a rate for a ‘professional day’ – is tried and tested. Or rather, it’s simple, easy to administer, and we’ve been paying for these services in this way for ever. But on reflection, does this encourage us to get the best value possible from this expensive resource? And is it offering the Contractor the best possible return for their efforts?

By and large we recruit Contractors for two main reasons: as workload supplementation for our Business-as-usual (BAU) activity, or as specialist resource to deliver a specific ‘ thing’. Much of what I am suggesting here applies more easily to the second of these two contexts i.e. the delivery of something specific. Having said that, I’m sure it could also be looked at in the light of BAU activity.

Let’s assume we hire a plumber into our home to fit a new bathroom suite, and they tell us it will take five days and that’s the effort for which they will charge us. If at the end of those five days the suite is installed but all the taps leak and the toilet doesn’t flush properly, what will we do? We’d expect the plumber to fix these things for the price quoted. If he tells us it will take another three days effort – and therefore cost – to put right, we wouldn’t accept it, would we? Why then do we take a different approach with Contract resource in our professional life?

Well, partly it’s because we are paying them for turning up (the day rate), not for delivering. There is a certain irony here in that we often employ contractors to deliver something specific and then don’t reward them accordingly. More than that, we often compound the problem in two further ways. Firstly we endeavour to incentivise our permanent staff around specific deliverables where this is often inappropriate as they may be more engaged in a more ‘fluid’ and less measurable BAU activity. And secondly, our permanent staff see Contractors doing the same / similar work and raking in more money without any additional pressure or constraint. The second case may be unavoidable where the work is BAU related and hard to break down into specific deliverables, of course. Here the argument for the differential is the same as it has always been: risk, job security etc. – although I would argue that in today’s commercial world this differential is not as great as it once was!

For me, this begs the question about whether or not there is a better way; the possibility to tweak the day rate system to drive more value from what is likely to be the most expensive resource we employ. And if there is, then can we extend these principles beyond the individual contractors to encompass the broader, wider-ranging engagement of Consultancies and Systems Integrators?

The core suggestion is that we explicitly link reward to the deliverable, to getting the job done. Just like we do for the plumber. This would have the immediate benefit of getting a little more skin in the game – the plumber would know for sure that he wasn’t getting paid any more than agreed only when the taps worked properly. Surely this would drive engagement and delivery in a very real way – and in a way that was different from permanent employees, thereby helping to mitigate any sense of injustice they might have against Contractors. For us, it might also help to improve certainty about the cost of getting things done, and aid our ability to hit project budgets.

I would argue that we should consider trying to arrive at some kind of ‘split fee’ approach. Let’s assume that we are paying a Contractor £500 a day. In the new model, we would still pay a day rate – perhaps £400 or £450 – with a ‘bonus’ when the deliverable was produced (the bathroom installed!) which would end up equating to the £500 day rate. That way, if the Contractor delivers as planned, no-one loses out. If they deliver late or deliver a bad product, then we have some comeback against the cost. And – this is important – if they deliver early and/or a ‘better’ product than we had asked for, we need to be able to reward that too i.e. they make more than the averaged £500 a day.  This might get us more hours in our ‘professional day’ and improve engagement and commitment (and in a way that’s harder to achieve with permanent resource?). Win-win!

Of course, it isn’t that simple.

It doesn’t work for all assignments. Where we have contract resource working on operational BAU activity such as support, the deliverables will be harder to define. Whilst there may be some generic targets we might expect them to hit, the simple day rate is probably still the best solution here – at least until we are sophisticated enough to be more specific.

We need to include metrics into the contracts. We have to agree the metric up-front. Some will be simple, binary even: something is either delivered or it isn’t. Then we more in to more quantitative measures: time and cost are the obvious ones in this area. The hardest ones are the qualitative measures. Some you can attempt to be specific about – zero defects, for example – but what about the quality of a document, or the efficacy of a strategy?

We need to agree the outcome. Having agreed the metrics, at the end of the job we need to agree the outcome. The quantitative and binary measures should be easy enough: yes/no, six days instead of five, and so on. The qualitative measures will be harder, especially those that are based upon personal opinion. Your hired resource might think their presentation is top notch, but you don’t. What do you do then? You need to be clear about as many of the metrics as possible at the start of the assignment, and probably leave out anything that could be dangerously contentious – at least for your first time round. You will need to be prepared for the “It wasn’t my fault” argument when things don’t go quite so well, when there are mitigating circumstances outside of the control of the Contractor that impacted their ability to deliver. Here, your integrity and honesty needs to be spot on. If you try and use these kind of graduated rewards as a means of getting a job done on the cheap then shame on you – and the word will spread as to how you operate!

The rewards? I would suggest a simple scale. For example, delivering on time to agreed quality would net a bonus that would work out to equalling the ‘normal’ day rate e.g. the £500. For being late or delivering a poor quality product, then maybe anything from a zero ‘bonus’ up to the day rate i.e. in the £400-499 per day equivalent. For delivering early and/or something of superior quality that exceeds expectation, well, take your pick – but being able to go beyond the £500 average is clearly the ‘carrot’.

Bottom line. Does it work? I have seen examples of fixed contracts where individuals have agreed to deliver a specific ‘thing’ to agreed levels of quality based on it taking them a certain amount of effort (hours or days). That becomes the fee. If they deliver it early, they get paid the same amount – effectively their ‘day rate’ goes up. If they deliver late, clearly the opposite applies. These people were focussed, motivated and delivered; they were engaged and committed. It really was win-win.

So tweaking the system – where appropriate – can work. Certainly it should be something worth thinking about, at least to try and calculate if the additional admin effort up-front will yield sufficient benefits downstream…

-*-

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 © 2012. 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.

A New Approach to Portfolio Solution Provision?

You are probably familiar with the scenario. After a period of strategy definition, soul searching and navel gazing, there you have it: the programme of work that will lead to a step-change in the IT service you provide your customers. Great! The only problem is that, well, it’s quite large and expensive, and you don’t have the products, skills and people to deliver it. So you’re going to need help – and fast! Especially as your neck is now on the block!

At this point, assuming the programme isn’t so closely knit and inter-related that it makes implementation of a major ERP solution a ‘no brainer’, there are two routes that you might choose to take. The first is to call in one of the major Systems’ Integrators (SI) who profess to be able to tackle just about everything. And in a world where traditional IT boundaries of expertise are being broken down, there are now more and more companies who play in this space: “Cloud? No problem! Hosting? No problem! Business Process consultancy? Six Sigma? Off-shore development? No problem!”. Life’s a treat!

The second route could be to break up your portfolio into its component projects, create teams for each of those, and then send them out into the world in the hunt for the illusive, mythical and vacuous ‘best of breed’ solution.

Both of these approaches are valid. How valid they are will depend on the nature of the programme of work you need to undertake; the size of the in-house IT organisation; your philosophy in relation to things like outsourcing; the skills and knowledge you have at your disposal now – both IT and business; whether you are breaking new ground; the size of your budget etc. etc. The list of things that affect your route is enormous – which means that there is probably no ‘right answer’.

And there might be no ‘right answer’ for other reasons. Take the SI route. SIs are filled with knowledgeable, talented, committed people. Time and again, they deliver a good end product to their clients. However, there are potential challenges if you take this path:

·         People & Skills. It turns out that the SI doesn’t have all the people and skills that it actually needs to deliver to you, so they go into the market themselves and potentially hire the same people you might have been able to secure directly. They may also subcontract much of the delivery, so the “Hosting? No problem!” scenario only works if the SI themselves doesn’t actually do it. These two things alone imply that there could be questions over the quality of service you get, and/or your control over that service.

·         Cost. SIs can be inherently expensive. Often this is valid because you are paying for top-drawer people, but that’s not always the case. And if they do go out and hire a contractor at £500 a day, will they charge you that (plus a modest mark-up) or their standard £900 rate?

·         Existing relationships. It is possible that the SI may have an ‘understanding’ with certain other IT organisations, despite protestations of impartiality and bias. When they suggest a component to fit your ‘best of breed’ goal, they may effectively be selecting from a shortlist of one.

·         Niche players. In the SI scenario, it is entirely possible that perfectly adequate, low-cost, functional solutions that would meet your needs perfectly well are never brought to the table – possibly because the SI doesn’t know about them, if for no other reason.

So let’s avoid these potential issues and take control of it ourselves, and follow the internal teams route. Well, I’m afraid that there are a new set of pitfalls that could be awaiting you there too:

·         People & Skills. You need the right numbers of people with the right skills to tackle your portfolio. This probably means you have to hire, and – as you know – recruiting people takes a lot of time and effort. A lot of time and effort…

·         Knowledge. Even if you have the people you need, many may have no experience of the kind of major undertaking you are considering, so they’ll be learning on the fly. Additionally, if you get into Requests for Proposals (RFPs) and all that implies, including the commercials, do you have access to adequate contract and legal ‘nous’ to get you over the line? Far too often there are people playing out of position here. We’ve probably all done it, or seen it!

·         Time. Without the kind of head start that an SI can potentially give you, your programme of work could run and run. And who’s to say that when you’re half way through, it is still the right thing to do?

·         Cost. Yes, the SI may be expensive, but when you add up the costs of this route – recruiting new people, building skills, time – your internal option could be pretty pricey too.

So, there are challenges – and there may be no ‘right answer’. And for the other people who could help you, the plethora of small- to medium-sized IT companies who have the solutions that might just be what you need, in this binary world of SI vs. Internal portfolio delivery approaches, they could be suffering. Not only might they not get a look in, but they could be spending a significant amount of money not getting a look in! The relative cost of getting new customers is likely to be high; they may need to make major investments in sales and marketing activities to try and punch above their weight. And in a crowded marketplace, getting their message across can be difficult.

Is there an additional option therefore? I think there could be. Call it Federated Solutions, or Composite Solutions. Call it what you like.

Think about Amazon. Amazon is no longer a bookseller; it’s a trading hub. It has provided many thousands of small niche retailers access to a global audience at very limited cost. You go to Amazon because you know you can get just about anything there; but what percentage of the end product is now provided by Amazon versus those who occupy spaces in their market place?

Why couldn’t IT solution provision work in the same way? Wouldn’t it be great if you could go to “Get-IT-Sol” with your requirement – say for a new Business Intelligence (BI) solution – knowing that they had access to a whole range of BI service providers, large and small, and that they could facilitate some of that up-front filtering, selection process for you? Then, having helped you short-cut the process, they could hand it back to the internal IT team to run the project. Or say you needed some help with internal governance and controls, or maybe COBIT-related processes. Wouldn’t it be nice to get to specialists who have been there, do it, got the scars in the just the way that’s relevant to you?

Of course, an SI will say that they can do all of this, and many will be able to. But it will more likely be an end-to-end proposition, under their jurisdiction and control. And of course you may say that you can do it with your team. But take a look at some of the players in the Amazon marketplace you’ve probably used personally in the past. How would you have found them without Amazon – and how long would it have taken you?!

A facilitated composite approach, if available, could provide an alternative route to simultaneously delivering a portfolio of IT ‘solutions’. If you consider some of the potential negatives of the SI and Internal models, this option could offer mitigation in the areas of People, Skills, Cost, Bias, Knowledge and Time. And for the smaller, niche players, it provides them with a way to get access to a larger customer base at a lower cost.

 Is this a new business model? Perhaps. But perhaps it is more about creating a new channel for IT service and solution provision / identification to complement those already in existence. Of course there would be major challenges in setting up such a ‘federation’ with a long list of pitfalls to avoid, but it could prove to be a winner not only for those who build and operate the ‘marketplace’, but for its customers and suppliers too.

 

-*-

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 © 2012. 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.