[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.

I’d been looking forward to the launch of Europeana, scheduled for yesterday. What’s Europeana? A pan-European collection of digital objects from a vast array of libraries, museums, collections and archives, covering books, magazines, film, photography, paintings, music, maps, sights, sounds.

I was travelling yesterday, and had planned to look at the site once I’d unpacked and showered, the idea being I could get a few things done before the children returned from school. But it was not to be. When I tried to get on, I was greeted by this:

Yes, it was another case of the Yogi Berra phenomenon. Nobody went there any more. It was too crowded.

I think Europeana is a great idea, and wish the people behind the project well. I hope it is a success, and look forward to using it.

I also think the failure is the shape of things to come. As more and more people get connected, swarming behaviours will get accentuated, and there is every likelihood that sites will get swamped. Of course we will learn from the swamping, we will see systems architected to deal with such behaviours, we will see the provision of infrastructure in ways that can handle such swamping.

Learning is already taking place. Animoto is pretty much the poster child of the Stampede Generation (my term for sites that experience remarkable traffic swings). Read the RightScale/Animoto story here if you’re interested; I’d heard about it some months ago; Michel Burger, then at Microsoft, tipped me off.

BTW Animoto is a great site, you should visit it. Takes your photos and music and mashes them up professionally. I met Stevie Clifton, their CTO, for the first time last week at the Harvard Cyberposium; he’s a great guy, they have a great product, and I’m sure that they will succeed.

In the meantime, we need more Fail Whales. They’re so much nicer than bland statements of unavailability.

My purpose is, indeed, a horse of that colour.

Maria, Twelfth Night, Act II Scene III. Shakespeare

A couple of posts ago, I used the word “piebald” in conversation, and that led to a number of comments and observations. Which in turn made me think about where the word came from and why I knew it.

Let’s take the why first. I used to read a lot of Westerns as a child and boy; our house was a Max Brand house rather than a Louis L’Amour house; Zane Grey barely got a look-in. [That fascination with Westerns now has me reading Elmore Leonard with glee and abandon.]

Westerns were not just about cowboys and guns and cattle, they were about horses. And Max Brand opened up a whole new vocabulary for me, one that I cherish even now. Bays and roans, sorrels, palominos, piebalds (pintos in the US) and skewbalds, paints, duns, chestnuts and brindles, greys with or without dapples.

Language is something that entrances me, particularly when it is precise and rich and full of colour (no pun intended). There is something deeply satisfying about using the right word in the right place, what I tend to call the Dandle phenomenon. [I’ve never been able to use the word “dandle” except in the context of “baby” and “knee”.]

A fascinating world, one that you can step into quite easily via Wikipedia. Just read this article on Equine Coat Color and you can make a start.

Apropos piebald. The more I thought about it, the more I realised there was a second influence, one beyond Max Brand. And it shows my age. Peter, Paul and Mary. In the Wind, their third album, is one of my all-time absolute favourites, a real Desert Island disc for me. And on it there is a song called Stewball, one I really like. But then I like the whole album. Long Chain On and Rocky Road are probably my favourites, and I just love the treatment of Quit Your Lowdown Ways and Don’t Think Twice, It’s Alright.

I used to wonder why someone would call a horse Stewball. Which led me to skewbald. And on to piebald. And on to equine coat colours in general. This was probably 1969, when I was 12, so the memory has lasted.

Somehow we need to preserve the richness of language that comes from passionate people following their whims and fancies, in this case people who love horses. [My thanks to Shaw-Web.net for the photograph, it’s just the kind of site that the web stands for.

Thanks to Hugh, Chris, Kathy and with a lot of help from Tim O’Reilly, my Faster Horses post seems to have engendered a number of interesting conversations, conversations I’ve learnt from. Snowballs, in Doc Searls and George Lakoff parlance, starting with a kernel somewhere, growing in size and gathering pace, finally landing up somewhere completely different from the origin.

The arguments I’ve seen have been truly fascinating; here’s my summary and response for now:

1. Customers should have a spectrum of choice. Customers can choose to let someone else choose for them, an outsourcing of choice, sometimes even an abdication of choice. But choice nevertheless. Similarly, customers can choose to have their choice restricted. But it’s still choice. As long as the customer is in control, the spectrum of choice can and should be vast. Reasons to restrict or outsource or abdicate choice tend to be about respect for human time: simplicity, convenience, ease of use. As one of the commenters said, some people really care about being able to choose their toothpaste; many would prefer choice in more profound decisions. Our challenge is to provide that spectrum of choice.

2. Customers should be able to look under the hood if they want to. Some customers want it all done for them. Some customers want to be able to do everything. Most customers are in between. We need to ensure that customers can choose their level of empowerment. They should be able to look under the hood if they want to; there should be tools for them to modify things should they want to. But only if they want to. Our challenge is to provide that spectrum of tools our customers want, safely and reliably.

3. It’s not just about what choices are offered, it’s about how those choices are offered. Customers need to be informed about their choices. At one extreme it’s about feature and price comparison of commodity. At the other extreme it’s about understanding the art of the possible. When we offer choice, we need to use modern tools to augment the information. Recommendations from their social network. Ratings from a wider population. Tags and folksonomies. Prediction markets. Access to collective and social intelligence about the products and services in general.

4. There is no law today that says the customer cannot be a disruptive innovator, a wild-eyed visionary. This is probably what I really wanted to say in my first post, and didn’t say well enough. Customers can be many things if they are allowed to. If they are given the voice, the choice and the appropriate tools. I am personally always sceptical about an artificial separation between the customer and the innovator. In an opensource world, quite often I don’t know the difference. I can cope with some distinction between the customer and the inventor, but even that makes me uncomfortable. When distinctions are drawn between customers and innovators, I am way way uncomfortable. There is no innovation without adoption. Customers can and do innovate; some customers even invent. We have to stop this holy-of-holies approach separating innovators and inventors from customers, particularly in the context of services.

Really that’s my main point. In the past it was difficult for the customer to have access to the right tools, the right environment, the right information and the right feedback loops to be a true innovator. Nowadays that no longer holds true. So we need to give our customers more choice and more voice, make more of them active innovators.

When we do this, we need to understand a few other things. One, the choices one customer outsources may not be the choices the next customer outsources. Different things matter to different people. Two, restricting choice on the grounds of risk-averse nanny-state safety in an increasingly litigious world is a Bad Thing. Human beings learn by taking risk, and we must never forget that.

I’ve always believed in the phrase “Talent is being able to build things that others can’t build. Genius is being able to build things that others can’t see.”

I’ve always believed in the value of people who can build things that others can’t see. What frustrates me is the tendency amongst so many of us to believe that customers can’t be geniuses.

Just ask them. Just ask the wild-eyed visionaries amongst them. At least try to ask them.They can and do exist, and it’s time we enfranchised them, gave them voice.

Whether it was Ford or the Wright Brothers or Edison, inventions and innovations often came as a result of considerable collaboration and teamwork; of course they were wild eyed visionaries, but, despite the wild eyes, there was a lot of collaboration, a lot of iterating, a lot of persistence, a lot of perseverance. Much of the literature I’ve read suggests that solo invention was very very rare and often misrepresented. That collaborators were often left out of the credits, that history has painted a false picture about the sheer process of invention and innovation.

We have an opportunity to bring customers into the innovation and invention processes. To really bring them in rather than just pretend to. That’s what co-creation is about.

And by the way, we don’t have to do anything about this. It’s happening. As “producers” we have choices as well. Be part of the new process. Or stop being.