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?".

Top tip #2 - Resource modelling in MS Project

One of the more important (and somewhat intractable) questions in project management is "How long could it take...?". Intractable because in the absence of a data driven answer, one or other existing 'compelling' dates is summoned out of air and a general preference articulated to complete the work in question by that date. Around 24 hours later (sometimes considerably less) that preference will assume the weight and authority of a board sponsored deadline.

If you're to dodge this bullet, there is a requirement for some preparation. First, you'll need to anticipate the question and the forum in which it will arise. Ideally, you control this. Next you'll want some sort of high level process or plan. The following is the sort of thing you should be able knock up in about 2 seconds and the only real requirement is for a fag packet to record it on. If you don't have the information needed to define the work to this level of detail - stay late until you do. I've included an optimistic forecast (in green), a pessimistic forecast (in red) and a median forecast in (orange).

Now in fairness, if you've got a requirement for a very large multi-hundred line project plan - that's not the sort of thing you can assemble in about the time it takes to drink a cup of tea. However, don't despair - you will nevertheless be able to apply the technique of resource modelling which I'll explain in a short-while. 

Where this technique really comes into its own is for activities which comprise a cyclical process which you'll negotiate dozens, hundred or even thousands of times. This could be migrating applications, migrating services between data centers or a large volume procurement type activity. Or anything for which there is a defined process. Typical project stuff, not quite all the same and not all different - but the sort of bread and butter activity that, as a professional change practitioner, you'll be comfortable with. And what you're really asking MS Project to do is use a set amount of resource optimally - something which would be extremely challenging to do via other means

Our process above has four steps roughly defined with some outline forecasting on work and duration. It translates to 4 lines in a project plan and it hopefully isn't to difficult to see how we got from the illustration above to the the outline plan below. I've set out the three different scenarios (optimistic, median and pessimistic) in green orange and red respectively.

I've made sure I've included both the work and the duration and you can see in the excerpt below I've assigned some resources (called optimistic, median and pessimistic).

Now, for reasons which are are better explained here you'll want to change the MS Project default from fixed units to fixed duration for this sort of modelling. But there is one little gotcha. When manipulating a project plan with the setting of 'fixed units', in theory MS Project shouldn't change the work or the duration when allocating resources. But actually - it does change the work on the first allocation of resources. When this happens you'll just want to pull it back to the original values. For the purpose of this activity - you'll only have to do this once for the 12 tasks shown below.

So - you might be thinking this seems like quite a bit of faff of no obvious gain. Bear with me and take a look at the next excerpt.

What I've done is created 10 process cycles under each forecast (optimistic, median and pessimistic). If I wanted to I could create 20 or 200 quite easily (and very quickly just cutting an pasting). MS Project very handily uses 'relative' (similar to Excel) predecessors and you don't need to jiggle these - it's cut and paste to your heart's content and in practical terms your limitation first and foremost is going to be your computer's capacity to level resources on project plans of many hundreds of lines .

Now, you have fair degree of flexibility in what you do next. You can plan for 2 resources or say 8 resources. (Just bump up the Max Units of the resource to 200% or 800% for instance). You can (if you must) put in constraints to that each process cycle must finish sequentially but as far as possible let MS Project do it's job of using the resources to the best possible degree. 

And, what I usually present to stakeholders is something that looks a bit like this. This is simply the timeline in MS Project with the appropriate summary tasks added to it. 

If I'm asked - I'll also supply the very first bit of network diagramming too. 

Note that one of the things I've done is tied in the time-lines with resourcing right from the get go. That's crucial as it starts to set in place the expectation (and dependency) that if I don't get the resources - I won't hit the dates.

What I'll do in a future post is put forward some fairly re-usable approaches using Excel and SharePoint for how you can prop up a workflow and have it generate rudimentary dashboards in real time to record and track the actual work being done.

Put project controls where you need them...

Although a quantitative kind of project manager generally, my default isn't to measure everything to oblivion and beyond. There's reasons for that of course but there's probably something to be said for '...if you can't measure it, you can't manage it...' and the less common supplement that '...if you can't manage it, you can't deliver it...'. But that's somewhat specious isn't it? Because it infers that measuring something is managing it. And managing it is delivering it. And, neither of these statements is true.

That all said - one of the first things I do on a new assignment is to check two things. The existence of Excel on my laptop and SharePoint on the network. Give me those two things and I can create custom lists and workflows which support well documented processes and dashboards in Excel which dynamically update and track the work minute by minute. People like that sort of thing - and I understand why.

Is this governance? Well, no - not by my yardstick. Is it control? Well maybe, maybe not. You might be either controlling what doesn't need doing or not doing all the things that need controlling. In practice you're probably doing both of those things to greater or lesser extent. Certainly more than you'd want do.

So what does the thinking PM do about this? We'll (of course) it depends on the size and shape of the red box in the below illustration.

So - with a little three dimensional visualization and we can see that we've got a relatively tight margin on cost but, a bit more leeway on time. Quality-wise - well that looks like we can just throw it over the fence and it'll be just fine.

You could quantify all this rather than just obsess over post graduate standard colouring in and this will probably bring some benefits.

But even more useful you could instate some fairly bespoked controls which would tightly control cost, control time satisfactorily and ensure that no more money was spent on quality control than was appropriate.

...but there's more.

If I were the big bad boss of change in an organisation, or the Chief Project Portfolio and Project Officer (C3PO) I'd set myself some loose objectives along the following lines.

1. Reduce the overall cost of project failure by failing less and failing quicker
2. Put in place KPIs / controls to support and track progress against the first objective
3. Develop quantitative approaches to inform project initiation and approval activities. i.e. stopping or changing potential candidates for failure before they start.
4. Reduce the amount of change incident on projects and, where inevitable, re-evaluate that project. We'll come back to this point much later on.

So how does our bit of three dimensional doodling above help with this? Let's take a moment to look a little closer.

There are the typical sam three variables which can be teased out and analysed.

Cost has a headline figure (well say £100) and we have some acceptable margin of variance (say £5).

Time-wise, it's a similar undertaking. We can say that we have a duration of 50 hours with an acceptable variance of 5 hours. It's not appropriate to overlook incorporating the level of effort in some shape or form - but I'm not going to worry to much about that just now.

Quality is just a little less straight-forward. And, I'd probably look to have some sort of qualitative assessment based on a scoring matrix. So we could have a range of (say) 1-5 to indicate a range of required quality from low to very high. There are undoubtedly numerous other approaches.

Sounding laborious and complicated? Not really.

We stick some numbers in a table that make sense. In point of fact your duration is more likely to be in weeks or months. And, your cost is likely to be in £000's. We can use some very straight-forward Excellery to create a very simple calculator. The specifics of which are very much down to you. It is the case however that as Duration, Cost and Quality figures goes up - so should your score and as the Variance goes up, your score should go down which is why there's a little fiddling about with the figures.

...but there's more.

The figures we could collate when reflected across historical information may yield up a threshold beyond which success becomes a very uncertain outcome. That's handy - because we could stop or re-configure those projects before they start - or at least make sure that they sit under the stewardship of the A-team, not (for instance) the B-team. Which bring us to an interesting point - the controls and scope of ambition ascribed to any project should clearly relate to the trust and experience of the project team.

Remember point 4 above which we'd said we'd come back to? If you move the goal-posts within a given project, all of the good work above will be for naught. The controls you had may not be the controls you need and you may suddenly find yourself sitting on a programme that far exceeds your appetite for risk. So, how can we defend against this?

Well, one way is to use the existing analysis above. You can see my use of the adjective 'moderate' and by inference there are other adjectives - maybe 'low', 'high', and 'abandon hope'. So, for me, I'd create a wrapper around the existing quality, cost and time constraints which constrain the project to remain within set boundaries. If you start out as a 'moderate' project, you finish as a moderate project. If this changes - you need to come back to project assurance to make sure you're still operating within acceptable boundaries. 

