Author Archive
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.
Dysfunctional IT attitudes: users are losers
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:
USERS ARE LOSERS
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.
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).
Eight to Late 