Eight to Late

Sensemaking and Analytics for Organizations

Archive for March 2008

Are project management practices generic?

with one comment

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:

  1. Demographic information on respondents (position, education, experience)
  2. Industry, organisation maturity and project characteristics.
  3. 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:

  1. Ranking of tools by average use in the whole population and within sub-populations.
  2. 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:

  1. Progress report 
  2. Kick off meeting
  3. Scheduling software
  4. Gantt chart
  5. Scope statement

The bottom 5 (in decreasing order of use) are:

  1. Cause and effect diagrams
  2. Critical chain method
  3. Pareto diagram
  4. Simulation software
  5. 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 CheckProject Management Journal, 39 (1), 16-33 (2008).

Written by K

March 28, 2008 at 7:22 am

Reviewing documentation on a work day evening

leave a comment »

With apologies to Robert Frost (and a colleague who shall remain nameless).

Whose work this is I think I know.
He hasn’t done a good job though.
He will not see me over here,
reading his drivel pure as snow.

The cleaners must  think it queer
that I’m still working, though midnight’s near.
Between you and me – it’s late,
on the darkest night of the year.

I give my poor head a shake,
and ask, “Why so many mistakes?”
The only other sound’s the sweep
of the vacuum cleaner’s swift intake.

Slumber beckons, long and deep,
but I have this job to keep,
And files to go before I sleep,
And files to go before I sleep.

Written by K

March 26, 2008 at 10:16 pm

Posted in Communication, Verse

Solvitur ambulando

leave a comment »

I do most of my writing when I’m not writing.

Having said something so clearly contradictory, I think I owe you an explanation. The mechanical act of writing – what I’m doing as I tap out these lines – is obviously done whilst I’m at my computer. However, by the time I begin the keyboard finger-shuffle, I’ve already figured out what I’m going to write. Not just the topic, but much more.  I know what I’m going to write about, the introduction and (broadly) how I’m going to develop the piece.  The hard part – generating ideas and developing them –  has already been done. What’s left is the easy bit; the actual writing down of things I’ve already thought through.

Where do ideas come from? Answering this would take me into the realm of speculation, well beyond my knowledge and experience. So I admit complete ignorance and leave it there. In any case, I’m more interested in finding ways to get new ideas, rather than figuring out where they come from.

So here’s a more relevant question:  are there certain activities that assist in generating  new ideas? For me the answer is a resounding affirmative:  it is while I’m on my early morning walks that I get them.  A writer told me that walking was valuable  not so much for the exercise, but for the ideas. I didn’t believe her until I found the same worked for me. The ideas appear to come from nowhere (I refrain from using terms like subconscious, that I’m not sure I understand).  I could be thinking about something and then, out of the blue, I get this notion which is completely unrelated to the prior thought. It could be just a phrase or a sentence, the mere inkling of a piece, but I can usually tell whether it’s worth pursuing or not.

Once the nascent idea has my attention, I start thinking about how I might develop it.   I find it best to do this right after I get the idea, else there’s a good chance  that I’ll lose the context in which I conjured it up. Consequently, I end up doing a lot of my idea development while still on my pre-dawn perambulation. The development phase also acts as a filter – if the idea is hard to develop, it probably isn’t very good. As a rule of thumb, if I haven’t found a promising development in five to ten minutes, the idea is probably not worth pursuing. However, just to be sure,  I jot it down in a phrase or two (on my mobile, which always accompanies me) and come back to it a few hours or days or even weeks later. Often the second look confirms that the idea is good only for the garbage bin. Very occasionally, I go on to develop these further. My mobile memo pad is full of ideas that never took off.

I’ve stopped trying to analyse where the ideas come from – I’m just grateful that they do.  My AM ambles are a double benefit: exercise and ideas. So, if you’re suffering from bloggers block you could try some strategies for overcoming writer’s block. On the other hand, you could try a  morning walk instead. Solvitur ambulando – it is solved by walking.  

Written by K

March 22, 2008 at 11:37 pm

Posted in Communication, Writing

Dr. Do-little

with one comment

So you’re the hardworking techie who’s just been promoted to project manager. Congratulations and all that, of course, but I’m sure you realise that your new job has very little to do with your old one. Chalk and cheese or caramel and chilli are comparisons that come to mind.

“What’s that you say? You didn’t know?”

You shake your head. “They didn’t tell me,” you reply.

“Well, of course they didn’t,” I respond, and rush back home to continue this piece…