Because we've gone to the trouble of quantifying things - we're not limited to gut feelings in a project board meeting. We categorically know that if we have change (up or down incidentally) that is in excess of predetermined boundaries  - we must seek leave to proceed. This has the advantage that it will probably reduce project change. And very lastly, I think with a bit of work this could quite easily be incorporated in your organisation's default MS Project template - so once a project was baselined, it would immediately alert project planners if you breached the allowable boundaries.

On making up words and other PM proclivities

When I hear Sir David Higgins speak, I prick up my ears, gag my son and turn up the radio. As a result, I'm an HS2 believer where before I was a naysayer. I also think his option to use the word use of the word 'deliverability' in a recent interview was, if not revolutionary, a useful addition to the PM's lexicon.


This is, in my opinion, an acceptable bit of etymological license. It's got its feet on the ground, it's readily intelligible and hasn't been "Brittassed" or "Brented" to death. More likely to ingratiate than alienate.


Synergy, synergise, synergistic, synergies on the other had are the worst sort of PM excreta.


While the word synergy is a word, the other variations are not. Yes, yes neither (technically) is deliverability but who cares? You mention deliverability - you might put the ball in the back of the net. You say synergistic - you're more likely to lose the locker room.


Which is a bit of a shame, because hidden behind the grotesquerie is reasonable ambition which might even help with deliverability. So, I have set myself the task of finding a suitable substitute.  My principal source of reference was of course the work of Mssrs. Noblet and Yabsley


I can assure you, there will be no need for the stated 10-15 scalpel or razor blades, the biohazard or heavy duty plastic bag for animal carcasses or even (heaven forefend) a fistulated cow (I kid you not). However (and now is the time to pin back your lugs) Mssrs. Noblet and Yabsley's paper "The Good and the Bad: Symbiotic Organisms From Selected Hosts" does summarise nicely the following types of naturally occurring symbiotic relationship.

• Mutualism - a symbiotic relationship in which both host and symbiote benefit.
• Commensalism occurs when one organism (commensal) receives benefit from from the association, while the other (host) is not affected (neither benefited nor harmed)
• Parasitism - when one organism (parasite) receives benefit at the expense of the other(host).

Oddly there is a relationship in project management that is distinct and not found in nature called a commercial dispute in which neither party benefit and both suffer expense. Sometimes that's called egotism.

Good things come in threes...

There are certain topics that I've historically given a wide berth to. Project governance is one of them. It's too easy a target, too contentious and every one has an opinion on the matter. Here's mine.

One of the things that's constrained having any sort of consistent dialogue / vehicle / entry point (delete as appropriate) via which governance is (or ever could be) dealt with in projects (and programmes) is the lack of a unified consensus.

Well, you ask, what does that mean? Good question. If you asked 10 project managers what do they understand to be implicit in the term project governance you will (I hazard) elicit a variance in the responses that is extremely difficult to unify. You could even swim into less certain waters still by asking "What are the hallmarks of a well governed project by comparison to a poorly governed project". Could anyone be confident of any kind of spontaneous consensus?

The splenetic Steve Jenner (who will I hope overlook any referencing of his words in deference to my describing him as splenetic) offered that "...governance is the job of defining what decisions are made, by whom, when and to what criteria...". I remember feeling a sense of overwhelming gratitude to Steve for having (I felt) pinned the tail onto the donkey quite so precisely, succinctly and without apparent contentiousness.

But then, you've also got corporate governance, IT governance, data governance and quite a bit more besides.

...and that's just the different areas of governance. There are different approaches to governance such as collaborative or multi-stakeholder. And then of course there's applying both the required area of governance (say Project Governance) to (say) an IT Project in (for instance) a multi-organisational project. Oh, and just in case that wasn't enough - how about meta-governance - the governing of governance. (I do yearn for a bit of this now and again mind you).

Incidentally - just in case you were about to yawn and look for your entertainment elsewhere since this wasn't a terribly interesting topic, consider for a minute a project in which the wrong decisions are made, by the wrong people, at the wrong time and to the wrong criteria. Does this sound a bit more engaging now?

Like any project manager faced with unmanageable levels of complexity I revert to the mental state of a 3 year old, effect a brief but meaningful inner tantrum and cling to the mantra - surely there is a simple way of ensuring that tomorrow is better than today.

...and of course, there is.

Simple step one to improving governance today

Documented process is an enabler (dependency?) for improving governance. So, in the very simple situation below we have an input, a decision and two possible outcomes. We have a decision point, some inputs (criteria) and presumably a forum or framework in which that decision will be made. Sounds a bit like we're half-way to something Steve Jenner might just suffer to include under the heading of governance.

Simple step two to improving governance today

Create a register of all the formal documentation to be produced during the course of your project / programme. Include information about who is going to produce it, who is going to review it, who is going to sign if off and who is going to own it going forward. And, any schedule information for when this documentation will be created. Publish this register to appropriate stakeholders (and in many instances this will simply be all of them).

This resource, at a glance, allows a range of stakeholders to discern what documentation is to be produced (and what documentation isn't), by whom, when and who is (and isn't) involved in review and sign-off.

Simple step three to improving governance today

Create and publish a product breakdown structure (PBS). Derive from this appropriately detailed product descriptions and keep these someplace useful (say a product dictionary - a.k.a. an Excel worksheet. This is very much the same carry on for step two (which applies specifically to documentation) but in this case we're looking at specific project deliverables (which may or may not be documents).

This resource, at a glance, allows a range of stakeholders to discern what products are to be produced (and what products aren't), by whom, when and who is (and isn't) involved in review and sign-off.

And that will do won't it? No expensive management consultants. No particular undue stresses and strains. Not even a requirement for the oversight of assurance satsumas mandarins - just a bit of practical elbow grease.





Problems with unrealistic objectives

A while back I wrote a post entitled "Fail less with project management" I remain broadly happy with the sentiments I expressed. Perhaps the most succinct summary I can relay is via the metaphor of an aircraft flight in which a plane, encountering stronger headwinds than expected, will burn a bit more fuel and take a bit more time. It will however ultimately touchdown safely at its intended destination. A success in aviation terms. Not quite such a clear cut case in project delivery terms.

I only found out recently that the Association for Project Management has a vision of "...a world in which all projects succeed".

Does this mean that collectively we cease to embark upon projects that are deemed risky? Does this mean that project managers who do not succeed in delivering projects have failed?

And now for a bit of multi-choice.

There is often a tension between two competing imperatives for the project manager. The delivery of a successful project and the successful delivery of the client's strategy. As an experienced and seasoned project manager is it your job to;

1. Deliver a successful project whether or not it is the strategy of your client
2. Deliver the strategy of your client whether or not it results in project success
3. Neither option

For me and my blog, the answer is option 2. In a client facing scenario, what I'm actually going to say is that as a professional change practitioner my job (and that of the team) is to reduce risk, add value and accelerate delivery. 

For those of you who went  for option 1 - best of luck - I recommend you keep the phone number of your professional indemnity provider handy.

For those of you who went for option 3 - with some sort of managed approach to influencing the sponsor away from his or her chosen strategy (assuming you have good reason for doing so) I would offer the following. First, the most effective way to do this may well be to fail quickly and conspicuously in any attempt to deliver it. Secondly and more importantly, as an "experienced and seasoned project manager" that isn't your job. Is it? (If you can't live with this, fear not. A successful career in project assurance may be beckoning).

But I said 'problems' with unrealistic objectives. Not 'problem'. Personally (though it may yet limit my career) I don't have any problems in telling the client that we've burnt a bit more fuel and we're going to take a bit more time because the headwinds we encountered were a little greater than we forecast 6 (12, 18, 24+?) months ago. One of the reasons I don't mind is that my job is to add value, reduce risk and accelerate delivery first and to deliver successful projects second.

If you don't adopt this sort of credo, you might find yourself overusing words like "contextualised success", "positioning" or possibly even "the war situation has developed not necessarily to Japan’s advantage".
 
So, if your client has opted for an approach to change that you're not altogether convinced about, I'd recommend helping the client develop the necessary information assets as quickly and cheaply as possible so that you can back-up, rethink, re-plan and take a second swing at it.

Other views undoubtedly exist.

This is not a post about critical chain project management

Ever had an itch you can't scratch? I don't have one of those.

What I do have is a lingering doubt. A sense that something or someone could answer a lot of questions if I just knew the right questions to ask and the right forum in which to ask them.

Some of these doubts and uncertainties have been discussed previously in this blog. But for clarity I'm going to cite the half dozen things that (I think) are just not good enough in project management right now.

1. Planning. Consistently falls short of what is required. Work is not identified, not adequately defined, not forecast accurately and doesn't have the corresponding supporting information to enable the brokering of appropriate resources. Successors and predecessors aren't pinned down accurately, F-S, F-F, S-F relationships aren't identified with the precision required
2. Resource brokering. If (as is the case within technology infrastructure projects) your project's delivery is dependent on skilled and scarce human resources  then resource brokering should be fit for purpose. Hands up all those people who work on projects with great resource brokering.
3. Success. Don't get me started (mainly because there's an angry man here who already has)
4. Perception. Does anyone out there hold projects, project teams, project managers in high esteem?
5. Benefits / return on investment. Goodness me but there are far to many people charging out for delivering change when surely the game should be delivering benefits.
6. Profits. Executing change effectively and efficiently will enable you to deliver your strategy with less risk and more value than your competitors. It follows that your costs will be lest, your agility greater and your profits will reflect this. 

Notwithstanding all this, there's Prince 2 and PMP accreditations, quite a bit of software intended to solve some of the knottier project management headaches, a recognition that practitioners of change are specialists and even that some expenditure on those specialists is a worthwhile investment. And, health checks, specialist consultancies, more historical data than you can shake a stick at, more than one MSc and a partridge in a pear tree. 

Perhaps most importantly (and I can speak a bit from experience here) there's quite a few bright folks in the industry and there is no limit to their determination and tenacity in trying to bring projects in on time (whatever on time means - 'cos I'm starting to get a bit jaded around that - but more on the "Aggressive but Possible" (ABM) vs. "Highly Probable" (HP) paradox another time. Discussions of 'on-time' aside, there's still the questions of scope, quality, benefits and cost.

Could it be there's something fundamentally wrong with the underlying mechanisms of project management or their application? I could go the route here of an extended negative hypothesis routine in which we discounted one by one all the other candidate explanations. I'm reasonably certain that a blog post is neither the time or the place. So let's cut to the main course.

Planning assumption #1 then; there's something wrong with project management approaches / mechanisms. Or at the very least something wrong with the way they're applied. 

If this planning assumption is born out (and there's quite a weight of evidence to suggest that it might be) then ideally we'd need something waiting in the wings as a substitute. While the current status quo is (ripe?) for improvement, it wouldn't be impossible to make it worse.

And that substitute just might be Critical Chain Project Management. I'm not going to tell you what I think. There would be an implication perhaps that you too should be thinking that. I think we all need to come to our own independent conclusions about Critical Chain Project Management but I will post on it again in the future and if it elicits only critical scrutiny of existing methods and approaches then that alone will be a worthy objective.

A cow, an Alderney and a raging bull...

Apologies for the gratuitous blog title. Google's decision to withdraw their excellent Reader tool has quite scythed my readership statistics with a corresponding impact to my moral.

I'm minded to start up such cheap tactics as including the names of minor celebrities such as Paris Hilton and Miley Cyrus simply to catch some incidental drive by traffic.

As a jobbing project manager, one of course does get a reasonable level of exposure to the catalogue of general (and often dubious) apocrypha that accompanies the day to day cut and thrust of managing change.

An example of such apocrypha would be "...all projects succeed and all projects fail. Just to varying degrees of both..." which is possibly a little trite, but I quite like it all the same.

One such example which I don't like is "...you pay a project manager to worry so you don't have to...". I've never liked this terribly much because in theory a very talented worrier is suddenly a sought after commodity and I'm not one of those.

And then there's this little gem "...you pay a project manager to communicate..". Simple, undisputed fact. I like it.

Perhaps because I'm a little left of centre about these things, I've always thought that Alex Alexander Milne's "The King's Breakfast" contains many allegories useful for the project manager. There's some stakeholder management, some requirements management, setting of expectations and supplier management all in a few simple lines intended to amuse children. There's even some remarkable insights into value management. (Okay - that last one is a bit of stretch

So perhaps now is an opportune time to elaborate a little on the title of this post. One of the challenges faced by the PM is summoning the language, the agility, wit, poise and timing to communicate effectively. Don't get me wrong, the PM isn't unique in having these challenges but the PM is certainly likely to be in the room when;

1. The sponsor asks for dairy products from the cow;
2. The supplier questions whether it is an Alderney or a Friesian from which the afore mentioned dairy products should be derived and;
3. The site foreman explains that no amount of coaxing is going to persuade an angry bull to give up a pint of the white stuff.

Yes, yes - I know, all part of the usual carry on a project management. But for our purposes here, we're talking about milk, Friesian's and bulls. And, you won't be. You'll be talking about change and, likely as not changes to an existing landscape many years in the making. You won't be talking to the king, the queen and the dairymaid, you'll be talking to real people with real skin in the game each of which is likely to have different needs and agendas, some of which will undoubtedly conflict. The information they want will be put to different purposes and will need to be presented in a range of different formats and mediums. Sometimes it's a one off and sometimes it'll be a repeating and up-to-date feed potentially updated in real time.

If this isn't delivered or can't be delivered it's likely to be the PM's phone that starts ringing.

So what useful steps can taken up front to guard against the prospect that either you can't or don't communicate as required. And, to understand the expectations and, where necessary to inform them.

1. Process and procedure. I'm not going to labour this one, I hope rather that it is self-evident. If you don't have process and procedures, make sure you can report on whatever alternative is in place. And by the way, I'm not altogether sure what that alternative is Semantics aside, there's usually a way to navigate around aspects of work that are inherently not susceptible to process. Wrap process and reporting around them and 'go up the stack' to ensure that the entry and exit points are understood within an overarching 'flow of process'. Acknowledge that there may be elements of the overall flow of process which are able to be more accurately and more precisely reported upon than others.
2. Validation and verification. Make sure you're doing the right thing. And make sure that thing is done right.
3. Nomenclature and language. Make sure that you're all singing from the same hymn sheet. Make sure your inputs are capable of supporting the required reporting outputs. Do not make assumptions that the data will just join up. Define it to the required level of detail and perform the requisite static testing and prototyping to ensure that it all stacks up.
4. Create standards, generate and publish a configuration management policy which is aligned and supports your overall reporting aims.
5. And perhaps most importantly make sure you, as PM ,are in the room to inform the discussions to make sure these steps are taken and that the necessary resources are allocated to the tasks.

 So, as it turns out, the phrase  "...you pay a project manager to worry so you don't have to..." might not be so much dubious apocrypha but rather something to say three times a day before you go to work to ensure that not for one minute do you ever forget it.

People are objects with attributes too.

Statements like "...soft skills are an essential and often overlooked aspect of project management..." and "...the importance of getting the right people for your project team cannot be understated..." are the sorts of thing that make me want to swear off the canon of generalist project management literature for good.

Not, you understand, because it's not true. But, because it's self evident and this sort of nonsense makes the job of project management look like the job of professionalising common sense.

I was addressed by a senior member of public sector management some years ago who offered (and I paraphrase here) that "... in the 1990's we hired people for their skills, in the 2000's we hired people for their knowledge and in the 2010's we'll hire people for their behaviour." I hope this worked out okay for those people adopting such an approach.

Quite how you hire someone (or even assess someone in interview objectively) on the basis their behaviour I'm unsure. For all I know, it might not even be lawful.

I do remember thinking at the time that I would continue to hire people on the basis of their talents, track record and ability. I offer it's served me satisfactorily in almost all instances. And, as often as not, supremely well.

Whatever organisational hiring framework you're faced with (challenged by...?), you can adopt and overlay the following approach to determine what you need and help you go and get it.

Someone may offer something supplemental to this appraisal but for the purposes of employment I seek to assess initially what I need someone to know, what I need someone to do and what I need someone to be. Hence the term, "know, do, be framework".

For, let us say, a prospective defect co-ordinator we might define the following know do be framework. I've made the file accessible here if anyone's interested.

So we've taken something somewhat nebulous and intangible, put some structure around it and quantified it. This is I hope well understood to be my general preference for most things. I don't know about you, but I'm already feeling a lot happier about my ability to define and articulate what it is I want.

If you're lucky, you'll be solely responsible for the hiring and you can now formulate some interview questions (or other assessment) via which you can assess a candidates alignment with the know, do, be framework.

Even if you're simply a passive invitee to an interview you can assess a candidate's suitability against your identified criteria and express your preferences accordingly. 

One other point worth noting. You can reverse engineer most job descriptions with this approach. Pick out the key requirements and define some key points in line with what you know, what you are, and what you do that support those requirements. This can be very helpful if you're filling an application form (who still uses those?) but can perhaps more usefully equip you with some very strong responses to likely interview questions.

Top tip #1 - Milestones, baselines and tracking in MS Project

A bit of a departure from the norm today. No far-reaching debates on the state of the nation - just neat way of creating a baseline and tracking and reporting milestones in MS Project.

Take the example below (Figure 1). We can save a lengthy discussion about Duration and Work for another time.

Figure 1

You'll see a very brief example project plan with some milestones, tasks and all the usual carry on.

It's not everyday that you get to play spot the difference on this blog but have a look at the illustration below (Figure 2). What's the difference? And, does it matter?

Figure 2

How about Figure 3 then?

Figure 3

Last one then. Have a look at the excerpt below. It's actually the same as Figure 3 - but just formatted a bit differently.

Figure 4

For the eagle eyed amongst you this was all about Tasks x & y and amending the duration. When Task y was adjusted in Figure 2 - the milestone Task z didn't get pushed out. But when Task x was extended in Figure 3 - it forced the milestone Task z to get pushed out a day.

This is hard enough to spot and track on this simple example. At the 50 to 100 row level its next to impossible (yes - I know Project helps with highlighting tasks which change but that's not a panacea for us here. Particularly when plans are being shared and updated by multiple parties).

What is shown in Figure 4 however is a tiny bit of formatting on a baselined project plan and it is immediately apparent that the milestone has moved. I think this is very very helpful. It helps you (the project planner or project manager) while tinkering with your project plan to see what you have manipulated and which milestones move and by how much. It's also extremely helpful in tracking a milestone summary derived from several plans - but we'll come to that another day.

For now a quick explanation on how this is done.

1. Baseline your project plan. In Microsoft Project 2010, select Set Baseline from the Project group on the ribbon.
2. Select (say) Baseline1 from the drop down (you can use the default)
3. Click OK
4. Select Format | Bar styles from the Format group on the ribbon
5. In the name column, find Milestone and change the colour to Red (for instance)
6. Select Insert Row, enter Baseline1 in the name column, format your the appearance as a black milestone, enter Milestone in the Show for tasks column and select "Baseline1 finish" for both the From and To fields.

The output should end up looking like Figure 5 below. Click Okay to apply the changes.

Adjust your project plan to push out a milestone and you will see both the original baseline milestone and the new milestone date.

Very handy.