Eight to Late

Sensemaking and Analytics for Organizations

Archive for October 2008

Assumptions of competence

with 2 comments

In a recent post, I wrote: “…most folks don’t really need to be managed because they’re competent at what they do, and go about doing their jobs in a generally diligent manner.”

On reading this an old friend wrote to me saying, “I am sincerely of the opinion that most people are not competent at their jobs…”  And a bit later in the same message, “If you are looking for quality and excellence, don’t expect to find it in business and corporate culture.”

Incidentally, he is an independent consultant with over fifteen years experience, much of it gained in  large corporations . His observations regarding the general lack of competence and quality in the business world must, therefore,  be taken seriously.  Nevertheless, I reckon he’s at least partly off the mark: I believe it behooves managers to  begin with the assumption that people are competent, and that they want to do high-quality work.

Let me start my case with three stories which may sound familiar:

Jim is a developer at the regional office of a large multinational. He is overloaded with work, typically working on at least two (often three) major projects concurrently. As a consequence he cannot do justice to any of them.  It is clear that Jim will not meet the deadlines on any of the projects. Though it is clear that his situation has been caused by poor management, he’ll be the one carrying the can.

Tracy is an experienced database programmer working on a large project. She has worked on similar projects before, and is arguably the best person to provide technical input regarding the design and implementation of database program modules for the product. Yet, her manager insists that every suggestion she makes be approved by him prior to presentation to the team, often adding his two-cents to her designs.  Of late the team has noticed that Tracy has been unusually quiet during project meetings.

Sanjay has been working as an ERP adminstrator for a while.  He has the job well under control, and is looking to pick up some new skills. The company he works for has just purchased a large number of licenses for a major business intelligence platform, so there’s going to be plenty of work building new reports.   Sanjay knows this area is under-resourced: there’s only one person working on the new platform, right from metadata design to creating reports. Clearly, this person could use some help, and it’s a perfect opportunity for Sanjay to pick up new skills.  Sanjay approaches his manager for permission to get involved,  but the manager refuses outright.

Sooner or later…

Jim’s blamed for the failure of his project(s).

Tracy has lost interest in her job.

Sanjay’s administering his ERP system competently enough, but spends his (considerable) free time surfing the Net. He’s bored, and makes no effort to hide it.

To a casual onlooker it may appear that Jim, Tracy and Sanjay “are not competent at their jobs”, but that is a superficial observation. The real problem is that they are no longer motivated by their work. The basic reason for their demotivation is bad management. More specifically:

Jim’s expected to achieve the unreasonable or impossible.

Tracy isn’t empowered to make decisions that affect her work.

Sanjay isn’t given the opportunity to learn new skills.

Fact of the matter is, these folks want to succeed at their jobs and even go beyond  their job description, but they aren’t given the support, opportunity and / or the means to do so.

I did say my friend’s partially right, and he is: with a demotivated team, quality and excellence and all those wonderful things we’re supposed to strive for in the workplace aren’t going to happen.  The question is, who is responsible?  As Deming mentions in his management / quality classic, Out of The Crisis, the fault lies largely with management.  I agree, but many don’t.  I’d be  interested in hearing what you think. Do let me know through your comments.

Written by K

October 28, 2008 at 11:03 pm

A note on bias in project management research

with 8 comments

Project management research relies heavily on empirical studies – that is, studies that are based on observation of reality. This is necessary because projects are coordinated activities involving real-world entities:  people, teams and organisations.  A project management researcher can theorise all he or she likes, but the ultimate test of any theory is, “do the hypotheses agree with the data?”  In this, project management is no different from physics: to be accepted as valid, any theory must agree with reality. In physics (or any of the natural sciences), however, experiments can be carried out in controlled conditions that ensure objectivity and the elimination of any extraneous effects or biases. This isn’t the case in project management (or for that matter any of the social sciences). Since people are the primary subjects of study in the latter, subjectivity and bias are inevitable. This post delves into the latter point with an emphasis on project management research.

From my reading of several project management research papers, most empirical studies in project management proceed roughly as follows:

  1. Formulate a hypotheses based on observation and / or existing research.
  2. Design a survey based on the hypotheses.
  3. Gather survey data.
  4. Accept or reject the hypotheses based on statistical analysis of the data.
  5. Discuss and generalise.

