Musing jetlaggedly about loss of control

[Apologies in advance. I woke up at 1am, unable to go back to sleep,  with no cricket to watch, with the residue of San Francisco time still in me, and so I started writing from the hip.]

I think of many things as projects; in doing so, I use what I assume to be fairly common definitions of what constitutes a project.

A project:

• must have a start date
• must have an end date
• there must be a bunch of resources at the start
• the resources should be of three classes: unstarted (where the resource is the labour used to build other resources); raw (where the resource exists, but work has to be done to convert that resource into something usable; componentised (where the resource is ready for use).
• There should a fourth type of resource, the tools used to integrate the other resources together

Project management is then the art or science of bringing together the three types of resources, using the fourth type of resource, in order to create some valuable output between the start and end date.

A project can be constrained in a number of ways:

• you could be required to have it done by a specific time
• you may be asked to complete the project within a particular cost envelope
• you may have limited choice about the resources used
• you may be restricted to using a particular set of tools
• and you may be asked to ensure the output meets or exceeds some defined standard.

Using this kind of definition, you can understand why I think of many things I do as projects. Take cooking for example. Every time I cook, I’m managing a project. I acquire some raw ingredients, primarily vegetables, meat, spices and, where appropriate, cooking oil. First I prepare those ingredients for use: cleaning, chopping, puree-ing, parboiling, mixing together, whatever. Then I combine those ingredients with others I may have in component form already: dried spices, condiments, sauces and gravies. If I’m lazy, if there is some unavoidable time constraint, or sometimes because I’ve inherited them, I may have some resources already in a prepared state: carrot batons, chopped onions, stuff like that. Then I’m all set to go, follow the instructions.

Some people use recipes or cookbooks, some prefer not to. When I was young, I refused to use a cookbook: I wanted to be an artist, to be creative, to make things up. Which was fine…..if I succeeded. And sometimes I didn’t succeed, with horrifying results. So I began to use recipes, modifying them when appropriate, but experimenting with the modification first before trying it out on others. A private beta as it were. Sometimes I created the recipes, but the beta was even more private in that case, just me.

[Regular readers of this blog will know that I love cooking. And eating. So when I describe cooking, I’m describing a labour of love].

When I was young, I insisted on many things. I insisted on getting all the ingredients myself. I insisted on clearing whole hordes of space in the kitchen, as much free work surface as possible; i insisted on having all the right tools, the right music, the right everything. I wanted to be left alone, undisturbed, while I worked on the food.

Yup, I was a right prima donna. An occasional not-particularly-talented artist who thought the world belonged to him just because he deigned to be in the kitchen. In the meantime, my wife would cook every day, insist on none of the things I insisted on, go about her business pragmatically and efficiently, and come up with the most amazing food every day. Without a fuss. Sharing the kitchen with others, doing other things at the same time, getting on with her life while producing quality food for the rest of the family on time and to budget day in day out. And she used recipes, recipes from cookbooks, from friends, from supermarket cards, from magazine articles, from the Web. She used prepared ingredients when she needed to. She got on with the job and did it well, not looking for credit, not complaining; she did it with no excuses, she did it even if she was ill or tired. I salute her. I have learnt a lot from her.

What point am I trying to make? It’s about control. A family household is all about sharing, about consistency and reliability and security, about pragmatic choices, about managing to budgets and times. It’s about consideration for others. A family is not about control, it’s about loss of control. It’s about relationship and covenant and caring and respect as the motivators to do something, rather than command-and-control and more-stick-than-carrot.

A household is a good model for shared services. It is possible to run a household as a set of isolated end-to-end units, with every person having his or her own infrastructure for cooking, washing, cleaning and so on. But it would be very expensive and time-consuming. Skills can and should be replicated: everyone should know how to cook and clean and wash. Infrastructure should be shared not replicated.

So it is with enterprises and markets. Skills can and should be replicated where possible; human beings are versatile, humans relish variety. Sometimes I think of assembly line as nothing more than an Industrial Age instance of the Caste System, a formal division of labour. Sometimes I think of professions the same way, particularly when we try and raise barriers to entry with the usual “you don’t understand this, you’re stupid, this is too complex for you, and anyway we speak a different language, a secret language, and we’re not going to tell you. You need to do your crime and your time before you become an expert like the rest of us. In the meantime, you’re barred from the holy of holies”. You know what I mean. Priests, accountants, lawyers, doctors, computer scientists, we’ve all done it.

A project manager’s first instinct is to insist on control. Control everything, end to end. Every ingredient. His own recipe. Not Invented Here. Clear work surfaces. Matrix not spoken here, go away.

It works. In fact, for amateur project managers, it’s probably the only way. But then let’s recognise them for what they are. This may appear fine from a results-oriented viewpoint. Until you look at the costs. Which is where the problem lies. The control-freak no-matrix project manager is an expensive proposition, expensive in terms of costs and time. And margin.

Shared-resource models and matrices did not enter enterprise life because there was some pinko lefty tree-hugger involved in organisational design. They did so because other models were not affordable.

Collaboration is not an option, it’s an imperative. Shared-resource models are not nice-to-have, they’re the only choice we have, particularly in these straitened times.

Which brings me to my coda. End to end control and devices. Many people point at Apple and BlackBerry as excellent examples of what happens when you have real end-to-end control, how quality is obtained and sustained, how the customer experience is so brilliant, and so on and so forth.

It’s true. End-to-end control, as in the Apple and BlackBerry device cases, does yield excellent results. But there’s a cost. A considerable cost.

Actually there are three costs:

• First, the process is more expensive, end to end control does that to you, and you have to pass the cost to the customer. Yes you could do a Henry Ford and reduce options in order to reduce the costs and deliver something affordable to the customer, any colour you like so long as it’s black.
• Second, there is a time delay. Shared service models, once they’re set up, reduce cycle time. There’s true component architecture and reuse. End-to-end control freaks tend to shy away from shared services and reuse. Witness the innovation cycles in OpenOffice and Office and you will get what I mean.
• Third, there is a loss of freedom. Freedom expressed in breadth of choice; freedom expressed in the options available, in the features and functions, in the tolerances for data migration in and out of the system.

Collaborative development is all about layering rather than silos, about horizontal consistency rather than vertical control. It is about open standards and interfaces rather than closed locks. It is about pragmatic community rather than prima donna behaviour.

It’s been some time since the telco lost control of the device; guaranteeing the end-to-end experience then becomes a question of influencing a series of horizontal layers while being accountable for the integrated experience. We’re learning about it, we have some way to go, but we’re on the way.

And so it is with computers. People, we’ve lost control of the device. Which is a good thing. Provided we are able to grow up and work with component architecture and reuse models, with open standards, with collaborative partnerships.

Provided we’re able to deal with the loss of control. [Which, by the way, has already happened. And it’s not coming back, whatever we do.]

It could be said that it took 40 years for IBM to “become evil”; 20 years for Microsoft to do so; 10 years for Google to follow suit; and 5 years for Facebook to join the gang. None of these companies is evil, there’s nothing evil about them. I have friends in all those companies, though I may not use all of their products. They haven’t changed. What has changed is the perception of value by the customer, the perception of the cost of a closed-system world.

Umair Haque said something along the lines of “The costs of being evil now outweigh the benefits”. So we have to move with the times. And that means giving up control.