Nursery rhymes for project managers
Mother Goose for Project Managers – version 0.001:
Little Jack Horner
Little Jack Horner sat in the corner,
watching his budget run dry.
Said he to the sponsor, “The project’s a goner.
and I reckon, so am I.”
Hickory-dickory dock
Hickory-dickory dock
The PM’s in shock.
The project’s aground;
the clock’s run down.
Hickory-dickory dock
Jack be nimble
Jack be nimble,
Jack be quick.
Dodge responsibility,
for it tends to stick.
Hey diddle diddle
Hey diddle diddle, the schedule’s a fiddle.
The deadline’s near; it’s too soon.
The sponsor won’t smile when he sees what’s been done,
especially after being promised the moon.
Hush-a-bye PM
Hush-a-bye PM, on a timeline.
Better wake up now, things aren’t so fine.
The scope is a-creeping, are you on the ball?
No change management will be your downfall.
Schedule, Schedule
Schedule, schedule on the wall,
the PM’s going to take the fall.
’cause everyone can plainly see,
his timeline’s but a fantasy.
The PM can’t sleep
The PM can’t sleep, he’s counting sheep.
The project is what’s troubling him.
Changes galore. Tell you what’s more –
there’s no money left to fund ’em.
Blah blah PM
Blah blah PM, spouting bull.
I can’t take anymore, my plate’s full.
The workload here is driving me insane.
So I’m leaving for a gig with the mob down the lane.
Getting the most from your consulting dollar
Consultants are engaged for a variety of reasons ranging from strategic (e,g. help develop corporate IT strategy) to tactical (e.g. augment internal resources). They are so ubiquitous that at any given time an organisation is likely to have a bunch of consultants floating around in one department or another. Given the often outrageous rates billed by high-end consultants, it is important that organisations get maximum bang for their consulting buck. When I worked as a consultant I often came across situations where my services could have been better utilised. On the other hand, as a corporate employee, I’ve seen consultants hanging around doing very little. So I’m convinced that many organisations often underuse or misuse the consulting time they’ve paid top dollar for. This doesn’t have to be so. It’s easy to ensure that you get the best value from the consultants you engage. Here’s how:
-
Know why you’re hiring them: One would think this should be obvious, but it often isn’t. Ask yourself why you’re engaging consultants and what (specifically) you want from them. The best way to be specific is to list the deliverables you expect from them. This gives you a checklist you can tick off as they progress through the engagement.
-
Be ready for them when they come in: Over the last several years I’ve been surprised at the number of consultants I’ve seen hanging around the coffee machine or twiddling their thumbs (whilst racking up huge charges) , all because the client wasn’t prepared properly for them. This is like keeping a taxi waiting – the meter’s ticking but you’re no closer to your destination – a waste any way you look at it. Be prepared for your consultants: ask them what they’ll need before they come in, and be ready with it. You want them working on productive stuff as soon as they arrive.
-
Listen to what they have to say: You’ve hired your consultants for a reason – presumably because they have something useful to offer you (knowledge, skills or whatever). It therefore behooves you to listen to them when they offer opinions (which may well be contrary to yours).
-
…but ask for explanations: Listen, but don’t be uncritical – you want the what, but you also need the why. Ask for explanations if you aren’t convinced. Ideally you want hire them only once for a particular job. The next time around you should know how to do it yourself.
-
Ensure knowledge transfer: This is really implied in the previous point. However, it is so important that I thought it worth mentioning again. You want to make sure that they’ve transferred all relevant skills to internal staff.
-
Document, document, document: This is a frequently overlooked aspect of most consulting engagements. Sure, consultants leave you with a final report. But that report, in my experience, is often less than useful. What you want are working, nuts-and-bolts documents like standard operating procedures. Be sure that your consultant leaves you with useful documentation. Have your people check the documentation before the consultant takes off with your cash.
Few present-day organisations can afford to maintain all the skills they need in-house, so most have to hire consultants every now and then. Your organisation is probably no exception. The aforementioned suggestions may help maximise the return from your consulting dollar.
Are project management practices generic?
Formalized project management frameworks such as those codified in PMBOK provide practitioners with a range of tools and techniques that can be applied in a variety of projects. However, such frameworks and methodologies typically do not offer advice on which tools and techniques are appropriate for particular situations or contexts. This begs the question: are project management practices generic? A recent paper by Claude Besner and Brian Hobbs, entitled Project Management Practice, Generic or Contextual: A Reality Check, addresses this question by looking into use of project management tools and techniques and the level of support provided for them in various organisations. This post is an overview of the paper.
In the usual fashion of academic research, the authors begin with a literature review. They find that much of the research done to date falls into one of two camps those who believe that project management practice is generic and those who don’t. Among the latter, they find that very few have studied the extent of variation (or similarities) in PM practices across different organisations and projects. The few who have, are focussed on specific tools and techniques or application areas. The authors claim that theirs is the first work that looks at commonalities and variations in project management practice across a wide range of organisations and project types.
And so, on to their research…
The authors gathered data from over 750 organisations through a questionnaire which elicited the following information:
-
Demographic information on respondents (position, education, experience)
-
Industry, organisation maturity and project characteristics.
-
Level of use of 70 specific tools and techniques as measured on a 5 point Likert scale.
The respondents were from the following industries:
-
IT and Telecommunication (~59%)
-
Engineering/Construction (~12%)
-
Business Services (~12%)
-
Other (~17%).
The data was analysed across the entire population and sub-populations (partitioned by industry, organisational maturity or project type) using two approaches:
-
Ranking of tools by average use in the whole population and within sub-populations.
-
Searching for statistically significant variations between levels of use across sub-poulations.
The results bring forth some interesting features which are described below.
As far as levels of use in the entire population is concerned, the top five tools are:
-
Progress report
-
Kick off meeting
-
Scheduling software
-
Gantt chart
-
Scope statement
The bottom 5 (in decreasing order of use) are:
-
Cause and effect diagrams
-
Critical chain method
-
Pareto diagram
-
Simulation software
-
Monte-Carlo analysis
The top five tools hold no surprises barring the fact that one of them (Kickoff meeting) doesn’t appear in the PMBOK! The commonly used tools also tend to be simpler to use than the least used ones. The latter are typically used only when there is significant organisational support for them. Another barrier to the use of the least used tools is their complexity: although people may be familiar with them (i.e. they know what the tools do), they may not have the technical knowledge to use them effectively. From my experience and that of others who I’ve spoken to, the technical complexity of a tool can be a significant limiting factor in its use.
As far as organisational support is concerned, there’s a very strong correlation between level of use of a tool and organisational support for it. No surprise here: if people are required to use a tool, they’ll use it. What’s more interesting though, is whether people use tools that their organisations do not support. Here the authors found that such autonomous usage occurs to some extent, but generally involves only tools that can be used without significant organisational support. I interpret this (near tautology!) to mean that autonomous usage will occur only for tools that are in a sense easy to implement and use at an individual level (i.e. no organisational resources required).
The next part of the analysis – variations of use between sub-populations – directly addresses the main objective of the research: i.e are practices generic or contextual. Firstly, the authors find that the rank-ordering of tools by level of usage indicates that the most and least commonly used tools are virtually the same across all sub-populations. This clearly indicates that there is a commonality in the way project management is practised across industries, organisations and project types. Having said that, the authors hasten to point out that there are significant differences across sub-populations too. I summarise the main differences in the following paragraphs.
Organisational Maturity Level: Respondents were asked to rate their organisation’s level of maturity on a scale of one to five, akin to the Capability Maturity Model . The authors grouped the responses into two lots: one with maturity scores of two and below and the others with scores above two. They found significant differences in tool usage between the two groups. This included:
-
All tools are used more often on projects in mature organisations.
-
There is greater autonomous usage of tools in less mature organisations
That being said, the most frequently and least frequently used tools were found to be virtually the same in all organisations, regardless of maturity level.
Project Size: The authors split the population into two groups based on dollar value of the project (a rough indication of project size), with the dividing line drawn (arbitrarily) at the million dollar mark. Here again, they found that the pattern of tool use frequency was much the same. The differences were:
-
Larger projects used a greater number of tools, and did so more often than smaller ones.
-
Larger projects tend to have a significantly higher usage of project controlling / monitoring and risk management tools.
Product types: Here the authors divided the population into three categories based on product type. These were: Engineering / Construction (E&C), Information Technology (IT) and Business Services (BuS). There are several differences in commonly used tools in each of these. I summarise the authors’ salient findings below:
-
E&C projects use contract related tools (bid documents, bidders conferences etc.) more than IT or BuS projects. This is consistent with the (generally) higher monetary value of E&C projects as compared to the other two. Further it is also consistent with the fact that most E&C projects tend to be for external customers whereas a significant proportion of BuS and IT projects are for internal customers.
-
IT projects tend to use scope and requirements definition tools more than BuS and much more than E&C projects. This reflects the fact that requirements tend to be more volatile for IT and BuS projects.
-
IT projects tend to use more tools for communication and coordination compared to the other two types of projects. I view this as a possible consequence of a general recognition that IT projects are plagued by communication problems!
-
E&C planning tools tend to focus on managing cost whereas IT planning tools tend to focus on schedule and resource allocation. The latter resonates with my experience on projects for a wide variety of customers (both internal and external).
-
IT projects use more risk management tools than E&C or BuS projects. This is perhaps a recognition of the fact that IT projects tend to encounter more project banana skins than the others.
-
BuS projects use a smaller number of project planning tools than either of the other two project types. However, they tend to make greater use of stakeholder analysis tools.
There’s more on variations between other sub-populations in the original paper – I’ve covered only the most interesting ones (from my perspective!). The interested reader is urged to consult the original paper for more.
As is clear from the above, the paper covers a lot of ground. As for the answer to the question posed at the start (and in the title of this post): project management practices are generic to a large extent, but there are variations depending, among other things, on organisational maturity, project size and project type.
I’ve already gone way beyond my normal word limit. However, I should mention a caveat before closing: as the author’s themselves note, the paper attempts to tackle the broad question of context dependence of project management practice by looking at a fairly narrow aspect of the practice – i.e. the use of tools and techniques. This is a limitation of the research. Nonetheless, their findings, which are interesting in their own right, vindicate the position that despite variations in specific practices, project management is a generic discipline with a wide range of applicability.
References:
Besner, C. and Hobbs, B., Project Management Practice, Generic or Contextual: A Reality Check, Project Management Journal, 39 (1), 16-33 (2008).
Eight to Late 