Benchmarking 'Mankind When Unmanaged'

David Maister presents the following figures in his talks (available here). They are a guess at categorising types of people as they are currently behaving within a professional service firm:

• Dynamos 23%
• Cruisers 60%
• Losers 17%

He presents his own definitions but the only one that isn’t particularly intuitive is his definition of ‘Loser’ where he recognises that we can all be losers at some type in our lives.

I would suspect that many people would suggest that this is a good guess of the percentages in each category for their organisation.

The really interesting thing is that David is, during this talk, is trying to make a ‘case for management’. He says ‘those numbers are probably about right for mankind when unmanaged’. So if these figures seem about right for your organisation then you a performing like an unmanaged organisation! Your management function (nothing personal here – jus the system itself) is not meeting the case for management presented by David.

Using the analogy of giving up his own smoking and over-eating habits David says ‘If you leave me to find the energy solely on my own the odds that I will do it purely because it’s logical and purely through self-discipline are in fact quite low’.

What an interesting question. How does your management system compare against the benchmark of ‘mankind when unmanaged’?

Structure and risk

Examine a standard project management policy around risk management and you are likely to find reference to a risk management process which looks a lot like this:

1. Invite stakeholders to a risk management kick-off meeting
2. Brainstorm risks and record in a risk register
3. Categorise the risks using attributes such as Likelihood, Impact, and Owner
4. Perform simple analysis which (usually) plots impact and likelihood to get a risk exposure
5. Aggregate all of the risks into a single 'bubble chart' which gives a the projects risk profile

Now there is nothing inherently wrong with any of those activities (with the possible exception that the last 2 steps are more about analysis than management). Project management needs to be both generic and actionable regardless of the context. The above activities are certainly that. There value, like most of the project management process, lies in the fact that they allow the project manager to act - even when faced with uncertainty. This is the most powerful part of the project management discipline which consistently delivers value. Many of the other benefits of project management derive value more from other skills of the individual project manager rather than the project management process itself. However, even the value of enabling action is limited. This is action at the personal level and does not necessarily equate to effectiveness at the organisational (read ‘project’ in this context) level.

.

Back to our generic risk management process, the problem with this approach is the lack of a reference architecture. The entire process relies on risks being identified by somebody. This brainstorming part of the process, which the rest of the process is based on, is actually completely subjective. Risks exist as inherent attributes of the endeavor which is the project. The risk management process must be able to find these risks - not simply focus on the activities and analysis which occurs after they are identified.

.

Structure, both organisational and the methodological structure, is actually the first step towards effective risk management. A collaboration architecture, or rather the generative process which ensures the true 'delineated shared understanding' which defines an architecture, ensures that risks embedded in all components are examined. More importantly, the collaboration architecture acts as a reference architecture to show where stakeholders haven't been identified or analysis hasn’t been performed. What this amounts to is a better understanding of the areas of uncertainty - an important component of an effective risk management process.

.

You might suggest that other parts of the project management process provide the structural components which support the risk management process. For example, before you hold your risk management kick-off meeting you have ‘defined scope’ and ‘documented roles and responsibilities’. The only problem with this is that, in the absence of a reference architecture, the project management discipline by itself doesn’t help you identify the right scope, or the right roles and responsibilities. The correctness of the components becomes a quality issue – not process quality in this case, but product quality. The product being the ‘scope’ or the ‘roles and responsibilities’. But unfortunately, within current management thinking, once an activity becomes a management activity it quickly become immune to the organisational checks and balances which naturally improve the quality of that activity (see ‘Management with an uncontested value proposition’ in the MWT Book).

.

Of course, it's also not all bad news that risk identification in the original process is subjective. You, if you wish, can look at risk management as providing a complete risk profile of the project. Alternatively, you can see the risk management process focusing on actionable risks. If nobody is identifying the hidden risks then they probably don't have an effective strategy for dealing with them (I say dealing with them and not 'mitigating' as this is only one approach to dealing with risk. Others might include 'ignore' which is definitely not mitigation). If you don't have an effective way of dealing with the risk then why manage it?

.

The problem only comes when you aggregate the data. If you presume that this is a complete picture of the risks you are wrong - unless you present with a reference architecture. Aggregation of incomplete data must be performed carefully. Without a reference architecture the areas of uncertainty (unknown data) will be lost in the aggregation. Where aggregation is striving to produce a complete ‘big picture’ of the data it often closes up the areas of uncertainty in the name of maintaining a cohesive structure in the presentation. To avoid this the presentation must be cohesively structured before the data is overlaid onto it. This often doesn’t mean pre-structuring the representation – rather evaluating the structural goodness separate to the data.

.

All methodologies embody some world-view of where the risks exist. A customised, comprehensive, and task-specific methodology - and by this I don't mean a cumbersome and monolithic methodology - can actually reduce the need to go back to fundamentals for all risks. After all, task-specific methodologies are developed in response to known risk indicators inherent in the task. Unfortunately, by the time most methodologies are 'rolled out' all sense of the drivers behind the components of the methodology are lost. In effect, the process of pre-preparing methodologies disconnects the methodology from the risk mitigation drivers which formed it. This in turn causes another cross-discipline disconnect - this time between the domain specialists promoting the methodology and the project management perspective.

New Blog Engine

My web hosting provider now provides a free Blog engine (based on WordPress, I believe). I've converted over to this engine so I have comments and trackbacks. The old entries remain at: http://www.managewithoutthem.com/blog/home.asp.

Update: I've since converted everything to Blogger. As you can see.

No rugby jokes, please

I was lucky enough to attend a presentation on Scrum by Joseph Pelrine in Sydney last night. More importantly, I was lucky enough to have dinner and beers with Joseph and some other people from OOSIG afterwards. A big thanks to Alex for organising this!

I found some interesting similarities between Joseph's presentation of Scrum and my ManageWithoutThem philosophy. This being my only real experience with Scrum I don't have any idea if I was connecting with the Scrum process itself or something more that Joseph bought to the presentation. He certainly did bring much more so I suspect the latter.

Specific comparisons with the MWT model include

• Joseph introduced Scrum with a brief discussion about the differences between Empirical processes and Directive processes. Of course, every time I try to explain MWT I start with observation that economics recognises that there are two different types of economies, planned economies and market economies. If you understand the differences in both cases I believe you'll agree they are different in the same ways.
• Joseph used but never never really defined this concept of 'simple design'. I presume this is because I was already supposed to know what this was about from eXtreme Programming. I suspect it is similar to the MWT concept of Organisational Usability. I don't really like the word 'simple' because it implies that simplicity is something you decide and then do – rather than the result of a process (understood or otherwise) that you must constantly evaluate the output of to determine if it is simple. To many times I have seen too many IT managers hide behind 'I just want a simple solution' when what they are really saying is 'I have nothing to contribute'. I like the organisational usability analogy better because it begins to give a criteria for simplicity.
• A general discussion Uncertainty and Agreement and there relationship to complexity. I'd like to hear more about Joseph's views of slide xx of his presentation. When I saw the slide I immediately thought that each activity would have a real position on the graph and a position dependent on how accurately the real position was perceived. If activities were managed as though there was less uncertainty and/or more agreement than there actual was then this would push that activities position on the graph in the direction of chaos. Joseph went many steps further and described 'a whole factual' of positions. It appears he had much more to teach about the dynamics within the 'complex' part of the graph than the big empty yellow mass implied. Excellent! Give me more!
• Joseph defended specialisation. I've often defended specialisation (I have a chapter heading, if nothing else, called 'In Defence of Specialisation') and consider it a sorry state for the science of management if it has to resort to 'I wish everybody was a generalist' when the whole point of management is the coordination of different specialists!
  
• I need the slides to continue this comparison. I'll post an updated entry when somebody posts the slides.

I felt three connected responses to Joseph's presentation. Firstly, when I recognised some of the ideas he was presenting as similar to my own I was a little disappointed that I wasn't quite as original as I thought. I sometimes feel like the John Nash depicted in A Beautiful Mind – driving himself mad in the search for a truly original idea (I also like a quote that my memory attributes to David Weinberger when he describes himself as 'an idiot savant without the savant part'). As I get back into writing the MWT book I really don't want to be held up by this kind of thinking.

Secondly, I felt vindicated. It was actually nice to know that I was right about a number of things. I've been struggling lately to continue to live under the delusion that there is value in the hideous and tedious processes that large IT consulting companies use to develop software. I actually already knew that these processes were not the optimal way to create software. However, I was willing to allow the process to keep occurring all around me. What's more, I was allowing it to exist. Often I would find myself preparing the immense plans, misguided and ambiguous functional specifications, wasting developer's time even, to produce a set of documents that 'fit the process'. All the time knowing that this wasn't how the software was going to be built.

I was, at least, honest enough to realise that a whole underground process was going to need to be developed for each project I was on. The process that would actually get the software developed. Often, some of my highly paid colleagues wouldn't admit to this. They thought the functional specifications were actually getting the software written. They thought that if only the plans were perfect next time then the software would be better. Be denying that the process was broken they were effectively allowing huge amounts of project effort to go unmanaged. They were never going to take control of the system in any confident and effective way because they were ignoring what was actually occurring in the system.

Thirdly, and lastly, I realised that there was a kind of zen-truth to all of these ideas. When Joseph started talking about the 5-6 things you can do to try and change a complex systems – something that intrigued me but went a little over my head at the time (he could probably see this in my eyes but was polite enough not to notice) – I was instantly reminded of Christopher Alexander's 15 properties, generative sequences, and structure preserving transformations.

This last realisation brought it all together for me. When you are heading towards a truth perhaps you shouldn't expect it to turn out to be a truly original idea. The truth should ultimately be familiar to us and connected to everything we do. This is partially the reason that certain people can come to the same universal conclusions through the mastery of different things. Joseph doesn't think of himself as a Smalltalk developer any more. He says he is exploring organisational complexity – or complexity in general. The fact that people can still 'mistake' him for a guru-status Smalltalk developer is a testament to the intellectual place he finds himself and the universal truths he has uncovered and is learning to incorporate into his behaviours and life.

Of course, I only spoke to Joseph for a couple of hours so I'm not even really talking about him. But isn't that the whole point...?

Believing their own PowerPoint

Unfortunately, large bloated IT consulting companies have no interest in developing software cost-effectively. Now it's important to understand that I'm not proposing that there is some sort of conspiracy to make software development projects cost more than they have to. It doesn't have to be that IT consulting companies are purposefully developing methodologies that make software development take longer. It is simply, in the absence of transparency and competition, the companies that cost the most are the ones that will be the most successful. Basically, they'll make the most money.

Again, I'm all for companies making more money. I don't actually have the chip on my shoulder about so-called corporate greed that so many people appear to have. All I'm saying is that in the absence of competition (or more importantly – diversity) and transparency there is no incentive for big bloated IT consulting companies to convert to more efficient methodologies for software development.

Now this is a worrisome state for the IT industry to be in. But it's even more worrisome when you consider that for a young generation of talented (or rather intelligent) recruits into IT consulting these methodologies are the only way of developing software they have ever know! Born and breed in an environment which sells the approach through a bastardised definition of risk management and fear mongering about software failures, these talented graduates learn to justify and sell the approach until they actually start to believe their own PowerPoint presentations. All the while, by ignoring the alternatives, they are paying only lip service to risk management and quality by turning these processes into a disconnected series of reviews and lists.

Real software quality, at reduced costs, is available to organisations through improved software processes. Monolithic software processes which require feats of great prediction and hundred's of hours of b-grade consulting to implement are not the answer. These process success only in ensuring value is delivered as late in the process as possible.

MWT Book Extract - Broken Collaboration Contracts

Part of one section of the MWT book is available below as a pdf:

MWT Book - Extract - Broken Collaboration Contracts

I will be taking a month off very soon where I will be able to progress the book further. I have, unfortunately, been too busy to write over the past 12 months.

The Organising Power of Science Fiction

I'm currently reading Cory Doctorow's Eastern Standard Tribe and it has inspired me. He has me thinking of the management potential of good science fiction writing and the vision it presents.

A few months ago when I was reading the doctor's first novel, Down and Out in the Magic Kingdom, I thought I'd discovered him. However, he appears to be gathering quite a following in science fiction circles and publications. This is much like when I thought I'd discovered on-line journal writer, author, and sometimes science fiction fan Jason Pettus a few years ago at a time when the AvantGo version of his on-line journal had over 10,000 subscribers!

I used to read science fiction as a teenager. I bought more of it than I actually read, mainly because I'd often buy a whole series only to be disappointed by the first few pages of the first book. I recall many types of science fiction; but much of it offered no more than the combination of some other genre with new technology and a slightly exotic location. Western with laser guns, soap opera on another planet or in a space-station, love story with tragic death born of alien invasion. That sort of thing.

