eight to late

CIOs the world over struggle to keep up with ever changing business requirements. At the same time, many companies feel short-changed by their IT departments, which end-users often perceive as being inflexible and slow to respond to changes in business needs. This lack of flexibility can usually be traced back to TItanic-like enterprise systems which straitjacket businesses into certain ways of doing things. In an article entitled Radically Simple IT published in the March 2008 issue of the Harvard Business Review , David Upton and Bradley Staats propose a “novel approach” to the design and development of enterprise systems. They call the approach path-based because it provides a path for systems to be developed over time, incorporating changing (or missed) requirements along the way.

The path-based approach is based on the following tenets:

• Meld IT and business strategies together: The authors reckon that IT-business alignment, as it is usually presented, is hard to achieve because of a lack of mutual understanding between the two sides (this is something I’ve alluded to in an earlier post on project communication). Most discussions between IT and business tend to focus on individual projects rather than the big picture. The latter, however, is integral to a path based approach. To ensure that both sides understand each other, the authors suggest that IT staff be encouraged to understand the business and vice versa. This recommendation is far from new - see this article from 2005, for example.
• Keep things as simple as possible: The article recommends that CIOs should strive for simplicity in their IT environments, thereby ensuring that systems remain flexible (i.e. open to change). Some ways to achieve this include:
  • Adhering to a minimal set of standards, so that the company has a standard operating environment at the client and server level. Additionally, standards should be recommended for specific applications.
  • Evaluating whether new functionality requested by the business can be provided by existing software.
  • Looking for simple solutions before buying or building complicated ones.
  • Developing a modular enterprise architecture . This is essentially the notion of loose coupling - where individual systems are built in such a way as to minimise effects and dependencies on other systems.
• Empower end-users: All project and IT managers know that the biggest resistance to new systems often comes from end-users who, quite naturally, are reluctant to change their ways of working. Without end-user buy in, any new system is doomed to fail. The authors recommend reducing such organisational resistance to new applications by rolling out changes gradually. They also recommend soliciting user feedback on a continuous basis. The feedback should be acted on (and be seen to be acted on) in a timely manner so that users know their input is taken seriously.

The above principles are hardly new or radical, and few CIOs would question them. The path based approach really amounts to a consistent application of these in a (often difficult and ever changing) business environment. The authors illustrate the approach through a case study based on the experiences of Shinsei Bank. The case study is helpful because it provides concrete examples of application of the principles discussed. For more on the Shinsei story, read  this transcript of an interview with Jay Dwivedi, the CIO responsible for implementing a path-based approach at that bank.

The article is well written and makes a good case for implementing such an approach in just about any corporate IT environment. However, many CIOs - particularly those stuck in organisations that don’t appreciate the strategic value of IT -  will find it hard  to put these principles into practice. But try they must, else their departments will continue to be viewed as cash sinks rather than strategic assets.

The knowledge gained during the implementation of a project is often lost after the project is completed. This loss carries a huge cost as future project teams have to rediscover lost knowledge, or reinvent the proverbial wheel.  Although learnings are often (or should I say ”sometimes”?)  documented in project post-mortems or lessons learnt documents, these are rarely, if ever, read by project teams down the line.  Management and transfer of knowledge involves complex processes which, in turn, depend on several factors that vary from organisation to organisation. One such factor is organisational culture.  A recent paper entitled, Knowledge Transfer in Project Based Organizations: An Organization Culture Perspective, published in the Project Management Journal investigates obstacles to knowledge transfer in project-based organisations, with particular emphasis on the role of organisational culture. I summarise and review the paper below.

The authors begin by a brief overview of what is meant by knowledge and how it is created. They distinguish between data (unprocessed facts), information (meaningful aggregations of data) and knowledge (information that is processed and filtered on the basis of an individual’s perception, skills and experience). Knowledge involves  assimilation by the human mind whereas data and information do not. The authors also draw a distinction between explicit and tacit knowledge, i.e. that which is documented and that which is undocumented, often existing only in people’s minds.  According to the SECI model proposed by Nonaka and Takeuchi,  new knowledge is created by an interaction between tacit and explicit knowledge through the processes of Socialisation, Externalisation, Combination and Internalisation. Other researchers claim that explicit knowledge is an extension of tacit knowledge to a new level, whereby it is “consciously known” and hence can be transferred to others.

The authors then move on to discussing how knowledge is transferred. Their discussion is based mainly on a paper by Nissen and Snider (see abstract), which describes three views of project-related knowledge transfer:

1. As solution - wherein knowledge is transferred on the job - i.e. when working on projects. In this perspective, managers facilitate knowledge flow by ensuring selection of appropriate technologies  and motivating individuals to use them.
2. As experience - wherein knowledge is transferred by capturing experiences (by documentation, for example) for future reference. Here the emphasis is on flow of knowledge across time. An example of this is when knowledge is transferred from one project team to another. 
3. As socially created -wherein knowledge is created (not transferred!) through interpersonal interactions (discussions, arguments and other informal communications). The challenges associated with this form of knowledge transfer are primarily in fostering an organisational culture that encourages informal communication. Although this may be considered outside the ambit of a project manager’s responsibilities, a project manager can  help by fostering a communication-friendly culture within the project team.

The authors then point out that project management has grown beyond its traditional role of planning, controlling and monitoring projects to a more strategic role of resource optimisations and inter-departmental collaboration - which ultimately ends up providing better customer service.  I’m not sure why they throw this point in, as it seems like a side issue to the main focus of the paper. Perhaps it is to emphasise that effective knowledge transfer processes become more critical as project management takes on a more strategic role in organisations.

Project teams are often required to find and assimilate knowledge that exists in organisational memory. The authors suggest that this task is easier in functional organisations than in projectised ones, because in the former, knowledge is organised and stored by department (and hence, presumably, easy to find).  I beg to differ: In my experience the task can be just as hard in functionally structured organisations.  This is true for most of the other knowledge transfer obstacles they mention, such as: volume of documentation, no time to document etc. etc. My point: knowledge management problems listed by the authors aren’t unique to project-based organisations.

Next the paper looks at the classification of project-related knowledge. Here the authors follow the work of Conroy and Soltan, who suggested that all project-related knowledge falls into one of the following: an organisation knowledge base, a project management knowledge base and a project-specific knowledge base; each being developed (or augmented) during the implementation of projects. Since projects are the only means via which knowledge bases are enhanced, it is important that project learnings are captured effectively.

Having discussed the need to capture project knowledge and the importance of project-specific knowledge, the authors move on to a discussion of obstacles to knowledge transfer in projectised organisations. They identify the following road blocks to knowledge transfer:

1. Project constraints leave little time and resources for effective documentation of knowledge.
2. The existence of significant social and cultural barriers to knowledge transfer. These are things such as: lack of openness, no tolerance of failure, blame culture etc.
3. Lack of motivation (or incentives) to undertake project reviews. This is the well known wiifm factor.
4. Lack of leadership that accords enough importance to developing the organisation’s knowledge base.

The authors contend that these issues boil down to inadequacies in organisational culture. Stated another way: the transfer of intrinsic knowledge (which exists in people’s minds) can occur only in an organisational culture that supports it.  This definitely rings true, and I don’t think any project manager would argue with it. I would add that the aforementioned obstacles are alive and well in all organisations - not just project-based ones.

Having established that a supportive organisational culture is critical to knowledge transfer, the authors move on to  discussing the cultural variables that promote knowledge transfer. In particular, they discuss models by West and Schneider.

West proposes the following two dimensions of organisational culture:

1. Flexibility versus control: this measures the degree of organisational control. Specifically, flexible organisations tend to have flat hierarchies, decentralised decision making as opposed to controlled organisations which have rigid (and often deep) hierarchies and centralised decision making.
2. Internal versus external orientation: this measures the degree to which the organisation is affected by its cultural environment. Although organisations are situated in a greater cultural context, the extent to which they are affected by it can vary.

As compared to control-based organisations, flexible organisations are characterised by flat hierarchies and decentralised decision making.  The authors mention that rigid structures and hierarchies promote efficiency, though often at the expense of innovation and collaboration.   In my experience in control-based organisations, the emphasis on efficiency and control often leads to an overemphasis on process, which is ultimately what reduces any possibility  of collaboration and innovation.

In contrast to West, Schneider proposes the following dimensions of organisational culture:

1. Possibility versus actuality: this relates to what the organisation focuses on - potentialities or facts.
2. Personal versus impersonal: this relates to how decisions are made in the organisation - process driven (i.e. by logic) or based on feelings, beliefs, ideals (i.e. all those “warm and fuzzy” notions).

These axes divide the universe of organisations into  four core cultures:

1.  Control: a process driven culture which values certainty and predictability above all.
2.  Competence: a culture that values excellence (in services or products). These organisations aim to have unique or best of breed products and services.
3.  Collaboration: this culture emphasises close connections with customers and collaborative working towards developing products or solutions. This is essentially the  opposite of a competence culture. 
4. Cultivation: this  culture emphasises openness, autonomy, ideals and ideas. These organisations tend to be innovative. This is essentially the opposite of a control culture.

It is intuitively clear that the above dimensions of organisational culture will have varying effects on the efficacy of knowledge transfer. The authors, however, do not delve into these. So their coverage of models of organisational culture, as interesting as it is,  seemed a little pointless in the context of the paper.

Next the authors point out that since project teams consist of individuals drawn from various professions, one needs to consider the effect of professional culture as well. This is an interesting point, which complicates matters because different professional  cultures approach communication in different ways - the example of IT and business cultures being a particularly stark case in point.

Finally, the authors end with a very general discussion of how knowledge transfer can be promoted in projectised organisations. They suggest that managers should:

1. Recognise different levels at which knowledge is generated - i.e. individual, group and organisational. 
2. Appreciate the role of organisational culture in promoting or hindering knowledge transfer between these levels.  They suggest the primary barriers to knowledge transfer are cultural rather than technical (See this article by Suzanne Koudsi, for an interesting case study).
3. Understand the role that management plays  in fostering a culture that facilitates knowledge transfer. This is particularly true for project managers who have to deal with many different cultures (organisational, departmental and project team) simultaneously. Awareness of cultural differences can help managers find the cause of obstacles to knowledge transfer.
4. Appreciate the challenges involved in transforming organisational culture.
5. And finally, since projects are the coalface at which knowledge is generated, practitioners must understand the issues that need to be addressed to facilitate gathering and preserving of relevant knowledge generated during project implementation. Some examples of these include communication modes between team members, what worked well in the project, what can be improved and how it might be improved,  etc.

Having covered a lot of ground (somewhat skimpily, in my opinion), the authors conclude the paper with three very general statements:

1. Effective knowledge transfer can occur only if the organisational culture is open to accepting new knowledge transfer activities. Managers must therefore prepare the culture to accept, adopt and implement these activities.
2. In addition to knowledge transfer, knowledge management is also about fostering an organisational culture that encourages the creation, sharing and utilisation of knowledge.
3. Project managers have to merge myriad organisational, departmental and professional cultures into an effective project culture that promotes knowledge management.

Although project managers may appreciate these points (and I suspect many do), there’s little they can do about changing an organisation’s cultural mindset. All they can do is ensure that they establish a culture that fosters knowledge transfer within their  own projects (point 3 above). Some ways to do this include: encourage collaboration between team members, establish a no-blame environment etc.

In conclusion, the paper was reasonably interesting but somewhat hard to read because it was thin on detail, and occasionally veered from topic to topic without proper transition or introduction. I suspect this is because the authors assumed their readership would consist entirely of academics with a strong grounding in project management theory. This is a pity because the paper, if better written, could have been of considerable interest to practising project managers. So I end this review with a plea to  journal paper authors: when writing your paper, please remember that project management isn’t just an academic discipline.

References:

Ajmal, M. M. and Koskinen, K.U., Knowledge Transfer in Project-Based Organizations: An Organizational Culture Perspective, Project Management Journal, 39 (1), 7-15. (2008).

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 Check, Project Management Journal, 39 (1), 16-33 (2008).

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).

Many businesses implement their IT projects with the help of external parties such as consulting or software firms.  In these projects, the eventual outcome - success or failure -  depends critically on the relationship between the business (the customer) and the external party (the vendor).  At one extreme, the relationship could be almost adversarial - which happens quite often.  At the other, it could be collaborative - which happens not often enough.  A recent paper entitled: A negotiation approach to project sales and implementation, published in the Project Management Journal provides a framework to support  and enhance the latter approach.  In this post I review the paper from a practical perspective , asking the question, “Does the paper offer any insights or ideas of immediate value to a practising project manager?”.

The short answer is a qualified, “Yes”. Read on for more.

The authors contend that project related negotiations typically  suffer from the following shortcomings:

• Negotiations between the customer and vendor, which take place at various stages of the project, are typically ”local” - i.e. they’re made in isolation, without much regard to possible consequences on subsequent phases of the project.
• The parties approach each of these local negotiations with only their own interests in mind, leading to a win-lose or distributive approach wherein one party gains at the expense of the other.  
• People involved in the discussions are typically not trained negotiators. Consequently they approach the negotiations in an unsystematic manner. 

 To overcome these shortcomings the authors suggest the following:

• A project be viewed as a  continuous process of joint decision-making that lasts through the project. The operative words are the italicised ones - emphasising that optimal outcomes can only be achieved through:
  • a project-wide view as opposed to a local one and,
  • a win-win or integrative approach to negotiations.
• The discipline of  negotiation analysis  be used to analyse and prepare for negotiations.  

Negotiation analysis combines techniques from game theory, decision analysis and behavioural decision analysis . Additionally, negotiation analysis also includes subjective information, such as perceptions etc.,  that do not have analytical backing. It also  acknowledges that negotiations often end up leaving both parties with sub-optimal (or inefficient) outcomes. This essentially because the negotiating parties do not exchange information that would enable them to reach efficient agreements - i.e. the parties do not collaborate. The goal of negotiation analysis is to improve collaborative (or joint)  decision making to the benefit of all parties involved.

A large part of the paper is devoted to discussing the authors’ conceptual framework for project negotiations.  I suspect many practising project managers will find the treatment a tad theoretical and somewhat idealised.  That said, the authors do make practical suggestions on how a qualitative application of negotiation analysis can assist in managing project negotiations.  I found the paper interesting, and recommend it to practitioners, if only for the suggestions it offers in improving ad-hoc approaches to project negotiations.

References:

Kujala, J., Murtoaro, J. and Artto, K., A Negotiation Approach to Project Sales and Implementation, Project Management Journal, 38 (4), 33-44(2007).