Tuesday, June 3, 2014

Top tip #3 - give network diagrams a chance

There's quite a treasure trove of project management tools which are left mouldering unloved and unused. Some deservedly so, but none less deservedly than the humble network diagram. Indulge me for a moment longer before you yawn and move elsewhere.

You may have discarded network diagrams for any of the following reasons;

  1. They're too big to manhandle even in software, let alone on paper
  2. The default formatting in Microsoft Project isn't particularly helpful
  3. You're fairly sure that they don't add any value and they certainly don't replace a detailed GANT chart
But what if, suddenly they were nice and small? Formatted usefully? And were shown to have some unique selling points? Bear with...

Now, what I'm not going to do is dwell on the nitty gritty of network diagramming, activity on node, precedence diagramming etc. Do by all means look into it if you're not already conversant - but you won't need to know the in and outs of it for the purposes of this post. MS Project does the work for you.

I don't feel the need to include any illustrations here but if I did there would be a project plan of (say) 100-200 lines and a network diagram which ran to several pages with nodes the size of pin heads. So, we now know what network diagramming isn't for.

But, let's say we are at the start of a project to, for instance, fit out and migrate existing services to a new data centre. In fact, it doesn't really matter what the project is, just think of something with a few multi-month phases.  For our purposes, we might have something like this.

Now - this is entirely 'high level' stuff. At this stage the durations barely qualify as estimates. The milestones should be accurate in terms of the broad headings to get the job done, but what comprises these activities is currently very vague. You'll be working with just enough subject matter expertise to understand what needs to be done and in what sequence.

We can drop that into MS Project quickly and then it looks like this.

So what? Okay - let's add in a few additional columns into the view - this isn't necessary but it'll start to put some meat on the bones.

The GANT chart is still there of course - I've just cropped it for clarity. Now you'll probably have used the term 'critical path' most days and you probably know clearly what it is. Namely, that if you're late with a task on the critical path you'll delay your project's completion date. And, for day to day use, that's a pretty good definition. But technically the definition of a task on the critical path is that it has zero float. If it is not done on precisely the days stated, there will be implications to the schedule. But what about anything not on the critical path? We can (by comparison) play fast and loose with these and derive all sorts of benefits.

And, where you're asking is the network diagramming in all this? Admittedly - there's a bit of fiddling with the formatting in MS Project but, it's not too difficult to end up with something that looks like the network below. The dates incidentally correspond to early start / early finish on the top row and late start, late finish on the bottom row on each node.

I've included a bigger image here. The pink items are (obviously) the critical path items.

So why bother doing all this? Well for starters it's much more manageable. It's a better starting point for all parties and in particular, the resource brokers, to start digesting what it is that is being asked for them, how long it could take and whether or not there's any float. Equally, it's much easier to integrate these sorts of network diagrams across multiple programmes and projects than it is link large multi-hundred line project plans. Equally, it gets some sort of plan out to stakeholders early and you know immediately where to start prioritising your energies. It's admittedly a bit of an extreme example, but the early and late start dates on some of the non-critical path activities above are in some cases over a year apart.

Yes, but aren't you still going to need your multi-hundred line project plans all levelled up with the identified resources defined in black and white? Yes, you are, but I'd much rather be deriving one smaller and more manageable project plan for each of the defined high level elements above than working with one monolithic project plan.