Lifecycle of a project: What's wrong with this picture?

This weekend, I attended a Design Hack session for CivicLab, a new effort in Chicago inspired by Milwaukee's Bucketworks.org; an institution that fosters member-driven civic and creative projects and activities.

There were several discussion groups taking up various themes. Since it seemed well correlated to what I do at work, I joined one about the lifecycle of activist projects and campaigns. Quite a few other software geeks took part, too.

The facilitator kicked things off by putting the following illustration on the board. Take a look, do you see anything wrong with this picture?

I quickly killed my good will with the facilitator by pointing out that Inception was a noun and Execute a verb. You don't execute at the end of a process, you execute all the way through a process. Someone else jumped in and observed that a lot of preparation has to happen before you can do an Inception. Another person wondered where Feasibility studies fit. And so on.

In the end it was a good discussion, enough for two or more blog posts but what I've been pondering all day is what kind of diagram would have said it better?  This is what I came up with:

Execution happens throughout a process. Throughout a process, research and investigation are happening to detect problems and opportunities. At any time, ideas may pop up, or you may set aside specific brainstorming sessions. Ideas, and problems and opportunities have to be prioritized. Problems and solutions have to be validated and evaluated - are they real problems? Will the solutions work? Will people adopt the solution as designed? Is it cost effective? Prototypes at varying levels of fidelity are in order throughout the process.

Feeding into all of this is an understanding of the context; the bigger environment of the problem and the people you want to assist: politics, money, geography, values, culture, etc.  Understanding the context and where you are in the process determines what tools will be useful in the execution of any phase.  

Throughtput: Changing the people

First, I just want to mention that I haven't posted anything for a month because I've been really distracted with my current assignment, which is three months in India (Bangalore) to be a trainer for ThoughtWorks University -- an intensive six week introduction to consulting and software development the TW way for entry-level new hires. I'll start blogging about that in my next post. But now, more about throughput:

In my previous post on this topic, I said that if you felt you weren't getting sufficient business value in each release, or it took too long between releases, then you had a process and/or people problem. I wrote that people problems required changing the people.

I want to clarify that. Superficially, it would seem that I am recommending getting rid of staff. That's one solution but not necessarily the right solution. Changing people may also mean making changes to people's job descriptions and assignments. Remix the people who make decisions about new features and enhancements. Add some new faces or switch/promote people into different roles.

It may also mean changing how you relate to your staff so that people understand you expect them to be creative and innovative about the software and the decision process. Let them know they'll score more points with you by taking chances, and you will support them, even when some of their ideas don't pan out as well as others.

Chapter 7 of Scott Berkun's new book, "The Myths of Innovation", does a very good job of explaining the tension between innovating and managing. On page 96, he writes: "... few managers recognize that their training and experience, designed to protect what exists, work against the forces needed for innovation ..."

On page 98, he quotes from Peter Drucker, "... management tends to believe that anything that has lasted for a fair amount of time must be normal and go on forever. Anything that contradicts what we have come to consider a law of nature is then rejected as unsound."

Finally, on page 100, Berkun writes, "... most management, most of the time, is sensibly directed at maintaining good business.... However, when managers raise the flag of innovation, the goals change, and the methods must follow. Many depend solely on Taylorism-inspired behavior .... as a rule ... they avoid all risks, never yield creative authority and operate with self-centric hierarchical control over the flow of ideas."

That's thing that has to change, the behavior, not necessarily the staff composition.

Throughput: How can I get more of it?

A while ago, a friend and I were comparing experiences on our projects. She talked a little about one of her key stakeholders and said, "He asked me how could he get more throughput out of his team. I didn't know exactly what to say."

Throughput, eh? The word calls to mind network traffic and bits and bytes of data streaming over cables or fiber optics. It's not too far of a jump to extrapolate that to manufacturing or industrial processes like gallons of oil pumped through pipelines or numbers of cargo containers moving through shipping terminals. You could imagine the term applied to fungible goods or relatively interchangeable units of stuff moving on assembly lines. But we were talking about software so what was interchangeable or fungible about that? Lines of code? Nope. Function points? Features? Well, maybe those things are countable. But to what end?

"So, what was he really thinking about?" I asked my friend. "Is he saying that it's taking too long to get a release delivered or is he saying that he's not seeing many significant changes in the releases?"

"Well, both," she said.

"Ahh. I see. What you have there is either a process problem or a people problem or both. And whichever it is, you have the wrong thing and probably too much of it."

If it takes too long between releases, you have a process problem and you probably have too much process -- too many steps, checkpoints, sign-offs, etc.

If you don't get much value out of a release, you have a people problem. The wrong people are making decisions or you are not talking to the right people to get ideas.

Change the process, change the people and throughput should improve.