Survey data plays a crucial role in empirical project management studies. This pleads the question: Do researchers account for bias in survey responses? Before proceeding, I’d like to clarify the question with with an example. Assume I’m a project manager who receives a research survey asking questions about my experience and the kinds of projects I have managed. What’s to stop me from inflating my experience and exaggerating the projects I have run? Answer: Nothing! Now, assuming that a small (or, possibly, not so small) percentage of project managers targeted by research surveys stretch the truth for whatever reason, the researcher is going to end up with data that is at least partly garbage. Hence the italicised question that I posed at the start of this paragraph.

The tendency of people to describe themselves in a positive light referred to as social desirability bias. It is impossible to guard against, even if the researcher assures respondents of confidentiality and anonymity in analysis and reporting. Clearly this is more of a problem when used for testing within an organisation: respondents may fear reprisals for being truthful. In this connection William Whyte made the following comment in his book The Organization Man, “When an individual is commanded by an organisation to reveal his innermost feelings, he has a duty to himself to give answers that serve his self-interest rather than that of The Organization.” Notwithstanding this, problems remains even with external surveys. The bias  is lessened by anonymity, but doesn’t completely disappear. It seems logical that people will be more relaxed with external surveys (in which they have no direct stake), more so if they are anonymous. However, one cannot be completely certain that responses are bias-free.

Of course, researchers are aware of this problem, and have devised techniques to deal with it. The following methods are commonly used to reduce social desirability bias

  1. The use of scales, such as the Marlowe-Crowne social desirability scale, to determine susceptibility of respondents to social desirability bias. These scales are based on responses to questions that represent behaviours which are socially deemed as desirable, but at the same time very unlikely. It’s a bit hard to explain; the best way to understand the concept is to try this quiz. A recognised limitation of do not distinguish between genuine differences and bias. Many researchers have questioned the utility of such scales on other grounds as well- see this paper, for example.
  2. The use of forced choice responses – where respondents are required to choose between different scenarios rather than assigning a numerical (or qualitative) rating to a specific statement. In this case, survey design is very important as the choices presented need to be well-balanced and appropriately worded. However, even with due attention to design, there are well-known problems with forced choice response surveys (see this paper abstract, for example).

It appears that social desirability bias is hard to eliminate, though with due care it can be reduced. As far as I can tell (from my limited reading of project management research), most researchers count on guaranteed anonymity of survey responses as being enough to control this bias. Is this good enough? May be it is, may be not: academics and others are invited to comment.

Written by K

October 22, 2008 at 9:16 pm

Posted in Bias, Project Management

Tagged with

A scope management farce in five limericks

leave a comment »

It began as some projects do,
with users who hadn’t a clue.
Their requirements
made no sense,
filling merely a page or two.

The PM,  he knew the score.
He asked the users for more.
They flatly declined
saying “We have no time,”
and booted him out the door.

The PM, now filled with dread,
went to the sponsor and said,
“We cannot proceed.”
The boss disagreed,
commanding him to press ahead.

The team, though flying blind,
worked hard (no time to unwind).
Built an app to the spec,
but the users said, “Heck,
this ain’t what we had in mind.”

The moral is clear to see:
With specs unclear or murky,
you’d do well to try
using techniques agile,
delivering frequently.

Some recent posts in my “five limericks” series are:

A cliche-ridden corporate crisis in five limericks
SOA what? A clarification for CIOs in five limericks
A cynic’s introduction to project management artefacts in five limericks
An IT system tragedy in five limericks

Written by K

October 17, 2008 at 7:41 pm

Managing knowledge on IT projects

leave a comment »


Many  IT projects are knowledge-based  – that is, their success depends on the effective creation, utilisation and transfer of knowledge .  Given this,  it is surprising that elements of knowledge management have not  been  properly integrated into mainstream IT project management.  For example: project managers recognise the need to document lessons learned and often do so, but these learnings are rarely integrated into organisational project knowledge. The current approach to knowledge management and learning on projects is  piecemeal at best – a sprinkling of lessons learned, a dash of knowledge transfer from consultants and some other random bits and pieces thrown in.  Clearly, a holistic view of knowledge and learning is needed: one which presents guidelines for knowledge management through the entire project lifecycle.  In a paper entitled,   Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice, published in the June 2007 issue of the Project Management Journal, Blaize Horner Reich presents a knowledge management framework based on the research literature. I present an annotated summary and review of the paper below.


