Archive for the ‘Project Management’ Category
A new model of motivation and its relevance for project managers
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.
New (yet not so new) techniques for managing complexity in projects
Over the last year or so I have written several posts on project complexity , most of which are based on papers published in trade and research journals. From my reading of the literature, it seems that most of the research on complexity in projects is aimed at answering one of the following questions:
-
Can projects be viewed as complex systems?
-
What makes projects complex to manage?
The first approach starts out with well-established concepts from the theory of complex systems and attempts to apply these to projects and project management. The second starts from the other end, using data to build models of complexity in projects. The two strands are complementary: one involves theory and concepts, the other empirical modelling. There is a third way – one that is purely pragmatic: it proposes practical techniques to manage complexity, on the basis of the demonstrated utility of these practices in a few representatives cases. In this situation, theories are too general to be applicable, and model building isn’t possible because of the small number of data points. In this post I look at a paper by Christian Berggren, Jack Jarkvik and Jonas Soderlund entitled, Lagomizing, Organic Integration and Systems Emergency Wards: Innovative Practices in Managing Complex Systems Development Projects, that takes this third approach. I review the paper, emphasising the practices presented by the authors. I also draw connections between the practices suggested and those that are already well-known and accepted in the software development world.
The authors begin by pointing out that although researchers have recognised the need for flexible, adaptive approaches to project management, most of the work is “…overly general in character and lacks grounded suggestions for effective managerial practices…” To address this, they take a practice-based approach wherein they present three techniques that have been used in complex telecom systems development projects at Ericsson. The three practices address the need to reduce complexity, understand complexity and rapidly act on the consequences of complexity respectively. They are:
-
Lagomising: a top-down approach to redefining project goals and transforming expectations based on the simplest possible design to achieve the core product functionality. The term lagomising is derived from the Swedish word lagom, which (according to the authors) means just right.
-
Organic Integration: a visual technique to help everyone on the team develop a shared understanding of system capabilities or functionalities.
-
Systems Emergency Ward: A high-visibility forum for managing errors and making associated decisions.
I describe each of the techniques below, followed by some comments which draw connections between these techniques and those already in use within the software development community.
Lagomising
According to the authors, “Mainstream project management often portrays delivery on time and according to specifications to be the keys for successful project management. However, according to our experience, it is normally not possible to meet both delivery time and specified customer requirements.” To this, I would add that customer specifications are often not entirely clear, leaving much open to interpretation by the project team.
The authors suggest that this issue can be successfully tackled via lagomising: a top-down driven reduction of specifications that does not involve the customer. Lagomising is not to be interpreted as a license to cut down on functionality (which obviously would not be acceptable to the customer). Instead, it is a simplification of specifications; paring down of unnecessary “fat”, whilst keeping the essential functionality intact. The authors explain that another aim is to, “…drive down designers’ interpretations of specifications from technical perfection to the simplest possible levels…“
To summarise, the benefits of lagomising are:
-
Clarification of unclear specifications.
-
Reduction or elimination of over-interpretation of specifications by the project team.
-
Addition of value by delivering useful functionality, albeit that which may differ somewhat from the original customer specification.
In absence of customer input, the task of lagomising falls to the project manager. As the authors state, “…project management takes on the task of delimiting scope, imposing non-negotiable constraints and reducing complexity…” Furthermore, since liberties have been taken with the original specification, it is imperative that the customer approval is obtained early in the game. Providing key functionality requested by the customer is retained, this should not be too hard. Any refinements and “nice to haves” (aka bells and whistles) should be postponed to the next phase.
Organic Integration
Organic integration begins with the premise that, “nothing is right from the beginning and traditional project plans are never sufficient.” This is simply an articulation of the well-known conundrum faced by project managers working with complicated projects: much about the deliverables is unknown at the start, but traditional project plans require that everything be known. This contradiction is particularly stark when technologies involved are complex, new or changing.But problems remain even when everything is known – one often finds that initial certainties dissolve into a morass of uncertainties as the project progresses. The traditional approach to dealing with complexity is to decompose deliverables using a work breakdown structure, and then apportion work packages to individuals or sub-teams. Although this may be the only way to proceed in very large projects, it is generally hard to achieve such a decomposition because of the complex interdependencies between components. Furthermore, a consequence partitioning the work in this way is that the project team will lack a shared understanding of the whole system. Such a collective view of the system is important on complex projects.
Based on their experience, the authors suggest developing a collective view based on functionality rather than function. Put another way: the system should be viewed in terms of what it does rather than what it is made up of. This method of visualising the system, termed system anatomy, has been described in a paper by Lars Taxen and Joachim Lillieskold, published in the ALOIS 2005 Conference Proceedings (see page 38 of the document).
According to the authors, organic integration starts with taking a system anatomy view and then identifying and building basic functionality first. More complex functionality is built later in short iterations. At every step continual integration (with what has been build to date) and testing is carried out. Such an incremental approach towards complexity ensures that unforeseen issues and problems are flushed out in a manageable way. Learnings can be assimilated by the team, and the plan refined.
The suggested approach radically different from the work or product breakdown structures recommended by traditional methodologies. The system anatomy / organic integration approach attempts to develop a shared understanding of the system based on non-decomposable functional interdependencies. The resulting project plan does not have a cast-iron schedule. It is based, instead, on incremental steps that must be followed in order to achieve the total functionality of the system.
Systems Emergency Ward
According to the authors, the challenge of handling errors on any complex project is akin to that of “navigating in tricky and misty waters.” This metaphor would be very familiar to those who have worked on software projects of any complexity: any changes to existing code runs the the risk of introducing regressions.
In Ericsson, this challenge is dealt with using an approach called Systemakut, which means System Emergency Ward. The basic idea is simple (and I suspect, is used in many shops): project managers and system specialists meet daily to discuss, prioritise and action all errors reported. The forum should include representatives from all relevant areas (sub-systems, specialisations or whatever) and management. The presence of management is important because it emphasises that error resolution is important in the big scheme of things. Since corrective actions may introduce new errors, the preference should always be to introduce the smallest number of changes possible, ensuring that these do indeed improve sytem capabilities.
On a related note, the authors also draw attention to the fact that, in the telecom industry, “new requirements are frequently added during the development time, and delivery time unstable. Nevertheless projects are required to deliver on short notice and still have complete knowledge regarding the usefulness, functionality and properties of the system delivered.” A consequence is that a system in development must be tested regularly and under realistic conditions to ensure that it works as expected. Such a practice keeps regression errors under control. It makes a case for frequent system builds – a practice already in place in many software development shops.
Concluding Remarks
Having read this far, I’m sure many readers would be going, “Hey, we already do that.” I have deliberately held back on commenting (well, almost!), but can’t help but notice that elements of the practices described by the authors are routinely used by many software development teams. For example:
-
Some of the practices described in organic integration are already followed inIterative/Incremental approaches to software development
- The system emergency ward technique incorporates regular system builds, a practice recommended by some agile methodologies.
To be fair the authors do mention that, “Several novel methods such as Scrum and Agile Project Management have been suggested. In several ways, these methods have been driven by technological development and opportunities within the software industry…From a research-oriented perspective, however, relatively few of these new practices are based on well-founded empirical analyses.” I’d say that’s a fair summary of the status of these methods. But here’s the problem – the practices proposed in the paper, being based on a small number of experiences in a single organisation, aren’t based on “well-founded empirical analyses” either. So where does that leave us?
Here’s the situtation as I see it: the practices are interesting and they work (as attested to by the authors and the experience of many agile development shops), but they don’t have empirical backing (i.e. the claims haven’t been quantified or validated by statistical studies). At this point readers may say, “So what? We don’t care about proof as long as the practices work.” And, you know what? I’d have to agree.
References:
Berggren, Christian., Jarkvik, Jack, & Soderlund, Jonas., Lagomizing, Organic Integration, and Systems Emergency Wards: Innovative Practices in Managing Complex Systems Development Projects, Project Management Journal, 39 (Supplement), S111-S122. (2008).
The sneak, the subversive, the shirk and the self-promoter
The presence of a bad apple in a team can have a significant negative effect on collective performance and morale. Unfortunately, many managers fail to do anything about these folks until it is too late. Often this happens because they fail to foresee the rot that can be wrought by these individuals. In this post I focus on four types of “rotten apples” I’ve come across. Coincidentally, these characters are best characterised by nouns that begin with the letter S. Now, S also happens to be the symbol for entropy which in social terms is defined as, “a doctrine of inevitable social decline and degeneration.” This is apt, as these folks can contribute to and even accelerate the decline of a team. So here they are, the sneak, the subversive, the shirk and the self-promoter1…
- The sneak: This is the guy who carries tales of your alleged wrong-doing to levels above. He’s dangerous because he has the confidence of a senior manager, whom he regularly regales with stories of your incompetence. His version of events – which may or may not have any relation to the truth – is designed to make you, the manager, look as bad as possible. Unfortunately, because of his connections, one has to be careful when tackling the sneak.
- The subversive: Closely related to the sneak, the subversive is the revolutionary who foments turmoil within the team. He does this by spreading stories of an unsettling kind. These are crafted for shock value – for instance, one could be built around a rumour that the company is about to indulge in a bout of downsizing (and the project team are candidates) or that project funding is about to be cut. These folks tend to tone down their activities once they’re aware that their penchant for stirring things up is known. So the best way to handle a subversive is to confront him.
- The shirk: This fellow is the teflon-man as far as work is concerned. He is seemingly able to avoid any tasks that require him to work at his full capacity. Yet, even though he is under-worked, he’s always late in completing his tasks. He manages to get away with it by palming off the responsibility for the delay on to an unsuspecting team member – “I couldn’t finish because Jake didn’t give me X in time” (where X is just any old Xcuse) or even the odd force majeure. So one’s stuck with the shirk because it’s never his fault. The best way to handle the shirk is to give him work and monitor progress closely. This is one situation where micromanagement (as bad as it is) may actually be necessary.
- The self-promoter: This gent is always in the background when work is doled out, but right at the front to claim credit- more so when senior management’s around. He thrives on accepting kudos for work that someone else did. In the unlikely event that he does something significant, you can be sure that the entire organisation will hear about it for the next few years. The strange thing is that this tactic quite often works. Through relentless self-promotion, the self-promoter rises through the corporate hierarchy much faster than his quieter colleagues. The self-promoter is best handled by giving him only as much attention as is his due – which isn’t very much at all.
Managing teams implies managing people. However, 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. The characters I’ve listed above are exceptions: watch out for them, manage them. You ignore them at your own peril.
1 Although the post refers to these folks using masculine nouns and pronouns, needless to say they can be of either gender.
Eight to Late 