Eight to Late

Sensemaking and Analytics for Organizations

Archive for February 2008

The effect of organizational culture on project success

with 4 comments

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 CultureProject Management Journal, 38 (4), 12-24 (2007).

Written by K

February 26, 2008 at 6:22 pm

Portents of project failure

with 3 comments

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.

Written by K

February 21, 2008 at 6:49 pm

Posted in Project Management

An elegy on the failure of a project

leave a comment »

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.

Written by K

February 21, 2008 at 5:19 pm

A project management tragedy in five limericks

with 9 comments

With many changes we had to cope
Deadlines near; no money, no hope.
There was no way to wrangle,
with the iron triangle
of budget, time and scope.

The project was  in a mess.
The reason I could only guess
was the carefully constructed
schedule was busted,
thanks to a dodgy WBS.

When called to explain the delay
I told the sponsor to pray.
When he asked, “But, why?”
I said with a sigh,
“On the critical path the tasks lay.”

He said to me, “This can’t be true.
There must be something you can do.”
Shaking my head
in sorrow, I said,
“All that remains is review.”

And now, I’m not in his pay,
You see, I was fired that day.
So, I exhort you all,
to stay on the ball,
and don’t run your projects this way.

Written by K

February 16, 2008 at 2:38 pm

W(h)ither, Corporate IT?

with one comment

Nicholas Carr’s latest book, The Big Switch: Rewiring the World from Edison to Google, predicts that corporate information technology (IT) shops will eventually be replaced by computing utility companies akin to the power and water utilities we’re all familiar with.  Carr’s writing is always interesting and thought provoking,  so I’ve duly placed an order for his book (which I’ll review in a later post). The central thesis of the book, the switch to utility computing,  appears to have evolved from the ideas he articulated in a piece entitled, IT Doesn’t Matter, which was published in the May 2003 issue of Harvard Business Review (HBR).  I read the article not long after it first appeared,  and filed it away as something I’d want to read again later.  With the book just out,   now is perhaps a good time to take that second look,  and discuss some of the consequences for those who work in corporate IT.

The basic thesis of IT Doesn’t Matter is:

There is no strategic advantage to be gained from maintaining in-house IT departments because IT is fast being commoditised.  As a consequence of easy access to all, it no longer confers distinct advantages on any.

In the article, Carr draws a parallel between the present-day computing industry and power utilities at the turn of the last century. He points out it was common for industries in the late 1800s to have their own in-house power generation plants. At the time electricity was a scarce resource that offered manufacturers distinct advantages over traditional power sources such as water mills. Hence those who could built their own, and thus gained a strategic edge over those who didn’t. Power utilities changed everything by bringing cheap, reliable electricity to the masses.   Once this happened, any industry  – big or small, rich or not so rich – could access electric power inexpensively without having to go through the hassle of generating it themselves.  In-house power plants went the way of the pterodactyl and the rest, as they say, is history.  

Carr argues that the IT industry is being rapidly commoditized in much the same way as the power, railroad and water utilities were in the late 1800s. That this is happening today  is undeniable, and is apparent   from the increasing number of vendors providing fee-based hardware and software services.

As might be expected, the article generated a lot of discussion. In June 2003 HBR published a “debate” featuring a selection of letters along with Carr’s reply. Additionally Carr maintains a compilation of annotated links to article responses on his Web site.   I found it interesting that many corporate IT professionals tend to agree with Carr (in substance, if not detail)  but big  vendors and consultants, who potentially stand to gain from the change,  don’t.

What do I think?

Well, it is clear that Operational IT – the “lights on” business of keeping servers and networks humming along – is already halfway (or more!)  there. Countless providers offer  dedicated servers at very affordable rates, with the added attraction of not having to deal with any of the maintenance issues in-house. Many small businesses do just this, and larger ones consolidate several small IT units into  internal data centres.

For IT Development, however, the case isn’t quite as clear. Granted,  shrink wrapped products such as MS Office face competition from open source products and web-based software services, and at the other end of the spectrum, large enterpricey apps such as <insert any random ERP or CRM system here> can, and are, being provided as services too. In the middle, though,  lie countless applications that address important business needs,  but are too small and specialised to be of interest to potential providers of computing services.  What about these? Well,  present-day software such as spreadsheets and desktop databases  are loaded with features that enable technically savvy business users to build their own specialised applications.  Many end-users do so (thereby causing much angst to those who run corporate IT!).  Additional features and improvements in the useability of such software will only accelerate this trend, thereby obviating the need for dedicated IT resources to build and maintain these applications.   

What remains then? Clearly, not much in the way of technical jobs. Yet, corporations of the future will need people to manage vendor relationships, run projects and provide unbiased technical advice. These folks would need to have:

  • A good understanding of the business.
  • Good communication skills.
  • The ability to manage complex vendor relationships.
  • The ability to manage complex projects involving external parties.
  • A broad (but not necessarily deep) technical knowledge.

The future corporate workplace envisioned by Carr will be radically different from the one IT professionals are familiar with. However, it will have a place for those technical people who focus on business issues rather than technology. 

Written by K

February 14, 2008 at 5:29 pm

Obstacles to project communication

with 14 comments

Communication is so important to project success that it has been referred to as the life blood of a project by more than one practitioner.  A recent post by Jack Vinson talks about the importance of  communication across project interfaces – interfaces being  boundaries between different groups within an extended project team.  He views  interfaces as constraints that limit project success. On reflection, I realised that many project communication issues  I’ve encountered have, in fact, occurred at interfaces.  In this post I explore the notion of an interface as an obstacle to project communication.

To keep things concrete, I’ll frame the discussion and examples in the context of projects in a corporate IT environment. For these projects the most common  interfaces are:

  • between organisations (customer-supplier, for example),
  • between departments within an organisation (marketing-IT, for example),
  • between teams within a department (testers-developers, for example) and
  • within distributed teams (part of the team is in Boston and the other in Sydney, as an extreme example).

In my experience, the main communication obstacles  (across interfaces listed above) can be boiled down three broad ones. I list these below with some pointers to how they might be addressed:

  • Political: Whenever there are many groups involved, there’s the possibility of vested interests and power games getting in the way of dialogue. Such political obstacles usually originate in the upper ranks of an organisational hierarchy, a step or two above levels at which projects are planned and executed. Project managers therefore need to make special efforts to be aware of the key political players in the organisation. In traditional corporate environments these might be functional or senior-level managers who aren’t always obvious project stakeholders.
    Once the political players have been identified, the project manager should take steps to gain their confidence and buy-in on project goals.  This should help eliminate political barriers to project communications. In my experience, it is best to settle political issues at the level where they originate – escalating political problems up the hierarchy (i.e. to the manager’s manager)  generally doesn’t help, and may even be counterproductive. Always keep in mind that political issues need to be broached with tact and finesse;   inept handling can be a CLM. You have been warned!
  • Cultural:  I’ll first deal with organizational culture , which is essentially the totality of assumptions and values commonly held within an organization. Clearly, this can vary considerably between organizations – some may be more open than others, for example.  Communication at the interface between two organisations with vastly differing cultures can be difficult. For example, one might expect some differences of opinion at a joint project planning session involving a very forward-looking, can-do supplier and a conservative, risk-averse customer. Another example:  in one organisation it might be considered perfectly natural for a developer to air a dissenting opinion at a meeting whereas in another it might not. Project managers can ease such difficulties by understanding the divergences in attitudes between the parties involved, and then acting as intermediaries to facilitate communication.
    In geographically distributed (or virtual) teams, differences between regional cultures can come into play. These could manifest themselves in a variety of ways such as differences in fluency of language, or social attitudes and behaviours.  Here again, the project leader, and the rest of the team for that matter,  need to be aware of the differences and allow for them in project communications.
  • Linguistic: Here I use the term linguistic in the sense of specialised terminology used by different disciplines such as Accounting, IT, Marketing etc. Often when specialists from diverse areas get together to discuss project related matters, there’s a tendency for each side to make assumptions (often tacitly) regarding a common understanding of specialised jargon. This often leads to incomplete (at best) or incorrect (at worst) communication.  An article I wrote some time ago provides suggestions on improving cross-disciplinary communication in projects. If done right, project communication can help align IT goals with those of the business

A wise old project manager once told me  that over ninety percent of project issues he’d encountered could be traced back to communication problems.  I’m not sure I can vouch for that number from personal experience (I haven’t counted, to be honest), but I’d have to agree that he’s right in spirit, if not in number.  

A shared world-view –  which includes a common understanding of tools, terminology, culture, politics etc. –  is what enables effective communication within a group.  Project managers  can facilitate a common understanding  in their projects by analysing and addressing communication constraints at  interfaces. 

Written by K

February 7, 2008 at 6:43 pm

%d bloggers like this: