Archive for the ‘Organizational Culture’ Category
On the utility of project management techniques for new product development projects
New product development (NPD) is a critical activity for many organisations. Since it is often central to continuing business success, it is important that activities relating to NPD be managed properly. Most organisations that are involved in NPD use aspects of project management to run their product development projects. It is therefore of interest to ask: to what extent are project management techniques useful for managing NPD projects? This is the question addressed by Dirk Pons in his paper, Project Management for New Product Development, published in the June 2008 issue of the Project Management Journal. In his words, the paper aims to “…examine the existing research to determine the efficacy (or otherwise) of using project management for NPD and provide a case study for comparison…” In this post I summarise and review the paper.
The case study presented by the author is the development of a new dishwasher for a consumer white-goods company. The entire product lifecycle – from idea generation through design, testing, production, marketing, distribution, market growth, maturation, decline and withdrawal – is treated as a single project. I’m not sure I understand the rationale behind this. Wouldn’t it be more appropriate to focus on “genuine” development activities (i.e. from idea generation through to initial production) as the NPD project? Anyway, having identified the entire product lifecycle as his project, the author develops a high level WBS based on existing models of the engineering design process and then models the activities using Microsoft Project. The resulting model, the Project Management Body of Knowledge (PMBOK) guide and research literature are then used as a basis for evaluating the utility of project management for NPD projects.
Before going any further I should mention that, in my opinion, the author takes a restricted view of project management (with exceptions as noted below). His discussion focuses on project management as described in the PMBOK Guide. But project management is much more than one particular framework or methodology. There are a host of techniques – critical chain, or the plethora of methods that go under the banner of agile, for example – adaptations of which may be more suitable for NPD projects. A Big Design Up Front methodology, as implicitly advocated by PMBOK, may not be the best way to handle such projects.
Following the format of the paper, my review is organised according to the nine knowledge areas described in the PMBOK Guide.
Project Integration Management
This area is concerned with orchestrating the diverse elements (activities, resources etc.) that make up a project. In NPD projects, project management is more applicable to development activities (which can be planned and controlled) than to product conceptualisation (which can’t be planned or controlled). Further, as the author points out, companies may have more than one NPD project running simultaneously, often using common resources. In such cases resource management across projects becomes important. Using the example of Microsoft Project, the author contends that software is increasingly able to assist in managing project resources. Be that as it may, I think it is more important to focus on the strategic factors (such as business priorities) which determine resource allocation priorities across concurrent NPD projects ( business priorities etc.). These considerations are unfortunately beyond the scope of the paper.
Scope Management
Many NPD projects are subject to tight time constraints because of small windows of opportunity in the market. Hence time estimates for project activities have to be accurate. On the other hand, these projects are plagued by uncertainties – especially where innovative products are involved. Stock standard scheduling techniques such as CPM and PERT have limited utility in such projects as they are unable to handle the iterative and uncertain nature of product development activites.
The stage-gate method is a popular approach to managing uncertainty in NPD. As the author points out, however, “…there is surprisingly little research literature on the effectiveness of the stage-gate approach, and most of the claimed benefits are conjectural rather than substantiated…” . The fundamental problem is that the stage-gate method assumes that design is a deterministic process, i.e. it proceeds in a predictable manner. This is clearly not the case for many NPD projects.
On another note, NPD projects often assume that product development can be broken down into several relatively independent sub-problems. In reality, though, the sub-problems are rarely independent. The solution of one affects the other in a significant way. The author recognises that such distributed design problems, as they are called, cannot be treated by the “divide and conquer” techniques of conventional project management.
To sum up, the author recognises that uncertainty and complex dependencies (often unrecognised in initial stages) of the NPD process limit the utility of scope management processes outlined in the PMBOK Guide. In my opinion, novel ideas such as integrating agile and stage-gate methodologies may offer a better option. Unfortunately, the paper does not cover these areas.
Time Management
According to the author, the biggest problem with estimating time is bias – i.e. the inability of the estimator to be objective in his or her estimates. There are objective estimation methods – see my post on reference class forecasting for example – but these can be hard to apply in practice. Another technique that has been used to cure bias is the critical chain method. The paper does not refer to these or any other objective estimation techniques.
Bias also makes it difficult to get accurate, objective, percent-complete reports for tasks during project execution. The author claims there is no research done on the accuracy of self-reported percent-complete estimates. If this is the case, it is certainly an area where definitive research results could reap immediate practical benefits.
Cost Management
Project cost estimates are based on scope and time estimates. The author makes the point that deterministic project paths are generally assumed when estimating costs. Given the earlier discussion, it should be no surprise that this leads to inaccurate cost estimates.
Regarding the specifics of cost estimation, the author makes several points. He suggests that the strategy employed to manage costs can be important. For example, research has shown target costing could be inappropriate when the product is differentiated on factors other than cost. As far as costs are concerned, the main variable costs in NPD are those relating to labour. These costs can be hard to allocate properly, particularly if resources work on multiple projects. From the project management perspective it is important that only time spent working on product development is costed to the project. The author recommends handling this allocation through project management software.
Since the paper focuses on the PMBOK Guide as the basis for discussion, I expected a comprehensive discussion on the use of earned value in NPD projects. However, the author only makes the comment that earned value metrics have several different definitions, pointing out that this needs to be resolved to avoid confusion.
Quality management
As I’ve stated in my ruminations on quality, it is important to realise that the term “quality” means different things in different contexts. The author’s discussion of quality looks at a couple of project management approaches, and finds both lacking for NPD projects.
Firstly, he points out that the PMBOK view of quality borrows heavily from Total Quality Management. Consequently, most of the items discussed therein are relevant to production processes rather than NPD project management. Factors that are important for NPD projects include functional and production quality standards and aesthetic considerations. It should be noted that there are two perspectives of quality here – consumer and producer. The former includes functionality and aesthetic considerations whereas the latter includes production quality. In NPD, the former considerations are paramount – after all, one wants to make a product that consumers will want to buy. The PMBOK guide has little to offer on this.
The paper also discusses quality from the perspective of lean project management. Lean project management attempts to optimise resource usage by adapting ideas drawn from lean manufacturing. Some examples include: just-in-time scheduling, minimisation of inefficiencies and waste etc. However, these will be more relevant for non-NPD projects (such as packaged software implementation) than for NPD projects. As the author mentions, lean project management is not likely to be useful for NPD because it removes organisational slack which in turn reduces one’s ability to deal with uncertainty. Further, lean project management does not provide a method for design, which is central to NPD.
Human Resource Management
The author rightly points out that the PMBOK Guide has little to say about social and behavioural aspects of HR management such as organizational culture and team dynamics. These are important for all types of projects, but even more so for NPD projects. The “mechanical” aspects of HR – definition of roles and responsibilities, staffing, task allocations etc. are well covered in the PMBOK Guide, but then they are also more straightforward to implement.
NPD projects often involve cross-functional teams drawn from various departments within the organisation. This has associated challenges. As an example, departments have to find temporary replacements for persons loaned out to the project. As another, it can be challenging to integrate people from diverse professional backgrounds into a team. There are also stresses associated with uncertainty and the temporary nature of projects.
The author draws attention to the area of strategic human resources management (SHRM), which he defines as the design of HR practices that encourage certain (desirable) staff behaviours that (are believed to) contribute to organisational success. He points out that SHRM might be particularly relevant for NPD, but that it has not yet been integrated into project management practice. On the other hand, he also mentions that certain SHRM practices can actually be counterproductive. For example, incentives may lead to suppression of open communication between team members (there being more incentive to hoard knowledge than to share it). In this context, the author points out that some SHRM research shows that input control (team selection, training etc.) tends to promote innovation but output control (incentives, performance management) may inhibit it. He makes the excellent point that current practices emphasise the latter over the former, to the detriment of many organisations. HR departments would do well to take note – efforts should be focused on hiring and training, not on managing performance.
The author concludes the section by noting that the PMBOK Guide is of limited relevance as far as HR management is concerned, and that NPD project managers may find it more useful to look at SHRM literature instead.
Communications Management
The PMBOK Guide focuses on communication between a team and other parties external to it (such as stakeholders), but has little to say about communication within the team. Smooth and open communication within a team is important for any project, not just those involving product development. Teams that communicate effectively are able to solve problems more efficiently. The author also makes a mention of the role of technology in enabling collaboration within teams. Although he doesn’t say so explicitly, this is more relevant for distributed teams.
The author also makes a brief mention of the role of communication in enabling knowledge transfer. There is a vast literature on this in relation to project management. In earlier posts, I have commented on effective knowledge capture and the role of organisational culture on effective knowledge transfer in projectised organisations. Many of the considerations highlighted in those posts apply to NPD projects as well.
Risk Management
The PMBOK Guide views risk management as consisting of the following processes: risk management planning, risk identification, risk analysis, risk response planning and risk monitoring and controlling. Since NPD projects are inherently uncertain, managing risk is a significant aspect of these projects. The author points out that these projects typically employ risk management principles and techniques that go beyond PMBOK’s view of risk management.
Procurement management
This deals with activities relating to the management of the purchase of goods and services for the project. Some projects engage contractors to perform all or a part of the work; some others may outsource work. In either case this involves setting up of and management of contracts and other agreements. These are the main focus of procurement management as laid down in the PMBOK Guide.
In the case of NPD projects, the author recognises that a lot of consumer electronics products consist of a large number of parts. It is unusual for an organisation to have the capacity to produce all components in-house. Outsourcing is thus inevitable and must be managed. This highlights the need to develop and maintain strategic links with suppliers, an area not covered in the PMBOK Guide.
The above considerations are more relevant for the production phases of the product lifecycle. They have a limited role in the important phases of NPD, such as product conceptualisation and design.
Implications
Based on references to research literature the author establishes that there are significant gaps in the PMBOK Guide, at least as far as NPD projects are concerned. As such, the guide provides useful tools for managing routine aspects of NPD projects (italics and emphasis mine, not the author’s). Gaps exist in many of the “softer” areas such as team dynamics and organisational learning. Given this, the author recommends that NPD project managers try new techniques and adopt them if they prove to be useful.
As far as future work is concerned, the author suggests that the PMBOK needs to incorporate techniques that can deal with uncertainty. He also emphasises the need for detailed research into the effectiveness “non-conventional” techniques such as lean project management. This is a good point: if new methods are useful, we need to understand the factors that make them useful. He also points out that some researchers have questioned the utility of project management for NPD, suggesting that trial and error, empathy and cooperation are superior to plans and processes. May be so, but a certain amount of the latter is necessary. The question is: how much? I think NPD projects require a bit of both. Exactly how much is best left to the judgement of the individual project manager who is familiar with the realities and quirks of his or her project.
Conclusion
The research discussed in the paper indicates that conventional project management (as described in PMBOK) is of limited utility for NPD projects. This is primarily because NPD projects involve a high degree of innovation and are, as a consequence, relatively ill-defined. This should be no surprise to practising project managers, who know from experience that conventional project management works best when scope is well-defined upfront. As far as NPD projects are concerned, the author identifies several areas in which the PMBOK is deficient. These have been discussed in detail in the paper (and above!).
To complement his coverage of the PMBOK, the author also looks into a few novel methods such as lean project management, which originated in construction or manufacturing. Unfortunately, he overlooks techniques such as iterative / incremental methods which have proven their effectiveness in NPD projects in the software industry. Although it isn’t clear how these can be adapted to projects that involve tangible products (as opposed to software), they merit inclusion in any study that deals with the utility of project management techniques for NPD projects.
To conclude, the paper is a useful read for project managers who work on NPD projects, particularly for its coverage of deficiencies in conventional project management techniques and how these may be addressed by alternate approaches.
References: Pons, Dirk, Project Management for New Product Development, Project Management Journal, 39 (2), 82-97. (2008).
Blinded by the light – when project management methodology matters more than project success
Many organisations believe (hope?) that strict adherence to a project management methodology guarantees project success. These unfortunates have been blinded by the dazzling (but false) promise of whatever methodology they choose to follow, and their projects suffer for it. My feelings on this are strong, but with good reason. I’ve seen too many projects go awry because of blind devotion to methodology.
The first step to fixing any problem is to recognise that it exists. So how can you tell if methodology has taken over your organisation? Well, here are a few warning signs:
- The focus is on following The Book rather than getting the job done: A classic sign of methodology madness is when things are done a certain way just because the process mandates it. This is sometimes seen in organisations with a strong project management office (PMO). To keep the powers that be happy, project managers often end up following the letter of the process but not the spirit, using other (informal) means to get the job done.
- There are templates for everything: The Book has a long appendix with templates for every conceivable action. You want to sneeze? Sorry, it has to be approved first. Please fill in form SN123, and we’ll pass on your request to the appropriate committee for review. Expect to hear from us in a week or so.
- Signatures / Approvals for everything: This is a particularly pathological variant of the well known, “Responsibility without authority” challenge that project managers face. Here, in addition to the lack of authority, you also can’t use informal channels to get things done because you need to have a paper trail to prove authorisation.
- Every action is over-deliberated: Is every project action re-visited and re-analysed ad-nauseum? If so, your project’s suffering from process sclerosis (a close cousin of analysis paralysis), wherein mindless application of process slows progress to a crawl.
- Everything is cast in stone: You want to do some things in a different way? Sorry, that’s not possible. The methodology has a prescription for every conceivable project action. No exceptions.
- Project management is a bureaucratic exercise: Project managers in methodology heavy organisations often end up becoming bureaucrats who spend most of their time fulfilling the requirements of the methodology. This leaves them with little time to actually manage their projects. Methodology has become an end in itself. Good luck getting anything done – you’ll need it.
Lest I leave you with the impression that I’m completely anti-methodology, let me assure you that I’m not. I’m a great fan of appropriate, well-considered use of project management processes. What do I mean by that? Well, many years ago a project management guru told me that every process employed in a project should be tailored to to that particular project’s needs and circumstances. Note his emphasis on the singular; each project is unique (by definition!) and must be treated so. Project management processes used in a project should be fit for purpose.
So I end with this thought: don’t let your organisation be blinded by methodology. Instead, insist that project management tools and techniques be used appropriately, in a manner that illuminates the way ahead on particular projects.
The effect of organizational culture on knowledge transfer in projectized organisations
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:
- 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.
- 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.
- 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:
-
Project constraints leave little time and resources for effective documentation of knowledge.
-
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.
-
Lack of motivation (or incentives) to undertake project reviews. This is the well known wiifm factor.
-
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:
- 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.
- 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:
-
Possibility versus actuality: this relates to what the organisation focuses on – potentialities or facts.
-
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:
-
Control: a process driven culture which values certainty and predictability above all.
-
Competence: a culture that values excellence (in services or products). These organisations aim to have unique or best of breed products and services.
-
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.
-
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:
- Recognise different levels at which knowledge is generated – i.e. individual, group and organisational.
- 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).
- 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.
- Appreciate the challenges involved in transforming organisational culture.
- 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:
- 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.
- In addition to knowledge transfer, knowledge management is also about fostering an organisational culture that encourages the creation, sharing and utilisation of knowledge.
- 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).
Eight to Late 