Eight to Late

Sensemaking and Analytics for Organizations

Archive for June 2008

Reading project road signs

with 2 comments

The metaphor of a project as a journey is one that has been used by others (see this article by Max Wideman, for example). As a consequence, a high-level project plan is sometimes referred to as a roadmap. Now, real roads have signs at appropriate points, informing motorists of potential hazards or other matters. In this post I extend the project-as-a-journey metaphor, looking at how some common road signs might be interpreted in project management terms.

I start with the stop sign. Project managers, as a part of their day-to-day work, make several decisions regarding their projects. Admittedly, many of these decisions are trivial ones, which don’t really matter one way or the other. But there are others which are major crossroads- and a wrong choice made could have a significant negative effect on the project. At such crossroads it is important to stop and deliberate before deciding which way to go.



There’s a tricky bit ahead on your project. What do you do? Well, you do exactly as you would when driving on a winding road – slow down and watch the road ahead carefully. Project managers often seek to maintain project velocity (rate at which the project progresses) even when implementing a technically difficult phase. It is important to recognise that some bits of work are harder than others. Recognising this means: a) slowing down and, equally important, b) keeping a close watch on quality, as the tricky bits of work may be more prone to defects than others.

This one deals with compromises. Have you ever come across a situation where you want something done in a particular way and your counterpart (sponsor, team lead, team member whoever) disagrees? May be you think you’re right. But on the other hand, may be you really aren’t. Is there a large inverted, Give Way (or Yield) triangle hanging above your disagreement? It is always worth checking for it. May be you are being unreasonable. In any case, it behooves you to consider the possibility.

Round and round we go – or so it seems in some project meetings. This sign is a warning that a meeting is headed nowhere. Metaphorically, I’ve seen it at many meetings that I’ve been in – interminable discussions on irrelevancies. The best thing a project manager can do when he sees this sign is to firmly, but politely, take charge of the meeting and drive it out of the roundabout.

A canny project manager will realise there are some battles that are simply not worth fighting. It takes some political nous to figure out which these are, and that’s where the No Entry sign comes in. As an example consider the case of a project team member who isn’t up to scratch. He or she may be slowing progress due to shoddy work. You’ve discussed the issue with the person concerned several times, all to no avail. You now go to the team member’s functional manager to discuss a potential replacement. He doesn’t want to hear about it, and starts to get upset with you. That’s a No Entry sign flashing right there. Back track, walk away and have the discussion another day.

This one has a universal relevance, despite the Australian imagery. I often think of the kangaroo sign when confronted with problems that are created by someone else unintentionally. Here’s an example: I need a data projector for a meeting that’s due to start shortly. I go to the support area to get the projector, only to find that another PM’s already grabbed it. I’m now projector-less, with the meeting coming up in 5 minutes. I’ve been blindsided or  “mugged by a marsupial”. I should’ve allowed for the possibility and reserved the projector well ahead of time.

There are quite a few unusual road signs out there, and it can be an amusing (if not edifying) pastime to look for project management (or, more generally, management) interpretations to these. So I sign off, leaving the interpretation of the following road sign as an exercise for the reader.




Written by K

June 28, 2008 at 9:02 am

Posted in Project Management

Modelling project manager performance

with one comment

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. 

  1. 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.
  2. 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.
  3. Communicate expectations: This refers to  the need to define and establish expectations regarding project objectives, particularly with customers and end-users.
  4. 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. 
  5. 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.  
  6. 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. 
  7. 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:

  1. It includes factors that aren’t people related (e.g. employ consistent processes) .
  2. 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.
  3. 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:

  1. Does the first factor influence the second?
  2. Does second factor influence the first?
  3. Do both factors influence each other?
  4. 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:

  1. 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.
  2. 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?
  3. 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.
  4. 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.


Anantatmula, Vittal S., The Role of Technology in the Project Manager Performance ModelProject Management Journal, 39 (1), 34-48. (2008).

Written by K

June 22, 2008 at 12:59 pm

A cynic’s introduction to project management artefacts in five limericks

with one comment

Project managers as a rule,
will construct a project schedule
on a wing and a prayer,
and estimates from thin air,
creating a timeline untrue.

The well-regarded Gantt chart
is little more than a work of art.
For it only masks
that most project tasks
never begin when intended to start.

A project management tool
can spice up a dodgy schedule
with critical paths,
simulations and charts.
Accuracy? Who cares – it looks cool.

Progress reports for sponsor reviews
should be vetted for only good news.
No one wants to hear
of impending failure,
or how things are going down the tubes.

Organisations have discerned
that documenting lessons learned
is a complete waste,
’cause they’re rarely based
on events that really occurred.

Other posts in my “five limericks” series are:

An IT system tragedy in five limericks.
A project procrastinator’s tale in five limericks.
A corporate IT tragedy in five limericks
A manager’s response to a corporate IT tragedy in five limericks
A project management tragedy in five limericks

