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.

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.





WBS - Second Foundation

A previous post (WBS as foundation) is far and away the most read post on my blog. So (and with a passing reference to Mr. Azimov) I'm following up with some additional practical tips that I use on more or less a daily basis.

For what a WBS is, how to construct one, what its ideally applied to and its limitations see my previous post.

So we still use the hierarchical structure previously described and I tend to use the SmartArt feature in Excel to generate and maintain the WBS structures. I tend to keep things fairly segmented - one worksheet per WBS and one WBS per work stream.

Please, please note - there are some big powerful tools out there for generating and maintaining WBSs. SmartArt works for me because as often as not I'm in a position to decompose stuff to a level that suits me. It may not work for you.

What I do next is create a product dictionary on a separate worksheet. I'll include a sample spreadsheet in a little while so you'll see the whole shooting match in action. There's a reason we put all the products on one sheet and you'll see that in the template I supply.

I cite a few points worth consideration.

1. In my last post I talked about the constant K - and idealised abstraction of the total amount of work required to deliver your project assuming no waste. This is relevant to our discussion here as K1 is the volume of work not identified during planning and due diligence. If you can't include it at the outset of a project, include the work as you discover it within the WBS and product dictionary - there's all sort of good reasons why.
2. The product dictionary is a fantastic way of tracking all your discrete components of work, who's doing it, the status of the work and a host of other stuff to
3. The work breakdown structure and the product dictionary comprise a very good record of the work done, work in progress and work yet to be started.
4. The product dictionary forces a degree of rigour into the definition of work that is issued to members of the project team
5. If you do define the WBS and product descriptions up front, the project plan will pretty much write itself. I succeed in winning this argument about 50% of the time and that 50% is always a better oiled and tuned project than the other 50%.
6. Both the WBS and product descriptions can form a very useful foundation to reporting and communication (what's done, what remains to be done and so on).

So there's a lot to recommend these two products and we can still extract a bit more smartness from the approach. See my work book here. I've included two different WBSs, each of which applies to a different work stream. We've got a product dictionary with a number of products assigned to three different people. There's a bit of filtering applied which means we can (for instance) pull all the products assigned to a given individual. And there's a bit of conditional formatting which means the individual line items change colour depending on their status which makes keeping an eye on things that little bit easier.

You could configure conditional formatting to change the colour (say) for items that are 7 days before their due date or for items that are due or overdue. But, that's really something I tend to rely on my project plan for.

You'll notice a lot of duplication in the sheet. In the instance here this is because this is a specimen created solely for you delectation and delight. However, it does highlight a particularly useful element of working in this fashion which is within any product dictionary there is a great deal of duplication. The Quality Criteria are generally re-usable for various products as are the resources and acceptance method. In short, these build nice and quickly, particularly where there's a bit of existing policy, process and procedure which can be referenced.

Lastly - something useful in Excel is the paste special 'transpose' function which means I can take any row, paste special and transpose into the 'product description' sheet as shown and I've a readily communicable summary of the product description to do with as I wish. If the product description looked familiar - it's a standard Prince 2 product.

And that is really about all there is to it.

Late for a very important date - again?

Say what you will, most projects don't get delivered on time. A critical appraisal might include the word late. I'm starting to think however that the terms 'on time' and 'late' are worth consideration. And maybe, if enough consideration is given to the subject perhaps there might be something genuinely novel and interesting to conclude about the nature of projects generally, the frailty of current management approaches and what can be done about it.

There's an interesting blog post here that I read sometime ago - you should read it but in absolute summary - there's no such thing as slipping dates, just bad forecasts. I remember this really making an impression with me when I read it. I don't just think its a good point, I think its a potent entry point to a much richer discussion.

A while back I prattled on about an idealised constant 'K', which represented all the work that was required to be done to complete your project assuming no waste. I've re-rendered the drawing below.

There's some simplification here. There's no discussion of change requests, procedural acumen or PMO statistics for this sort of project run in your organisation but broadly;

Work that needs to be done to complete your project is K
Work that you identify to be undertaken for your project is Kb
Magnitude of error in plans is K - (k2) + (k1).

k2 is interesting as you may or may not end up doing it and to some extent it cancels out k1 which you'll always have to do.

What's our list of variables then? Things that might influence k1 & k2. I suggest the following

1. Preliminary planning fails to identify accurate the work that needs to be undertaken or the time it will take to complete it.
2. Failure to accurately identify dependency relationships, leads and lags
3. Blunders, poor forecasting and re-work
4. A change budget (£/$) but no corresponding schedule allowance
5. HR Management issues (absence, incompetence and ineptitude)
6. Failure to manage complexity
7. Criminal or unlawful activity
8. Acts of nature

Of the 8 points above, I would suggest that item 1 is far and away the most significant. Some other time I might take the time to blog on the predilection of homo sapiens to focus on outliers at the same time as dismissing the significant but for the time-being I think I'll simply focus on items 1, 2 & 3 above.

Let's take a moment to summarise and take stock. Project delivery consistently moves to the right (perhaps systematically so) and there is (I suggest) some consistent harbingers of this movement. Interesting this isn't it? We've got a consistent output (delays and destabilisation of the project schedule), consistent inputs (I'll continue to subscribe to points 1-3 above - other views almost certainly exist). Shouldn't this mean we can do something to quantify and assess the potential impact to our projects?

There's a little bit of overlap here potentially with the schedule performance index which I mention here. But its not quite the same animal. Firstly, you've actually got to implement some rudimentary earned value management and (somewhat shockingly) almost no one ever does. But it will only help you so much as it will only use a sample of work done so far rather than a more useful measure the project in its entirety. This means you'll get increasingly good data as your project progresses but at the outset, it'll be highly unreliable.

At this point, I feel I want to talk about cooking for a while. 

Cookbooks are full of recipes. They describe the ingredients and implements required, the steps, temperatures and techniques to use and usually describe the output. They do this consistently well otherwise people wouldn't buy them.

If you follow the instructions and you have a little culinary acumen you can have a high level of confidence that what is delivered will be edible. Delicious even. If however, you use second rate ingredients, rush the prep, burn the food and respond to a late request to remove the anchovies, there's significantly less chance that what you deliver will be fit for purpose or on time.

Cookbooks are a good illustration of our idealised constant 'K' that I mentioned above. They do have the advantage however that a) they're not a unique undertaking and b) almost universally they'll have been reworked and rehearsed perhaps over several generations. So, they're not projects are they. But they do highlight the importance of knowing everything there is to know at the outset and what the benefits of knowing everything are.

Continuing on our epicurean line for a spell longer. If we removed some of the ingredients and steps from a recipe we'd be doing something to model in abstract the deficiencies in planning to which many projects (all?) find themselves prone. Would we be able to identify the omissions? What could we do with them if we did identify them?

We'll, there's one sure way of identifying that there are omissions (as opposed to what they are) and that's cook the dish. I don't think its too much of a stretch to suggest that any omissions could be identified and quantified. So what's the benefit of investing this time and effort? What can we do with the information we're now in possession of?

Can we extrapolate anything about the remainder of recipes in the cookbook (project)? Can we play any discrepancies across the remainder of the project? Well, maybe. Omissions from the fish section might not be applicable to the dessert section and should you take your cookbook to your aunt's for Sunday roast, all bets might be off when comparisons are made with cooking in your own kitchen. This is where the schedule performance index (and cost performance index) fall short for our purpose here - they focus exclusively on the sample of work that has been done, not a proportionate sample of the whole piece.

What I am tilting at here is that if we cook a few recipes up front we'll be better able to assess the cookbook in its entirety. The more recipes we test (the greater the sampling) the better picture we'll develop of the overall scheduling, scope and procedural quality.

So what next? I'll seek to elaborate the points above and answer the following questions.

1. When is this sort of critical appraisal essential as opposed to desirable or superfluous?
2. What could the job of analysis of a project scope / schedule entail?
3. What could the output be used for?
4. Who would do it? When? And for what purpose?

Requirements part 5 - a very useful spreadsheet

I think there might actually have been one or two more posts on requirements than 5. No matter the end of the tunnel is in sight.

I've written quite a bit about what not to do with requirements and conversely some useful salves for common problems. What I haven't done (until today) is state clearly my approach to managing requirements (and more besides) or provide the tool to get the job done.

To date, we've talked about MoSCoW analysis (yuk!), pair-wise comparison, cost of compliance / non-compliance, KANO analysis and quite a bit more besides. We've never talked about UML or a bunch of other stuff, but ultimately (as you'll see) that might not matter too much.

Consider the illustration below - a veritable soup of inputs relating to requirements. Equally, a customisable and completely transparent score card that can be constructed and agreed by stakeholders early in the process.

What we're starting to get towards here is an approach to requirements prioritisation and management that can be highly customised to suit any situation. 

Get the stakeholder buy-in right, get the score card right and the rest will follow.

In the example below, I've used the following scoring elements - you however can use what you like.

• MoSCow - exactly what it says on the tin. MoSCow does have its place albeit do remain cognisant of the limitations previously discussed.
• Kano - see last post. A quick and easy way of assessing non-monetary value
• Contribution to the business plan - if it doesn't contribute, should you be doing it?
• Compliance - do we have to have this to meet regulatory requirements?
• Senior stakeholder flag - if the the budget holder wants it in taupe, then let's have that right out in the open from the get go.

Your score card might incorporate the elements illustrated above or be something complete different. You might have specific organisational imperatives which mean you incorporate none of the elements above - fine. The approach is no less valid.

So - you've got a score card - what next? Excel that's what. What you're seeing below is the scorecard above incorporated into Excel.

It's not too busy a spreadsheet but it has got a couple of tricks up its sleeve.

First, the fields are 'constrained' and aligned with the scorecard.

And, we've got a a simple but long formula to do the scoring calculation. Note the red highlight. We don't put the scoring in the formula itself - we use a lookup to a table elsewhere. This is important and we'll discuss this more later.

=IF(C2="Must have",Lookups!$B$1,(IF(C2="Should have",Lookups!$B$2,(IF(C2="Could have",Lookups!$B$3,(IF(C2="Won't have",Lookups!$B$4)))))))+IF(D2="Dis-satisfier",Lookups!$D$1,(IF(D2="Satisfier",Lookups!$D$2,(IF(D2="Delighter",Lookups!$D$3)))))+IF(E2="Key",Lookups!$F$1,(IF(E2="Required",Lookups!$F$2,(IF(E2="Aligned",Lookups!$F$3)))))+IF(F2="Yes",Lookups!$H$1,(IF(F2="No",Lookups!$H$2)))+(IF(G2="Yes",Lookups!$J$1,(IF(G2="No",Lookups!$J$2))))

I've uploaded the spread sheet here and you can play to your heart's content.

Some things to bear in mind.

1. You aren't constrained to 'sum' the scores. Multiplication has its place particularly as it opens up using a zero to effective nullify a requirement
2. You aren't constrained to using this just for requirements - the same approach works very well for (say) assigning a risk rating to server moves in a data centre migration
3. I've used significantly larger spreads sheets both in terms of the number of criteria used and the scores which correspond to those criteria. Undoubtedly there's a limit but I haven't found it. If you do (and good luck with that) you can always split the formula in two and sum the output.
4. Don't limit yourself to linear scoring - in point of fact, you're going to need to justify very carefully the use of linear scoring (i.e 1,2,3,4,5,6 as opposed to 1,3,8,20). Most things (I think) will benefit from a non-linear scoring approach.
5. Make sure you get your criteria right from the get go, the scoring only needs to be 'about' right as we re-tune that later on.
6. Weighting - don't think you can't apply a specific weighting to one or more elements on the scorecard - in point of fact this is just another way of playing with the scoring but don't rule it out.
7. If you're smart enough you can probably use a custom list in SharePoint to do this.

Finally, getting the scoring in the scorecard right from the get go is tough. So tough in fact that I discourage you from trying. Stakeholders can get a bit cagey too as, while they see the merit in the approach, they tend to be less certain about getting tied down by a scorecard that they (quite understandably) can't appreciate the fullest implications of at the outset.

Fine tuning the scoring is the subject of the next post.

Requirements part 4 - Kano Analysis

One of the things that I always keep in my mind when assessing and prioritising requirements is the cost of fulfilling the requirement relative to the cost of not fulfilling the requirement. I tend to think of this as the cost of compliance versus the cost of non-compliance.

Cost is an important dimension to incorporate into the overall requirements management effort, stakeholder engagement activities and so on and so forth. The application of this sort of approach is broad. I've recently been working with a client to work out which of their 'extensive' software library they wish to retain and which they can afford to withdraw. 

It isn't quite the case that there's a one to one relationship between a software application and a set of requirements. But there is often a 'service' comprising of one or more applications (and possibly more besides) which together fulfil a set of business requirements.

With all of this said, costs of compliance / non-compliance, serve as a useful entry point to start a conversation about 'what's in, and what's out'. It's quite useful too to bring any written business objectives into the equation as well.

But, as I say above, the cost argument is an important dimension, it isn't the whole story.

It can be difficult to sell a decision based wholly on cost (even if the decision is actually wholly cost based). This can be particularly trying when the end-user is divorced from the costs. So, we can bring something else into the equation which can help namely, Kano Analysis.

Kano analysis nicely skewers the fact that there are some very different types of requirements as far as stakeholder perception goes.

1. If you walk into a room and turn the light on, and it comes on you're only ever going to be so happy. On the other hand, if the light doesn't come on you will be dis-satisfied.
2. If you walk into a room and the temperature is too cold, but you can adjust the temperature with a thermostat, you'll probably be satisfied.
3. If you walk into a room and there's coffee and biscuits laid out for you, you'll probably be delighted.

Kano analysis is intended to give you a structured approach to identifying which category your requirements fall into with your stakeholders. It has the added bonus of being very quick and easy.

See the illustration below. All we need to know is the answer to two questions - the answers need to represent a consensus of the stakeholders. Workshops can be used to elicit the information and you could do something useful in a room of people with sticky labels (I'm all for getting decisions made at the coal face)

With these two questions answered we can map a requirement to one of the following categories. In practice, you don't tend to get any of the combinations marked null. It does happen an usually it's because there's a lack of consensus or clarity.

We can usefully articulate the requirements as follows. I haven't bent my meagre brain to it yet, but I can see a useful bubble chart in Excel mapping out the requirements - do let me know if you beat me to it.

And, in the event that ultimately all decision making is cost led, you can engage and communicate with stakeholders to manage expectations (and sometimes fallout) from commercial decisions that have implications for them. It's all good, useful information.

We've got two last bits to cover off and then I think that'll be an opportune point to take a break from requirements.

Making life easier (and a bit of process stuff)

Projects generally have a lot of 'interconnectedness'. And please - I don't just mean railway projects.

Processs are rarely 'stand-alone'. The outputs from one process are, more often than not, the inputs fir something else. (So help me) you'll start to hear the words ecosystem and (abandon hope all who enter) 'synergy'.

In an ideal (and possible mythical world) you have ERP, CRM and EPM tools into which all your various risks, issues etc are included. But, from time to time, the enterprising PM may find themselves without these tools and forced to fall back on more prosaic mechanisms (by which I mean Excel).

I've provided a spread sheet here. I call it ACRID (derived from Assumptions, Constraints, Risks, Issues and Dependencies). You'll also come across the term RAID (minus the constraints), and you'll probably not often come across a CORDIAL log which (of course) contains the lessons learned log. Any attempt to include a quality log is headed for the rocks.

We don't want to make life too hard for ourselves and, of course, we'll want to keep an eye on the whole process ecosystem angle so we're not duplicating effort left, right and centre.

I include here a template for a highlight report. I like highlight reports as I know of no better way to bridge the divide between the poets (for whom business transformation is a mere pen stroke) and the plumbers who lie awake all night worrying about it. I take some license but there's a sliding scale in there somewhere.

So, back to the whole inputs and outputs thing. If you take a look at the highlight report template (which is aligned with Prince 2) you'll notice there's quite a bit on work packages and products. Check back to previous posts and you'll have all all you need to cut and paste into the highlight report.

In fact I'll paste in the contents page from the highlight report template and append it with where you derive the content from each section from.

1. This reporting period

Not much going on in here

1.1 Work Packages

...Or here

1.1.1 Pending authorisation

If you need them, you'll have been writing them and you'll know which ones are outstanding authorisation

1.1.2 Completed in this period

From the project plan, paste in relevant sections of WBS

1.2 Products completed in this period

From the project plan, paste in relevant sections of WBS

1.3 Products planned but not started

From the project plan, paste in relevant sections of WBS

1.4 Corrective actions taken during the period

Issue log or other sources as appropriate

2 Next reporting period

Not much going on in here

2.1 Work Packages

...Or here

2.1.1 To be authorised

From the project plan, paste in relevant sections of WBS

 2.1.2 To be completed in the next period

From the project plan, paste in relevant sections of WBS

2.2 Products to be completed in the next period

From the project plan, paste in relevant sections of WBS

2.3 Corrective actions to be completed in the next period

Could be anything - use your judgement to include what you feel is appropriate

3 Product and stage tolerance status

SPI / CPI figures as appropriate (this will have to wait for another day for detailed coverage).

4 Requests for change

From the ACRID log so long as you raise all your changes as issues

5 Key Risks

From the ACRID log

6 Issues

From the ACRID log

7 Lessons Report

From the ACRID log

***************************************
Some points to bear in mind.

1. Truncate (i.e. hide a few columns) on the product descriptions, WBS elements, risks etc as you'll not fit them all on a single landscape A4 and the detail is probably more than your audience will want
2. I'll cover off a bit on the cost performance index (CPI) and schedule performance index (SPI) another day.
3. Corrective action could mean almost anything - include what you think is appropriate
4. Some stakeholders will want detailed information about resource burn, budget status or other detailed information not included above - this is a good sign and shows that the sponsor is 'on board' and giving the project focus.

And, to wrap up the topic of the highlight report I conlude with the following key points which I hope will impress upon you the benefit of producing it, even if your stakeholders are sanguine on the topic.

• It is an excellent tool of communication to all stakeholders, both to relay issues and status concerns but also to keep all parties abreast of progress. It is a principal tool by which the project manager can relay, escalate and communicate issues and anxieties which require board / sponsor input.
• I find it amongst the best ways of structuring a project board meeting, particularly for stakeholders less experienced in sitting on project boards
• If (like me) you keep all your WBS elements, product descriptions and logs up to date, with practice, you can produce one of these in about 20 minutes.

Sewing up a few lose ends and knitting it all together

Time to wrap up (for now at least) on the WBS and allied products.


I mentioned that sometimes there was a lot of work and not much product. If you need better control around this or simply better control period then I enclose a work package template here.


The first half is pretty much Prince 2 all the way. The second half incorporates specific test management activities intended to root out defects.


Two interesting points about work packages - sometimes resource pools really respond well to them. They can definitely accelerate delivery. Secondly, if you ask for written checkpoint reports from assigned resources you can rely on finding out problems after they've happened. If you take the time to verbally engage with the assigned resources you might be lucky to catch sight of problems before they occur.


Next I include a small but useful resource which is distilled from the WBS (which we have talked about) and the project plan (which we haven't) which nicely sows up all the delivery dates for all the products. 


For ease of administration I recommend including the WBS dictionary, the product descriptions and the product handover log on different work sheets in the same work book. I've never done anything clever with this using SharePoint / Excel Web Services but doubtless they'd be some value in exploring this.


I'm a bit cautious with the illustration below but felt it was worth including even in its slightly flawed state. The PBS is a bit nomadic, and there are one or two abstractions too far. But I think there's more right with it than wrong so I include it here and welcome suggestions for how it can be neatened up a bit.

There's a heck of a lot more worth exploring, both central to the illustration above (testing, estimating, tracking and controlling progress) and peripheral (benefits management, value management, business case writing) to name but a few. But, that's all for another post on another day.

Taking the WBS forward towards a project plan

In my last post, I talked at some length about the work breakdown structure as a foundation for all that was to follow. I summarised some points worth noting when creating and manipulating work breakdown structures. One of the limitations of a WBS is that it can't incorporate that much detail. And for some of the WBS elements, you're going to want a lot of detail.

I'll come on to how much detail and for what purpose shortly. In the meantime, l include the following table which supplements the WBS elements with more detail and specifies the product descriptions which correspond to any given WBS element.

Most of the fields are self explanatory and most come from Prince 2. There are things which Prince does very well - this is one of them.


One or two things aren't self-explanatory. BCWS stands for budgeted cost of work scheduled and this is beyond the scope of this post. It's a component of earned value management for those sufficiently interested. The CAM is the Control Account Manager and while this terminology is fairly specific to aspects of earned value management, you'll discern that this is the person(s) who is accountable for the product's delivery and ensuring it meets requirements.


All the WBS elements should incorporate version control. The related products descriptions relate to specific products that will be produced during the execution of this work. The nomenclature is deliberately 'transparent' and it should be readily apparent from any product reference what the corresponding WBS element is. The schema of the product descriptions is larger and will be the subject of a subsequent post. You should note that if the WBS element doesn't output a product, there won't be a product description and this might be as far as you elaborate.


You can download the specimen template shown above here

The start and finish dates are fed back into the WBS dictionary when you've completed the scheduling work in the project plan.


A few points on the subject of detail and how to assess how much of it you need to have.

1. Is your project intolerant around costs? Schedule? Quality? All three? This should inform the level of detail where appropriate
2. Is the work novel or contentious. Has reference to corporate or programme lessons learned resource indicated anything about which you should be wary?
3. Are you expecting lots of change around the specific element of the WBS or resulting products?
4. Is product acceptance a particular concern?
5. Is this a new supplier or one with whom there is little prior precedent?

That's a few points to be considering when assessing the degree of detail that should correspond to a particular WBS element or its related product descriptions. 

Incidentally, at this point I've still not covered where a really helpful narrative can (and should) be included. In my last post, I included an illustration of the WBS. When publishing the WBS, I always include an accompanying table with some supporting information about what a specific element of the WBS actually encompasses.

I include an illustration below of what I usually include with the WBS.

And you can download the template here


I'll deal with the product descriptions next and then we'll be in the business of assembling our project plan.

WBS as foundation

In my last post I said I couldn't add much to the existing breadth of knowledge on work breakdown structures (WBS) or the product based equivalent the product break down structure (PBS). And, I can't. However, I don't want to preclude any potential readers who may not be familiar with the technique. I can pull out a few points worth re-noting and, simply because it's so important a component of the overall planning process, it won't hurt if we all start from the same place.

One of the things that makes the WBS so likeable is that it's very simple, readily comprehensible and consequently, rarely needs much by way of explanation. The product breakdown structure is an excellent tool of communication to illustrate a project's scope. The work breakdown structure is a slightly more focussed tool, but nevertheless is a great way of engaging with resource brokers.

Here's a few of the things I keep in mind when constructing a work breakdown structure.


1. Proportionality - I decompose elements of the WBS to a level that 'makes sense'. This is often informed by early assessments of the volume of work and who's going to do it.

• Estimating is more accurate when work is broken down into small chunks. 6 separate work breakdown structure elements of 3 or so days each tends to be more reliable than one of 18 days.
• There's some logic in breaking tasks down to a level of work that can be completed by one person only - this has some benefits when manipulating and scheduling the project plan in software
• Resource brokering - ideally, I'd like each element of the WBS to be undertaken by resources brokered through a single individual. Or to put it another way, I want to go and see one team leader about a job, not two or more. The resource brokers are likely to be happier about this too as it reduces constraints in resource planning.

2. Manageability and maintainability - I usually create the WBS in MS Word - there's a couple of hierarchical structures in the SmartArt feature that lend themselves quite well to the creation and maintenance of the WBS. I find the 'Organisational Chart' works well. Microsoft tend to pick and choose which features they include in any given version of a piece of software - I use MS Office Professional Plus 2010 - other versions may differ. If they get really big then you could use some like MindJet's MindManager, but there are some practical points to be born in mind. The WBS above was created in Google Docs.

• You do want to be able to produce this on a single page (whatever it's size) - a multi-page WBS is probably more like multiple WBSs
• If it's getting unavoidably big, you lose some of the benefits such as the WBS being a readily comprehensible tool of communication
• The bigger the WBS the more likely errors will creep in
• I find a three tier WBS works quite well for most of my work and if things are getting beyond that then I tend to segment the work into more manageable stages.
• If you've got, by necessity, a very large WBS under constant edit and amendment by multiple parties, you're going to need a different tool - they do exist.

3. A requisite level of detail - while there is a little bit or wriggle room, if work needs to be done and resource needs to be brokered it must be on the WBS

• There is an obvious conflict here in terms of keeping the WBS simple enough to work with. This is readily managed by taking the WBS elements within the WBS and elaborating them further in other products (more on this in another post) but so long as we have a WBS element with a unique identifier - we can (and do) expand this elsewhere.
• Certain things don't go in the WBS. These mostly relate to work that generally comes under the heading 'Level of Effort' or LOE or the effort relating to project management processes themselves.
• In my illustration, I've included quality activities (the snagging and building control sign-off) this is a good way of seeding quality through-out the activities and illustrating this to all parties early on. 
• I've also included certain activities like estimating and make or buy decisions

4. And generally - the following can be helpful to keep in mind

• Generally speaking, left to right and top to bottom reflect the chronological sequence of events. This isn't critical, but can just assist the overall readability
• I haven't identified a reason why the elements need unique titles - happy to hear otherwise, but you must have a unique identifier
• Avoid trying to incorporate too much detail at this juncture (dependencies, resourcing and scheduling) this isn't the tool for the job
• Peer review is vital - you're unlikely to be a subject matter expert across the whole WBS - get the appropriate individuals to formally review and approve specific parts of the WBS - you must be on a firm, consensus led footing when this activity is finished.

The next few posts will take the WBS above and supplement it with additional detail to make it a self-contained resource. We'll start to look at the WBS dictionary and product descriptions too. 

Breaking it down and getting it done

Somewhere in my many posts related to this must be the observation that the business of getting on an delivering anything has, thus far, been conspicuously absent. 


First, don't go looking too hard for activities related to delivery in the 'achieving quality' model. That's an abstraction focussed around meeting customer requirements. But then again - don't lose sight of that while getting on with the business of delivery.

Next, don't necessarily follow the steps above verbatim. You're almost certainly going to have to maintain a flexible footing, responding to the particular business needs you're facing. I'll offer this isn't a bad starting point however.



[If you want more detail on product or work breakdown structures see any number of other sources elsewhere. I can't add anything to the existing breadth of coverage.]


Step one above isn't something I'm going to dwell on too much at this point. Somewhere in the project mandate, brief, charter, PID, business case you'd better make sure there's a crystal clear vision of what the customer wants. If not, you'll need to lift whichever drains you have to in order to get that unequivocal vision of what is to be produced. 


I can think of one or two exceptions, but mostly the (PBS) should pretty much always come before the work breakdown structure (WBS). Define what you're going to do, then how you're going to do it. Scope definition can be a (very) big job in itself and if this is a self-contained stage in its own right, then you might have a WBS for which the output is a clear definition of scope (the PBS).


Be it PBS, WBS or any other type of work breakdown structure, the objective is 'compartmentalisation'.


The project plan is easily derived from the WBS. In fact, if you're using software to do your project planning (and you almost certainly are) then if you have the WBS, the project plan will almost write itself. The only substantive information you'll need to add are dependencies and lags (where applicable).


If you adopt this approach, i.e.WBS then the project plan, I'm convinced you'll rarely deviate. It has a number of advantages around scope definition, change control and taking some of the effort for the creation of the project plan away from the project planner. Conversely, I'm not convinced you can derive a complete WBS from the project plan, and developing the two in tandem is best avoided.


Finally, once you've got your project plan, you should be at the point where you can generate your resource plan. And, in fact, your project planning software will almost certainly do this for you.


There's quite a bit more ground to cover on this, specifically relating to 'progressive elaboration' to the appropriate level of detail. This will be the subject of future posts and will deal specifically with the WBS, the WBS dictionary, product descriptions and the generation of specific work packages. They'll be plenty of templates to get you started and save you time too.

Proportionality in controls

Early identification of the 'pinch' points and putting more effort towards controlling those elements is, in my opinion, time well spent.


In the example below, we're 5 months in on a project, the customer isn't too sensitive to cost, but is extremely sensitive to delays.

Doubtless there are a few ways of tracking quality. I've often thought that if you're handing over  project deliverables sequentially, CPI and SPI sort of give you a 'QPI' or quality performance index since your customer is signing off acceptance of products as you go. 


With IT projects you do involve the customer in test and review activities throughout the design and development work, but sign-off tends to be a bigger bang type activity. The PM of any IT project needs to be fully cognisant of the customer's wants, needs and any deficiencies as an ongoing process. This activity is encompassed within testing and defect management.


I'll do a post at a later date on the range of metrics relating to defect management which I like to capture but here I've singled out something I've always been very keen on. See the bottom of the three charts above. Something not entirely clear is that that the graph isn't cumulative. Each month the number of defects identified that month is plotted against the number of defects fixed that month. At a glance, this shows whether or not you have an unsustainable, worsening or improving state with regard to defect identification and resolution.

Note the control charts above, not only are these easily maintained and communicable, they illustrate trends and the tolerances to which the project is expected to adhere. Incidentally, I'm a fan of publishing this sort of material directly to the project team - it encourages shared ownership and good alignment of decisions throughout the project team.

As can be seen above we've got more tolerance on cost than time. Take the cost (CPI) plot, we went from a good start, to holding steady, followed by three consecutive periods of deteriorating performance. With the benefit of hindsight it would have been useful to have a more frequent reporting interval - if we'd had fortnightly reporting - somewhere between month 2 and month 3, it would have become apparent that corrective action was required, and consequently far more easy to justify.

While the time (SPI) plot serves to illustrate this point very well, what we could have seen in advance was the very limited tolerance on schedule would have benefit from more regular reporting for precisely the reason above. The emergence of a trend would have happened far more quickly.


These sort of indicators are one approach to helping ensure that within any given project, benefits are maximised and risk is minimised. The best indicators are those that inform timely decision making before things go off the rails, not simply reporting on the fact that they have.