Invest in your corporate brain

The brain consumes about 20% of the body’s energy, and that is why we are by far the most dominant organism the world as ever seen.

From the point of view of development, I would say that formal processes represent about half of every company’s brain – a good deal of its memory, its practical skills, its controls of perception and behaviour, quite a lot of its capacity for reasoning, balance and coordination, and most of its basic language and social skills.

On the other hand, most companies' formal processes - their lifecycles, their operational mechanisms, their ways of working - are designed more like the brain of a crocodile. (The analogy is more exact than you might imagine.) They are spread out across they organism, they barely speak to one another, they are almost never tailored to the practical needs of their users, they are seldom created with a meaningful outcome or benefit in mind and never tracked or measured to see whether they are doing their job and seldom fixed even when they plainly aren't, they have no effective direction or ownership, they are formally changed in an arbitrary and impulsive manner, they are never changed to anticipate a real problem, and so on.

Without major evolutionary leaps processes like this will never evolve into something truly intelligent.

Why is this?

It is, I think, because we don’t bother to invest in them to the extent necessary. Perhaps we just can’t believe that they need maybe 20% of all resources. Perhaps, like the brain itself, the significance of these processes is lost on people who, almost by definition, cannot see what they contribute. After all, we only need to invest so much in a corporate nervous system because most the useful things an organisation does require a span of knowledge, control and attention no individual possesses. Hence the paradox of processes – they are installed because we cannot manage such vast and complex systems, but even when they are installed and doing their job perfectly well, we seldom construct, implement or support them in a manner that really improves our view of the whole. We are still cogs in a machine that, although it may now be working better, we still cannot grasp processes as a whole.

So what needs to be done to improve our grasp? There are quite a few things that can be done:

1. Engineer processes properly in the first place!
   
   1. Make it a collective activity, don’t under-estimate how much effort it will take, or the hidden cost of getting it wrong.
   2. Start with a clear end in mind – and constantly test processes to see whether they are doing their job.
2. Make sure everyone understands what the processes are for – i.e., don’t allow people to wander blindly through their work.
   
   1. Train everyone and train in detail. The ROI on training is higher than the ROI on almost anything else in management.
   2. Not training is not only completely counter-productive but also extremely demoralising and defeats the purpose of hiring intelligent, capable people.
      
3. Do not over-engineer processes:
   
   1. Define standards and processes in terms of functional goals, not detailed technical steps, so they can be implemented and adapted locally.
   2. Conversely, explicitly Maximise local discretion and flexibility, so decisions made remotely cannot inadvertently force absurd actions locally.
4. Make sure that you can fix any problems with the process.
   
   1. Instrument the processes to make sure they tell you how well they are doing without having to ask specially.
   2. Have an intelligent waiver/exemption process so local teams can escape the worst excesses of processes not defined for their purposes.
   3. Part of every well-defined process is the possibility of changing it. It will need changing, and you need that fact into it. So make sure that all processes are owned, with clear local accountability and authority to improve. Invest in the time and re-training needed to do that.

There’s a lot more, but if you are already doing all this, you probably have other things you should be focusing on instead.

Your SDLC is your company's brain

I have recently been asked to review a large insurance company's delivery methodology, and found a state of affairs I have not witnessed for about 20 years. It’s a sad thing that major companies routinely neglect their lifecycles, methods and processes, presumably because they do not appreciate just how valuable the potentially area. It’s almost like they can’t see what good their brains do, so they neglect them in favour of other, more obviously useful organs (mainly the stomach, I think), and as a result their brains shrink and they become still less able to evaluate those same brains' purpose, effectiveness or value.

In fact the brain is very good analogue of the an organisation’s development lifecycles. not least because it is the reason why we are by far the most dominant organism the world as ever seen. From the point of view of development, I would say that an organisation’s formal processes represent about half its brain – a good deal of its memory, its practical skills, its controls for perception and behaviour, quite a lot of its capacity for reasoning about cause and effect, balance and coordination, and most of its basic language and social skills. Yet in many companies development lifecycles are organised and managed like the brain of a crocodile, not a human being, and while that continues it will never evolve into an intelligent being. (The analogy is more exact than you might imagine.)