In the introduction Dr. Reich states, “One promising lens through which projects can be understood and potentially improved is to conceptualise them as arenas in which knowledge is generated and exploited, and learning is essential for success.” Projects, as temporary organisations, face similar challenges to permanent organisations with respect to managing knowledge and learning. However,  transience implies that the challenges are greater for projects.  The existing literature in knowledge management is  vast, and highly conceptual. On the other hand, project management research tends to have a more practical bent.  The author, recognising this difference,  focuses attention on papers that incorporate both project and knowledge management. This has the dual benefit of ensuring that a) the number of papers to be reviewed are manageable and  b) the research has a practical, project-oriented focus.


In the remainder of this post I focus on the practical results of the research, referring the reader to the original paper for more on the author’s research methodology.

The author notes that project managers lack a common understanding of what is meant by knowledge management in the context of projects.  She therefore begins with the following preliminary definition:

Knowledge management in the context of projects is the application of principles and processes designed to make relevant knowledge available to the project team. Effective knowledge management facilitates the creation and integration of knowledge, minimises knowledge losses, and fills knowledge gaps throughout the duration of the project.”

I like this definition because it clarifies what good (or effective) knowledge management can do for a project.

Classification of knowledge

After defining what is meant by  knowledge management in  the context of projects, the author moves on to a classification of knowledge types that are important to IT projects.  She identifies the following four knowledge types:

Process knowledge: This refers to knowledge of project-related processes such as methodology, time frames, project organisation etc. This is important from the perspective of understanding different roles in the project and what is expected from them. A common understanding of processes also empowers team members to organise themselves in the best possible way to achieve the project objectives.

Domain knowledge: This refers to business, technical and product knowledge relevant to the project.  Typically this knowledge is collectively held by a large number of individuals (subject matter and technical experts). It is the job of the project manager to ensure that the individuals who hold this knowledge are identified and consulted at appropriate times.

Institutional knowledge: This includes all relevant knowledge of the organisation: its people, power structures and politics.  A project team needs to have a good awareness of these in order to get things done. This is particularly important for individuals who are drafted in to the project from outside the organisation.

Cultural knowledge: This refers to discipline-based cultures (as in IT, business, academic etc.) and national cultures. Obviously team members on interdisciplinary projects need to be aware of variations in work cultures between different disciplines. Further, project teams are often composed of people from different countries; hence the need for an awareness of  the norms of different national cultures.

Typically the need for the first two types of knowledge is well recognised and catered for.  The need for the latter two should not be underestimated, as many projects fail due to the lack of organisational support and /or breakdown in communication between project sub-teams located in different countries.

Knowledge-based risks

After presenting the above knowledge typology, the author moves on to a discussion of knowledge-based risks in project management. She identifies the following risks that relate to knowledge:

1. Lessons not learned: This is probably the most recognisable knowledge-based risk. Although many organisations inisist on proper documentation of lessons learned at the end of a project, few use this effectively on subsequent projects. Most often this happens because project teams (and management) are keen (or pressured) to get on with working on the project proper. Taking the time to read and reflect on documentation from past projects is viewed as a waste of time.

2. Flawed team selection: It is in the project manager’s interest to get the right people on the project team. Specifically, one needs people who have the required process, domain, institutional and cultural knowledge. Often, though, project managers have little or no control on team selection.  On the other hand, even if project managers have a say in team selection, it may be hard to identify the skills needed upfront. Sometimes it is also hard to find out how much exactly people do know – claiming knowledge is different from actually having it.

3. Volatility in the governance team: It is important that there be continuity in the stakeholders who sponsor and run the project. When a project sponsor leaves, he or she often takes with him the project’s raison d’etre from the organisational perspective. This includes things such as the business context,  organisational issues and risks that might affect the project etc. If the project manager is struck by a bus, there is potentially a loss of knowledge regarding the state of the project and what needs to be done to make progress. Research has shown that the loss of the project manager has a significant negative impact on the project (see this paper, for example).

4. Lack of knowledge of role among the governance team: The project governance team (sponsor and project manager) are critical to the success of the project. Although organisations recognise and act on  the need to train project managers and equip them with the knowledge they need to do their jobs, few accord the same attention to project sponsors. As a result, many project managers find that they have to gently “educate” their sponsors regarding what needs to be done in order to move things ahead in difficult times.

5. Inadequate integration of different types of knowledge: This is a major risk on large projects which involve specialist knowledge from different domains. In this case it often happens that no one has the big picture, which includes all the parts that need to come together in order to make the project succeed. A common example of this – particularly on technology projects -is the so-called gap between IT and the business. Project managers can bridge the gap through effective project communication.

6. Incomplete knowledge transfer: Many IT projects are carried out with the help of external consultants who design and implement a solution, only to vanish into the sunset soon after. The need to transfer knowledge, though frequently identified and catered for early in the project, is all too often done in a half-baked way. Only when one turns to the documentation to figure out how something works (usually when its broken) does one identify that the documentation is incomplete. Quality assurance of vendor-supplied documentation is an important but oft-neglected facet of project handover.

7. Loss of team members: When a team member leaves, he or she takes with him a whole lot of irreplaceable knowledge regarding the project. Even if he or she has been diligent with documentation (and that’s a big IF), there are a whole host of things that simply can’t be documented. This is a particularly significant risk on projects that run over a long period.  For a project manager, the best way to handle this is to identify, proactively, the areas most vulnerable to this risk and to have a plan to deal with them.

8. Lack of a knowledge map: In complex projects, it is impossible for every person on the team to know everything pertaining to the project, even at a high-level.  It is therefore critical to have a knowledge map: i.e a document which keepst track of who knows what within the team.  Research studies have indicated that such knowledge maps (and the networks that result through interactions between team members)  are more effective than focussing on knowledge integration. Many of those surveyed by the author identified the lack of such a map to be a knowledge risk.

9. Loss between phases: Knowledge is lost between project phases because changes in team composition. Proper documentation is the standard way to address this issue. However, there is much that cannot be communicated through the written word. In my experience an hour long chat with an expert is way more useful than reading a document that he or she has written. Conversations, where one can go back and forth, discussing and clarifying the rationale behind certain decisions are the best way to transfer knowledge across phases. Unfortunately, it is frequently the case that the folks who have this knowledge are no longer available.

10. Failure to learn: This is perhaps the best known knowledge risk. Most everyone knows the importance of documenting lessons learned. Despite this, research shows that project post-mortems don’t happen as often as they should. The main reason for is time pressure and / or the lack of motivation to do these. Further, even when post-mortems do occur, it often happens that difficult or sensitive topics aren’t broached because it isn’t safe to do so. The importance of psychological safety in organisational learning is well-established, but few organisations make it truly safe for employees to speak out. Project environments are no exception.

The above catalogue of knowledge risks can be considered comprehensive, as it is based on an extensive literature review. The author has done an excellent job in distilling and incorporating this information into her model. In my opinion this is the most useful part of the paper.

Principles and practices

After discussing knowledge-based risks, the author proposes some principles and practices of knowledge management that are aimed at addressing these risks. I discuss these below:

Establish a learning environment: As mentioned towards the end of the previous section, the need for fostering a learning climate in organisations is well known. Many organisations now do this quite successfully. Creating a learning focus on projects is harder because of  the temporary nature of the project organisation. Based on survey responses, the author suggests five practices to foster learning in projects:

  1. Engage the team when building the risk register. In my opinion, although this helps recognise risks instead of sweeping them under the proverbial rug it does not really contribute to fostering a learning environment.
  2. Communicate that mistakes are a part of learning. This is important, the team should know that it is safe to own up to mistakes. This does indeed encourage learning – people learn from their mistakes and those of others providing they are made public in an acceptable way.
  3. Reward behaviour that supports learning, not just results. Encourage experts and senior team members to pass on their knowledge and skills to others. One way to do this is to recognise and reward folks who spend time helping or teaching others.
  4. Practice desired team behaviours on a daily basis. Make knowledge sharing, mentoring, helping others etc. a part of the team ethic by practising them on everyday issues. This is a slow process which is hard to implement in a time-bound project environment. One way is for the project manager to demonstrate these behaviours and thus serve as a role model for the rest of the team. Easy to say; hard to do.
  5. Be honest and speak the truth: Be honest about issues that the team has to deal with. There’s nothing worse than a project manager glossing over potential difficulties that team members have to deal with. Further, be open about problems that you foresee. There are ethical considerations here though: for example, what do you do if you are privy to confidential information that affects the team. As with so many things in project management, this comes down to a judgement call.

Establish and maintain knowledge levels: The first step here is to identify the skills and experience required on the project.  Projectised organisations generally have a process by which project requirements are matched to skill profiles of employees.  Generally, though, there are always knowledge gaps. These need to be filled through training, workshops joint tasks or whatever. On a related note, it is important that all team members have a base-level knowledge of the project and its business context.

Once knowledge levels are established, it is important to ensure that they are maintained. The author suggests the following practices to minimise knowledge loss:

  1. Ensure key roles have a backup: I’ve discussed this at length in an earlier post.
  2. Seek generalists: Generalists are team members who have a range of skills, and hence can contribute to the project on many different fronts. Furthermore, since they have a wide knowledge, they are able to see connections and (as much as I hate to the word) synergies between seemingly disparate areas. From personal experience I can vouch that a good generalist or two can make a huge  difference on  a project.
  3. Ensure the core team remains together through the duration of the project: This can be hard to do on long projects. The author suggests using financial rewards and bonuses to entice team members to remain on the project. I would suggest supplementing rewards with people-first management techniques. If you run your project keeping people at the centre of focus, it is less likely that folks would want to leave.
  4. Encourage knowledge diffusion through delegation: One way to spread knowledge around is to delegate work and responsibility downward and laterally through the project hierarchy. When people are made responsible for particular tasks, they’ll make it a priority to gain the knowledge required to perform them. However, delegation by itself isn’t enough. Project managers must also ensure that people have the time and means to access and assimilate the required skills. This is often conveniently forgotten.
  5. Develop formal introduction procedures for new team members: A formal induction should be instituted for new team members. This should include project documentation which includes  project background, objectives,  relevant business context and technical information. New team members should also be introduced to “go-to” people for various issues and be assigned a buddy or guide.

Create channels for knowledge flow: An important, but under-appreciated function of a project manager is to establish communication channels for the flow of information and knowledge pertaining to the project.  In this connection, the context in which knowledge is created, shared and utilized is important. This was first pointed out by Nonaka and Konno in a paper published in 1998 where they introduced the concept of “Ba” – or “place” in which knowledge is created and disseminated .

There are a plethora of methods by which knowledge can be shared.  The project manager has to choose the most effective ones – i.e. those that are interactive / easy to access and use. The author makes the following suggestions based on responses from surveyed project managers:

  1. Co-locate teams: This works well providing team members have their own private work spaces (see next point)
  2. Use open-plan offices: This is a common practice, but one which I have to disagree with: the gain in proximity can be more than offset by the loss in productivity.
  3. Publish project newsletters: In my experience these work well for disseminating knowledge about administrative stuff – schedules changes, new people introduction, training and rollout information – but they aren’t necessarily the best vehicle for conveying other types of  project knowledge.
  4. Have daily huddle sessions where key issues are discussed: This works well for issues that need immediate attention, but not so well for other, less urgent (but possibly as important) ones.
  5. Encourage informal communication: In my opinion this is the most effective, but hardest to achieve. Informal communication works best when team members are comfortable with and trust each other. This can only be achieved in an environment of openness, with no sneaky hidden agendas. Even so, it takes time to achieve the required level of trust and comfort.

Knowledge flows through communication channels. Remove obstacles to communication and you’re well on your way to facilitating the free flow of knowledge.

Develop Team Memory: The author identifies the team’s collective memory as one of its most important resources. At the start, various team members contribute suggestions based on their experiences and lessons learned from past projects. This has a major influence on how the project develops initially.  As  the project evolves, team members need to be kept abreast of what decisions have been made and, more importantly, the rationale behind the decisions. At the end of the project, learnings should be recorded in the (infamous?) lessons learned document. The most practical way to go about this to record noteworthy events (and their analyses) as they occur, instead of waiting for the project post-mortem.

Team memory initially consists of individual experiences. As the project evolves, the project manager has to ensure that the team  develops a  shared understanding, or common memory of the project.

Use a risk register: The author suggests placing the knowledge risks listed above in the risk register. These can then be analysed and prioritised based on the specific project environment. Although in risk management the focus is on external events, the author contends that “protecting key team members and their accumulated project knowledge is just as important as protecting the project from exogenous shocks.” I agree. Once the exposure to specific knowledge risks is known, one can put in place appropriate mitigation strategies.


Whew – that was a bit to go through! But the effort of reading the paper (and writing this review) was definitely worth it.  Why?  Well, viewing a project through the lens of knowledge management brings into focus knowledge-based risks that are sometimes overlooked. Further, the paper also offers  some practical advice – couched as principles and practices – to address these risks.   What’s really interesting, as readers have undoubtedly noticed, is that the risks described are generic in that they are common to most projects. Hence understanding these risks and the strategies to address them will enable practising project managers to deal with knowledge-based risks on all their projects.


Reich, Blaize Horner., Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice, Project Management Journal, 38 (2), 5-17. (2007).

Written by K

October 14, 2008 at 11:19 pm

People-first management

with one comment

Edwards Deming believed that work quotas and management by objectives (MBO) are counterproductive because they have a detrimental effect on quality – i.e they emphasise quantity over quality (see point 11 of Deming’s 14 principles).  Despite this, quotas and “objective” performance indicators advocated by MBO   continue to be popular in many organisations. I have had several discussions with assorted managers  from diverse organisations about this,  and although some concede the shortcomings of MBO,  many continue to believe it is the best available method for managing people because it “eliminates” subjectivity.

Now, the alleged objectivity of MBO can be debated, but it’s probably not going to make a whit of a difference: performance measurement systems and those oh-so SMART objectives are here to stay.   Which brings me to my point: performance measurement systems tend distort the behaviour of many managers who, in the push to achieve their objectives,  drive their teams beyond reasonable limits.  In the long run this is counter-productive: folks suffer burnout, lose respect for the manager or, if things get too much,  simply up sticks and leave for pastures of a better shade. This is a loss for the organisation. There is another way – one which  maintains employee motivation and engagement in the workplace whilst also getting the best possible results. Honestly, there’s no rocket science involved; just a small shift in perspective. It can be summed up follows: put people first and results will naturally follow.

How might one do that? Here are some concrete actions one can take:

1. Set people up for success, not failure: This is important: ensure that you set realistic objectives for team members, else you’re just setting them up for failure. Yes, I know Realistic is the “R” in SMART, but it’s frequently forgotten.  What do you do if your boss sets you unrealistic goals?  Two words: push back. Longer answer: explain logically (but without getting emotional or excited) why you think the goals are unachievable in the time allotted. By the same token, be prepared to receive similar feedback from your team. If you have to live with MBO, make sure that meeting objectives doesn’t call for superhuman effort. The workplace is no place for heroics.

2. Assume everyone wants to do their best: Some managers start with the assumption that people need to be supervised and monitored continually (as per Theory X) else they will lapse into slackness and indolence. In my experience the opposite is true: people generally want to do well and be recognised as valuable members of the team. This makes a manager’s job easy:give people meaningful work, empower them to make decisions about how they will do it, and  get out of their way; don’t interfere , avoid gratuitous advice (unlike me!), unnecessary recurring meetings and pointless written reports. Monitor progress informally ( MBWA works well for me in this regard). Jump in only when asked to do so, or if intervention is really necessary.

3. Be consistent: Tell a consistent story from day-to-day. What does this mean? Well, it’s a combination of things, including:

  • Not flip-flopping on decisions. I’ve seen managers who’ve changed their minds as often as they’ve changed clothes. Such behaviour confuses and eventually irritates everyone who reports to them.
  • Approaching work and any work-related issues that arise in a consistent way. This amounts to having a set of principles by which you live your professional life. This is particularly important when you’re under stress, because that’s when impulsive or “out of character” decisions are made. At such times remind yourself of the need for consistency: take a step back and examine the decision in the light of your principles.

Consistency is important; any inconsistency, though not apparent to you, will be quite evident to those who report to you.