Written by K

June 19, 2008 at 9:47 pm

Improving project forecasts

with 17 comments

Many projects are plagued by cost overruns and benefit shortfalls. So much so that a quick search on Google News  almost invariably returns a recent news item reporting a high-profile cost overrun.  In a 2006 paper entitled, From Nobel Prize to Project Management: Getting Risks Right, Bent Flyvbjerg discusses the use of reference class forecasting to reduce inaccuracies in project forecasting. This technique, which is based on theories of decision-making in uncertain (or risky) environments,1 forecasts the outcome of a planned action based on actual outcomes in a collection of actions similar to the one being forecast. In this post I present a brief overview of reference class forecasting and its application to estimating projects. The discussion is based on Flyvbjerg’s paper.

According to Flyvbjerg, the reasons for inaccuracies in project forecasts fall into one or more of the following categories:

  • Technical – These are reasons pertaining to unreliable data or the use of inappropriate forecasting models.
  • Psychological  – This pertains to the inability of most people to judge future events in an objective way. Typically it manifests itself as undue optimism, unsubstantiated by facts; behaviour that is sometimes referred to as optimism bias. This is the reason for statements like, “No problem, we’ll get this to you in a day.” – when the actual time is more like a week.
  • Political – This refers to the tendency of people to misrepresent things for their own gain – e.g. one might understate costs and / or overstate benefits in order to get a project funded. Such behaviour is sometimes called strategic misrepresentation (commonly known as lying!) .

Technical explanations are often used to explain inaccurate forecasts. However, Flyvbjerg rules these out as valid explanations for the following reasons. Firstly, inaccuracies attributable to data errors (technical errors) should be normally distributed with average zero, but actual inaccuracies were shown to be non-normal in a variety of cases. Secondly, if inaccuracies in data and models were the problem, one would expect this to get better as models and data collection techniques get better. However, this clearly isn’t the case, as projects continue to suffer from huge forecasting errors.

Based on the above Flyvbjerg concludes that technical explanations do not account for forecast inaccuracies as comprehensively as psychological and political explanations do.   Both the latter involve human bias. Such bias is inevitable when one takes an inside view, which focuses on the internals of a project – i.e. the means (or processes) through which a project will be implemented.  Instead, Flyvbjerg suggests taking an outside view – one which focuses on outcomes of similar (already completed) projects rather than on the current project. This is precisely what reference class forecasting does, as I explain below.  

Reference class forecasting is a systematic way of taking an outside view of planned activities, thereby eliminating human bias. In the context of projects this amounts to creating a probability distribution of estimates based on data for completed projects that are similar to the one of interest, and then comparing the said project with the distribution in order to get a most likely outcome. Basically, reference class forecasting consists of the following steps:

  1. Collecting data for a number of similar past projects – these projects form the reference class. The reference class must encompass a sufficient number of projects to produce a meaningful statistical distribution, but individual projects must be similar to the project of interest.
  2. Establishing a probability distribution based on (reliable!) data for the reference class.  The challenge here is to get good data for a sufficient number of reference class projects.
  3. Predicting most likely outcomes for the project of interest based on comparisons with the reference class distribution.

In the paper, Flyvbjerg describes an application of reference class forecasting to large scale transport infrastructure projects. The processes and procedures used are published in a guidance document entitled Procedures for Dealing with Optimism Bias in Transport Planning, so I won’t go into details here. The trick, of course, is to get reliable data for similar projects. Not an easy task.

To conclude, project forecasts are often off the mark by a wide margin. Reference class forecasting is an objective technique that eliminates human bias from the estimating process. However, because of the cost and effort involved in building the reference distribution, it may only be practical to use it on megaprojects.



1Daniel Kahnemann received the Nobel Prize in Economics in 2002 for his work on how people make decisions in uncertain situations. His work, which is called Prospect Theory, forms the basis of Reference Class Forecasting.

Written by K

June 15, 2008 at 12:18 pm

Posted in Bias, Project Management

Tagged with

Lead, don’t take the easy way out

leave a comment »

Over the last few weeks, parliamentary proceedings in Australia have been dominated by debates (if one can call them that) on the price of petrol. In the process, the public has been treated to the unedifying spectacle of a government and an opposition squabbling over a GST cut on excise  which, if passed, will reduce the price of petrol by the princely sum of 4 cents per litre. A cut that will sooner than later be swallowed by ever rising oil prices.

Rather, than lead – in this case by telling the truth about hard choices that face us – politicians continue to take the easy way out by looking after their own short-term interests (i.e. the next election). Hence the fixation on cutting petrol prices, even if by only an insignificant amount. The truth is we need to look at long-term solutions such as improving public transport and fuel efficiency while also looking at alternate energy sources. All hard yet necessary options which, if implemented, might well irritate the electorate. Incidentally, regarding the first point, anecdotal evidence suggests that soaring petrol prices have already pushed more people into public transport, thereby putting further strain on an already creaky system. Addressing that, for a start, would be more productive than arguing over a 4c price reduction.

