Monday, December 31, 2012

Management, governance and a partridge in a pear tree

I do read quite a few other blogs and there must be something about the year end that elicits a desire in bloggers to report on what they did well during the past year, what they won't do in  the next year, emerging trends and must haves for the ensuing 12 months. You get the picture. I'm not so sure I have much to add to the existing canon but it has spurred me to be just a shade more speculative that is the norm.

I include some points below which might be worthy of a moment's consideration in terms of positive change to the overall landscape of project management


  1. Project Complexity Modelling. For clarity, this is an approach to modelling how complex a project is and there is some coverage of this topic in the (former) OGC's Portfolio, Programme and Project Offices – P3O literature here. However, it's subjective, qualitative and not (in my experience) used. I'd like to see something quantitative, something that was capable of analysing a network diagram and, ideally something that allowed you to manipulate a project's plan or scope to influence (reduce) any given project's complexity.
  2. Getting change practitioners a seat on the board. CEO, COO, CFO, CIO, C3PO? (you heard it hear first). My view is that a business's ability to undertake change effectively and efficiently leads to a significant overall competitive advantage. Supplement this with 'poor governance' being an oft cited cause of project failure and isn't it time the business of change took its seat at the top table?
  3. Configuration management (bit of a misnomer this one). I like to think of myself as a generalist PM, an aspiring 'project manager's project manager' if you will. I do acknowledge however that a lot of my thinking comes from 15 or so years working in assorted I.T. environments. In any I.T. environment, configuration management (the management of your configured items) is a cornerstone of a well managed I.T. estate. Get this right and you have the opportunity to get most other elements right too. Get this wrong, and this opportunity will elude you. In very succinct summary, the CMDB (configuration management database) should in most cases facilitate an answer to the question "what should I worry about if I change this specific item". It provides a map (of varying quality and granularity) of what is joined up to what. There probably is something similar in the world of project management - the portfolio view, the PMO, the integrated programme and project management tool-sets - call them what you will. There's never been one when I've needed it.
And I think three things will do nicely. Three's a good number in management - military organisations the world over have known this for quite a while hence, there are three sections in a troop, three troops in a company, three companies (or thereabouts) in battalion an so on.

And that's not a bad hopping off point for the next point. Ask five people in a room what management is and you'll get six different answers. I always come back to the point that if something isn't being planned, controlled and directed, then it isn't managed. And furthermore, that things that are managed are predictable, sustainable and controllable. I think most of this relates pretty well to points 1 to 3 above.

(Incidentally, if you ask five people in a room what governance is, you'll get 3 answers, 2 questions and a partridge in a pear tree - but that's a topic for another day).

So after all I might have something to add to the overall cannon of project management rhetorical introspection. A bit more management in 2013 would just do nicely.


Wednesday, December 26, 2012

Forecasting part deux

Vicissitudinous. Now that isn't a word you'll hear everyday, let alone everyday in the field of project management. But is should be and if it wasn't such a challenge in terms of spelling and pronunciation, my feeling is that it would be a good deal more used than it is. In short - prone to adverse change.


As is my habit, in my last post I talked at some length about the shortcomings of the Pert weighted average. I'll try and suggest one or two improvements.

First however, a simple suggestion that quite apart from any estimating technique will help immediately with the accuracy of your plans and the forecasting effort.


Keep your tasks short in duration / work - never longer than week, ideally to a maximum of 2-3 days. Decompose your tasks to a level that can be undertaken by one person.


Sounds obvious doesn't it? I have however lost count of the number of project plans in which a few vague words (usually something like "Re-provision host environments" or some such hides 300 man days of work and a 60 day duration. And when, as surely you must, you enquire as to the specifics of the host environments and quite what their 're-provisioning' entails you'll often be greeted by a wall of jargon or a dismissive wave of the hand which suggests if you don't know already, you shouldn't be asking. 

Keep digging. How long does it take to change a tyre? Actually, I'm not certain - but I know the following questions are easier to answer.


  1. How long does it take to remove the spare from the boot?
  2. How long does it take to jack up the car?
  3. How long does it take to unscrew the wheel nuts?
  4. How long does it take to find the locking wheel nut adapter? Ah-ha - you say you don't know where the locking wheel nut adapter is? Well, that's very interesting isn't it...
So you get the picture, decomposing the task through what is sometimes call 'progressive elaboration' is time well spent. Estimating shorter smaller tasks is easier and it tends to throw out details that might otherwise get overlooked.

I don't think I want to get too side-tracked here but I will take the opportunity to address a concern. The drive towards productivity very often means that planning phases are curtailed both in terms of duration and the degree of rigour that is sponsored / supported. Equally, there's often the (somewhat incredible) imperative to spend money quickly (usually this is about allocated budgets and financial drivers). In short, the PM is busy trying to create product breakdown structures, product descriptions and plans that actually reflect the work to be done, and the project sponsor / board is saying - get on with it. Remarkable.

I'll spend some time on how to address this particular concern at a later date, but right now (for all you project sponsors who don't support detailed and structured planning) I offer the following. For your project to be any kind of success you will need to address the following.

  1. You will need to identify all requirements
  2. You will need to elaborate the work to deliver the requirements
  3. You will need to identify and broker the resources to do the work
  4. You will need to do the work to deliver the requirements
  5. You will need to undertake such quality assurance work as is necessary to find defects in products being delivered.
  6. You will need to fix any defects you find.
  7. You will need to pay for items 1 - 6 above
Accepting (as I hope you will) that 1 - 7 are somewhat inevitable, you can do all that at the end of a project if you so choose. It's a darn site more expensive that way and tends to get up the noses of your stakeholders something rotten. Okedoke - I concede that I've wandered a little off my intended track here - but surely worth it for the word vicissitudinous alone!






Sunday, December 16, 2012

Less poor forecasting (the first in a poorly planned and shambolic series of posts on forecasting)

Surely it can't just be me who thinks that estimating with the PERT weighted average is awful?

You know what I'm talking about (1 x the worst) + (1 x the best) + (4 x the most likely) all over 6. I guess that not any people can think it's that great, because I've never encountered anyone using it.

What then is the problem? Well first, what is the level of confidence in the output? Dunno. And I mean, really, you don't know. The principal problem is you don't know where the input figures came from. Likely as not, a bit of a stab in the dark in a workshop. At best, it will be sourced from experienced team members who have done something very much like the work before. This doesn't guarantee much as we shall see, but it's an improvement. Oh and the best bit, you're just as likely to corrupt a good figure as average out a bad one.

So what's wrong with a stab in dark? It has its place surely? We can refine things as we go can't we?

Let me cite two quick examples.

I'm working with a colleague over the phone - he's got the job of assembling a project plan. He's asking me about specific aspects of my work and putting 'durations' next to the work. We talk about a particular task and he offers that 2 days seems reasonable. I counter with 1 hour. Quite correctly he challenges this disparity. I'm able to have some level of confidence in my figure because I'd already done the work - and it took about an hour. We then quickly move towards a second activity which utilises the output from the first task. My colleague offers that the work will take around three weeks. I counter with 45 seconds. What he thought was a manual task was a bit of cut and paste with a spread sheet. 

If Pert weighted estimating is used in these two cases then the first example will be off by around 800% and as for the second, I'm not even going to waste time with a calculator.

So, two quick examples of how things can go off the rails. Now someone out there will be saying hold on, hold on; Pert weighted averages are only as good as the data that goes into them - same as any forecast. I agree up to a point, but there is no discussion or reference anywhere to this in the literature. Is there? Moreover, where do you get an optimistic estimate and a pessimistic estimate from? I've only got my best estimate, but usefully I'll tell you where it came from and often, what my level of confidence is in the figure. Oh - and not forgetting that there's not mention of how to deal with estimates that are either highly consistent or wildly divergent - and these two scenarios should be treated differently shouldn't they?


Let's set out a few immutable truths. Or at least some points which I hope won't raise too much debate.

Good things arising from good forecasting


  1. Better project plans that build confidence
  2. Better stakeholder engagement and perception - they know what's coming, when and in what order
  3. Better management of commercials - you can sign those distracting multi-million pound contracts with a little less anxiety
  4. Better expenditure profiling - you know what costs are coming when
  5. Better resource planning, and importantly brokering. Just 'cos I said you could have 2 engineers this week doesn't mean you can have 'em next week...
  6. More productive project boards - you're not arguing about the schedule all the time
  7. A happier project sponsor
...and quite a bit more besides.

Bad things arising from bad forecasting
Quite apart from the absence of points 1 - 7 above are the following.

  1. You'll constantly be re-working the project plan and your monthly project board will become your monthly re-baselining meeting.
  2. Your project will quickly become a source of generalised uncertainty, consternation and (quite possibly) resentment
  3. Your chances of getting to the finish line and fulfilling anyone's definition of a successful project will fairly quickly diminish to nil
  4. And a real kicker here, you'll dilute your governance (who makes what decisions, when and to what criteria)
As is so often the case, my blog post has ended up in quite a different place than I anticipated (that of course is attributable to poor forecasting) but between this article and those yet to be published I'll try to provide adequate coverage of the following.

  1. Parametric or reference class forecasting
  2. Guessing, uncertainty and pragmatism
  3. Never mind 6 Sigma - 1 will do you quite nicely
  4. The PMs job in fighting for exactitude and rigour in the planning process
  5. Some helpful language and strategies to challenge sub-standard practice
  6. Some real life scenarios and tools consistent with other articles in this blog that I hope will add a bit of value