4.  Treat failures as learning experiences: Despite everyone’s best efforts, there are times when things go wrong; sometimes badly wrong. At such points it is important to remember that mistakes happen.  Identifying and berating a scapegoat may feel good for a moment or two but the satisfaction soon fades, leaving you with a very upset team member.   Instead of looking to anoint a scapegoat, find out what went wrong and why, and what might have been done to avoid it. This should be done dispassionately, with a no-blame attitude even if the offender is responsible for a  mess up.

5. Don’t “crunch credit”: Often a manager will get the credit for work done by his or her team. This is natural because the manager is the public face of the team. Unfortunately in some of these cases, the  manager hogs the credit, barely acknowledging the efforts of his or her team. The right thing to do, of course, is to pass  the plaudits on to the team, ensuring that those involved are recognised and rewarded appropriately. The latter is important: the rewards should be appropriate  (no lucite plaques!).

6. Offer opportunities to learn new skills: Doing the same thing over and over again gets boring. To maintain the interest and engagement of people in their work, it is critical to offer them opportunities to do new things. Ideally you would have the means to send them to external courses, but sometimes that isn’t possible. However, it is always possible to give people a chance to pick up new skills whilst on the job. Admittedly this is somewhat easier in IT, where even a small corporate IT shop would have a range of technologies – certainly enough to offer people something new to learn. However, people need the time (and official sanction) to do this – and that’s where the manager comes in.

7. Empower people to make decisions: People should be able to make decisions regarding how they do their jobs. This helps in two ways:

  • Decisions get made at the level at which work is done.
  • Folks who do the work feel in control of what they do, and are able to fulfil their potential.

See my post entitled Empowered or Not – a litmus test of organisational culture for more.

The points listed above are based on personal experience. They’ve worked well for me in many different contexts ranging from projects to corporate environments. I can attest to their effectiveness in improving  team motivation and morale which,  in turn, leads to improved productivity and results.

To summarise: push people to achieve results and you’ll get neither results nor a happy team; improve team motivation, though, and you’ll get both in spades.

Written by K

October 10, 2008 at 8:20 pm

A new model of motivation and its relevance for project managers

with 2 comments

Many managers struggle with the question of how to motivate their team members effectively. A recent Harvard Business Review article entitled, Employee Motivation: A Powerful New Model, by Nitin Nohria, Boris Groysberg and Linda Eling-Lee describes a new model that provides concrete steps which organisations and individual managers can take towards improving team motivation. The model is based on analysis of data gathered from a large number of  employees across many organisations.  Projects are temporary organisational structures so  the model is of potential interest to project managers: hence this  annotated summary of the article.

The authors start with the premise that people’s choices are guided by four basic human drives which were described in a book written by Nohria and Lawrence in 2002 (see a review of the book here).  In brief, these are the drives to:

  • Acquire: To obtain tangible items (things such as a car, house etc.) and intangibles (such as respect, status etc.) .
  • Bond: To seek membership in groups (e.g. work teams) and form connections with individuals (e.g. friendships)
  • Comprehend: To understand the world and thus develop a personally meaningful and coherent view of one’s social and work environment.
  • Defend: Protect what is important (to the individual) and ensure fairness (to those who form a part of one’s world)

The authors make the point that these drives are independent, and that one must address all of them in order to motivate employees fully. This is interesting because it implies, for instance, that people cannot be motivated by money alone. This point may be obvious to some, but I know some managers who believe that financial rewards alone are enough to motivate employees and team members.

The authors suggest some organisational levers that may be used to fulfil each of the aforementioned drives. These are:

  • Reward System:  A well-designed reward system that includes equitable remuneration and  transparent, performance-related bonuses can be used to address the drive to acquire.
  • Corporate/Team Culture: A collegial work environment. which encourages openness, camaraderie,   and team work will foster a sense of belonging in employees / team members. This can fulfil the drive to bond.
  • Job Design: The drive to comprehend, or understand one’s place in the world can be fulfilled by engagement in a job that is interesting, challenging and meaningful. The employee or team member should clearly understand the importance of his or her job, and where it fits in the big scheme of things.
  • Performance management and resource allocation: Any system that includes performance-related rewards must be accompanied by an transparent and trustworthy processes to assess performance. Further, any resource allocation (for projects or other corporate initiatives) must be done in a way that is based on the merits of the endeavour, completely free of bias.  Performance assessment, through its effect on individual and team rewards impacts the employees drive to acquire and bond; whereas the resource allocation, through its effect on projects impacts the drive to comprehend (i.e. people’s jobs). Hence these two offer employees ways to defend things that are important to them (or things that fulfil other drives).

Granted, project managers do not always have control over all (or even any!) of the organisational levers listed above. However, the authors’ research indicates that employees more often than not understand the limited influence that  their direct managers have on these levers. Hence, most employees only expect their managers to do their best to fulfil all four motivational drives within the  organisational constraints that are imposed from above. That is, employees are pretty realistic about what their managers can and can’t do. This is good news for project managers because it means that team members generally do not expect miracles from them! Examples of specific things a project manager might do include:

  • Offer more autonomy and learning opportunities to team members.
  • Promote team bonding through joint activities.
  • Foster relationships based on trust within the team.
  • Recognise achievement through public acknowledgement and other non-financial means (for example, by informing the senior management)
  • Raise the profile of the team in the larger organisation.

…and so on. There are ways to tweak organisational levers, even if one doesn’t quite have the muscle to yank them.

To summarise: the article outlines a model of motivation that is built on research in biology and psychology. The model is based on the need to address four basic human drives – i.e. the drives to acquire, bond, comprehend and defend. Managers need to  understand that all four drives must be fulfilled in order to motivate employees fully. Employees generally recognise that their direct managers have limited control over  organisational culture and reward systems. However, they expect their managers to do their best to motivate teams within these constraints. In my opinion the article is worth a read (regardless of the validity of the model) because it emphasises that motivation involves more than financial reward and, even more importantly,  it encourages front-line managers to take an active role in motivating their teams.

Written by K

October 6, 2008 at 8:55 pm

Dysfunctional IT attitudes: users are losers

with one comment

Twenty something years ago…

I approached the computer centre with trepidation – folks had told me of the eccentric misanthropes who manned it. It was unavoidable though; my research project required access to one of the powerful mainframes that were housed in the centre. I didn’t know it at the time, but I was to spend three long years performing  tedious calculations in molecular dynamics as I worked towards my degree; but  that’s another story.

Anyway, I finally found the senior sysadmin’s office and knocked on the door. I heard a grunt in reply, which I chose to interpret as an invitation to enter. The sysadamin, furrowed brow, fingers dancing on keyboard, was evidently engaged in deep, meaningful communication with machine. He paused typing just long enough to push a form towards me.

“Fill it. Leave it with me. You’ll have your account in two days.” Lines delivered, he resumed making eyes at his machine.

As I left his office, I noticed his whiteboard had the following written in big blue capitals:


Very appropriate, I thought. The phrase summed up his view of the people he was hired to help. In those days such an attitude was very common, so I wasn’t as annoyed as I should have been.

Flash forward to the recent past…

“There’s no need to ask our users,” he proclaimed, “we know what they want. Besides, they don’t have any apps with similar functionality right now, so anything we give them will be an improvement. “

“Your users may not think so,” I thought, but didn’t speak out –  a conference dinner isn’t the best place to contradict a CIO from a well known company. I thought his peers  at the table may have something to say,  but if they did,  they kept it to themselves. 

At first I thought the gentleman was joking, but after a few minutes it was clear he wasn’t. He went on in this vein for a while, outlining his vision (nightmare?) of an application environment that was totally IT-Driven.  It turned out that he had been given a carte-blanche to rationalise the IT environment in his domain, and he was about to do just that –  without any user “interference”, thank you very much!

Clearly, in some circles users are still losers.

There are those in IT management who hold such heretical thoughts. They’d much rather not have to worry about meeting end-user demands and expectations. “Anyway”, the thinking goes, “it is impossible to ensure that everyone is satisfied, so why try.” So it’s no surprise that when these folks get an opportunity to take control of their application environments, they do so with complete disregard of their users’ needs.

After all that’s been said and written about the need for IT/Business Alignment and customer-focused IT, there are still those who cling to the “our users are dumb; we know best” attitude. They live in a world that deliberately shuns contact with end-users, and hence continue to develop and deliver apps that nobody wants to use. Technology may have changed the face of the world, but in this case  perhaps another cliche is more appropriate: the more things change, the more they stay the same.

Written by K

October 2, 2008 at 10:41 pm

%d bloggers like this: