Category Archives: Uncategorized

When is Elaborate Project Plannng Appropriate?

I got varying reactions on my last post. Some thought the story about making coffee using an extremely detailed plan was funny.  For example Fabio Akita wrote:

“Planning is the death of any project” http://bit.ly/bFYkAW Just an entertainment story, but fun nonetheless

I’m certainly proud to produce something that is considered fun. Yet my little story actually has some serious background. Of course the simple task of making coffee doesn’t justify elaborate project planning. But which task does? As we have seen, simple tasks don’t.

So how about complex tasks? Tasks that depend on circumstances in many ways, like e.g. balancing a stick on a finger, or playing table tennis. It would surely simplify the task, if we knew exactly when to make which movement. But we can’t plan this kind of thing, because the tiniest deviation from the intendend movement at some point in time will greatly change the required action some time later.

The coach teaching me project management had a great example of a project needing very accurate planning: When you build a nuclear reactor, the core will get encapsulated in a huge steel chamber. There are only very few cranes huge enough to move this thing. And they need a rail track to get to the building site, as well as a foundation for the crane to stand on. Rent of this crane is expensive as hell and you have to fix the dates years in advance. Everything that was needed for this crane and the needed structure, was planned with great care, to make sure everything was in place.

Few of us build nuclear reactors. For all others check these rules as a guide for the amount of planning justified:

  • How plannable is it anyway? Don’t try to plan the unplannable. Get it out of the way instead. This is what many agile approaches do, when they implement the most risky stuff first.
  • Do you have fixed dependencies between tasks? A plan becomes more helpfull, when you have many dependencies between tasks, possible with long ramp up or preperation time. As with the crane: The task of moving the steel shell wasn’t  very long, but the preperation had to start years ahead. Without a plan it gets easy to kill a deadline long before it comes into sight.
  • What is the damage done, when you don’t stick to the plan. In some projects, the only damage done is that somebody has to adjust all the plans. In that case, you might just as well scrap the plan.

You should Provide a Service, not a Defense

A row of cannon
Cannon

Let’s assume you are manager (or just part of) a small department. The task of the department is to make sure that everybody in the company is using Grglwup for wumpeling and does so in the correct way. What do you do to achieve that?

The approach I see most of the times lets me wonder, if companies are run by Vogons. It looks like this.

A document is written describing the process for wumpeling by use of Grglwup in great detail. It gets published on a newly created website, which nobody knows about.

A 23 step process is put up defining how to get Grglwup, how to get a license for it and who is allowed to use it. It describes the 5 forms 7 signatures and 3 trainings you need, but it lacks any reason, why it is a good idea to us Grglwup instead of Open G which you could download and use for free and which is so easy to use, that anybody will be done with the task of wumpeling within 5 minutes.

Of course nobody adheres to that process. So an evaluation if wumpeling is needed and a 5 day consulting with the fixed result of advising to use Grglwup are made a required and expensive part of every project.

That was easy right? Now nobody can do any wumpeling without Grglwup as desired. At a side effect your department grew by a factor of 5 in order to handle all the consulting. Oh, and the cost of every project increased by about 10.000Euro for the consulting and getting through the whole process. Therefore people will hate you and your department.

I propose a different approach.

Find out why Grglwup must be used. If it is a valid reason, make sure everybody at least in your department understands it. If there aren’t valid reasons, fight the requirement.

Everything else is about making work with Grglwup a pleasure:

Write easy to use and fun to read documentation for it. Prefer a wiki as a platform so everybody can improve on it.

Make sure that that page shows up whenever anybody is searching for Grglwup, wumpeling or Open G on your intranet.

Offer free training for use of Grglwup.

Make the question: “What else can we do to make working with Grglwup easier?” part of every contact with a user.

Make sure that you reply to those that answer the question. Actually reply twice: First to confirm that you received the answer and then when you actually provide something.

You probably would like to have a single way uses address your team with questions about Grglwup. Still you should accept any way of communication: e-Mail, fax, phone or whatever. Don’t make them use your preferred tool. Of course you are free to funnel communication inside your department into a single tool.

Make sure everybody who might need to do some wumpeling, knows about you and your department.

If you succeed in this, everybody use Grglwup because it is the easy, the obvious thing to do.

Of course all this will cost money, just as the first approach. But you can’t charge the users for that. They aren’t the ones that want to use Grglwup. The company wants. So the company should pay for it.

Careers for Developers

Many developers try to get into (project)management. That is ok I guess. But what bothers me is, that many developers do that without actually wanting to be managers. It’s just that they want to make some progress and the only career option available is to get into management and manage larger and larger teams, or leave the company to work somewhere else.

I can only speculate why this is so. Maybe managers can’t think of alternative career paths? Well, I think I can help with that. Here are a couple of things developers might consider a step up on the career ladder.

Trainer: Many of the better developers I know, love to teach their knowledge to others.

Mentor: While a trainer will do workshops, a mentor will work together with a single coworker, or a small group, to pass on his knowledge. It is a lot of work, a lot of responsibility but very satisfying when the student comes back to the mentor after sometimes with something like “I learned a lot in the time with you as my mentor.”

Firefighter: Send a fire fighter into projects which have problems. The firefighter moves in, puts out the fire and moves one to the next project/fire. It makes a job extremely interesting but also stressful.

Technical Teamlead / Software Designer / Architect: Whatever these people get called at your place, they have a larger than average saying on what tools, what technologies get used and how.

Researcher: The guy evaluating the new languages, the new tools before anybody else gets to use them.

Prophet: While the researcher evaluates what can be done today, the prophet tries to see in the future, evaluates all the hip stuff in order to separate the hype from the good stuff.

Don’t get me wrong, nobody should print business cards with these titles on. But managers should make sure the developers who should do these things know about it, get the appropriate resources. And they should make sure that these tasks a only put in the hand of the best people.