(no title)

Yes, yes, yes. I’m back. Yes, I’m annoyed. Yes, I’m tired. And no, I haven’t mellowed, so you’ll undoubtedly be pleased to learn that I’m about to have another rant.

One topic that’s quite close to my heart, but one I’ve kept clear of discussing is that of Project Management. Or mis-management; unless you’ve been in orbit around the second moon of Jupiter.

I first went to the Farnborough Airshow in 1988, and saw a wonderful pile of bolts called the EAP. It was the prototype of the Eurofighter Typhoon, and impressed us all with its ability to loop, roll and deafen anyone within 30 miles – qualities which I sure terrified the Russians…

So there we have it; a fully working aircraft on display to the public.

What’s to do? Well, quite a lot, apparently.

Ten years later, I found myself at a desk working on the flight controls for the same plane – an aircraft so unstable, it needs to be controlled by about a dozen Commodore Amigas… Which brings me neatly to the actual topic-in-hand – Project-Management. With a team running into thousands, across 4 countries, how can it be possible to take so long to produce a single fighter?

At the SAME company, I also worked on the Boeing 777 PFC – and yet that entered service within a couple of years from project launch to service.

Software design is a strange beast; an unholy-alliance of science and art, each resultant product is unique. I’ll accept that many products are derivatives of what went before, but each involves building the unknown.

Let’s take a moment to think about the term “Project Management”. The two words that can make or break an enterprise.

Consider it. There’s a task that needs to be done by a certain time. You have a set of resources. Let’s build a house. You’ve got some brickies, a chippie, a roofer, an electrician and a plasterer. Logic suggests you build the thing using the brickie and chippie. At the end, you tile the roof, run the cables through the place, then call in the plasterer the hide the mess. That’s fairly obvious, but what happens if snow falls? You have to delay the builders, the electricians get pushed out, and the plasterers are sitting around getting plastered. And that’s just scheduling individual tasks. If you have multiple houses at different stages of construction, you may be able to get the roofer involved on those units that are unaffected by the snow. And then you put them back on their first units, while you use the electricians and plasterers on the unit that has just been worked on.

What have we learnt? That resources should not be statically allocated, and you should be prepared to re-assign them due to external factors.

So, project-management is a damn sight more than putting dots on a Gantt chart and connecting the lines. I should at this point, admit that I’ve been forced into project planning – with the results you’d expect. I’d have been better off standing in for the principal-violinist for the London Symphony Orchestra, or maybe deputising for Wayne Rooney.

What a Project-Manager does NOT do is simply take estimates from their staff, and then punish them for failing to meet them – particularly if they’ve been advised of potential issues by those staff.

By now, you’re waiting for the punchline. Well, there isn’t one. But what I can do is to offer some observations about what a Project-Manager should do:

1) When you start a project, use the estimates from your staff as a “Dot-On-The-Chart” to give you a feel as to the confidence of your staff.

2) Use metrics. I know I’ve said each project is unique, but draw on your staffs’ expertise. If you’ve never attempted a particular product in your company, draw on the experience of those that have.

3) Be PROACTIVE – monitor the checkins. A large number of trivial checkins should indicate that a developer is under pressure, and feels a need to show progress.

4) CHANGE THE PLAN. I know this sounds simple, but you’d be amazed how few managers do it; The Plan is what MUST be met at any cost. Sadly, this is the trap that most managers fall into; you have a set of resources – shuffle them about. If someone has expertise in a particular area, then allocate them to the area of concern, even if temporarily.

5) It’s ironic that I’ve left this until almost last, as it’s probably the most important of all. Have something MEASURABLE! Its YOUR plan – you live and die by it, so support your people by making it known what they need to deliver. Simply saying “Add Power Reduction” is not enough. How much power reduction, how do you control it, what is the impact on other parts of the system? A comprehensive Requirements Specification will help you immensely.

6) Be aware of other parties. You may be managing a development team in one location, but if you are working in a multi-site environment, consider that other parties may have a vested-interest in your new feature; don’t inform them through the code changes – get them involved at the start.

And that’s it. Six, just SIX (6) simple rules for effective project management.

So, have I solved the “Software Crisis?” Well, no actually – because people seem to have an inability to do what they’re told. The above rules have been formulated over many years and at many companies, but all 6 rules apply to anyone developing a multi-party software product.