Archive for the ‘Corporate IT’ Category
Beyond Best Practices: a paper review and the genesis of a collaboration
Introduction
The fundamental premise behind best practices is that it is possible to reproduce the successes of those who excel by imitating them. At first sight this assumption seems obvious and uncontroversial. However, most people who have lived through an implementation of a best practice know that following such prescriptions does not guarantee success. Actually, anecdotal evidence suggests the contrary: that most attempts at implementing best practices fail. This paradox remains unnoticed by managers and executives who continue to commit their organisations to implementing best practices that are, at best, of dubious value.
Why do best practices fail? There has been a fair bit of research on the shortcomings of best practices, and the one thing it tells us is that there is no simple answer to this question. In this post I’ll discuss this issue, drawing upon an old (but still very relevant) paper by Jonathan Wareham and Han Cerrits entitled, De-Contextualising Competence: Can Best Practice be Bundled and Sold. Note that I will not cover the paper in its entirety; my discussion will focus only on those aspects that relate to the question raised above.
I may as well say it here: I have a secondary aim (or more accurately, a vested interest) in discussing this paper. Over the last few months Paul Culmsee and I have been working on a book that discusses reasons why best practices fail and proposes some practical techniques to address their shortcomings. I’ll end this post with a brief discussion of the background and content of the book (see this post for Paul’s take on the book). But let’s look at the paper first…
Background
On the first page of the paper the authors state:
Although the concept of ‘imitating excellent performers’ may seem quite banal at first glance, the issue, as we will argue, is not altogether that simple after deeper consideration. Accordingly, the purpose of the paper is to explore many of the fundamental, often unquestioned, assumptions which underlie the philosophy and application of Business Best Practice transfer. In illuminating the central empirical and theoretical problems of this emerging discipline, we hope to refine our expectations of what the technique can yield, as well as contribute to theory and the improvement of practice.
One of the most valuable aspects of the paper is that it lists some of the implicit assumptions that are often glossed over by consultants and others who sell and implement best practice methodologies. It turns out that these assumptions are not valid in most practical situations, which renders the practices themselves worthless.
The implicit assumptions
According to Wareham and Cerrits, the unstated premises behind best practices include:
- Homogeneity of organisations: Most textbooks and courses on best practices present the practices as though they have an existence that is independent of organizational context. Put another way: they assume that all organisations are essentially the same. Clearly, this isn’t the case – organisations are defined by their differences.
- Universal yardstick: Best practices assume that there is a universal definition of what’s best, that what’s best for one is best for all others. This assumption is clearly false as organisations have different (dare I say, unique) environments, objectives and strategies. How can a universal definition of “best” fit all?
- Transferability: Another tacit assumption in the best practice business is that practices can be transplanted on to receiving organisations wholesale. Sure, in recent years it has been recognized that such transplants are successful only if a) the recipient organisation undertakes the changes necessary for the transplant to work and b) the practice itself is adapted to the recipient organisation. The point is in most successful cases, the change or adaptation is so great that it no longer resembles that original best practice. This is an important point – to have a hope in hell of working, best practices have to be adapted extensively. It is also worth mentioning that such adaptations will succeed only if they are made in consultation with those who will be affected by the practices. I’ll say more about this later in this post
- Alienability and stickiness: These are concepts that relate to the possibility of extracting relevant knowledge pertaining to a best practice from a source and transferring it without change to a recipient. Alienability refers to the possibility of extracting relevant knowledge from the source. Alienability is difficult because best practice knowledge is often tacit, and is therefore difficult to codify. Stickiness refers to the willingness of the recipient to learn this knowledge, and his or her ability to absorb it. Stickiness highlights the importance of obtaining employee buy-in before implementing best practices. Unfortunately most best practice implementations gloss over the issues of alienability and stickiness.
- Validation: Wareham and Cerrits contend that best practices are rarely validated. More often than not, recipient organisations simply believe that they will work, based on their consultants’ marketing spiel. See this short piece by Paul Strassman for more on the dangers of doing so.
What does “best” mean anyway?
After listing the implicit assumptions, Wareham and Cerrits argue that the conceptual basis for defining a particular practice as being “best” is weak. Their argument hinges on the observation that it is impossible to attribute the superior performance of a firm to specific managerial practices. Why? Well, because one cannot perform a control experiment to see what would happen if those practices weren’t used.
Related to the above is the somewhat subtle point that it is impossible to say, with certainty, whether practices, as they exist within model organisations, are consequences of well-thought out managerial action or whether they are merely adaptations to changing environments. If the latter were true, then there is no best practice, because the practices as they exist in model organisations are essentially random responses to organizational stimuli.
Wareham and Cerrits also present an economic perspective on best practice acquisition and transfer, but I’ll omit this as it isn’t of direct relevance to the question of why best practices fail.
Implications
The authors draw the following conclusions from their analysis:
- The very definition of best practices is fraught with pitfalls.
- Environmental factors have a significant effect on the evolution and transfer(ability) of “best” practices. Consequently, what works in one organisation may not work in another.
So, can anything be salvaged? Wareham and Cerrits think so. They suggest an expanded view of best practices which includes things such as:
- Using best practices as guides for learning new technologies or new ways of working.
- Using best practices to generate creative insight into how business processes work in practice.
- Using best practices as a guide for change – that is, following the high-level steps, but not necessarily the detailed prescriptions.
These are indeed sensible and reasonable statements. However, they are much weaker than the usual hyperbole-laden claims that accompany best practices.
Discussion
Cerrits and Johnson focus on the practices themselves, not the problems they are used to solve. In my opinion, another key reason why best practices fail is that they are applied without a comprehensive understanding of the problem that they are intended to address.
I’ll clarify this using an example: in a quest to improve efficiency an organisation might go through a major restructure. All too often, such organisations will not think through all the consequences of the restructuring (what are the long-term consequences of outsourcing certain functions, for instance). The important point to realize is that a comprehensive understanding of the consequences is possible only if all stakeholders – management and employees – are involved in planning the restructure. Unfortunately, such a bottom-up approach is rarely taken because of the effort involved, and the wrong-headed perception that chaos may ensue from management actually talking to people on the metaphorical shop floor. So most organizations take a top-down approach, dictating what will be done, with little or no employee involvement.
Organisations focus on how to achieve a particular end. The end itself, the reasons for wanting to achieve it and the consequences of doing so remain unexplored; it is assumed that these are obvious to all stakeholders. To put it in aphoristically: organizations focus on the “how” not the on the “what” or why.”
The heart of the matter
The key to understanding why best practices do not work is to realise that many organizational problems are wicked problems: i.e., problems that are hard to define, let alone solve’s (see this paper for a comprehensive discussion of wicked problems). Let’s look at organizational efficiency, for example. What does it really mean to improve organizational efficiency? More to the point, how can one arrive at a generally agreed way to improve organizational efficiency? By generally agreed, I mean a measure that all stakeholders understand and agree on. Note that “efficiency “is just an example here – the same holds for most other matters of strategic importance to organizations: organisational strategy is a wicked problem.
Since wicked problems are hard to pin down (because they mean different things to different people), the first step to solving them is to ensure that all stakeholders have a common (or shared) understanding of what the problem is. The next step is to achieve a shared commitment to solving that problem. Any technique that could help achieve a shared understanding of wicked problems and commitment to solving them would truly deserve to be called the one best practice to rule them all.
The genesis of a collaboration
About a year ago, in a series of landmark posts entitled The One Best Practice to Rule Them All, Paul Culmsee wrote about his search for a practical method to manage wicked problems. In the articles he made a convincing case that dialogue mapping can help a diverse group of stakeholders achieve a shared understanding of such problems. Paul’s writings inspired me to learn dialogue mapping and use it at work. I was impressed – here, finally, was a technique that didn’t claim to be a best practice, but had the potential to address some of the really complex problems that organisations face.
Since then, Paul and I have had several conversations about the failure of best practices in to tackling issues ranging from organizational change to project management. Paul is one of those rare practitioners with an excellent grounding in theory and practice. I learnt a lot from him in those conversations. Among other things, he told me about his experiences in using dialogue mapping to tackle apparently intractable problems (see this case study from Paul’s company, for example).
Late last year, we thought of writing up some of the things we’d been talking about in a series of joint blog posts. Soon we realised that we had much more to say than would fit into a series of posts – we probably had enough for a book. We’re a few months into writing that book, and are quite pleased with the way it’s turning out.
Here’s a very brief summary of the book. The first part analyses why best practices fail. Our analysis touches upon diverse areas like organizational rhetoric, cognitive bias, memetics and scientific management (topics that both Paul and I have written about on our blogs). The second part of the book presents a series of case studies that illustrate some techniques that address complex problems that organizations face. The case studies are based on our experiences in using dialogue mapping and other techniques to tackle wicked problems relating to organizational strategy and project management. The techniques we discuss go beyond the rhetoric of best practices – they work because they use a bottom-up approach that takes into account the context and environment in which the problems live.
Now, Paul writes way better than I do. For one, his writing is laugh-out-loud funny, mine isn’t. Those who have read his work and mine may be wondering how our very different styles will combine. I’m delighted to report that the book is way more conversational and entertaining than my blog posts. However, I should also emphasise that we are trying to be as rigorous as we can by backing up our claims by references to research papers and/or case studies.
We’re learning a lot in the process of writing, and are enthused and excited about the book . Please stay tuned – we’ll post occasional updates on how it is progressing.
Update (16 June 2010):
An excerpt from the book has been published here.
Update (27 Nov 2011):
The book, which has a new title, is currently in the final round of proofs. Hopefully it will be available for pre-order in a month or two.
Update (05 Dec 2011):
It’s out!
Get your copy via Amazon or Book Depository.
The e-book can be obtained from iUniverse (PDF or Epub formats) or Amazon (Kindle).
On the relationship between projects and organisations
Introduction
Most of the research and practice literature on project management tends to view projects as being isolated from their environment. It is obvious to anyone who has worked on a project that this isn’t so. In view of this, it is useful to look at the relationship between projects and the organisations that host them. This post looks at this issue, drawing on a paper by Gernot Grabher entitled, Cool Projects, Boring Institutions: Temporary Collaboration in Social Context.
The emergence of projects
Grabher begins his discussion with a sketch of the how projects emerged as a distinct work form. Projects – i.e. time bound, goal focused activities – have always been around. The modern notion of a project, however, arose from a development philosophy that came out of the US Department of Defense in the 1950s. He states,
…Instead of fragmenting and pre-specifying the development of military technologies along functional disciplines, these technologies were described in relation to their objectives, i.e. the military parameters of these weapons. The pacing of these concentrated efforts was crucial: parameters had to be met, goals had to be accomplished according to a grand scheme (program?) to win the armament race. Development processes that earlier were seen as separate activities were now conceptualized as an integrated entity called a program, system or project. The overwhelming scale of these projects in terms of financial and scientific resources as well as their ambitious timing created formidable problems of coordination and control. Experiments with various forms of organizational control ultimately lead to the professionalization of the role of the project manager…
From thereon the concepts of projects and project management were taken up (with much enthusiasm and optimism) by business and industry. The formalization of various project management methodologies, standards , qualifications and trade journals can be seen a culmination of this process.
Given the military-industrial origins of the profession, it is easy to see why a “command and control” philosophy dominates much of project management thought and practice. Many of the early projects that are paraded as textbook examples of successful projects operated outside normal organizational oversight. They were, to a large extent, deliberately shielded from external influences. I believe this is why isolation from the environment is seen as a Good Thing by project managers – problems of coordination and control become so much simpler when one does not have to manage relationships and politics that are (perceived as being) external to a project. This practice may be necessary and workable for classified projects that run on billion dollar budgets, but it doesn’t work so well in environments that most project managers work in. Projects don’t take place in a vacuum; they are born, live and die in real-world organizations. To forget that is to see the “tree of the project” and miss the “forest of the organization.” This is particularly so because, unlike those near-mythical mega-projects of the 1950s, the efforts that you and I work on are deeply entwined with their hosting organizations.
Organisation-related characteristics of projects
Grabher then notes some characteristics of projects. I summarize these in the next few paragraphs.
First, it is interesting that the original meaning of the word “project” referred to a “proposal” or “idea”, rather than a “directed, time-bound effort.” Grabher points out that this shift in meaning was accompanied by a shift in focus: from project as idea (or goal) to project as process (or means to achieving a goal). Projects are thus seen as vehicles for achieving organisational goals.
Second, Grabher notes that projects are often hard to decompose into constituent tasks, and that such a (commonly agreed) decomposition is only possible when stakeholders interrelate with each other continually. This underscores the importance of communication in projects.
Third, Grabher highlights the importance of the project manager (he uses the term contractor) as the “lynchpin on whom trust is focused.” The role of the manager is particularly important in projects on which team members do not have the time to get to know each other well.
Fourth, the project manager / contractor is also the wielder of organizational authority as far as the project is concerned. He or she is, in this sense, a representative of the organization – a person whose presence underlines the fact that the project exists to achieve specified organizational goals.
Finally, deadlines are a defining aspect of projects. They serve several functions. For example, they ensure that a sense of urgency for action and progress remains through the duration of the project. They also might serve to legitimize execution of project work without external interference (this argument was frequently used in the military-industrial projects of the 1950s). But above all, the final deadline, which culminates in the termination of the project, also serves as a connector to the rest of the organization. It is a time in which handoffs, documentation, team disbanding etc. occurs, thus enabling the results and experiences from the project disperse into the wider organization.
Projects in organisations
The characteristics noted above highlight the dual nature of projects: on the one hand, as noted earlier, projects are seen as semi-autonomous temporary organisations, but on the other they are also firmly embedded within the hosting organisation. An effect of the latter is particularly evident in consulting and software services firms (or even corporate IT shops), which tend to do similar projects over and over. As Grabher notes,
[projects] apparently operate in a milieu of recurrent collaboration that, after several project cycles, fills a pool of resources and gels into latent networks. Project organising is mostly directed towards the actual realization of a potential that is generated and reproduced by the practice of drawing on core members of (successful) prior projects to serve on derivative successor projects. Such chains of repeated co-operation are held together (or cut off ) by the reputation members gain (or lose) in previous collaborations…
Another aspect of embedded-ness is the co-location of team members within a larger organizational milieu. The standard benefits of co-location are well known. These are:
- Savings of transactional costs such as those incurred in communication, supervision of staff at remote locations etc. See my post on a transaction cost view of outsourcing for more on this.
- Co-location improves the efficacy of communication by encouraging face-to-face interactions.
- It enables “near real-time” monitoring of the health of the project and its environment.
There’s more though. Grabher notes that in addition to the above “intentional” or “strategic” benefits, co-location also ensures that team members are exposed to the same organizational noise – which consists of a “concoction of rumours, impressions, recommendations, trade folklore and strategic misinformation (falsehoods!).” Co-location enables project teams to make collective sense of organisational noise – this shared understanding of the environment can contribute significantly to the creation of a team spirit.
A related notionis that of enculturation: that is, the process of becoming an accepted member of the group, or an insider. This has less to do with expertise and knowledge than learning the unspoken rules and norms of a community. Although becoming a member of a community has much to do with social interactions within the workplace, there is more: a lot of essential know-how and know-what is transferred through informal interactions between senior members of the team (who are often senior members of the organisation) and others.
Projects generally need to draw upon a range of organizational resources: people and physical infrastructure being the most obvious ones. Grabher notes that the increasing projectisation of organizations can be attributed to a perception that project-based management is an efficient way to allocate productive resources in a flexible manner (…whether this perception is correct, is another matter altogether). However, there are other less obvious influences that organisations exert too. For example, Grabher points out that organizational norms and rules provide the basis for the emergence of swift trust, which is trust based on roles and professional ability rather than individuals and personalities. Further, at a higher level, organizational culture plays a role in determining how a project is governed, managed and run. These explicit and implicit norms have a stabilising influence on projects.
In addition to the stabilizing influence of the hosting organisation, projects also offer opportunities to build and enhance links between organisations – for instance, strategic partnerships. This is, in effect, institution building aimed at leveraging the strengths of the participating organisations for a greater joint benefit. In such situations the participating organisations take on the role of “lynchpins” on whom trust is focused.
Grabher makes the point that firms (and institutions comprised of firms) not only provide resources that make projects possible, but also host a range of processes that are needed to organize and run projects. For one, projects are usually preceded by several organisational processes involving deliberation, selection and preparation. These activities have to occur for a project to happen, but they normally fall outside the purview of the project.
A somewhat paradoxical aspect of projects is although they offer the opportunity for enhancing organizational knowledge, this rarely happens in practice. The high pressure environment in projects leaves little time for formal training or informal learning, or even to capture knowledge in documents. To a large extent the hosting organisations are to blame: Grabher suggests that this paradox is a consequence of the lack of organizational redundancy in project-based organizing.
I’ll end this section with the observation that the social dimension of projects is often neglected. Projects are often hindered by organizational politics and inertia. Further, a large number of projects fail because of varying perceptions of project goals and the rationale behind them. Although it seems obvious that a project should not proceed unless all stakeholders have a shared understanding of objectives and the reasons for them, it is surprising how many projects drift along without it. Many project planners neglect this issue, and it invariably comes back to bite them.
Conclusions
In the conclusion to the paper, Grabher states:
The formation and operation of projects essentially relies on a societal infrastructure which is built on and around networks, localities, institutions and firms. Relations between temporary and permanent systems are not a matter of straightforward substitution but have to be regarded in terms of interdependence. ‘Cool’ projects, indeed, rely on ‘boring’ institutions…
This is unarguable, but it should also be kept in mind that projects are often subject to negative organisational influences which can slow them down, or even kill them altogether (which is perhaps why those early defence projects were set up as near-autonomous initiatives). So although it is true that projects are made possible and sustained by the organisations they’re embedded in, they are sometimes hindered by those very organisations .
To sum up in a line: Projects depend on organisations not only for material and human resources, but also draw sustenance from (and are affected by) the social environment and culture that exists within those organisations.
Redefining project success
Introduction
When can one say that a project has failed? Although the answer to this question depends on the criteria used to measure project success, most project managers would not think the question (or its answer) could raise much controversy. In this post I discuss why the issue of project success is more ambiguous (and contentious!) than seems at first sight.
The crux of the issue lies in the observation that managers and programmers often use different criteria to judge project outcomes. As Robert Glass states in his wonderful book on facts and fallacies of software engineering:
There is a disconnect between management and their programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.
I’ll expand on this statement, drawing from Glass’ book, the research study he mentions, and personal experience.
The disconnect
Much of Glass’ discussion is based on a paper by Kurt Linberg entitled, Software Developer Perceptions about Software Project Failures: A Case Study. The paper details a lot of information about the project, its context, reporting structures and the composition of the team. Although this is important from the perspective of a research study, it is more relevant to look at how the various project stakeholders perceived the project.
First a few words about the project that Linberg studied. The project was aimed at creating a software-driven medical device. The management-approved schedule for the project ran over 14 months, but the project actually took 27 months to complete. Further, the software development portion of the product was originally budgeted at a little over a million dollar but ended up costing more than four million! In view of this there’s little surprise that management deemed the project a failure.
What about the programmers? Linberg interviewed/surveyed many of the developers who were a part of the team. One of the questions he asked was: what was the most successful project that you have worked on, and why? Surprisingly, more than 50% of the team answered that the project described above was the most successful one they had ever worked on! The reasons they gave were revealing:
- The project was a technical challenge.
- The product worked as intended.
- The team was small and high performing.
The following quote from one of the team members says it all:
[the project] was the most successful because of what we accomplished. The code was more solid than any I have ever written. The verification testing was extensive. All the other places that I’ve worked relied on the software developer doing the testing. I always thought that I could have done more testing. I also really enjoyed the people I worked with. I also think that it was the best-managed project of any that I’ve experienced. Also, the product was well designed. I did not see the scope creep that is so prevalent on other projects. I never felt pressure from schedule. I would ask the project manager and technical lead if we were in trouble. They would be cool, calm and collected. They emphasized the importance of doing the best job we could do. We were able to focus our energy on the tasks at hand!
So, we see a complete disconnect: according to (majority of) the developers the project was success because it delivered a quality product, but by management metrics of budget and time it was a failure!
Bridging the gap
To bridge the disconnect between management and developers, Linberg asked the team members why the project was late and over-budget. The following reasons were offered:
- Unrealistic schedule and expectations.
- Poor understanding of scope (underestimating the effort required)
- Lack of resources
One of the team members summarised the schedule situation as follows:
Unfortunately, I believe program management established over-ambitious and incorrect expectations during early meetings with the executives. In reality, we had no idea how long it would take to develop this system. It is a real tribute to this team that they pulled together and developed an excellent product.
Another had this to say about the poor understanding of scope / lack of resources:
We ignored history. Although we didn’t have experience estimating this type of development, there are groups of people in our building that have been working these types of applications for years. They typically have 6 to 10 people working on their applications. How could management not see that assigning one or two people and constraining the schedule would be unrealistic?
Yet, the team thought that the project was managed quite well. Quoting from the paper:
Compared with other projects, the software developers believed the project management on the project was between average and best. In two cases, the software developers said it was the best that they had experienced. One of the software developers that gave high marks for the project management stated that the project manager had good technical skills and could manage time lines.
In fact, one of the developers said:
The project manager, team lead, and program manager each provided leadership. The leadership worked very well together. The program manager knew his strengths and his boundaries. He left the software and firmware management to the software project manager. The software project manager was not threatened and left technical decisions to the team lead. We were always told of changes before they happened. The leadership was the best that I have experienced in my 14 years.
The overall impression that Linberg conveys is that the project was well-managed. So where is the problem?
The programmers felt that upper management was largely responsible for the disconnect. This makes sense: front line managers rarely have the clout to set overall allocations of time and resources. They have to work within the parameters set by executives.
Based on this, Linberg proposes a new definition of software project success, which is based on industry averages rather than arbitrary metrics.
| Completed | Cancelled | |
| Failure | Does not meet customer expectations | Not learning anything that can be applied to future projects |
| Low Success | Below average cost, effort, and schedule performance compared to industry AND meeting quality expectations | Some learning can be applied to future projects |
| Success | Average cost, effort, and schedule performance compared to industry AND meeting quality expectations | Some learning can be applied to future projects and some artifacts can be used on future projects. |
| High Success | Better than average cost, effort, and schedule performance compared to industry AND meeting quality expectations | Substantial learning can be applied to future projects and a large number of artifacts used. |
| Exceptional Success | Meeting all quality, cost, effort and schedule expectations. | A Cancelled project cannot be considered an exceptional success. |
This definition begins to bridge the chasm between developer and senior management perceptions of project success. It does so by broadening the definition of success. The current project management-driven definition is too narrow because it takes only one perspective into account – the perspective of those who hold the purse-strings. Such a definition cannot work because it completely ignores the viewpoint of those who know software development best: the developers.
Conclusion
Linberg’s case study highlights the fact that there can be a huge gap between how developers and managers view project outcomes. Interestingly, the factors that cause the gap are usually present from the start of the project: unrealistic schedules, poorly understood scope and lack of adequate resources. One could hypothesise that most of the projects that “fail” do so for one or more of these reasons. Also interesting is the fact that even such “failed” projects can be deemed successful in the eyes of developers because they see things from a different perspective: what was learnt and what can be used again. Seen in this light, a project that goes over-time and over-budget can be successful because the experience gained can be used on future projects.
I’ll end with a story from experience. Some years ago I was a part of a team developing a product for a telecom software company. The product was ambitious in scope, and the timeline and budget tight. Nevertheless, the team looked forward to the challenge of designing and building a product from scratch. The architect, project manager and several members of the development team (excluding me) had years of experience in building software for the telecom industry. The product specs were developed by domain experts. Management’s initial intentions were good: they assured the dev team that they (management) knew that it would take time to develop a solid product from the ground up. To reduce risk it was decided to build the product using incremental approach with monthly deliverables.
Progress was slow but steady. Unfortunately, as the product started taking shape, business reality intruded: the sales guys who had been working hard had not been able to convince anyone to sign up. Funds began to dry up and management responded by cracking the whip. Predictably, the project started to unravel and was canned a few months later. Officially the project was deemed a failure, yet many on the dev team believed that a) it was one of the best projects they had worked on b) they had learnt a lot and c) what they had learnt wouldn’t go waste.
Was the project a failure? I suppose the answer is that it failed from a purely commercial standpoint. From a broader perspective, however, it fits quite neatly into Linberg’s definition of a successful cancelled project.
Perhaps it is time to rethink the definition of project success.
Eight to Late 