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.

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.