But of course, the human consumes about 20% of the body’s energy, while most development lifecycles would be lucky to receive 1% of a company's attention. Which is odd, to say the least. Any improvement in process brought about by improving the local development lifecycle would surely need to change in performance by at least, say, 4-5%. In a £20 million programme, that means spending £1 million on their lifecycle would at least be covered - yet does anyone spend so much on this crucial part of development? As for a £100 million portfolio, how many companies pend £5 million a year on maintaining their development processes, let alone the central nervous system's budget of 20%?

On the other hand, the efficiencies that could be achieved by integrating the delivery process as a whole and making it a dynamic part of real delivery are vast. Some time ago Accenture published a paper showing that training had an ROI of more than 350%, and I suspect that the same would be true of improving most companies’ development lifecycles.

Here is a quick questionnaire of the most important issues, based on about 20 years of looking at (and occasionally helping to six) the problem. Note that it does not start with the details of the lifecycle documents and products – that is the least important fact! On the other hand, in more mature organisations the issue is often no more than obsolescence and missing items follow from the lack of sustained management focus, but in all too many cases there are major gaps.

1. Is there a global management approach to the delivery process itself?
• Clear unitary and controlled ownership, management & rules of delegation of the end-to-end development process.
• Is there a development strategy?
• Is there real expertise in methodology development? Just asking PMs what they think is like asking drivers how to design a far – you’ll get some of the user requirements but nothing useful about the design.
• Is there a coherent or proportionate rollout/update process?
2. Is there a simple, intelligible presentation & access?
• A single, integrated model of delivery as a whole, including:
• Governance, management technical tasks and support functions?
• All stages, including both work selection and initiation and solution deployment/transition and work closure?
• A single, user-friendly site for accessing the delivery process as a whole?
• Effective control over authoritative versions (and withdrawal of obsolete materials)?
3. Does it cover all of your most important delivery strategies?
• Outsourcing?
• Offshoring?
• Package procurement & implementation?
• SAAS (Software As A Service – thinks like Salesforce.com)?
• Does it have enough (or anything) to say about non-development activities?
• Procurement?
• Support and maintenance?
• Technology upgrades (Oracle, SWIFT, etc.)?
4. How mature is the lifecycle itself?
• Are there proper delivery and management processes - i.e., some components exist, but they do not operate as a complete, end-to-end, Prince2-like process?
• Is there a true programme management lifecycle (most organisations are dominated by programmes now)?
• Does it include a convincing model of change management as a whole, notably:
• Business design, development, readiness & transition?
• Operational design, development, readiness & transition?
• Does it handle very small projects (which can often be managed through a single artefact)?
5. How well does the lifecycle define basic management elements?
• Roles + responsibilities – are they current, consistent and complete?
• Are there explicit criteria, rules and authorities for adaptation, scaling & exemption?
• Does it include (or at least point to) integrated stage and task-level processes & tools?
• If it is a waterfall lifecycle, does it include a risk-driven iteration model for managing individual tasks and stages?
• Are there detailed procedures for basic management tasks (risks, issues, assumptions, dependencies, change/configuration control, product/document management, impact analysis, estimating, planning, resourcing…)?
• Have standard stage/task/product level risks, assumptions, dependencies, etc. been identified and articulated?
• Does it set credible gateways, including include stage-end consolidation & validation, evaluate full project content, review performance to date or readiness for next stage, etc.?
6. Are all individual products actually inadequate?
• Are products defined by independent product descriptions?
• Are there stage, product- and task-level procedures, advice & information?
• Are there samples of good practice, including instances for each major area of usage?
• Does each item have a supporting quality checklist?
7. Is alignment with other functions well defined?
• Clear & efficient access to supporting management functions & data (resourcing, MI, finance, architecture, etc.)
• Explicit alignment with and access to related standards + policies?
8. Is the lifecycle actively supported?
• Are there discipline or process owners, with clear roles & responsibilities, a proper management cycle and allocated time to do the job?
• Are there SMEs, with clear requirements and channels for feeding their experience into the organisation (e.g., a central lessons learned system or training/briefing programme)?
• Is there an R&D process (minimally to drive innovation, capture and socialise training and disseminate new joiners’ knowledge & experience)?
9. Is there a training programme covering all processes, roles, tools & techniques?
• Is there a specialised SDLC training function & system.
• Is there a training programme for staff, consultants, outsourcers, offshore & contractors?
• Are there self-training packages for key activities – individual products, reviews, testing, requirements management, etc. – so users can refresh their knowledge independently and as and when needed?

