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.

Is that a project manager or a product manager you're after?

I typically do quite long stints with clients. This enables me to approach the market every 2-3 years with a clean pair of eyes and some ability to discern how it has (or has not changed).

And, I observe a dominant trend in the market for project managers. Something that while it may have been present previously, is now all but ubiquitous. 

Let me ask a couple of quick questions first - consider this a little warming up to the subject.

1. Which project management methodology requires the project manager to be a subject matter expert?
2. Which project management process requires the project manager to be a subject matter expert?
3. Which project management product requires the project manager to be a subject matter expert?
4. Which project management process, product or methodology requires the project manager to have implemented the same (or nearly the same) product before.
5. How many projects fail due to a lack of subject matter expertise on the part of the project manager?

(Please note - your project management subject matter expertise is a given)


And, the answer in all cases (as you almost certainly reasoned for yourself) is none of them. Even if you quibble the last one - it's almost a self-evident conclusion if you accept the other 4.

Now I do understand why project managers tend to operate in their chosed fields of (say) construction, accounting or (in my case) information technology. If you spend 90% of your time communicating, you can't spend 90% of the time deciphering what (for the uninitiated) is going to be opaque jargon.

But, that's not what I'm seeing. What I'm seeing is hiring managers who (for instance) are seeking a highly literate technical project manger, with (say) extensive CRM experience and (in particular) SalesForce.Com. But also (and these aren't necessarily nice to haves), Oracle, SQL, Agile, UML. Oh and not forgetting your extensive (for example) experience with off-shore oil and gas and the two CRM implementations you'll have already done.

Now a quick review of some of the chief culprits which cause projects to fail

1. Poor risk management
2. Poor stakeholder identification / engagement leading to omission of requirements
3. Estimating that corresponds in no way to what is achievable on the ground
4. Flawed business case
5. Poor scope control

So which of these are addressed by anything other than good project management practice? Yep - none of them.

So how did we get here? I can't say because I'm not a recruiter with my finger on the pulse of the concerns and imperatives of hiring managers, but I have my suspicions. 

1. Unprecedented levels of cynicism towards both project managers and the profession of project management
2. Organisations instinctively reaching for the comfort blanket of 'someone who's done it before'.

I'm somewhat fortunate in that my technical background allows me a certain discretion. But I know this. On any project where I'm forced to use my technical expertise, I'm not doing the job the client is paying me for. And worse still, neither is somebody else.

Quotation incrustation (and a little inoculation)

Francis Bacon said, 'There arises from a bad and unapt formation of words a wonderful obstruction of the mind'. And where better for a wonderful obstruction of the mind than the program kick-off meeting? A slide-deck which has been over worked, with pictures of sinking boats (that will never happen here of course), some incidental shots of a medal winning track team and maybe even the odd roaring lion. And of course the quotes. Where would the slide-ware of any self-respecting change practitioner be without some well chosen quotes from a few notable luminaries?

You know the sort of thing... "I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom" or "Success is not final, failure is not fatal: it is the courage to continue that counts".

But quotes are funny things. And, it was only when recently reading Daniel Kahneman's "Thinking, Fast and Slow" (which I can't recommend highly enough incidentally) that I realized just how potentially beguiling a quote can be.

Now even I am not going to try and distil Professor Kahneman's comprehensive insights within a paragraph or two of my blog but among the great swathes of wisdom provided, Professor Kahneman discusses something called the 'confirmation bias'. The tendency to search for, interpret, focus on and remember information in a way that confirms one's preconceptions.

So with that in mind and to underscore by point a little, I ask that you cast your eyes over the following, almost universally flawed, quote-ware; 

“Marriage is a bribe to make a housekeeper think she’s a householder” (Extraordinarily naughty)

“Better to be on the ground wishing you were in the air than in the air wishing you were on the ground” (Unhelpfully playing on latent fears about more or less anything)

“Hat’s divide generally into three classes: offensive hats, defensive hats, and shrapnel” (Smirk-worthy undoubtedly, but entirely content free)

“The only fetters binding the working class today are mock-Rolex watches” (Mildly offensive and with some obvious pandering to smouldering prejudices)

“It is queer how it is always one’s virtues and not one’s vices that precipitate one into disaster.” (Stealthily seductive and quite possibly dangerous!)

“The truth is that our race survived ignorance it is our scientific genius that will do us in” (Truth? Prove it!)

“Dreams come true; without that possibility, nature would not incite us to have them” (A bit of grandiose whimsy)

"A policitian’s words reveal less about what he thinks about his subject than what he thinks about his audience". (Rather insightful actually).

You might find that (in view of Professor Kahneman's run-away success) that your audience isn't quite as susceptible to an approach of "...here's a quote to back up what I'm telling you so it must be true...". You might also be less easily beguiled by a well chosen (if specious) quote should you be on the receiving end of it.

But, most importantly, you won't need roaring lions and Benjamin Franklin in your communications if you simply answer the questions; what's the point and why does it matter?

That's agile with a small 'a' for me please

Business agility is a good thing. But that's not Agile project management. Agile working is probably a good thing in most cases, but that isn't Agile project management either. An agile mindset is more or less obligatory for the jobbing project manager - but nor is that Agile project management.

Don't get me wrong, there's a lot to like about the Agile Manifesto and even more to like about the 12 principles which underpin it. (I must remember to say the words "...maximizing the amount of work not done is essential" in my next job interview). But neither of these things are (in themselves) project management.

I can understand the appeal of Agile to programme stakeholders. If you've adopted Prince 2, all your requests for change should technically be added to the issues log. This can sometimes lead to a distinct cooling of the relationship with the sponsor when (inevitably) it is their requests for change. And it's not just Prince 2, if you've adopted the PMI/PMP standard, then one of the sponsor's key roles is to defend the project from change.

Against this, Agile adopts the persuasive position of "Welcoming changing requirements, even late in development." And, show me the techie who wouldn't heartily endorse the value of "working software over comprehensive documentation".

But since there isn't actually any such thing as "Agile Project Management" per se but rather a collection of iterative approaches (namely; Scrum, Extreme programming, Agile Modeling, Unified Process, Agile Data, Kanban etc) what exactly were you after? Because if you don't know the answer to that question - I certainly don't. (It might be that by the time I've finished this post - there will be such a thing as Agile Project Management - its a fluid landscape...)

Is Agile something of an emerging 'norm' in software development (and selected other) projects? Undoubtedly. But I'm not even sure if that's the point. If you're a programme sponsor or budget holder attracted by Agile techniques and want to know what you are going to get and when you are going to get it, you might want to validate that Agile can answer these questions to your satisfaction.

But you've heard all sorts of good things about an iterative approach and you want one? Fine - adopt v-model development or incorporate specific iterative elements into your project methodology either by tailoring Prince 2 or adopt PMI / PMP which already has a healthy iterative element in its planning cycle.

Personally, when I hear the word Agile used on projects I'm usually on the immediate look out for either of the following potential issues;

• Is the project simply too big to satisfactorily drive out one set of objectives and requirements (in which case it should be split into multiple projects)
• Is your schedule so tight that to spend the time required on planning "is going to place the schedule into an unacceptable negative schedule variance".* (in which case you should hire in some lots of very smart planners, recognise you're running at high risk and adopt rolling wave project planning 

*Credit to Wikipedia for turning 1 syllable (late) into more!

It isn't my view that Agile 'anything' is necessarily the antidote to these two potential issues. 

The author is a business focused, benefits driven project manager with no formal qualification in Agile and no experience whatsoever in developing software. Other views undoubtedly exist.

Would you be comfortable with an independent audit of your CV?

1. Go for it - you'll be lucky to find a spelling mistake
2. I'm okay about this - there's supporting evidence for most of it
3. None of the above

Some people might regard me (and many of those who share my views) as somewhat idealistic, potentially a little naive or maybe just unhelpful. I don't.

I don't fib on my CV. Never have, never will - and there's plenty like me too. Other views do exist and they always will.

To some extent, some hiring managers can afford to be somewhat relaxed about this - they either outsource the effort to validate the CVs or structure the interview to mitigate the risk.

If that was really an optimum way to work however - they'd have been no horse meat scandal. We'd accept 'mis-labelling' as a cost of doing business and move on. But then the horse meat scandal had two victims - those who (like me) might have been partial to the odd 'Shergar pie' now and again and also the legitimate farmers and retailers who's margins were either driven down or eradicated by one product masquerading as another.

And so it is in the professional arena. We have hiring managers who are being misled (examples too numerous to quote) and job seeking professionals who are being squeezed by candidates with less professional integrity. And, when an individual is prepared to concede in the national press that not only have they lied on their CV but they'd to it again - that's a problem.

For the time-being though, all I can do is help my clients sift CVs and seek to validate in interview their content. This experience has acquainted me with business analysts who can't analyse and technical specialists who aren't special at all. Which is fine up to a point. I do however reflect lamentably on all the CVs which were passed over because they didn't measure up to someone else's masquerade.

PMs probably aren't normally distributed

I probably ought to start out by suggesting that the content below isn't supported by a shred of evidence. Now, unhindered by the need for proof, let's move along.

Let's create some arbitrary boundaries namely; does not meet requirements, meets requirements, exceeds requirements.

In the illustration below I've taken the (arbitrarily selected) profession of plumbing and assumed three equally sized buckets into which professional plumbers could be slotted in.

But wouldn't all professions be similarly distributed? No - take the example below

Here we've got a safety critical role. Constant audits, training and re-examination ensures a very different distribution. I might expect the profession of pilot to be an even more rarefied example.

So what next? I'm probably least able to speak to the profession of teaching. However, it's public sector - there's more support and management for staff yet reach the standard required. There's also less emphasis (and funding) to exceed requirements.

So what's a reasonable position to take for the profession of project management? Here's my 'gut feeling' on the distribution of project managers across the capability range.

So how did we get from our nice orderly world of plumbing to the highly eccentric world of project management? 

A brisk whisk of risk

I've been in around change for a while. If you're reading this, I hazard you may have been too. 

I'd like to ask three questions about risk.

1. How much value or benefit do your current risk management activities add to your project or programme?
2. How many of your programme's issues were initially identified in the risk log?
3. Have you ever worked on a change initiative particularly beset by adversity (our nice word vicissitudinous springs to mind)

I'm guessing that in at least some (if not in most or even all cases) the answers were somewhat in line with "no idea, none, and yes of course".

So, putting my imaginary project sponsor hat on "What the hell are you spending my money on?".