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?

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.

Forecasting - part four

Ironically in my first post on forecasting I cited the following points which I would aim to cover.

1. Parametric or reference class forecasting
2. Guessing, uncertainty and pragmatism
3. Never mind 6 Sigma - 1 will do you quite nicely
4. The PM's 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

And here we are on the fourth post on the topic and I think I still have pretty much the lot still to get through. Something relevant to the topic of forecasting in their somewhere methinks.

Let's hustle on a bit. 

Parametric or reference case forecasting is simply the process of using historical events to inform forecasting. Let's go back to our example of changing a car tyre. I discussed some useful stratagems on getting to a more accurate forecast, but ultimately you can't beat having changed a tyre yesterday to inform a useful forecast on how long it might take today.

Guessing? Don't do it. If you don't know how long something is going to take, set a duration on your project plan and commit to using a schedule performance index to track progress and assign more (or less resources as appropriate). Or, some other similarly pragmatic approach.

Standard deviation isn't something we've talked about before and I think it would be worth keeping this back for a specific post. (That's the point on 6 Sigma / 1 Sigma above). What I think I will do for the remainder of this post is focus on point 5 above.

There are undoubtedly a great many opportunities for the activity of forecasting to fail. I'm going to describe a few ways that (I've seen) project delivery deviate wildly from the forecast and then highlight some stratagems to help avoid it doing so.

Shoddy project planning - I don't know how many more project plans I'm going to have to work with that comprise 1000+ lines, rely wholly on duration based (rather than effort based) planning and (to top it all) incorporate 50%+ of hard coded dates.

I don't have the knowledge, capacity or inclination to write at any length on the topic of project planning and good practice using MS Project (or other). However, allow me to suggest that the inputs to creating a project plan include the following;

• Experienced planners who understand critical path analysis, activity on node / on arrow techniques
• Knowledgeable staff who have either been through a structured programme of learning or other activity necessary to equip them with the knowledge needed

And some general useful pointers while we're on the topic

1. The near term should be at a far greater level of detail than than the mid- or long term
2. Decompose tasks to an 'appropriate' level of detail
3. You don't have to, but project plans comprising tasks which track back to product break down structures and product descriptions tend to have a much firmer foundation
4. Supplement your forecasting with appropriate controls so that if you're wandering off schedule, your have good information early
5. Make sure public holidays and staff leave are configured within your resource planning
6. Agree up front what the resource capacity is (70%-90% - typically 80%). Never 100%.
7. Practice rigorous change control. You may (or may not) be able absorb additional tasks of less than 0.25 days effort. Make sure you have a mechanism to manage anything that exceeds what you can comfortably accommodate.
8. Building (clandestine) budget contingency into business cases and budget forecasts is wrong (and can be fraudulent). However, I'm pragmatically fairly well disposed to building in a degree of flexibility / contingency into forecast schedules. You'll be able to cope with a greater degree of unforeseen events and I've yet to find a client who complains when you bring something in a bit early. You'll also be able to give the client an answer other than no when he asks if you can bring something in a bit quicker.

Supplier management issues certainly figure highly in my short list of frustrations most likely to unhinge a project plan. You're embarked upon a project and chances are, so is your supplier with all the vicissitudes to which projects in general or prone. Some points intended to enhance stability follow.

1. Don't blur the lines between dependencies. If you have a dependency for which the supplier is responsible, don't start to re-plan and re-forecast (unless absolutely necessary) when the supplier starts to slip. That's a recipe from a problem shared is a problem doubled.
2. Make sure your contract and commercials with the supplier are appropriate
3. Make sure you have the appropriate written and agreed documentation to support the supplier's statement of work and scope of supply. 
4. Verify your supplier has instated 'good practice'.

Governance or lack thereof. Get the right decision made, at the right time to the right criteria. Incidentally, it's worth mentioning IT Governance in here - this is distinct to the typical corporate and project governance insofar as it's principal objectives are maximising value and minimising risk. Technical design assurance, testing, change management and a solid approach to service transition all comprise elements of good IT governance.

A little more yet to cover on this topic generally. If I'm feeling suitably whimsical, I may relay at some future point my thoughts on the role of analogue computing to forecasting in project management (another first for PMfizz surely?)

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.

Something a bit fishy...

Well it's no good beating about the bush with this one. I've produced a double headed Ishikawa diagram for the purposes of illustrating causal factors corresponding to the influence and repositioning of stakeholders. I think it's fair to say no one's done that before.

So what's the point?

First, if you need to get some background on Ishikawa / fishbone diagrams, pop along to Wikipedia. They are worth having some background information on whether or not you're a convert to my eccentric approach to presentation above.

When writing my post some weeks back "Influence - a pragmatic and effective approach" I recall a sense that I hadn't quite nailed the visuals. Sometime later I had to generate a communication management strategy for a project and, when re-visiting the topic with fresh perspective, I came up with the approach above.

So, with the combined knowledge supplied by Wikipedia and my initial post, I hope you can at least intuitively grasp what I'm trying to do here. 

But why? And more to the point, why include something like this in a communication management strategy?

Well first, I think this is a good workshop approach to elicit input. You're not always going to have enough back story on a client site to generate one of these yourself, but you can provide the footpath and fill in the information as (hopefully) the client supplies it. You can also record that input and articulate it in a way that makes sense.

Incorporating it into the communications management strategy (or other similar document) has the benefit that all communications undertaken under the aegis of the project have the opportunity to be informed by themes that should assist that overall stakeholder engagement effort. Better yet, it should do that whether or not you're there to review and edit prospective communications yourself. Generate one of these Ishikawa diagrams, provide a supporting narrative in the communications policy and hopefully, you'll see helpful references and positive themes sewn throughout the project communications effort.
*Per my previous article - the credit for the better part of the approach to stakeholder influence goes to these guys.

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.

Theories need evidence, facts need proof.

Always nice to stumble upon an academic bun fight. For the very tip of a very large iceberg on the relative merits of quantitative versus qualitative analysis see here, here or here.

But I'm a PM not an academic so what's the angle? My qualitative answer would be that knowing the difference will sometime enable a project manager to make optimal decisions . My quantitative answer is about 45 degrees - which to be fair isn't much use in this context.

For reference.

Quantitative research consists of those studies in which the data concerned can be analysed in terms of numbers ... Research can also be qualitative, that is, it can describe events, persons and so forth scientifically without the use of numerical data ... Quantitative research is based more directly on its original plans and its results are more readily analysed and interpreted. Qualitative research is more open and responsive to its subject. Both types of research are valid and useful. They are not mutually exclusive. It is possible for a single investigation to use both methods. (Best and Khan, 1989: 89-90)

Qualitative research is harder, more stressful and more time-consuming than other types. If you want to get your MEd dissertation or whatever finished quickly and easily do a straightforward questionnaire study. Qualitative research is only suitable for people who care about it, take it seriously, and are prepared for commitment (Delamont, 1992: viii)

Both these excerpts are from "An introduction to the qualitative and quantitative divide"

Whether it be the generation of the initial business case, the management of risk, key design decisions or resource planning, the project manager is faced with a veritable zoo of decisions. Some are more critical than others and on a sliding (qualitative) scale we make decisions which if wrong have very limited consequences to those 'irreversible' decisions to which great heed must be paid.

Question; has anyone ever sat down with project stakeholders and asked them if they want quantitative risk management, qualitative risk management or both? Do you understand the question? Would your stakeholders? Does it matter?

Take the following examples. First, what I hope will look a fairly typical excerpt from a fairly typical quanititative risk log. All with me so far?

 Next, something from the qualitative end of the spectrum.

R1 - qualitative assessment


Failure to provide adequant fencing, or early warning mechanisms as appropriate may result in injury or death to Donald Duck.