Without a Yes to at least most of these questions, you have the methodological equivalent of a crocodile's brain, and it will be all but impossible to make substantial and sustainable progress to real intelligence.

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.

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.

Defining capability

Another question I have spent much of my professional life pondering: What must a business capability of any kind have in order to create success?

Quite a lot of experience of service management suggests this basic model.

(Click on the picture to expand.)

Capability management cycles

I have spent a long time studying capability management - the active creation of a integrated approach to continuous improvement that goes beyond localised incremental change.

This diagram summarises my current view of this process.

(Click on the picture to expand.)

What makes a good manager?

Five minutes ago a junior project manager in the company I am currently consulting to came to me and asked me a simple question. What makes a good project manager?

I asked him why he wanted to know, and he said, ‘Because that’s what I want to be, and you’re an outsider who knows about this stuff’. So this is what I told him. I think it applies to other kinds of manager too.

Master the basics

There is no substitute for doing the basics and doing them well. Planning, risk management, dependencies, team-working, and all the rest. And make sure that you really do them well – that issues and actions are routinely tracked, that you write formal work packages rather than just assuming that what you have said is clear, and so on. Qualifications are nice because they provide a structured model for management, but just learning to do the basics properly is a matter of attention, responsibility and commitment – virtues without you will never be a good manager.

Be professional

You can acquire any number of professional qualifications and certificates. But for other people to think you a professional, you need to be worthy of the name.

For example, when I recently gave a course on delivery management and suggested that the project manager’s ultimate responsibility was to make sure that the benefits our colleagues hope for are really achieved, one very senior manager responded with ‘That’s not my job’.

Well, no, if you define your job by your formal job description, maybe it isn’t. But as Max Weber – the man who practically created the idea of professionalism – said, an employee is someone you pay so you can tell them what to do, whereas a professional is someone you pay to tell you what to do. I’m pretty sure that a good project manager is a professional, not just an employee, and I cannot imagine how a project manager could ‘tell me what to do’ without understanding what, ultimately I was trying to achieve.

So if my plan says ‘meet these requirements’ or ‘deliver this system’ then I don’t doubt that I will fail if I don’t. But I cannot see how I can really succeed unless I understand the benefits you think these requirements and deliverables will give you, and make sure that I work towards them too.

There are a million other things a professional manager does as a matter of routine. Many of them are not unlike being a consultant. Indeed, I don’t think there’s much difference between a good manager and a good consultant – they tend to merge in direct proportion to their maturity. Think big, take pains, even all do those clichéd things like ‘going the extra mile’. And do not think ‘outside the box’ – just recognise that there is no box unless, out of fear or ignorance, you put yourself in one.

Master the corporate management system

The third (and probably biggest) item is harder, as it is not in the individual manager’s power to do much about it. It’s the corporate project management system – that can make more difference to being a project manager than anything else. In fact I regard it as the litmus test of my own work building management systems – that managers don’t have to do anything but manage. All the rest – the petty bureaucracy and standards and elementary tools, techniques and templates – are all provided in easily used form by the policies and systems and training I create.

On the other hand, if your system isn’t quite that friendly, it is still open to the good manager to take a hand. Except in the kind (happily rare) organisation where authority is either so rigid and draconian that you would be far better off getting another job, the reason the management system doesn’t support you is usually either because you don’t understand what it is trying to do or the people who manage it aren’t telepathic and they did not know that it was causing you problems. If it’s the first (and regretfully, it often is) then once you understand the problem (hopefully) goes away, but if it is the latter, then what is stopping you getting them to change it?



Ultimately you will know when you are a really good manager – it is then that working really is more fun than fun.