Project plans (part 2 of 3): Turn the question around

As my last post was a moan I promised to give some advice on how to go about project planning. There is a lot to this and I can’t possibly give all the details in a short blog so I’ve split this into three blog posts. Still there is a lot more I could say.

Turn the question around
Instead of a confrontational question and defensive answer have a rich discussion.

When someone asks “when will it be ready?” turn the question around - (1) When is “it” needed by?

When does your business need a product to use? What are the important dates for the company - end of quarter? end of year? trade show? competitors? contract signing?

I always prefer running a project were there are hard business driven milestones to make. Dates which mean something.

Next (2) What is needed on these dates?

Unfortunately too many conversations in the software business seem to involve someone saying “I need everything and I need it yesterday” - not a very useful position, and if its true you should start looking for a new job because there is no way anyone can make that happen.

Look at each of those date and define what is needed. What are the qualities of the thing that is needed? What is the minimum marketable product or feature for that date?

At this point you know: what is needed, how long you have, and who you have to do it.

Yes, I slipped that last one in because its true: you have the people you have and in the short run your resources are constrained because of Brook’s Law and because hiring people takes time.

So within these parameters the engineering team can now come up with options. How can this need be met within this time with these people? This activity separates the real engineers from the rest. Engineers create solutions within these parameters.

Wikipedia (today) says: “Engineers are concerned with developing economical and safe solutions to practical problems, by applying mathematics and scientific knowledge while considering technical constraints. As such, the work of engineers is the link between perceived needs of society and commercial applications.”

And if you cant? Then go back to the “customer” and discuss it. Find a smaller feature, extend the time (shoot for a different trade show), find an alternative way of delivering.

(Tom Gilb has some good examples of engineering solutions into tight constraints and his impact estimation tables can come in useful here.)

Vision
All work needs to be guided by a bigger vision. You can call it a vision or a goal if you wish I don’t mind. Personally I like the term BHAG - Big Hairy Audacious Goal. You’ve got to know where you are going to give context to everything else.

There are two ways to run a project. The first - exemplified by Gantt charts - is to get all the pieces of string you think need to do the project, lie them end-to-end and see where you get to. If you read my previous post you’ll see why I don’t like that approach.

The second way, I’ll call it the BHAG way, is what I discuss above. Decide where you want to be, when you want to be there, what is will look like and then find a way of getting there. How you get there is called engineering. It is what engineers do.

My favourite example of the BHAG way? The Digital OpenVMS team committed to a delivery schedule and said “We don’t know how to achieve this, but we commit to finding a way.”

• Project plans (part 1 of 3): Why I don't like Gantt charts
• Project plans (part 2 of 3): Turn the question around
• Project plans (part 3 of 3) - Planning cycles
• Run Scope Creep backwards