Project management at the borders - why milestones count

I was at the airport recently with a business partner. The check in girl was looking perplexed as she could not find my reservation. The problem was that my partner told me to buy a return flight and I did - in other word the flight back from Vienna, assuming he had bought the outbound flight. Sadly, his idea of a return flight meant both ways! I made the flight but it's a real example of what besets projects all the time.

I may know what I have to do. You may know your part. But actually do they meet up or do they overlap meaning we're all working too hard?

It's at the interfaces that things most commonly go wrong. For example, the spacecraft that crashed into Mars because one group worked in yards and another in metres. Their invidual parts were fine but they didn't fit together. It's the railroad tracks meeting in the middle of the US and finding they use different gauges for the track (a great cartoon not a fact). How do you stop this happening in projects.

Well there are a few things to remember. The main one is to always incorporate the 'voice of the customer.' This might be an external company, an internal function or simply a champion in management who wants this new 'thing.' In terms of agreeing the specificaton for the project and carrying out reviews, they are vital. If you can't identify a 'customer' then you are actually in some trouble. If no-one really cares then who is going to help you when you need extra resources, a favour, influence or whatever? The answer is probably no-one.

However, let's assume you have a customer who can review and agree the specification. You then need to have a sensible way of creating and agreeing milestones as these are the key. I'm not talking about putting a nice black diamond into MS Project to signify a milestone. I am talking about a definite state of achievement. A milestone should represent a point that the project has reached. To prevent misunderstanding that means a milestone should not be a verb.

For example, a milestone that says "write software for six weeks" is useless. Okay you do six weeks work but is it finished? Does it work? Is it bug free?

A proper milestone should be expressed as an achievement followed by an evidence statement.

The engine is assembled AND has passed test procedure A17

The molding machine is installed AND has produced 10,000 parts accepted under quality standard
G1

By creating milestones that show the achievement AND how you know when you are there, you can control different groups within the project so that it is clear what each will deliver. This makes it easier to then review for consistency because you know exactly how each will quantify success. If a group reaches milestone A then you know what will have been achieved. If you don't consider that's enough you need to change the acceptance criteria and add detail.

Okay so will this solve the problems I gave as examples above? The simple answer is not always, but it will reduce them down and eliminate some really daft misunderstandings.

The next step is to work out how you will actually test the overall performance (systems integration test) as opposed to each element (unit integration test). It's another story but by setting clear and unambiguous milestones you will be on your way.

I'm always happy to discuss and help with real project issues. Let me know if I can help.

Read more!