The transition from a techie to a project manager can be a difficult one. The biggest and hardest adjustment is  this: project managers are responsible for a whole lot of stuff that they don’t do themselves. The best way to explain what I mean is through  my own experience. 

As a project manager I’m responsible for the success of a project although I’m not directly involved in the nuts-and-bolts of its implementation. I depend on the team for the latter. In effect, as far as technical work is concerned, I’m Dr. Do-little – I do very little (if any) coding or design. 

So what do I do?  The facetious answer is:  I manage  projects.  To most people who don’t know what project managers do, this sounds like a Very Important Job. One  in which I get to order people around, tell them what  needs to be done and by when. The reality, as all experienced PMs know, couldn’t be more different.  The following paragraphs should serve to illustrate just how so.

A lot of my time and effort is spent in ensuring that others can do their work unimpeded by obstacles of any kind  – political, physical, communication-related or whatever.  (Ah, I see that look of disbelief on your face now  – but believe you me, it’s true.)  Some examples of this include: following up with vendors; making sure that a developer has the stuff he needs to proceed with cutting code;  resolving misunderstandings between developers or between developers and users, and so on.

Another aspect of a PM’s job is negotiation. Sometimes it seems that I spend entire days negotiating –  with team members (cajoling… no pleading… with them to get the module finished by Friday, as they’d promised) or with vendors (to try and get them to ship the hardware that was to have arrived yesterday) etc.

Finally, because I’ll be the first one out of the door if the project fails, it is in my interest to ensure things are on track. Here too, things aren’t black and white (or even red, amber and green as those wonderful traffic light status reports show) – they’re in several hundred fine shades of gray. A task can be late but still be under control. Even more paradoxically, it could be early but getting out of control. There’s way more to keeping projects on track than is detailed in status reports. You have to have an eye out for potential trouble,  or project banana skins as I’ve called them in an earlier piece. For example, a task could have finished early because the developer wanted to finish it up before resigning –   things are about to spin out of control and you’re not yet aware of it.

I may be Dr. Do-little in that I don’t cut code or do design. And although I don’t to a Very Important Job, I do a reasonably important one. Without my efforts, the project may well fail.  So, to the novice project manager I say:  welcome to the infuriating and frustrating world of project management. Remember,  in the end –  when your projects are successful –  it can also be very rewarding.

Written by K

March 20, 2008 at 10:00 pm

Posted in Project Management

Two project managers, one project

with 4 comments

Some projects are run by more than one project manager (PM).  The most common manifestation of this is on projects that have a clear distinction between business and technical responsibilities. In such cases it is  logical, not to mention efficient, to divide these responsibilities between two PMs –  one from the business and the other from the tech side. At first sight this arrangement appears to violate one of Henri Fayol’s principles of managementunity of command. Further,  with two people running the show, there’s an increased potential for confusion regarding roles and responsibilities. One is, therefore,  justified in thinking that two PMs on a project implies trouble (or should I say, double trouble?). However,  from experience I can say that such an arrangement works well, providing some simple and fairly obvious guidelines are followed. So, if you have the double-edged fortune of being one half of a project management team, here’s some unsolicited advice from someone who has been there:

  • Develop a good rapport with your counterpart: As I’ve written about elsewhere, communication is the basis of good project management. It is easier (and a lot more fun) to communicate with someone you like and get along with. Hence this is number one in my list: get to know your counterpart, socially if possible. Building a rapport (even better, a friendship) will help ease the inevitable tensions that crop up when the project is underway.
  • Divide all responsibilities: This is almost as important;  responsibilities must be completely partitioned between the two PMs. This means: 
    • all responsibilities are assigned to a PM  – i.e. no unassigned responsibilities and, 
    • no overlap – i.e.  each responsibility assigned to one PM only (never both!). 

    Note that this point addresses the apparent violation of principle of the unity of command

  • Help each other: Yes, despite what I’ve said in point two, you will occasionally need to help each other. This could, for instance, be by helping out with hard tasks or covering for your counterpart while she’s away. Remember, you never know when you’ll need help yourself. So, offer assistance, if only for selfish reasons!
  •  …but don’t tread on each other’s toes: After all is said and done, you and your counterpart are individuals. Respect that by not barging into each others territory. There’s a difference between offering help and interfering – though, some people seem to find it hard to make this distinction.  As an example,  don’t  offer unsolicited advice (unlike me!), unless you’re sure it will be taken in the right spirit. 
  • Make joint presentations at sponsor meetings: You and your counterpart are a  leadership team. Giving joint presentations to sponsors reinforces the notion that both of you are jointly responsible for the project.

Running a project with another person can be an enjoyable experience. Yes, each of you will have to adjust to the other’s management style and quirks. However, you’ll both find that this effort is repaid many times over through the support and assistance you receive from each other.

Written by K

March 17, 2008 at 5:23 am

Posted in Project Management

Solutions in search of problems

with one comment

History repeats itself;  first as tragedy, then as farce – Karl Marx.

Although Mr. Marx didn’t say anything about repetitions beyond the second, one can safely assume he would have considered them beyond farcical. Yet, in the world of corporate IT, we’re continually faced with the following repeat offender:  the solution in search of a problem (or SSP).  I should define the term before I go on – a SSP is a project that has been sanctioned without any regard to  the actual value or utility of the deliverables. This post is aimed at assisting project managers in identifying a SSP, so that they can take appropriate action when confronted with one. This basically amounts to of the following: sidestep it (i.e. duck it somehow), step down (i.e. resign) or suffer (i.e. accept the responsibility of managing the project and, well, suffer).

So, here we go then, seven deadly signs of SSPs:

  1. No one knows what the project is about. Everyone talks about it, but no one seems to know why it is being done.
  2. It’s all about technology or standards (SOA anyone?), not the business. The justifications on offer for the project are seasoned with phrases like “best practice” or “state of the art technology”; terms that  have more to do with technology than business need.
  3. There’s a committee responsible for implementation (often with a global reach). You’ve got to love global committees with their 10,000 metre view of ground level realities. Most recommendations that emerge from these are either so general as to be unusable,  or worse –  patently incorrect. 
  4. Since no one knows what it’s about, the project is more about the means than the end. Put another way, project management processes or process improvement methodologies in their full bureaucratic glory will reign supreme. Be sure that you’ve filled in all the right forms and have all the right signatures, else all hell will break loose.  
  5. No one is aware of a successful implementation: The global committee has little to show for their three years of the project, barring the pilot they did two years and nine months ago,  involving 1.5  users. 
  6. The project will replace a perfectly good existing solution: You have a good system in place? Don’t worry, the SSP will replace your tried and tested solution with  one that will give your staff many  hours of debugging fun, and the gray hairs to prove it. 
  7. And finally: these projects often originate in the upper reaches of the corporate hierarchy, where the connection with  ground level reality is somewhat tenuous. Corporate mandated projects have a fair chance of being SSPs.

So, it isn’t hard to spot an SSP. What do you do if confronted with one? Well, that’s up to you. As mentioned earlier, you have three options: sidestep, step down or suffer. The choice is yours.

Written by K

March 17, 2008 at 12:50 am

Certifiably mistaken: two wrong reasons for pursuing project management certification

with 6 comments

Project management certifications are booming. However, it seems to me that the main beneficiaries of the certification gold rush are the certifiers, not the certified.   There are a lot of articles aimed convincing people of the value of certifications. Here I take a different, and possibly contrary approach: I’ll give you two common, but (in my opinion) wrong, reasons for pursuing PM certification.

My motivation for writing this post is a recent conversation I had with a colleague. It went like this:

“Do you think a PM certification is worth the effort?” 

“Depends on what you want out of it,” I replied.

“Well I reckon it will make me a better project manager and help me stand out from the crowd .”

Now I don’t remember what I said in reply, but he’s wrong on both counts. Here’s why:

  1. To become a competent project manager: A cert does not a PM make. Preparing for a certification will teach you formal project management processes  as decreed by  a particular certifying authority. These processes are easy to learn  by reading a book or two. The “hard bits” of project management – negotiation, people skills, crisis management, conflict resolution, prioritisation, stakeholder management (I could go on and on but I’m sure you get my point) – are not, and cannot be, learnt through certification.
  2. To stand out from the crowd: The fallacy here is easy to see: certifying authorities push their credentials like there’s no tomorrow, hence the number of people gaining certs is growing rapidly. That being so, the “stand out from the crowd” factor is getting smaller and smaller every day. 

Before I conclude, I should come clean and admit that I have a cert or two. My main reason for getting certified was (is!) that it is a good way to learn about commonly used project management processes and the associated terminology.  The certs don’t make me a better project manager, and they won’t help me get that dream job either. However, they do help me recognise jargon-laden bulldust when I hear it (which, unfortunately, is  quite often). 

In the end, formal knowledge is always useful. So, gaining a cert won’t hurt,  but be sure you aren’t doing it for the wrong reasons.

Written by K

March 11, 2008 at 8:21 pm

Posted in Project Management

%d bloggers like this: