Pages

Tuesday, 27 July 2010

Agile: Guidelines or methodology?

Another discussion on LinkedIn, this time about whether Agile is a methodology or just guidelines. The consensus seems to be guidelines, which seems to reflect the spirit of Agile better.

But at the same time, this view seems only to address Agile in the abstract, not Agile (or any other delivery model) as implemented in any real organisation. Which is a pity, because it is at that point that the strains will start to be felt if Agile remains no more than guidelines. On the other hand, to convert it to a formal corporate methodology would not only defeat much of its underlying philosophy and approach but also lead to Agile being ossified in the same way that waterfall – which was never inherently rigid or bureaucratic – was ossified by immature implementations and too much top-down corporate management freakery.

And of course, there always been legitimate management reasons why Agile cannot be left to go its own way, any more than any other management tool. There will be inescapable (and entirely reasonable) reporting requirements, stakeholders will often want to know what progress is being made in non-Agile terms, and so on.

So, for any organisation that does not want to see something as promising as Agile degenerate into either paperwork or making it up as you go along, it is necessary to be rather more specific about how either a Agile-as-methodology or Agile-as-guidelines is implemented.

So even if Agile is to be forced into the mould of a corporate methodology, any self-respecting implementation can features that prevent it from becoming a rigid, inappropriate and self-defeating. For example:

  • It will be specifically tailored to the type of work that is really being done.
  • It will be abstract enough to permit considerable leeway for professional judgement.
  • It will be fully scalable (no, not just big, medium and small).
  • It will include user-friendly mechanisms for granting exceptions and waivers.
  • It will include wide-ranging but rigorous (the very opposite of rigid) ranges of meaningful options.
  • It will be implemented through training and tools, techniques and templates that make explicit the team’s authority to vary, depart from or just plain ignore the ‘rules.
And so on.

I don’t see that any of this gets in the way of Agile, or how any complex organisation could safely or profitably implement it without at least a few of these quite standard methodology components.

Friday, 18 June 2010

How good is DSDM?

I recently initiated a discussion on LinkedIn entitled How good is DSDM? Although there was (unsurprisingly) a consensus that DSDM was A Good Thing, we were collectively unable to come up with much hard data until Jennifer Stapleton – a past Technical Director of the DSDM Consortium – kindly offered me some data from Xansa (bought by Steria in 2007) and British Airways. Xansa’s data is especially interesting, as it covers a number of clients (including BT) and Xansa was, at that time, the world’s largest DSDM practice.

