Bottom up: knowing what you do

Raising a child has its problems. You can tell 42 times "don't run, you might fall", but actually having a little (innocent!) fall makes a more lasting impression. This doesn't mean that the parent is better off throwing the kid on the pavement. The parent tries to guide the child as good as it is able to, through the process of learning and experiencing. And this wisdom from someone who hasn't kids.

Links of Interest
Bottoms Up: Leadership Style For A Better World

Back to the kids in the organization. Starting the "new way of working" at the individual employee level raises the critique that the employees are too stupid to change. "They perform this job in this way for 30-years. These guys are too old to change." And more arguments like this one. Instructing employees to deliver you a process description that complies to a project-approach doesn't work. I agree. But a little guidance in the activity creates miracles.

The guidance should consist of answering the big 'why': why do we need a new process? Why should it look like this? You could provide everyone with this fabulous book. People should know why the game is played like this, that's the key to success.

To middle management who will get the role of customer 'visibility' should be the mantra. Schedules, budgets and results will be transparent. Issues will be made clear by the project manager, to avoid as much surprises as possible. That will probably sell itself. Some discipline from the customer is of course required. Ambitious goals with no budget and a very narrow timeframe will be killed from the start. The only thing made transparent is its impossibility. The visibility also makes it difficult to change your mind. Middle management can change their initial thoughts, but it's 100% clear minds are changed; it's impossible to claim you are saying the same thing as you always did. This can be a drawback for managers.

For technical employees, like programmers, the trick is to show them "better planning, is more relaxed". If for example programmers can provide the project manager with a perfect estimate on how long they need for a certain job, they can do their work in their own pace, without time schedules slipping and pressure building. Assuming the project manager doesn't slash every estimate by 50%. When this is clear, just show them the way to improve their ability to plan. Watts Humphrey [1995] has constructed a complete process for this. The essence is to let people record what they are doing, and how long it takes. They can see for themselves which tasks consume most time, so they can take action to improve them. It makes visible how long a certain tasks actually takes. When asked for an estimate they can make a more informed guess, based upon their records on previous tasks. "System X cost me 1 month. This one has a little more functionality, so I would estimate for this system 2 months."

So, filling in time sheets is the way to go? Not if you put it like that. Just read the previous paragraph again and compare it with using time sheets to control the programmers in a directive manner: "You are late! Why?", "This takes too long! Why?" You will be heading for a disaster.

Top down: best practices

Having all those individual employees improving themselves is not enough. First of all, from the top down incentives must be provided to keep the people going. It is after all extra workload, so someone should better appreciate it.

Finally, let someone in the organization collect all the lessons learned from the individuals, and summarize it as an integrated and coherent set of best practices. For this purpose, best practices are always better then a complete method, as the best practices are really invented here!