Project Momentum – Recovering from a Body Blow

The momentum of a software project varies. There are times when momentum is good; progress is being made, the team is optimistic, all features seem possible. At other times momentum is bad; a team member or two is pessimistic, every obstacle seems like a mountain, people begin to wonder why the project was ever started. In my experience a trigger can usually be identified; a trigger which shifted the tide one way or the other.

Sometimes momentum is real. Sometimes it is imagined. This is true for both good and bad momentum. A good project lead is a realist. They know when perception of momentum is temporarily distorted. Asking the right people, the right questions, even when the answers are known, can often improve the situation.

Occasionally project momentum takes a body blow. It might be a little thing like leaving work two days in a row with no solution to a seemingly trivial problem. It might be a big thing, like realizing that key assumptions affecting large swaths of architecture – were wrong. Whatever the cause; project momentum comes to a standstill.

What to do? No single answer will work in all cases but here are some things to try:

Talk about it; get the team together and bring the perceptions to the surface. Let everyone express some frustration and vent before taking on the difficult problem.

Get some help; bring people who are not working in the project into a meeting. Tell them about the problem. They may or may not be able to help – but talking through the problem with an outsider may force minds into different grooves; grooves where there is a solution.

Redirect to other work temporarily; you almost always have some other work that can be done. Redirect the team to this other work for a day or two, let them rack up some successes, then go back to the hard problems. Some problems that cannot be solved by a developer with low self confidence are a breeze following success in another arena.

Have a Google search fest where the team spends 15 minutes searching the web for help; ask each person to bring their top 3 links to a meeting. This is a variant on ‘get some help.’

It would be nice if some meter visible to the entire team could show a real indicator of project momentum. Dream on. Just be aware that there is such a thing as momentum, that triggers can cause it to reverse tide, and that action can sometimes fix it when it goes astray.

So you want to be a software developer?

You will write (or generate) large amounts of code that will have to be re-worked or completely re-written because design decisions and goals will change.

You will struggle with technically difficult challenges; sometimes for days.

You will face the question "when will it be done?" many times - and you won't know the answer.

There will be deadline pressures all year long, year after year.

There will be competition for your attention - pulling you from one project to another.

You will want to work on new things...but have to work on old things first.

You will have to find and fix errors months or even years after you or others originally create them.

New technology will come at you at a rapid pace - and you will have to struggle and learn about it on your own - for no extra pay. This will never stop while you are a developer.

You will search the internet relentlessly looking for solutions.

There will be days when you code non-stop all day long and still have lots left to do.

You will have to look at, understand, and fix other people's code.

You must be able to communicate with others about your code and their code.

You will have to make progress when given the most vague and ambiguous directions or specs.

You will read large volumes of coding related material to keep up with technology.

You will find yourself working with design or architecture decisions that you don't like or agree with.

You will not be able to give up when solving a difficult problem.

You will have to communicate with and support end users throughout your career.

Some work will be tedious, repetitive, boring, and make your wrists sore - but you'll have to do it.

You will have to communicate effectively through writing.

You should desire to always improve the quality of the code you write and the efficiency with which you go about the work.

But... it is a darn engaging way to make a living!