Cory Doctorow doesn't write that sort of science fiction. Cory writes pure vision. He reminds me of Stanislaw Lem but I don't really recall the details of Lem (it's been 15 years!) so I fear I might just be comparing them based on a generic 'goodness' rather than any specific qualities. Lem is worth checking out regardless.

Back to Cory Doctorow's Eastern Standard Tribe. My Palm e-book reader tells me that I'm only 17% into the book and already I'm intrigued by the novel's vision of the future. In particular, in the novel's incorporation current and evolving technologies into new social structures. It also has a focus on technology offering competitive advantage at a individual level.

You can feel (though no explicit mention has been made of them yet) the micro-payments swishing about as intelligent agents query information, verify documents, and raise alerts - all from wearable personal computers. You call also see evidence of technological 'arms races' as individuals and organisations each use increasingly technical solutions to counter the other's technologies.

All this amounts to a powerful vision. Management has been fond of vision for years now - but corporations are sadly lacking in technical and organisational (and organising) visions.

Why not outsource visioning? Perhaps Doctorow (who is already actively looking for alternative ways to grow rich from his writing), and other authors of his caliber, can hire themselves out to write novels which explore the potential of a corporation's products and services. Or even, after spending a little time hidden within the corporation's corridors � acting as an employee, perhaps � write a vision of how the corporation might operating internally or with its partners.

I'm not talking about propaganda - not even marketing - but a vision. Perhaps the vision completely destroys the corporations value proposition. Or perhaps two alternative visions are offered. There is no implication that the novel would be something you would want to show the shareholders. Should be a vision in the sense that it is a horizontal organising mechanism - a vision in the practical sense of an enabler of collaboration and organisation.

Interestingly, between the time I downloaded EST and the time I started reading it and typing this blog post, it appears that Vodaphone has made reference to the novel in one of its market-facing publications. Vodaphone obviously already see some of the commercial potential of Cory's vision.

Doctorow is already exploring the question of 'Eastern Standard Tribe coming true?' on his web site. He is also well aware of the need to experiment with alternative models for embracing and exploiting his creative talent � offering multiple distribution options for his work, including free Creative Commons licensed download being part of this. What he also needs to explore, and what people will pay big dollars for, is the potential for his writing to actually create, rather than just predict, the future.

Update (01/07/2005): I've been feeling kinda silly giving Cory advice (even if not directly). His name keeps coming up all over the place. He's certainly been doing a hell of a lot more than I suggested - and he's been doing it for years!

Mindmaps

Alternate Definition of Management #532

Management is the art of deciding which decisions don't require consensus.

Happy Birthday Ayn Rand

Article on Mises.org.

Falicious planning

I believe there is an old Dilbert comic that shows Dilbert's pointy-haired boss asking the development team to 'design everything you can think of so I can choose which one I want'.

This is the problem when management is seen as simply decision making (or worse, as deal making) rather than allocating scarce resources and assuming responsibility.

Of course, everybody knows this. Everybody can say they are pragmatic. However, there are still many fallacious arguments made disguised as pragmatic management.

While I see management activities and expertise as something that is inherently task-specific I still tackle every management challenge as a general management challenge. Part of this is recognising when planning is being faked.

Take an example that I often hear from test managers. Test managers try and tell me that they will prioritorise which test cases they are going to produce and/or execute by listing all of the possible test conditions that could be tested and then assigning a priority to each one. On other occations the test manager doesn't even intend to take responsibility for the prioritorisation of the test conditions. In these caes business stakeholders are asked (after they have already prioritorised features and other requirements) to do the prioritorisation for the test manager.

Now the problem with the extreme version of this approach � where business stakeholders do the actual prioritorisation � is that it gives up responsibility for testing. Give up responsibility and your really can't say you're managing anything.

The more subtle problems come from the specifics of the testing problem domain. Testing is one of those unbounded activities that you can devote as much or as little effort as you like to. Within that there are also extremes of effectiveness with regards to that effort which essensially represents the quality of your testing.

By taking a brute-force approach to prioritorising the testing effort you are ignoring the test design process. You are still designing test cases � but you are not tracking (managing) the effort. Worse still you are taking a 'default' design which is the default result of the unmanaged process you have ignored. If this is your approach there is no guarantee that your actions will result in higher quality activity than would have been performed if you were there.

The problem is that this behaviour doesn't have to be on purpose or malicious to occur - it simply has to be the behavior encouraged by the organisation.