Archive for the ‘Paper Review’ 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).
Modelling project manager performance
A project manager is typically judged by the success of his or her projects. However, to really understand what makes a good project manager, it is necessary to identify and analyse factors that make a project manager successful. Much research effort has been expended on this over the years, with various factors posited as being the keys to success. Some of these include: project management knowledge (as defined by assorted methodologies), general management skills, leadership skills etc. Interestingly, there are studies that indicate there is virtually no correlation between performance and project management knowledge. Possibly as a consequence, the focus has shifted to management and leadership skills – i.e. the so-called “soft”, or people-related skills. In a recent paper entitled, The Role of Technology in the Project Manager Performance Model, published in the Project Management Journal, Vittal Anantatmula develops a performance model based on people-related factors identified from the literature. He also looks at the role of technology tools in supporting project manager performance. This post presents a summary and a review of the paper.
To begin with, the author describes his main objectives as the following:
- To identify a set of people related factors that influence project success, and to find relationships between these.
- To develop a performance model based on relationships between the factors.
- Based on the model, to identify areas where technology can support project manager performance.
As a background for his work, the author presents a detailed, literature-based discussion on the relationship between technology and project management, and on the role of project managers vis-a-vis the project team. Due to limitations of space, I will not go into this here – referring the interested reader to the original paper for more. My focus is purely on the research itself – i.e. the identification of factors, development of the model and the role of technology in project manager performance. That in itself is going to add up to a pretty hefty word count.
From a review of existing project management literature, the author identifies the following set of people-related factors which influence a project manager’s performance.
- Create clarity in communications: One of the major responsibilities of a project manager is to facilitate clear communications between all stakeholders, particularly at the early stages of the project.
- Define roles and project management processes: A clear definition of roles and responsibilities within the project team is important for project success. The roles should cover the entire gamut of project-related activities, but should avoid overlapping responsibilities. Further, unambiguous definition of project management processes adds clarity by ensuring team members know how the project will be run.
- Communicate expectations: This refers to the need to define and establish expectations regarding project objectives, particularly with customers and end-users.
- Employ consistent processes: The use of formal processes reduces project risks and ensures that a project progresses through a well-defined path. The trick here is to understand and implement only those processes that are really necessary and add value.
- Establish trust: Project team members have to develop a sense of trust in each other. This is critical for sharing knowledge and for working together as a team. Although not often acknowledged, this depends on nebulous factors such as organisational culture which are not in the project manager’s control.
- Facilitate support: This refers to the need to obtain organisational support for the support for the project, particularly from senior management. This is a critical function of a project manager.
- Manage outcomes: A project should deliver all that has been laid out in the objectives. As mentioned in the first line of this post, a project manager is often judged on the basis of how well the project meets its objectives. Managing outcomes is thus an important function of a project manager.
In my opinion this list is somewhat arbitrary because:
- It includes factors that aren’t people related (e.g. employ consistent processes) .
- It misses important factors such as team motivation (see this paper, for example). There are probably good reasons for this- one being that such factors are hard to quantify. However, a comprehensive performance model should attempt to incorporate these in some fashion.
- The author has selected a set of factors with no justification other than that they appear in the literature. Now, there are several other people-related factors that have been studied over the years. So, why were these seven factors chosen over others?
Having identified the above factors, the author develops a performance model using Interpretive Structural Modelling (ISM). ISM enables one to prioritise factors (i.e. rank them in order of importance) and also develop causal relationships between them, based on data collected from a population of respondents. ISM is derived from the technique of pairwise comparison. For each possible pair of factors in the list above, respondents were asked about the relationship between factors in a pair. Specifically, they were asked to choose from one of the following options:
- Does the first factor influence the second?
- Does second factor influence the first?
- Do both factors influence each other?
- Are the factors unrelated (no influence either way) ?
Based on responses received from 54 respondents, the author developed a model using ISM. The resulting model is depicted as a directed graph below (note: the diagram has been adapted from the paper)
The arrows are to be interpreted as “leads to” (or causal) relationships – i.e the factor at the starting point of the arrow leads to the factor at the end. The numbers next to each factor denote its priority – i.e. how important the factor is, according to the survey respondents. A low priority does not imply that a factor is unimportant, as the factor could be the result of other, more important, factors (a case in point is the low priority accorded to “Manage Outcomes”). I describe the model below, along with some critical comments.
As shown in the diagram, survey respondents attached the highest priority to defining project roles and processes. This is a prerequisite for smooth running of the project. Roles and responsibilities relate to individual team members, and processes relate to what needs to be done in the project. The project will run in an ad-hoc fashion if these aren’t spelt out early in the game. Definition of processes is a precursor to employing them in a consistent manner (bottom portion of diagram). Further, according to the model, clear definition of roles and processes helps the project manager identify and facilitate the required organisational support required for project success. For example, if one knows the skills required on the team, one can set about negotiating with management to get the right people on the team. In my opinion, facilitating organisational support depends on a whole lot more than the use of consistent processes. In fact, one could well have a situation where the organisation uses consistent processes, yet functional managers stonewall when it comes to making resources available for a project. Not an uncommon situation, I think.
The upper portion of the diagram consists of “softer” factors that are hard to quantify. As per the model, one needs to have a clear idea of roles, processes and requirements before one can communicate expectations. Role and process definition is necessary in that it tells the project manager what needs to be communicated. However, it does not say anything about how clear communication can be achieved. Effective communication involves a whole lot more than a knowledge of roles, processes and all that formal stuff. Because the factors enabling effective communication are so hard to pin down, methodology-focused studies (such as the present one) tend to take a very blinkered view. The author states, “…By defining roles and processes, the project manager can establish expectations from stakeholders but also predictability and openness in communication…” In my opinion, this claim (which is stated without any supporting arguments) is, at best, only partially true. Definition of roles and processes does not of itself lead to open and predictable communication. The latter has more to do with to communication skills (at the level of the individual project manager) and organisational culture (at the level of the organisation), both of which aren’t included in the study.
According to the model, managing outcomes depends on all the factor that precede it (excepting establishing trust). That seems logical enough. The author states that other studies on the relationship between trust and performance in collaborative environments also back this claim.
For reasons outlined above, I believe the model is simplistic, and should be viewed as an initial attempt at modelling project manager performance. As such, it cannot be used as a basis to improve project manager performance. Specific criticisms of the model include:
- The limited number of factors used and the arbitrary choice of these. The author bases his choice of factors on a subjective literature review – there is no good reason offered for why these factors were chosen over others.
- Despite the explanations offered in the paper (and, one assumes, the survey), the meaning of each of the factors is open to interpretation. This begs the question: can one be certain that all (or a majority of) survey respondents interpreted every factor in the manner intended by the author?
- The choice of modeling technique. ISM is a relatively simplistic technique that is based on the method of paired comparison. As such it shares some of the limitations of that method. As another example, ISM can handle only static relationships (i.e. those that do not change in time). However, people-related factors are far from static.
- The causal relationships inferred from the data are based on subjective opinions of a limited number of respondents.
After describing the model, the author turns to a rambling discussion on the role of technology in supporting project manager performance. As far as I can tell, the main point he makes is that technology tools can be divided into two categories: those supporting communication, and those facilitating decision making. The former, which includes technologies such as Internet/Intranet, video conferencing etc., support factors shown in the upper half of the diagram; whereas the latter, which includes tools such as databases, knowledge repositories, project management software etc., support those in the lower part of the diagram. As far as I can tell, there’s not much new in the discussion – the specific supporting roles of individual tools that the author discusses are already well known to practising project managers.
This brings me to the end of my (not so brief!) summary of the paper. Some closing remarks are probably in order. In the concluding section the author states, “The project manager performance model developed in this research effort – showing the dependency relations among important critical factors – can be used as a template for managing projects effectively by integrating technology systems and tools.” I have my reservations about this claim. As discussed above, the model is not detailed or comprehensive enough to be used as a template for managing projects. Having said that, I acknowledge that developing a performance model is a difficult task because of the multitude of factors involved and the complex interrelationships between them. As the author suggests, an extensive study involving more factors and respondents is needed in order to arrive at a comprehensive model of project manager performance. The one presented in this paper may be considered, at best, a small step in the right direction.
References:
Anantatmula, Vittal S., The Role of Technology in the Project Manager Performance Model, Project Management Journal, 39 (1), 34-48. (2008).
A memetic view of project management
A few days ago I came across an interesting perspective on project management put forward by Jon Whitty, an academic who teaches at the University of Southern Queensland. Whitty’s view, which he published in a paper entitled A Memetic Paradigm of Project Management, presents a somewhat heretical take on the discipline of project management. In this post I outline and comment on some of the essential points made in the paper.
Whitty begins with the uncontroversial statement that project management, by and large, fails to live up to the expectations of stakeholders. This is well documented by studies such as the Standish Report, so needs no further explanation. To quote Whitty, this widespread failure suggests that academics and practising project managers “…still do not really understand the nature of projects, and that too much research effort has been directed towards clarifying the reasons for project success and failure, while downplaying research on why projects exist and behave as they do …” Whitty believes that the current paradigm of project management cannot help us understand the true nature of projects. Instead, a more critical approach, which considers projects to be a “…human construct, about a collection of feelings, expectations and sensations, cleverly conjured up by the human brain…” might be a more fruitful way of looking at projects. Here’s where the memetic bit comes in. I expand on this in the following paragraph.
The term meme was coined by the evolutionary biologist Richard Dawkins in his book The Selfish Gene, in which he presents the idea that the genes that survive evolution (i.e. those that are passed on) are the ones whose characteristics serve their own interests. In other words, genes act “selfishly”, to propagate themselves. In the book he draws an interesting parallel between this view of biological evolution and that of the evolution and propagation of ideas. Ideas, according to Dawkins, propagate themselves through assorted means ranging from education to mass media. A meme is basically an idea (or any unit of information) which gets transmitted (from person to person) through communication or repeated action. It is important to note that a meme isn’t just any random, fleeting thought; it is an idea that is transmitted with a fair degree of fidelity. Some examples of memes are: a folk tale or a joke (or even a methodology!).
Now, with that explanatory detour out of the way, I can get back on topic. In the paper, Whitty suggests that the discipline of project management should be viewed as a collection of related memes which propagate as a group (such groups of memes are called memeplexes). With the background of the previous paragraph, this isn’t surprising at all- basically any academic discipline or professional practice can be considered so. The implications of considering project management to be a memeplex are interesting, and form the main focus of Whitty’s paper. I look at a few of these in the following paragraphs.
A basic consequence of a memetic view (of any discipline) is that it turns the notion of knowledge being created by scholars or practitioners on its head. Memes create the scholars and practitioners, rather than the other way round! This isn’t as strange as it sounds, if one thinks about it for a while. For instance, project management as a discipline has given rise to various standards, bodies, certifications etc. thus legitimising it as a profession. To gain acceptance into the community of project managers, an aspirant subscribes to standards, joins professional bodies and gains certifications, thus being created by the memeplex.
The rapid development of project management as a discipline is a memeplex characteristic. In the last decade or so, there has been a huge growth of membership in professional bodies. Further, in universities and business schools, project management has gained legitimacy as a sub-discipline of management, with all the attendant trappings such as journals, academic conferences, textbooks etc. In a memetic view, all this only serves to propagate the memeplex. Whitty raises the concern that “…a large amount of memes in the PM memeplex are today being generated and replicated by University Business Schools. Moreover, as we continue to define organisational success in monetary terms our education sustems seem more naturally an extension of corporate training…” The implication being that the memes propagated aren’t necessarily good or correct, because their propagation is driven by a lopsided notion of what is good.
One can take the argument even further. Project management, as it is practised, consists of a set of mental models – ways of looking at how things work in the real world. One example of such a model is a project plan, which serves as a representation of the project from start to end. Project management texts are vehicles for recording and propagating such mental models (which are nothing but memes). The important point is that new knowledge is always seen through the filter of existing knowledge. So, the chances of a radically new idea making it through to mainstream are small, simply because it is seen through the lens of existing ideas. Radically new ideas are typically discarded as the memeplex propagates or evolves. This, too, isn’t a limitation of project management alone; it’s true of any discipline.
The paper has a lot more than I can go into in the space of a blog post. So, rather than continue my second-hand account, I’ll refer you to the original piece for more. I’ll sign off here with one final nugget from the paper: Whitty draws attention to the fact that false memes frequently get propagated along with true ones. The point is, once ensconced in mainstream thought, an incorrect idea gets the stamp of legitimacy and thus becomes almost impossible to question or correct. In contrast, a memetic approach – wherein it is known that propagated memes aren’t necessarily correct – recommends that practitioners be critical of ideas and practices handed down by authority. That, in the end, is excellent advice for us all, regardless of whether or not we agree with Whitty.
Eight to Late 