In the words of Ross Gittins, a Sydney Morning Herald columnist – our pollies are too gutless to give us the bad oil . And there lies a lesson in how not to lead, because Gittins is absolutely right: our politicians aren’t leading, they’re taking the easy way out.

Written by K

June 11, 2008 at 9:09 pm

Communication impedance mismatches on projects

leave a comment »


Most  folks have been in situations where something they’ve said or written  has been comprehensively misunderstood by the recipient of the message. When this happens it’s as if the other party is on a different wavelength, thus completely missing what’s conveyed. In this post I propose the term communication impedance mismatch to refer to this phenomenon.  Below I explain why this bit of jargon, which has its origins in electrical engineering,  is an appropriate one to use in this context. I also look at some reasons why communication impedance mismatches are so common on projects. In this connection, readers may also want to have a look at my earlier post on obstacles to project communication.

What’s an impedance mismatch?

So, what is an impedance mismatch?  A good place to start is with some definitions from Wikipedia. Electrical impedance is essentially a measure of opposition  to the flow of alternating current in a circuit. The impedance of a circuit component depends, among other things, on the frequency1 of the alternating signal. Now, for a fixed frequency, it is possible to adjust the circuit impedance so that power transfer through the circuit is maximised. This is called impedance matching.  Basically, if impedances aren’t matched, power transfer  through the circuit isn’t optimal.

Impedance matching is the principle behind radio tuning (and hence a connection to communication).  In brief, radio tuning works as follows: impedance varies with signal frequency (or wavelength); so, for a fixed impedance, signals of a specific frequency  – the tuned frequency – will be “let through” while the others will be “blocked”2. Although I’ve been using frequency as the variable here, I could just as well have used wavelength as the two are related. So, the wavelength metaphor that I used earlier is really quite apt-  if the other party is on a different wavelength they will not get the message.

Anyway, this technical term from physics and electrical engineering has a history of being appropriated by other fields (see this post, for example).   As an example from software development, the object-oriented programming crowd use the term to refer to the mismatch between data representations in a relational and object-oriented worlds.  The term has a nice “jargony” feel about it. And seeing that it’s been appropriated by others before, I have no hesitation in appropriating it for the communication lexicon.

Why are communication impedance mismatches common on projects?

OK, so  why am I so fussed about  communication impedance mismatches on projects? Here why: at least one study claims that poor communications are the most frequent cause of project failure.  It is therefore worth looking at why communication impedance mismatches are so common on projects. Here are some reasons that come to mind:

  • Team members don’t know each other well: A project is, by definition, a time-bound undertaking with a clear start and finish. Hence, in many cases, the people involved in a project would not have worked with each other before. Even worse, they may not even know each other.  Such a situation is fraught with the potential for communication impedance mismatches. To alleviate this, it is sometimes recommended that team members spend time getting to know each other before the project begins. This is often done via team building activities, which I confess I’m not a great fan of. I much prefer letting people find their own niche within a team, rather than forcing a false sense of togetherness through contrived activities.  Either way, a project manager has to be conscious of the potential for misunderstandings caused by team members simply not knowing each other well enough.
  • Projects are high-stress environments: Projects can be high stress environments, especially when things aren’t going well. Paradoxically, it is when things aren’t going well that good communication is needed. However, in times of stress, one generally finds that communication impedance mismatches rule. Minor misunderstandings can be blown all out of proportion. At such times, a good project manager acts as an impedance matching device, getting all involved parties to communicate with each other on a common wavelength.
  • Communication gap between the customer and supplier: The objectives of customers and suppliers on projects are typically different, and often even contradictory (for example, the customer wants it done cheap whereas the supplier wants to make as much money as reasonably possible). This fundamental tension between the two parties often leads to communication impedance mismatches. These can be resolved by a project manager who understands both points of view, and looks for negotiated, or collaborative, solutions that take into account both parties’ objectives.

These are just some of the reasons for the ubiquity of communication impedance mismatches in project environments.  There are a host of others, which I’m sure you may have come across in your work. I’d welcome additions to the list through your comments.

In Conclusion

Communication impedance mismatches occurs whenever  communications  – written, verbal or otherwise –  are misunderstood.  They often occur in a project environment because of the temporary  and time-bound nature of projects, and also because  projects are comprised of parties with conflicting interests. A project manager has to be aware of the potential for communication impedance mismatches, so that he or she can act to reduce them before they cause unnecessary strife.


1The standard mains frequency is 60 Hz (or cycles/second) in the US and 50 Hz elsewhere..

2I couldn’t find any good, non-technical online references, but see this short explanation or this longer one in Yahoo Answers for more..

Written by K

June 7, 2008 at 7:06 pm

A memetic view of project management

with 9 comments

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.

Written by K

June 3, 2008 at 9:39 pm

%d bloggers like this: