The effect of organizational culture on project success

It is a truism that two organisations using the same project management practices and structures will have different levels of success with them. Clearly, there’s a lot more to project success than project management. Despite this, most studies of project success tend to focus on  project level, or operational, variables such as  level of user involvement, use (or not) of a formal methodology, reliability of estimates etc (Note: these variables have been taken from the oft quoted Standish Report). As important as these factors are, they fail to take into account that projects live and evolve in a wider environment which includes the sponsoring organisation.   A recent paper entitled, New Product Development Projects: The Effects of Organizational Culture published in the December 2007 issue of the Project Management Journal, studies the effect of organisational culture on project success with specific reference to new product development (NPD) projects.  I summarise and review the paper below.

The authors claim that despite the importance of NPD projects for the long term success of an organisation, the effect of strategic level variables (organisational culture, organizational strategy, management involvement etc.)  on project success has not been widely studied. They suggest this might be so because these variables are hard to define, quantify and measure.  Further, on reviewing the existing literature, they find that the few published, organisation-oriented studies tend to focus on the end result of the development process (i.e. the product) rather than on factors affecting the project. Hence the motivation for their study.

Incidentally, they note that there has been some work on the effect of national culture on NPD project performance,  but these studies find no correlation between the two.

To measure something as elusive as organisational culture, you first have to pin it down by defining it. The definition does not have to be all-encompassing, but it needs to be precise enough for people to have a common understanding of what you’re talking about. To do this, the authors created a set of questions based on various definitions of organisational culture available in the literature. The resulting questionnaires were mailed out to various organisations engaged in NPD projects. The responses received (from over a hundred organisations) were analysed using  exploratory factor analysis,  enabling the authors to group the questions  into the following dimensions of organisational culture:

• Positive work environment: this includes factors such as
  •  openness to new ideas,
  • employees feeling valued as individuals,
  • open discussion with superiors encouraged etc.
• Management leadership:  this includes factors such as
  •  clear goals set and responsibilities delegated,
  • employees have input in decision making, 
  • incentives offered to work on new ideas, 
  • high-risk high-return projects encouraged etc.
• Results orientation: this includes factors such as
  • employees are pressured to finish work,
  • correct procedures more important than correct results etc.

These dimensions define organisational culture for the purposes of their study. 

To measure project success, the authors use the following dimensions adapted from Griffin and Page:

• Consumer-based:  the customers are satisfied with the product. This can also be classed as Customer Satisfaction.
• Commercial success: the product makes money
• Technical success: the product works as intended.

Note that these variables are actually a subset of those suggested by Griffin and Page. 

Project success was measured by getting upper management in the surveyed companies to rate product success along each of the above dimensions.

Finally, the authors correlate organisational culture to product success (for the surveyed companies) using correlation and regression analysis. The results (which are really no surprise) indicate that:

• Positive work environments and management leadership are strongly correlated with each other and with the three measures of product success. That is: 
  • Strong management leadership and positive work environments go hand-in-hand. 
  • Companies with positive work environments (and, by implication, strong management leadership)  have better commercial success with new products, enjoy better customer satisfaction and have greater technical success than those with less positive work environments (and, by implication, weak leadership).
• Results orientation is not strongly correlated with any of the other variables. If this seems surprising at first sight, take another look at what goes into making up this variable and it will seem less so!

Although the paper focuses on NPD projects, I think the conclusions – especially those pertaining to customer satisfaction and technical success –  apply to other  projects  as well.  Further, though the conclusions may be obvious to many, such research is important because it lends analytical backing to otherwise intuitive notions. It does this by:

• Defining (albeit, in a limited way) what is meant by organisational culture and project success.
• Studying the relationship between the variables that make up the two. 

Defining variables and quantifying relationships can give us a sense for which organisational culture variables are the most significant determinants of project success. So, although the study is a preliminary one (as the authors themselves admit), the work is a useful step in understanding the relationship between projects and the larger environment in which projects live and breathe.

References:

Belassi, W., Kondra, A. Z.,  and Tukel, O. I., New Product Development Projects: The Effects of Organizational Culture, Project Management Journal, 38 (4), 12-24 (2007).

Portents of project failure

Most project managers have had to deal with a failed project or two. Unfortunately, by the time it is recognised that a project is in trouble, it is often too late to do anything about it.  Many project failures, however, are presaged by other, less serious problems. It is useful to keep an eye out for these so that one can take action to prevent subsequent disaster. To use a medical analogy, it is best to to identify sick projects before they become terminally ill. As doctors say : the earlier the diagnosis, the better the prognosis.

So here they are,  six symptoms of sick projects (in no particular order):

• Low team morale: Team members complaining that things are out of control and that they can’t cope is a sure sign of trouble ahead. Solution: get to the root cause of the problem. Figure out why they think “things are out of control” or “they can’t cope”. You need to find the underlying cause for their angst before you can address it.
• Chronic buck-passing:  A typical case of this might be where a team member says, “I coudn’t finish on time because X didn’t give me what he was supposed to last week.” Project roles and responsibilities should be defined in the plan, and I’m assuming that this is the case (if not you have bigger problems!).  In a  situation where responsibilities are defined, buck-passing is usually a consequence of communication breakdown across a project interface.  This has to be handled by smoothing out the obstacles to communication.
• Sponsor loses interest (or worse, quits!): A sponsor quitting is a situation that a project manager can’t do much about, except be aware it might (will!) impact the project. Loss of interest, on the other hand, could mean that the business no longer considers the project important. Whatever the reason, it is probably best to speak to the sponsor to find out more.
• Chronic distractions: This is possibly the most common one I’ve come across. It typically happens in corporate environments where team members are temporarily “loaned out” to the project team. The demands of their regular jobs still remain and consequently they’re continually pulled away to do non-project tasks. The way to handle this is to speak to the relevant managers, reminding them of the importance of the project and their original commitment to it. As a last resort, one might need to involve the sponsor. The preferred option, however, is to settle the issue at the level of the manager.
• No one in-charge:  This is really a variant of the previous point, but is important enough to stand on its own. It typically happens when the project manager is a part-timer who has to focus on his or her real job whilst (additionally) looking after the project.  Although such an arrangment might work for a small project with limited scope,  it will not do for a project of any decent size.  It still surprises me how many important projects (such as ERP implementations) are run by part-timers.  Although the people involved do their best,  part-time attention is rarely enough to stay on top of the complexity of the project.
  I should also add that this can also happen when a project manager is incompetent!. This, however, is much rarer as such folks tend to get weeded out of the profession before they get to handle a big project.
  In either case the solution is to get management to understand that (competent!)  full time attention is necessary for project success.
• Lack of familiarity with technology or processes (coupled with the lack of external help): This one is common enough. I’ve seen several frustrated project teams struggle to familiarise themselves with an unfamiliar technology whilst attempting to use it in a project. The time to a learn a new skill is before the project. It’s too late to throw people into training after the project starts; they need to learn and practise the technology well before that. If your team doesn’t have the necessary skills,  for heaven’s sake get help from outside. Else you’ll kill morale along with the project.

To sum up, projects rarely fail without warning. It is helpful to keep an eye out for signs that a project is heading south, and to act on these before it’s too late.  To this end, I’ve listed a few of the symptoms of sick projects. I’d welcome your contributions to the list via your comments.

An elegy on the failure of a project

I’ve written a project tragedy in limerick form earlier, so I thought I’d try an elegy this time.

Those interested in sampling a real elegy written by  a real poet will do well to read Elegy on the death of a mad dog  by Oliver Goldsmith, instead of my sorry attempt below. Anyway, for what it’s worth, here’s my first (and I promise, last!)  elegy commemorating the failure of a project.

All ye PMs far and wide,
listen to this tale.
Of a project gone awry,
and verily doomed to fail.

It started many moons ago,
with a project plan
mapping how to reach the goal
within the time in hand.

Requirements were discussed,
in meetings way too long.
Where many stakeholders fussed
over details right and wrong.

The small and petty arguments
over matters rather trifling,
stalled signoff of documents,
causing a delay in starting .

Then all went well for a bit,
as deliverables were crafted.
Until, alas, the tech lead quit,
to the competition he defected.

The PM hunted high and low
for a replacement.
But despite the perks and dough
there was no applicant.

Progress slowed to a drag
as the days went by.
Team morale started to sag
and there was no wonder why.

The PM was soon commanded,
to explain the sorry state.
The powers that be demanded
his head on a plate.

So ends this tale so drawn
of a PM and his team.
Fortunately I woke this morn,
realising ’twas  a dream.