Archive for July 2008
In a recent Harvard Business Review article entitled The Secrets to Successful Strategy Execution, Gary Neilson, Karla Martin and Elizabeth Powers identify reasons why many companies fail in translating strategy to reality. Their research is based on surveys from over 100,000 employees in more than 1000 organisations worldwide. The article also lists the top five traits of organisations that are effective in executing strategy. When reading these, it occurred to me that the same characteristics are also crucial for successful project execution. Judge for yourself: the attributes, rephrased in project management terms, are listed and discussed below.
- Everyone has a good idea of the decisions and actions for which he or she is responsible: The project manager shouldn’t be the sole decision maker on the team. Many decisions (and follow-on actions) are best made by individual team members, especially when these pertain to their expertise. A smart project manager realises this and delegates specific decision rights and action responsibilities to appropriate persons on the team. Empowering the team in this way removes decision bottlenecks and keeps the project running smoothly. Moreover, delegating real responsibility demonstrates trust and improves team morale.
- Important information about the project and its environment gets to the project manager quickly: A project and its environment are dynamic – things change, sometimes from day to day. When changes that affect the project occur, it is important that the project manager is made aware of these as soon as possible. As an example, a developer realises that an approach he intended to use isn’t going to work. Rather than taking unilateral action – say, by shoe-horning his efforts into the time allotted – it’s better to let the project manager know so that both the developer and project manager can come up with a mutually agreed approach. This is critical because the project manager may be aware of certain things (like reserve time or resources, for example) that the developer isn’t. If project-related information doesn’t get to the manager quickly, it is inevitable that sub-optimal decisions will be made – either by the project manager or the team.
- Once made, decisions are rarely second guessed: If the project manager has delegated decision rights (as per the first point above), it is imperative that decisions made by team members aren’t second guessed. Too many project teams spend time reviewing decisions ad nauseum. Don’t do it – once a decision is made, get on with it. Decisions should be revisited only in exceptional circumstances, and only with very good reasons.
- Information flows freely across all project interfaces: This is all about communication. Many projects suffer from a lack of open communication between various stakeholders (see my post on obstacles to project communication for more on this). One of the important functions of a project manager is to ensure smooth communication, both within a team (internal interfaces) and between a team and other stakeholders (external interfaces). Most project managers are conditioned to ensure good communication across external interfaces, especially when the external party is a sponsor! But they often neglect to facilitate communication between team members. Dysfunctional communication within a team can kill a project, so project managers should continually watch for signs of intra-team communication problems. Communication, or information flow, is a good segue into the next point which is…
- Team members usually have the information they need to understand the impact of their day-to-day choices: Team members are at the coalface of the project. They’re the ones who, through their day-to-day work, are making it happen. Seemingly inconsequential decisions made by them can have a large knock on effect on the project. Given this, they should be fully aware of the impact that their choices (and actions thereof) can have on a project. This can happen only if they have all relevant information regarding the project. What’s relevant? That’s up to the project manager to figure out, and communicate to every team member.
Perhaps you’re asking, “Why should traits relevant to effective strategy implementation have anything to do with running projects?” Well, a strategy can be regarded as a set of time-bound objectives together with a plan for implementing them. This makes it a project. So it’s no surprise that traits which improve an organisation’s effectiveness in implementing strategy also make project teams better at executing projects.
In a recent lecture on leadership in software development, Mary Poppendieck relates the well-known parable of the three stone cutters. The story, in short, is as follows. Three stone cutters are asked what they’re doing by a passer-by. The first one answers, “I’m cutting stones”; the second, “I’m earning a living”; and the third, “I’m building a cathedral.” A variant of this tale is related in Ricardo Semler’s best-selling book, Maverick, in which he details how he turned his company, Semco, from a traditional, hierarchical organisation to one in which workers were empowered to make decisions that affected them. In effect, he turned an organisation of stone cutters into one of cathedral builders.
When asked, most senior managers claim that their organisations, like Semler’s, have more cathedral constructors than stone slicers. However, this is their subjective impression which, quite obviously, should be taken with a sprinkle of sodium chloride. What’s needed is an objective test of employee empowerment in organisations. In her lecture, Mary Poppendieck proposes such a test. Here it is:
What do people in your organisation do when they are annoyed by some aspect of their job?
a) They complain about it.
b) They ignore it.
c) They fix it.
(a) corresponds to the stone cutter, (b) the wage earner and (c) the cathedral builder. Poppendieck’s point is that when people are empowered to change aspects of their job that they feel need to be fixed, then it is clear the organisation has pushed decision making down to lowest possible level. This situation is desirable for two reasons:
- Decisions get made at the level at which work gets done.
- Everyone in the organisation is able to fulfil their full potential
So, now that you’ve taken the test, do people in your organisation (or team) cut stones, earn a living or build cathedrals?
“The Next Revolution in Productivity.”
Hype’s alive and well – so we see.
But implementing software
that’s not business aware
will cause much pain and grief.
The slick salespersons who sell
SOA software won’t tell
the truth, it’s tragic
that it ain’t no magic,
but a true integration hell.
So, don’t be sold snake-oil.
For you will be in for much toil.
With nothing to show
for all your spent dough,
but an organisation in turmoil.
A while ago I wrote a post entitled, Two project managers, one project, in which I offered some suggestions to those who share project management responsibilities with one or more colleagues. In the present post I’d like to discuss the opposite situation – one where a project is managed by someone who has to juggle project management responsibilities with their regular job. It’s pretty obvious that this is a recipe for failure (of the project), burnout (of the project manager) or both. Nonetheless, this situation isn’t uncommon and, given the ever-increasing resource constraints that organisations are subject to, I suspect it will only become more common. Hence the motivation for this post in which I offer the part-time project manager some tips on dealing with this predicament.
My first tip is to refuse to do it. Having said that, I realise that in most cases refusal isn’t an option, and may even be a career-limiting move. So, here are some other suggestions that may help deal with the issue head-on:
- Get someone to help with your regular job: Look into the possibility of off-loading some of your regular job duties to your co-workers. The first step is to get your co-worker’s consent. One way to get buy-in is to ensure that the work you’re handing over is meaningful for the other person. Consider giving away something that will be interesting and perhaps also useful from skill / knowledge development perspective. Next, you’ll need to get approval from management. When speaking higher-ups, be sure to emphasise the importance of freeing up your time to focus on the project. Some say one should speak to management first – I disagree. It is important to get buy-in from the “off-loadee” before approaching management about doing any off-loading.
- Find another part-timer to share project management duties with: If you can’t find anyone to do your regular job (or a part of it), you may have more luck getting someone to share project management duties with you. Here too, you would want to get the person’s OK before talking to management. Obviously it will also be necessary to get buy-in from management, but that shouldn’t be too hard if your project is important from the organisation’s perspective.
- Smart multitasking: OK, if you fail to get help – either with your regular job or with managing the project – you’re stuck with doing the project on your own. In this case, it is inevitable that you will have to multitask. Check out this post for some tips on how to multitask effectively.
- Know your limits: Despite your best efforts, it may become apparent that the project is suffering from the lack of a full-time project manager. In this case it is important to appraise management of the situation as soon as possible. You’re not doing anyone any favours by indulging in heroic efforts that may lead to burnout, so be sure that management understands the problems you’re having. The decision on whether to help or not is up to the folks upstairs, but they must know the full story to make an informed decision. If they decide not to help, at least it isn’t because they didn’t know.
After reading the above, you’re probably thinking that the suggestions I’ve made are pretty lame – they’re either impractical or won’t help much at all. You’re absolutely right! The truth is, a half-a-project-manager scenario is a bad one for both the project and the project manager. The best way to deal with it is not to sign up in the first place. So I return to my first tip – when asked to do it, just say no.
Stan was the go-to guy in the IT department. He had a deep knowledge of many technical areas, and had the ability to come up with creative solutions to just about any technology-related problem. Further, unlike your stereotypical IT employee, Stan understood the business (he had worked at this company for several years) and was very articulate. All in all, the perfect IT guy…or so it seemed, until the day Stan was sacked.
His colleagues were shocked, stunned, and many other emotions of a similar shade. They asked the simple question, “Why?”, but got no satisfactory answer from anyone. Management wouldn’t say anything except the official line which was, “Consistently unacceptable performance” – a line his colleagues simply didn’t believe. Getting no believable answers, they indulged in wild hypothesising, which included a conspiracy theory or two. Stan himself wouldn’t say, which only added spice to the speculations.
It turns out the truth behind Stan’s dismissal was really quite simple. Stan was a victim of perceptions – or two perceptions to be precise. Let me explain…
Within the IT team, Stan was indeed the go-to guy. He wouldn’t hesitate to drop what he was doing to help a colleague resolve a technical issue. He’d spend hours reading up on and exploring technologies, writing nifty utilities and even contributing to the odd open source project. All this made him ever more valuable as technical employee. He was perceived by his IT colleagues as brilliant, approachable and always helpful.
Trouble is, folks on the business side didn’t share this perception. They perceived him as being arrogant and unhelpful. A typical complaint from an end-user would go something like, “I told him over two months ago that this report isn’t working, and he still hasn’t fixed it. I asked about it yesterday and he tells me he’s still working on it.”
On digging deeper it turned out that Stan was a serial postponer. He’d continually put off doing work that he found uninteresting. This included any business-related issues, application fixes, new reports or whatever. Stan claimed that his technical workload left him little time to do anything else. So, as the pile of unattended issues on his desk grew ever higher, the business-wide perception of Stan sank lower and lower. He got a couple of warnings which he ignored. Eventually, his manager gave up and put him on a performance management program. Stan dealt with this in the worst possible way. He immersed himself deeper into technical matters, to the further detriment of his business responsibilities. Paradoxically, he continued to grow in his IT colleagues’ estimation whilst incurring the increasing ire of the business. Then one fine day things came to a head and the rest, as they say, is history (as is poor Stan) .
Perceptions matter. Don’t let anyone tell you otherwise. This is particularly important to those who have to maintain a variety of professional relationships in the workplace. Corporate IT is a case in point: folks who work in IT must be able to deal with technical and business people. As illustrated by the Stan’s story, perceptions should be managed on both fronts. Mis-management of perceptions is what leads to the stereotype of the inarticulate, unhelpful, technology obsessed IT employee. Many corporate IT departments have a Stan or two (or more!) lurking within. Such folks would do well to heed this tale.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
It’s been a while since my last post on stereotypes, so I’m well overdue for another. This time I take aim at a much misunderstood mob – project sponsors. These are folks, who by virtue of their financial or executive clout, actually call the shots on projects. On the off-chance that some sponsors I’ve worked with read this post, I hasten to add that this is a work of fiction. Any resemblance to sentient sponsors is purely coincidental and wholly unintended. With the disclaimer done, I can compose my rogues gallery of project sponsors, without having to remind readers that fictional characters are often based on real life.
Andrew Astronaut: This guy is way up in the rarefied heights of the executive stratosphere (by his reckoning anyway). With all the big picture stuff to look after, the project’s just a small speck of inconsequence for him (“Project? What project?”). As a project manager, it is possible that you may not even meet him – he doesn’t show up for sponsor meetings and communicates only through emails from high above. In fact, it is rumoured that he doesn’t exist, and is really an email alias for the CEO’s Assistant.
Charlie Count-the-cash: Charlie’s a cash-counter, so it’s natural that he’d see the project as a black hole for company cash. To counter this, he has a bag of tried and tested money saving devices. One of his favourites is to “save money” by cutting costs at the start of a project (eg: “You can’t have 3 programmers, we have funding for only two.”). Trouble is, when the project’s running late, he ends up throwing twice as much money at it.
Devlin Details: Devlin thrives on detail. He’s the kind of sponsor for whom the 50 page progress report (and the 500 page business case) was invented. Not sure how he finds the time to wade through reams of documents given all his other onerous duties, but he actually does. This is evident from the perceptive and pointed questions he asks later. When dealing with Devlin, do as the scouts do – be prepared.
Len Leftfield: Len’s the guy who shows up at sponsor meetings only to display his superior intellect. He does this by coming up with clever questions and perspectives that no one (least of all the project manager) has thought of. His questions may not be relevant – but they’re always clever and, of course, unanswerable.
Mick Micromanager: Mick likes to see the “small picture” or the “trees for the forest” or “the local view” or <insert any appropriate reverse cliche here> . Despite his executive responsibilities, Mick feels compelled to keep close track of (and offer unsolicited advice on) project planning and execution. According to him he has no choice in the matter, because project managers are prone to messing things up.
You may have recognised some sponsors you’ve dealt with in the above list. If so, have a beer or three and the feeling should pass. Even if it doesn’t, you’ll feel a lot better – particularly if you’re dealing with a snarky sponsor on your current project.
Before I close this piece, I should mention one last stereotypical sponsor – Pete Perfect. Pete provides high-level guidance and business perspective, is available to sort out political issues, understands problems that project managers face etc. etc. In short, he’s the perfect project sponsor. “In your dreams,” I hear you say. You’re right, of course – but then I did say this is a work of fiction.