(A little digression here on the the two approaches to risk - if you fail to communicate to your board the potential impact of a risk with numbers (quantitative) try words instead (qualitative). On more than one occasion I've managed to elicit a response by describing in detail the consequence of a risk occuring having failed by ascribing it an impact and probability.

The Beaufort Scale incidentally makes rather good use of both qualitative and quantitative approaches - that's meteorology for you.

The PERT weigted average here is purely quantitative.

Now I could rattle on at length here, but I don't know if a blog post is quite the place for it. So I'll leave you with a couple of summary points.

1. Make a judgement of which type of data suits your needs and then go and get it
2. Personally, I prefer numbers to adjectives (with the proviso that they're right)
3. Look back at the quantitative risk assessment example above. Are your quantitative risk assessments based on analysis of the statistical likelihood of the event and the impact to cost and time should it occur? If not, then your quantitative analysis is in fact a qualitative analysis.

Conundrums in communications (part 2)

2 down, four to go.

1. You might saturate communication channels
2. Someone else might saturate communication channels 
3. Your stakeholders 'lose sight' of the communication plan
4. Your stakeholders actually tell you they should have read the communications, but they're sorry they didn't and now they're in a bit of a mess
5. You've racked your brains but you can't work out a way to ascertain whether or not your stakeholders have read, retained and understood your communications.
6. You're facing universal stakeholder apathy (this is on a sliding scale from mildly disinterested to venomous mischief making

Your stakeholders have 'lost sight' of the communication plan

The symptoms

This is one of those damning euphemisms which you really don't want offered forth in a board meeting. It's usually a response to some adverse incident which an observer has laid at the door of a communications management deficiency. A more forthright assessment might find the issue wholly predicated upon human factors.

The cause

Either you don't have a communication plan or, you're not 'managing your stakeholders'*. Or, you do have a communications plan, you are appropriately engaged with stakeholders and the assessment is simply wrong.

I take the stance that you don't treat stakeholders like farm stock, but not everyone maintains such an enlightened view.

The solution

Do not allow something that isn't a communications issue to be painted as a communications issue. If you don't have a communications plan, you'll have to bite the bullet. If you have a communications plan and the issue really is a communications issue then use something like 5-whys of other root cause analysis approach and take the corrective action necessary.

Your stakeholders are in a bind because they've not read your communications

The symptoms

You've done your job. Really, you have, You can show unequivocally the accountability for the lapse (be what it may) lies elsewhere and in this particular instance with someone who should have, would have, could have but didn't read any of the 6 carefully planned and executed communications bulletins. However, they can't work now and are costing the business money and that's starting to make you look bad.

The cause

Insufficient quality management. The key here is not the fact that your stakeholders didn't read the communications, its the impact of them not reading the communications. You cannot ensure your stakeholders read, understand and retain what is provided to them. In most instances you can manage what happens if they don't read it, understand it or retain it.

The solution

Implement poka-yoke or simliar. However you do it, don't let your stakeholders fall into a man trap because they 'didn't get the memo'.

You can't validate the efficacy of your communications (#5)

The symptoms

You've no qualified or quantified measure of the efficacy of your communications plan. Nagging doubts. Often at 2am.


The cause

You're a project manager not a mind reader

The solution

You've hopefully still got your communications stooges on talking terms from issue #1. They'll be a good help with this from simply opening up a dialogue to engaging them in test activities. I'm not a fan of surveys for this purpose. If I instate a test activity it will be designed to weed out deficiencies in communications or, what might in fact turn out to be confirmation testing. I'm not sure a survey does either one of these things well.

Apathy (and sometimes venom and mischief)

The symptoms

Rather self evident this one

The cause

Not ever so likely to be a communications issue but quite possible one which is first encountered by those project staff engaged in communications activities.

The solution

It's not a communications issue. Communications probably isn't the root cause and certainly is unlikely to resolve this independently. Escalate to the board and sponsor. Use the risk and issue logs with due prejudice.

Conundrums in communications (part 1)

I have a bit of a love hate relationship with communications. They can suck up resource, they're fiendishly difficult to get right (I sometimes even wonder what 'right' even means) and I can't be alone in having been burnt on one or two occasions by a nanosecond's lapse in concentration on the topic. 


Conversely, they give the project team an opportunity to raise their profile, to champion their aims and objectives and, done right, they can be one of the more satisfying aspects of the job.


Here's a few headline manholes.

1. You might saturate communication channels
2. Someone else might saturate communication channels 
3. Your stakeholders 'lose sight' of the communication plan
4. Your stakeholders actually tell you they should have read the communications, but they're sorry they didn't and now they're in a bit of a mess
5. You've racked your brains but you can't work out a way to ascertain whether or not your stakeholders have read, retained and understood your communications.
6. You're facing universal stakeholder apathy (this is on a sliding scale from mildly disinterested to venomous mischief making)

At this point I could espouse the virtues of a carefully crafted communications plan or stakeholder engagement plan. But I'm not going to and here's why. If you're fortunate enough to have specialist communications input, or even just a chunk of resource to throw at communications you can spend all the time in the world on soft market research, repositioning key stakeholder groups and deciding the precise colour scheme to use across the breadth of your media interfaces. So not only will you have time and money to develop specific purpose built documents and strategies, you'll be able to underwrite the resources for them, manage them and (one assumes) see them through to a successful conclusion.

Meanwhile, back in the real world, you've fought like a tiger for the limited resource you've got, your fingers are bleeding from back to back authoring of the business case, mandate project brief, project initiation document, configuration management plan WBS and product descriptions and the sponsor is wondering when you're going to start delivering something. So you make a note somewhere that the communications plan will be included in the RAM on stage 3 of the project (or something similarly vague).

This all said, you might find yourself facing problems 1-6 inclusive, or some uniquely quirky issue particular to your project and needing a bit of communication lubrication. Below I include my suitably pragmatic salve to the issues above.

You have saturated your communication channels

The symptoms

Communications have become less effective, stakeholders are grumbling, you hear the words '...not another project blah email...' in the lift, Paradoxically, because people are starting to disregard your communications you have to send out even more. People are setting up email rules to junk your mail.

The cause

You've overcooked it. You might even simply be following the communications plan (that needs an update by the way).  You've got no temperature check or feedback loop in your communications so you keep on spamming the entire stakeholder pool whenever you feel slightly anxious that your message might be getting lost in the corporate soup.

The solution

Prevention is better than cure. You need to recruit communications stooges (confederates in the stakeholder pool or business) who will primarily assess your communications from the receiver end of the equation as well as being your eyes and ears in those environments. If you've missed the prevention boat, take a two week communications holiday while you recruit your stooges - that should kill two birds with one stone.

Someone else has saturated your communications channels

The symptoms

Broadly the same as before. You have the satisfaction of knowing that you are not directly responsible for the blunder, but the annoyance that you will have to directly fix it.

The cause

Could be a lot of things but two spring to mind which I cite specifically because you'll approach the matter differently.

1. Poor email etiquette from co-workers. You're getting a lot of reply alls on emails or, other, similar blanket channels of communication are springing up. You're not managing them (in fact no one is), messages are getting garbled and coherence lost.
2. Someone in the customer's organisation, the stakeholder pool or simply someone you need to do business with is suddenly and deliberate fielding a great deal of communications, most of which is making your day a good deal harder than it needs to be.

The solution

In the first case, you're going to need to get that someone some feedback on email etiquette or simply the fact that communications for project blah start and end with the project team. That'll probably get you fixed.

The second case is a bit more of a curve ball and is correspondingly a little tougher to fix. Remember the communications plan we were going to right in stage 3? You need to get that thing written promptly. Don't kick yourself - having it earlier wouldn't have done you any good. 

You're going to need to define your communications interfaces, media, authorised and approved communications providers and get the plan approved by your project board. You will of course ensure that you've specifically outlawed stakeholders exploiting project communications channels to prosecute their own agendas and you'll also include that breaches of the communications plan will result in a project issue being raised to the board.

I can't promise you this is the panacea to every stakeholder that decided their views superseded those of the project board or sponsor - but this does tend to either quiesce over active stakeholder communications or, in the event it does not, reduces your exposure as PM to the problem as you've got some structure and a readily available channel of escalation.

I'll see off the remainder in the next post. If anyone has any communications issues not listed, do add a comment - I can't promise to have an answer, but my readership is almost into double figures - we'll crowd source an answer!

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.