Three Big Ideas for Project Management

The dream will hate the reality

Dreams get their value from entirely different process than reality. Dreams are appreciated, and funded as projects because they are simple, ambitious or address our basest fears. Project dreams often use "all" language - "Same, complete, total, easy." Project dreams often use novelty langauge, "new", "digital", "different".

Dreams can fly. Reality has to put one foot in front of the other. In reality it really matters what's in the list of "everything that the old system did." In reality, just because something's new, doesn' mean that it's valuable.

Here's my revelation.

The process of implementing the reality will always be threatening to the dream - and the dreamers

This is absolutely going to be the case with any kind of iterative methodology, like Scrum. Scrum will throw up the problems with the "dream" of a project extremely fast. And many "throw up" is the right phrase. When Scrum encounters problems with the dream of a project early on, it's can be noisy, messy and involve an unpleasant smell. Scrum will do this particularly well if there's any kind of focus on working software.

Working software is magical and terrifying stuff. It's especially terrifying for whoever is associated with the dream of a project. Why?

If working software can't be made to work, it can show that there are fundamental technical aspects of the idea that just aren't feasible.

If working software works, it can reveal just how expensive it is to get a tiny bit of the dream working.

If working software can be put in the hands of potential users, those users might say that they don't like it.

But (here's the magic):

If working software is something that the users want, the whole dynamic of the project changes from delivering on a dream to satisfying a need.

Safety is an option - a disasterous one

People are good at looking after themselves. When the reality of implmenting a project starts to attack the project dream, the people associated with the dream will try to stop it. They will attack the professionalism of the team, they will threaten (or actually) throw people and companies off of a project. Sometimes they might just distance themselves from the project.

Of course, when this happens, the team will learn fast. They will learn "don't put your hand in that fire, it burns" fast. They will learn not to rock the boat, not to upset the people who are associated with the dream. Everybody involved will move to a position of safety, and the project will be almost guaranteed to be a disaster.

The challenge in most projects is to continue to attack the dream until something can be found that's valuable to users without causing those associated with the dream to either kick you out or run away themselves.

And here's my revelation, actually it's also an admission.

The kind of people who are good at seeing the problems in a project, probably aren't the best people to deliver the bad news

I'm pretty good at seeing the problems in projects. I'm pretty terrible at delivering this news in any palatable form. It needs really good diplomacy skills.

But it has to be done. The natural dynamic of a project will always be tending towards a "safe" conflict-averse agreed activty which I wrote about yesterday. So it's the unnatural job of someone be constantly opening the team to conflict.

Value Streams are for Car Factories - novel software projects need value EXPLORATION

Lean production has some interesting ideas. But people figured out that cars were a good idea and they wanted them a 100 years ago!

There's no point thinking about what we're doing as a value stream, where we go through a series of steps, each of which adds value. For most new software products, what we have is a value landscape. We have to explore and find out if there is anything in that space that's valuable to our users, but also profitable to our customers (it has to be both).

This is user research. What are the users pain points? How do they react to low fi prototypes? How do they react to working software? What's the value landscape other people and organisation that you're working for?

This is also customer research and exploration. What motivates the people that you're working for? What scares them, what pleases them, what annoys them.

This is my third and final revelation.

Research and exploration is the only thing that will get you there

You simply do not have a chance of delivering a successful project without a lot more user reseach and client research than you think you need. What makes this really hard is that exactly what this means will be different for every project. What makes this even harder is that this is almost certainly something that the client won't think the project needs.

This is what will make this easier: have someone on your team who's first instinct when they her any statement about the project is to try test it with users or customers. Have someone on your team who is alway doing more research with users and having more contact with customers than you are necessarily comfortable with.