The gist of the data is that DSDM offers huge improvements in productivity, team size, delivery time and project quality. Here are the basic graphs (not as contemporary as I'd like, but still solid data):


Friday, 11 June 2010

What, ultimately, is Agile about?

There is an interesting discussion of Agile going on at LinkedIn at the moment. The topic under review is 'Transitioning from command and control to a servant based style of leadership'. personally I think the idea of 'servant leadership' is both misconceived and redundant, as the answer (so far as I understand the issue) was provided by the German sociologist Max Weber about a century ago.

In brief, at least as far as successful Agile projects are concerned, I suspect that this change in the way organisations work under Agile is closely connected to the distinction between being a professional and an employee.
  • An employee is someone you pay to be able to tell them what to do, and is best suited to command and control.
  • A professional is someone you pay so that they will tell you what to do, and so works better in a collaborative environment - which Agile is designed to create.
Conversely, I suspect that whether an Agile initiative is successful depends heavily on the extent to which truly professional capabilities and a professional culture exist. In that respect it would be very interesting to hear from people for whom Agile had not worked as to why it had failed.

Note the causal direction. If companies insist on command and control, they get employees – i.e., people who need to be told what to do. If you give people opportunity and responsibility (and a non-trivial amount of skill), you will get professionals.

On the other hand, the training and coaching needed to get people who were previously treated as employees to operate as professionals (and therefore suite to Agile) can be very great. The transition is not easy or straightforward, not least because the skills required are by no means solely technical. There are personal and social capabilities that are also required to succeed at Agile. But they are encompassed by the concept of professionalism.

This can be exemplified by a major cultural problem Agile implementaitons often seem to face, namely empowering staff saying no to their boss (eg, the Agile PM). Managers need technical training (i.e., how to do Agile) but other team members need the social and personal ability to insist on their own professional perspective. Few organisations cultivate this attitude (though I have known a few), but I would say that it is crucial to making a success of Agile.

The same point applies at the other end – to business stakeholders. They also frequently need a change of culture – to become involved, to own the project, to participate effectively, to accept an incremental approach and to be able to change their minds without embarrassment or political penalty.

Wednesday, 26 May 2010

Why prefer DSDM to Scrum?

Ultimately practitioners know that there is no need to choose between Scrum and DSDM, of course: they can be integrated into a hybrid that suits your specific requirements. However, it is helpful to have a clear idea of what the different flavours are and what they are capable of, because it is not only purists who want to know exactly what you are doing: so will the people who are shelling out the cash to pay for the change. Being able to give them a clear choice between clerly defined options, plus clear criteria for choosing, is essential to selling any form of agile.

So, here are some reasons for preferring DSDM to Scrum, in direct proportion to the size, complexity and innovativeness of the project and the difficulty of the technical and compliance requirements.
  1. The Foundation stage makes sure that everyone ‘gets’ what you are up to. Without this, something very bad is likely to happen to your project. Adding a 'Sprint 0' isn’t the answer unless it looks very like DSDM’s Foundations anyway.

  2. DSDM is a true end-to-end process, not just the middle, development snippet. Since most of the mistakes in IT are made before the ink is dry on the contract (internal or commercial), this is a crucial consideration.

  3. Defining the roles as completely as DSDM does can be extremely helpful in any but the most trivial of projects. After decades of IT neglecting this issue, it is refreshing that DSDM includes it. Very hard to do well (and the sell to the business and operations alike), but absolutely essential.

  4. Defining a few basic products – BAD, SAD etc. - is also very helpful. Given the complexity of most real projects, it can be impractical to rely too heavily on prototypes and the authority of empowered teams, powerful though they are.

As this list suggests, DSDM is much more suited to a corporate environment, where the playfulness, autonomy and spontaneity of Scrum clashes rather sharply with the demand for formal definition, accountability and predictability. It's hard to get the full benefits of Scrum while adhering to corporate formalities dictates concerning governance and accountability, investment prioritisation, intelligibility and visibility to a wider group of stakeholders, quality management, reporting and architecture.

Anders Larson has kindly pointed me to this good comparison of DSDM and Scrum from the DSDM Consortium site. Its author, Andrew Craddock, summarises the position very well: after listing the principles of the Manifesto for Agile Software Development, to which both Scrum and DSDM practitioners contributed and subscribe -

  • People and Interactions over Processes and Tools
  • Working Software over Comprehensive Documentation
  • Customer Collaboration over Contract Negotiation
  • Responding to Change over Following a Plan

- he notes that 'DSDM recognizes value in the items on the right of the Manifesto statements more than Scrum does, whilst still putting the highest value on the items on the left. This allows DSDM to fit more comfortably with the normality of larger organisations and gives rise to some of the differences between these two Agile approaches.'

Tuesday, 25 May 2010

Why is DSDM called Atern? A methodology by any other name...

Rant on.

For some while I had wondered why DSDM’s most recent incarnation is called ‘Atern’. What could it possibly mean? An internet search – including a search of the DSDM site itself unearthed – nothing. Then the other day I was browsing through the discussion of the DSDM Group on LinkedIn entitled – ‘What does Atern mean?’ Given that the discussion was initiated by David Winders, who seems to know what he is talking about when it comes to DSDM, this I slightly surprising.

Like David, I awaited a potentially embarrassingly simple answer – and one came back straight away, from Inna Dalton:

I was told that it stands for an arctic tern - a bird. There was something, it
was claimed, in the fly pattern or behaviour of this bird that has some
semblance to the iterative and/ or incremental nature of the method. Hence, the
image of this bird on some of the books by DSDM Atern.
Embarrassingly simple indeed. But who should be embarrassed by it is another question. Not so much those who did not know but, I think, those who gave it the name in the first place. Because it lacks meaning, 'Atern' is just annoying, or perhaps a pretentious little joke for insiders. Now that I know the answer, my reaction is somewhere between a despairing 'Oh dear' and a thudding 'So what?' - exactly the opposite of what a brand name should do. What could possibly have possessed them to do something so crass?

Still more importantly, plainly hardly anyone seems to know what the name means – i.e., that it is the name of a bird - so the species probably doesn't matter much. Metaphorical names (eg, a bird) are useful, but only if it is clear what the metaphor actually is!

As David concluded, ‘I do hope the Arctic Tern doesn't become a Dodo or indeed the version isn't a Turkey’.

Rant off.

The business case for DSDM (and Agile generally)

Currently I am participating in a very interesting discussion about the business case for DSDM with the LinkedIn site’s DSDM Group, particularly with David Winders.

There seems to be very little hard evidence that DSDM is significantly more efficient than a waterfall approach at doing the work, which would seem to kill the business case stone dead. After all, why incur the costs of migration if the grass really isn’t any greener on the other side?

But as the discussion has evolved, it has become clear that this is to misread what Agile methods like DSDM (or Scrum) are offering. (And perhaps this should have been obvious from the start – I only really noticed this point once the discussion was well under way).

To boil down what is (for the time being) the final argument, there is indeed a narrowly economic argument for DSDM. Unlike a waterfall, DSDM is never going to waste stakeholder time and money by delivering (say) 100 function points that were agreed a year ago, when they were almost certainly based on premature and immature judgements. We probably don’t want exactly those things any more: our thinking has evolved, our goals have evolved, and the business situation has evolved. Instead it (DSDM or any other agile methodology) will deliver 100 function points and for much the same price per FP, but they will all be FPs we know we want.

Add to this DSDM’s far closer control over the delivery process, which makes it far less likely that the whole project will go over budget, schedule but under scope, and the business case for DSDM is clear: even if DSDM projects don’t cost less per FP, they represent better value for money, because they are all FPs you want.

Another interesting point was made by John Isgrove of Collaborative Consulting -

What we found was that DSDM completed the same development in 66% less time. It did not complete in less effort however as with agile projects they tend to be shorter but fatter resource profiles i.e. work for less time but more people involved at the same time across the time period. Overall effort was about the same with with higher proportions than the waterfall project being spent by the analysts and testers.

Monday, 24 May 2010

Moving to Agile - Identifying the truly essential documentation

A crucial feature of migrating to Agile is identifying the irreducible documentation needed to support the process. For many Agile practitioners the very notion of a fixed documentation suite will raise their hackles, but there are many stakeholders, not all of whom are not directly involved in the delivery process, but all have interests that must be taken into account.

To name only the most obvious, there are three general classes of stakeholders, each with their own distinct information needs:

  1. The delivery team itself
  2. The business
  3. Operations, compliance and support

These groups are already often poorly served by waterfall processes; the risk is that Agile’s understandable and largely justified desire to take an axe to the great mass of pointless documentation will result in them being served still worse. So…

The delivery team

Well, obviously. And generally speaking the Agile assumption that there is, by default at least, no need for internal project documentation, holds good. Why would I need to write down what I can tell everyone in a tenth of the time? Why write down anything at all if its lifetime is likely to average 15 days?

But less obvious, is it in fact the case that they need nothing? In very simple projects, yes, it usually is, but in a more complex programme – for example, a dozen Agile workstreams flowing into a common integration/release cycle – they may well need a good deal more. The PM is likely to be unavailable (doing programme-level duties at meetings and forums) and when they return to base, unable to convey everything by word of mouth.

Then the standard criterion applies – fitness for purpose. But in a project of any significance (size or importance), that rule is unlikely to result in their being no documentation at all. Add to that the other reason why documents exist – because the project is innovative, organisationally complex, heavy with technical or regulatory content, and ‘pure’ Agile starts to look a bit thin. Absolutely never create more documentation than are strictly needed, but don’t assume that the minimum set is zero. That is usually wishful thinking.

Business stakeholders

Yes, a properly empowered business rep should allow you to dispense with almost all external review and approval, but even in the most benign environment, there are likely to remain yet higher level reports. Much as most of us would like to dispense with this too (why don’t they just have faith in us?) but ultimately projects exist solely because they serve the interests of the organisation as a whole, and someone up there really does need to know what you are up to. So there is all but bound to be some form of reporting.

However, taking a constructive approach to this can also encourage those to whom reports are due – PMOs, line managers, HR, finance, direct reports to senior stakeholders, etc. – that they don’t really need the detail they are probably accustomed to. Reporting strictly by exception is the starting point, as it is that, rather than no reporting at all, which is the true corollary of empowerment. Using the move to Agile to rationalise reporting isn’t a bad idea either.

Operations, compliance and support

Now we come to the groups who are most in need to solid documentation and most likely to be neglected. In many organisations the needs of operations, service transition and support teams are already poorly met, and Agile is unlikely to do them any favours. Nevertheless, it is crucial that their needs are met, and these go far beyond touching base with them or even having them represented on the project. They will spend far more on the delivered system than the developers, and the better equipped they are to manage the delivered solution, the better for everyone.

Operations, compliance and support will make up the great majority of all but the most superficial IT projects (e.g., throwaway web pages or transient rate changes), and their needs are not only substantial but also penetrate deeply into the heart of what is being developed. They all need to be consulted about the original requirements (e.g., to define SLAs) and strategy (e.g., to ensure sustainability), they all need early warning of what, functionally and technically, is coming down the track, they all need to know what exceptions have arisen as the original requirements/backlog is progressively shaped and re-shaped, and they all need to be aware of the (now multiple) schedules for release.

Conclusion

So what does this all add up to?

  1. There is a very great deal of documentation that genuinely can be thrown away – and good riddance. It adds nothing but dead weight to the project and should be discarded whenever possible. Which is remarkably often.
  2. Quite a lot of other stuff needs to be transformed. It is very likely that groups such as administrative functions (PMOs, HR, finance) will have to change the way they think about projects and how they are reported on, but it is unlikely that they will eschew reporting altogether. Nor should they. Likewise for business stakeholders – they need to assign real power to their business representatives within the project, but they are unlikely abandon all visibility. And given their responsibilities, how wise would it be?
  3. Finally, there are those who will need what they have always needed. But if you don’t give operations and support what they need, they probably won’t notice much: by and large they aren’t getting it now either.

Wednesday, 19 May 2010

Moving to Agile - Critical business factors

Some years ago I implemented DSDM (then the preferred flavour of Agile) at Churchill Insurance. As far as the core processes were concerned, there was no great difficulty (admittedly we threw everything at it), but the business was a problem for two key reasons: empowerment and availability.

The nub of the empowerment issue was asking the business to allow their own representatives on the project enough authority to approve of what was going on on the spot (e.g., prototypes, changes, reprioritisations, etc.), without constantly referring to senor management. In short, they could not let go of the strings. As anyone who has worked in IT projects for any length of time will know, there is a ludicrous irony in this, because quite a lot of the problem with delivering successful IT projects of any kind is the business’s ambivalent attitude the ownership. In all too many companies, the business want to be in control of the project (i.e., able to make make-or-break calls about it) without taking responsibility for its delivery. The implicit question is always, do you prefer delivery to control?, and all too often the effective answer is ‘control’. This is as much a problem for Agile as it ever was for waterfall projects.

The second problem was getting the required effort from the business representatives to the project. These individuals were necessarily very experienced and valuable people (who else would you empower?) but that was precisely what made them hard to replace in their day jobs. So we needed them to spend about three days a week on the project, but they still needed five (usually very long) days for their BAU work. No surprise, then, that project work soon started the back seat to day job, the quality and speed of decision-making plummeted and the project started to look pretty wonky.

So although the business was keen on an Agile approach, they could not participate effectively. It was a long struggle – only partially successful – to deal with this problem.

Moving to Agile - Creating an Agile environment

In my experience a crucial precondition for achieving agility is a certain level of maturity. Although the core processes, roles and tools are critical, so is the presence of quite a wide range of highly standardised core mechanisms of which the agile operations can take advantage.

The classic example, familiar from IT development (whence agility sprang, of course) is test automation. Without this the development team is unlikely to be able check its day’s labours swiftly enough to move on confidently the next day. But test automation itself can only be adopted by an organisation that already has standardised test classes, a well established test process, a clear understanding of the basic mechanisms of test scripting, and so on. Without all of these (and much more), test automation will fall flat on its face – becoming either ineffectual or rigid – and quickly start to turn agility into paralysis.

Of course, in a vey small, simple project or activity, the preconditions for agility are very limited. But in a more complex situation, such as BAU operations or a large-scale programme, agility can be achieved, but only ensuring that a full ‘agile environment’ is also in place. The elements of this environment can themselves be agile, but they certainly must be present and specifically geared to allowing other areas to take them completely for granted – it is, after all, the most basic basis of agility that the would-be agile activity can either omit or take for granted that everything in their environment.

Hence one of the key task – perhaps the single most important task – when implementing agile methods is to investigate what the organisation’s ways of working can offer to the agile area – and what they demand from it too.

A few (there are many more - this is just a flavour) of the areas you need to get right include:
  1. A governance system that allows for rapid validation and approvals of many incremental releases.
  2. Business and operational organisations and processes that are capable of assimilating frequent change.
  3. Office arrangements that support closely collocated teams.
  4. Extremely slick mechanisms for remote groups – vendors, outsourcers, other offices, and so on.
  5. System architectures that support rapid change.
And so on - an enormous range of factors, many of which are typically intensively embedded in the wider organisation. it isn’t easy getting this sort of thing right.

Wednesday, 21 April 2010

Two Cheers for Bureaucracy

‘So, you love bureaucracy,’ said the researcher from the BBC. ‘Can you tell us why?’ She’s calling in response to my response to a BBC blog piece entitled ‘Are there too many bureaucrats in the UK?’, where I had indeed admitted to loving bureaucracy.

‘Well,’ I reply, ‘“love” would be putting it a bit strongly. But I do think bureaucracy is the most important thing humanity has ever invented.’

I see. Not content with loving these crushing administrative behemoths – he thinks these embodiments of all that is wrong with the modern corporate world are our greatest achievement. What will the funny man say next – that toothache is a much undervalued pleasure?

But it’s true. Bureaucracy is the nervous system of society, and has been for five millennia. It puts electricity in the wires, food on the supermarket shelves and controls business and government’s every move. It puts these words in front of you right now.

So what does a bureaucracy do that society finds so invaluable? It controls the flows of information and decisions an organisation needs to carry out its activity. Different bureaucracies do this more or less well, but as long as society includes lots of different individuals doing lots of different things, and they need to collaborate across wide spaces and long periods of time, then something has got to organise them, and it’s hard to imagine any alternative that won’t be bureaucracy by another name.

But why does bureaucracy have such a bad name? Why does so much of it seem to degenerate into red tape? Why are politicians constantly planning to cut it?

The full answer is complicated, but the first part is simple. Contrary to popular feelings of frustration – feelings I share whenever they break down on me – bureaucracies rarely go wrong. A past colleague of mine, Melissa, had a useful analogy: bureaucracies are the brains of society. But, she would add, like the brains that control our bodies, ‘we only notice society’s bureaucratic nervous system when it stops working. Any idea what your visual system is actually doing right now? Me neither. But we’d all find out soon enough if it stopped doing it’.

Hence the ease with which a bureaucracy gets a bad name. Most work just fine practically all the time, but who gives thanks for the good old bureaucrats when the lights go on or our salaries arrive on time? When it goes wrong, though – the wrong tax demand, the double booking, the failed delivery – who doesn’t automatically curse the idiots who made this mistake? And if it it’s only when it goes wrong that we notice bureaucracies, how can we help but have negative feelings about them?

Actually it’s astonishing that bureaucracies work as well as they do. Even to professionals, it’s quite intimidating how much information and what a complicated process you need to come to what seems a simple decision. It takes careful thought, a strong sense of purpose and a great deal of effort to design, build and manage a bureaucracy of any size, let alone having it perform note-perfectly. And as soon as its parent organisation starts to change – which can well happen unintentionally – the bureaucracy also has to change. Given that change is increasingly a way of life for organisations, it’s not a recipe for easy success.

On the other hand, the fact that bureaucracies are as imperfect as any other human creation is no argument for less bureaucracy. That would be like saying that, because cars sometimes break down, we should have fewer of them. Now, there are lots of reasons for having fewer cars, but that isn’t one of them. And just like your car, bureaucracies need occasional maintenance – which, in my professional experience, they seldom get.

Not that I’m complaining. Most of my living comes from fixing management systems that have been allowed to wither – just recently one of the biggest UK supermarkets, a major player in the City exchanges, a healthcare company. They’re all equally lax about keeping themselves sharp – which is, after all, what even they say their administrations are for. Rather worryingly, though, I haven’t had to learn much in the course of two decades advising companies – there are still plenty making the same old mistakes.

And every time I hear about some big consultancy or software company building yet another huge IT system for the government – often to the tune of hundreds of millions of pounds – I just remind myself remember that an IT system is simply an electronic bureaucracy. Given how badly we handle the paper variety, it is small wonder that so many major IT programmes – private as much as public - turn into a ‘bureaucratic’ quagmire. Years late, millions over budget, and few happy with the final result.

In fact the way these huge government projects have so often failed illustrates what is wrong with the way bureaucracies – paper and electronic - are often treated by their owners. No one is quite sure what they are for, and executives are often allowed to make endless new demands for new information, new reports, new updates, without thought for the cost and disruption this entails. They’re also often allowed to change their minds in midstream. In fact the stream of fundamental mistakes seems to be as endless as it is easily repeated.

Middle managers and staff then have little option but to turn their administrations into all things for all men: saying ‘No’ is too often a definite Career Limiting Move. And from then on, many bureaucracies face a constant demand for more and more, frequently with little budget or resource to do more than kludge together a jerry-built ‘solution’, which its ‘stakeholders’ then expect to have at their disposal forever. And if you add to this the number of reports that bureaucracies dutifully prepare and are then never read, you can perhaps imagine the disillusionment felt by many bureaucrats.

So what is the end result? Ask the people at the sharp end. Call centre staff – the modern face of faceless bureaucracy – are quite routinely the butts of public scorn. Usually paid little more than the minimum wage, they are expected to answer perhaps 60 calls a day, day in, day out. Could you do that? I’m not sure that I could. And then there’s the abuse – not least the racial abuse routinely received by Indian call centre workers.

As one anonymous call centre worker put it on The Weekly Gripe website, ‘It's shocking how badly these people are treated. First of all they are blamed for a multitude of sins by the customer about things that are completely beyond their control. As if that isn't bad enough, next they are treated like cannon fodder for the company to blame when it all goes wrong’.
Or perhaps it’s in the nature of call centres: ‘I am sure a lot of people have the kind of mind set that means if they cannot see the person they are talking to, it is somehow perfectly acceptable to be rude, abrupt and patronising’.

Do the staff deserve it? Of course not – and no doubt most abusive callers know that. But faced with delays or not being able to get what they need, who else is there to explode at but the anonymous, faceless innocent at the other end of the line?

All in all, it’s astonishing how pleasant and polite the average call centre worker remains – but less than astonishing that the industry as a whole has staggering turnover rates. Industry figures suggest about 20% each year – which in turn suggests that the average call centre worker stays for five years. Hard to imagine. But research by George Callaghan of the Open University has challenged the official figures, concluding that the average worker stays only eighteen months.

‘Many employees expressed extreme frustration with their jobs. They were under the impression they were employed for their great people skills, but then not allowed to use those skills’, Dr Callaghan observes. ‘This is one white collar environment where employee performance is measured by the second.’

It’s a familiar accusation: bureaucracies crush the life out of professionals through their constant demands for risk assessments and reports and the constant micro-management of every aspect of their work. The public services especially seem to be prone to this – scrutiny of them is so much more intense.

Yet this is not really the result of bureaucracy as such. It is perfectly possible to design the rules that govern an organisation to include great latitude for personal discretion. They can also be built to be extremely flexible and adaptable and to be responsive to change, personal experience, unique circumstances and individual needs. It’s not bureaucracies that are at fault, any more than word processors are to blame for bad novels.

Bureaucracy as such requires only that information and decisions are designed and organised well enough to get the larger job done. In a public service organisation like a hospital, a school or a social services department, it would be perfectly possible to treat broad sweeps of professional activity as ‘black boxes’, leaving precisely what is done and how to the professionals.

The bureaucracy might also need to know a little more about how the job is carried out – who actually did the work, what resources were used (for inventory purposes only), and so on – but more than that? Only if there was a compelling reason. These people are, after all, professionals. You have employed them because they know how to do the job better than you do.

So what counts as a compelling reason for more bureaucratic control? Well, one thing shouldn’t: a media frenzy. Because even where tragedy strikes, it’s hard to imagine a better recipe for creating the wrong answer than covering your back.

After the Baby P tragedy, ‘The front-line professionals – teachers, health visitors, doctors - took fright’ recalls one healthcare worker, who prefers to remain anonymous ‘and started to make far more referrals to their local social services department. But at the same time, our own local social services department started to block direct calls between outside professionals and their staff. They even changed their telephone numbers so we couldn’t call them personally. Then we’d have to go through a long Q&A session – who we were, the child’s name and address, a lot of other details – when all we wanted was to have a quick chat, professional to professional, about whether they needed to know more about our cases. Mostly they probably wouldn’t have wanted us to refer them, but we had to go through the same rigmarole every time.’

A typical bureaucratic response to a crisis. It’s hard to see how this sort of control over professional communications made a child any safer, but it’s easy to see how it would protect the organisation.

‘Of course, when we finally got through, we just exchanged our direct phone numbers anyway, so the system was side-stepped almost as soon as it came into existence’, added my informant.
But this isn’t really the result of bureaucracy. It’s the result of managerial paranoia. Well, perhaps not paranoia – after all, a social services department’s fear of another media feeding frenzy is well founded.

So the answer is, not more bureaucracy or less, but getting bureaucracy right. But this is not something that is likely to be achieved by politicians and business executives who understand little about their own organisations’ administrations beyond the a priori assumption that it must be a bloated monster.

So the first step is to take a serious look. No, don’t hire a consultant to do it for you – go and look yourself. Martin Long, founder and ex-Managing Director of Churchill Insurance, insisted that every single Churchill employee spent regular mornings doing someone else’s job, including a turn on the call centre phones, and then suggesting three things to improve the work. Nor was he above taking a turn himself – indeed, pictures of Martin on line to customers were familiar to everyone.

I have often thought that every MD and CEO should spend some time anonymously taking a closer look at their own organisation. Like King Harry before Agincourt, a stroll past the foot-soldiers’ tents might teach them a thing or two – a very surprising thing or two – about the organisations they imagine they understand. (They just need to avoid the shameless logic chopping Shakespeare puts into Harry’s mouth.)

It’s not hard to do better than most organisations are doing right now. In fact there’s a bit of a vogue these days for so-called ‘lessons learnt’ systems that actively prompt a bureaucracy’s operators and users to feed their experience – good and bad - back to the managers who can do something about it. But it’s too early to get excited - this is only the latest of many rounds of self-improvement technique that have not quite solved the problem. Or rather, quality circles, kaizen, ‘lean’ management, Six Sigma have all helped to make bureaucracies more efficient, but whether they have made them better for their workers, customers or even the organisations that own them is a question that remains to be answered.

Still, lessons learnt systems need to be tried, if only because, unlike many other improvement tools, they ask the fundamental question of what the bureaucracy is ultimately for. It’s a bit fiddly and for many organisations deeply counter-cultural. But it’s a lot cheaper than the millions they dole out every year to consultants like me to dig their existing bureaucracies out of the pits they have created by years of poorly thought-through initiatives, weakly managed change and simple neglect.

In sum... One cheer for the general idea of bureaucracy, though it’s seldom carried out well. Another cheer for the poor bureaucrats, the butts of everyone’s scorn. But no cheers at all for the many organisations – private as well as public – who just don’t get it.

[Listen to the original BBC broadcast here.]

Saturday, 10 April 2010

What are the Key Success Factors for a new CIO?

I've been following the above discussion on LinkedIn here. Some interesting stuff, so I thought I'd summarise what I have read so far.

The whole thing seemed to me to break into three parts: the first 90 days, creating the day job, and justifying the 'C' in CIO. Here goes...

The first 90 days
  • Find how you can save the company money immediately.
    • Ask everyone who reports to you for 10 ideas to save the company money.
  • Find out how you can make the company money.
    • Understand the business – goals, strategy.
    • Identify your key customers and stakeholders, and set up KPIs and CSFs forthem.
  • Tap existing desire for change.
    • Poll IT and business for quick wins.
  • Establish your credibility.
    • Sell IT actively to executive & stakeholders.
    • Evangelize how information makes business competitive.
    • Lead how organization thinks about performance.
    • Build shared view & alliances with peers.
  • Know your department.
    • Operations, development, governance, architecture, support.
    • Define KPIs & results-based reporting.
  • Learn the business
  • Always have a backup plan for whatever the IT department does.
Creating the day job
  • Build a strong team.
    • Talent, performance, delivery, R&R.
    • Stakeholder-facing responsibilities.
    • Self-managing, self-starting.
  • Integrate IT and business.
    • Business ownership of projects.
    • Shared/interlocking governance.
    • Budget/investment interlocks.
    • Portfolio management, etc.
  • Make sure IT do the basics right first time.
  • Emphasise speed of decision-making & delivery.
  • Get to grips with your basic technologies.
  • Bring development and operations closer.
  • Do change management simply but well.
  • Routinise governance, architecture, infrastructure and operations.
  • Build active innovation and self-improvement into IT.
    • Lesson learnt, empowerment, etc.
    • Track stakeholder satisfaction.
  • Develop backup plans for whatever IT does.
    Justifying the 'C' in CIO
    • Create a credible organisational plan that embeds the dynamism of your first 90 days in IT.
    • Be a business executive – not a techie.
    • Define a credible but radical vision that creates a quantum jump in IT’s competence and performance.
      • Goal: To move IT from technical enabler to business leader.
      • Create an IT strategy that solves real business problems.
      • Subordinate all tactics to this strategy.
    • Manage the politics.
    • Foster innovation and change.

    Thursday, 4 March 2010

    BPM, SOA and the relationship between business and IT

    I am struck by the fact that discussions about the perennially fraught relationship between business and IT always seems to omit reference to the very different natures of business and IT. IT reality has always worked more or less at right-angles to business reality - an engineering discipline in the midst of business. The links between are generally limited to very high levels at which the relationship is mediated by very general language that does not really require either side to have any insight into the other (i.e., requirements), and at very low levels that actually have little influence over the relationship as a whole (i.e., day-to-day system users).

    While this remains the case, there is no practical need for this relationship to get any better, and each side will continue to prioritise their owns engineering/business perspective over the other side’s concerns. And while IT technology always reverts to a strictly engineering mode of thought and the business side lacks a genuine ‘engineering’ element of its own, it is very unlikely that this impasse will be overcome. We can all agree that ‘something should be done’ and even agree what it is, but however important this is, it will never be urgent, and certainly not capable of being built into both sides’ day-to-day ‘common sense’.

    However, my own impression is that there are developments in the pipeline that will overcome this. On the one hand, the emergence of service-oriented architectures in IT is forcing IT people to define what they do (even for themselves) in terms even the business can understand. On the other, the (rather slower) emergence of formal business process management is creating a kind of ‘business engineering’ that obliges businesses to thing of their own activity in quasi-technical terms that even an IT person can recognise. Between them, SOA and BPM are creating the language, the conceptual framework, and the technical toolkit business and IT need to create that ultimate goal, a unified business/IT worldview.

    Not that this is either all that is wrong or likely to offer a complete solution. All the same, I doubt that there will be any solution until business and IT alike learn to think of themselves in such terms. This does not mean that IT people need to understand business or vice versa, but it does mean that they need to think of themselves in mutually compatible terms. Which is what, I think, a combination of SOA and BPM will achieve – without either side intending it.