Archive for September 2008
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.
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 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.
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.
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 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.
The lack of a clear definition of project complexity has lead to much confusion amongst project management academics and practitioners regarding what makes a project complex to manage. A recent paper by Harvey Maylor, Richard Vidgen and Stephen Carver, entitled Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice, is a step towards changing this situation. In the paper Maylor and his co-workers present a qualitative empirical model which captures both structural (static) and dynamic1 elements of managerial complexity in projects. I summarise and review the paper below.
Background and Objectives
The authors make the observation that project management methodologies (as codified in the various “bodies of knowledge”) contain what is deemed as accepted practice rather than best practice. The point being that there is never any proof offered that the practice in question is indeed the best, or even better than others. Such proof is impossible because methodologies are highly prescriptive and ignore context (i.e. the particular environment and quirks of individual projects). This dogmatic, “our way is the best way” attitude is inconsistent with the diversity of situations and factors that make projects hard to manage. Hence the need to develop a understanding of what makes a project complex.
It may thus be helpful to consider projects as complex adaptive systems. As a first step, the authors discuss various characterstics of such systems, in particular those that might apply to projects. I have covered much of this material in an earlier post, so my coverage here will be brief. The main points the authors make are as follows:
- The components of a complex system interact and produce outcomes that are unpredictable and nonlinear.
- One cannot understand a complex system by studying the individual components that comprise it.
- A complex system displays path dependence (i.e. dependence on history) and sensitivity to initial conditions.
- Adaptive systems can change and “learn” from experience.
There have been several models of project complexity proposed by researchers. Each of these propose various dimensions (or factors) that capture complexity. Some of these factors are:
- The number of physical elements of a project and their interdependencies. (Baccarini)
- Organisational, technical and resource complexity.
- Organisational and technical complexity, and structural and dynamic interactions between the two. (Xia and Lee)
Although earlier models have been useful, organisations have found that other factors (unaccounted for in existing models) contribute to managerial complexity in projects. With this in mind, the authors’ aim to develop a comprehensive empirical model of managerial complexity in projects and thus answer the question: What makes a project complex to manage?
The model was developed through workshops that involved a large number of practising project managers. I will not go into details of research methodology here; please see the original paper for details. What is important to note is that the model includes input from a broad range of practitioners. With that said, I’ll move straight on to a description of the model.
The model describes both structural and dynamic elements of managerial complexity. The authors find that structural complexity in projects comprises of the following broad dimensions: Mission, Organisation, Delivery, Stakeholders and Team. Following a distinctly academic penchant for acronymisation (to coin a term), the authors call their model MODeST, taking the first letter or two from each of the above dimensions.
The hierarchy below lists each of the above dimensions along with their sub-dimensions. Further, the lowest level of the hierarchy (sub-dimension level) lists representative questions that can be used to characterise each sub-dimension. (Note: Please see the paper for full details).
- Is there a clear vision?
- Are the goals clear?
- Long timescale?
- Large number of resources?
- Are there interdependencies with other projects?
- Are there interdependencies within the project?
- Does it involve new technology?
- Has the project been done before?
- Are there legislative or compliance constraints?
- Are there multiple timezones?
- Are team members colocated?
- Is there face-to-face communication between team members?
- Are there multiple languages?
- Project / organisation fit
- Is there a mismatch between project team structure and organisational structure?
- Organisational change
- Does the project involve organisational restructuring?
- Is project reporting accurate, adequate and does information get to people who need it?
- Is project data collection accurate, true and complete.
- Decision Making
- Is there effective governance of project decision making?
- Are too many levels of management involved in decision making?
- Change management
- Is the change management process cost effective?
- Is it flexible?
- Project processes
- Are project processes defined, standardised but not overly bureaucratic?
- Is there a clear responsibility for tasks and deliverables?
- Project management methodology
- Is there a common methodology used throughout the project?
- Resources – Human
- Are human resources shared across projects?
- Who controls human resources for the project?
- Does the project manager have control over resource selection?
- Resources – Technology
- Does the project have tool support?
- Resources – Financial
- How flexible is the project budget?
- Stakeholder Identification
- How many stakeholders are there?
- Are there any unidentified stakeholders?
- Support for project
- Do stakeholder groups interfere with the project?
- Do stakeholders have sufficient time for the project?
- Do they respond to project needs in a timely manner?
- Relationship basis
- Is the relationship between the project and stakeholders contractual?
- Do the stakeholders have realistic expectations of the project?
- Do they have domain experience?
- Do they have project management experience?
- Do the stakeholders have power to make decisions.
- Key stakeholders
- Is there senior management support?
- Are there hidden agendas or unsurfaced assumptions?
- Do stakeholders have conflicting priorities?
- Are there any conflicts between requirements of different stakeholders?
- Are there interdependencies between stakeholders? (e.g. between suppliers)
- Stakeholder Identification
- Project staff
- Do team members have sufficient prior experience?
Does the project involve multiple technical disciplines and languages?
- Are the team members knowledgeable and competent in all aspects of the project (business, technical and project management)?
- Are the team members motivated?
- Do team members have sufficient prior experience?
- Project manager
- Is the project manager an effective communicator?
- Does the project manager have authority?
- Are there cultural differences between team members?
- Are there personality clashes or is there any rivalry within the team?
- Does the team have a shared vision for the project?
- Project staff
The above dimensions and sub-dimensions characterise the structure of managerial complexity in projects. However, that isn’t all: the authors mention that many workshop respondents emphasised that elements (i.e dimensions) that make up the model interact thereby “multiplying” managerial complexity. This is one aspect of dynamic complexity. The authors also note that interactions can occur within a single element – for example, within interdependencies between suppliers and stakeholders. Analysis of the data showed that there is a dynamic element corresponding to every structural element of the model. Further still, dynamics of an individual structural element can be affected by interactions with other structural and dynamic elements. That is, the dynamics of one part of the system can be altered by other changes in other parts. The model thus captures structural, dynamic and interactive aspects of managerial complexity in projects.
The authors report that workshop participants also recognised their own role in adding to managerial complexity. For example, a project manager who fails to recognise task dependencies in early stages of a project contributes to complexity down the line. Project managers are thus, ” key actors embedded within the conceptualisation of the complexity of their projects rather than external observers.” The authors suggest that this indicates that many elements of managerial complexity can in fact be tamed by proper management. That, arguably, is what a project manager’s job is all about.
Implications and Discussion
The authors observe that projects are ubiquitous within organisations. Yet, current project management practices as codified in well-known methodologies fail to account for variations in context between projects. Managerial complexity varies with (and is defined by) a particular project’s context – for instance, a project may have several stakeholders with conflicting requirements whereas another may have only one stakeholder. The model developed by the authors describes managerial complexity using five dimensions and several sub-dimensions. These structural elements can change in time and also interact with each other, so the model is also capable of describing dynamic complexity in projects.
To illustrate expand on the last point of the previous paragraph, consider stakeholders – the “S” in the MoDest acronym. The authors point out that, “from an organisational theory perspective, a project can be seen as being constituted from the entire set of relationships it has with itself and with its stakeholders.” Project managers need to understand not only the power and legitimacy of each of the stakeholders, but also the relationships or interactions between them. Moreover, the relationships between stakeholders evolve in time – i.e they are dynamic. Similarly, the other four dimensions of the model also display dynamic behaviour.
This dynamic behaviour is merely a restatement of the obvious: in projects things change, sometimes rather quickly and unexpectedly. Standard project management practice offers techniques such as risk management, configuration management and change control to manage these. However, the authors suggest their data shows that, “the nature of change considered by existing approaches is limited and that such programmatic responses may be inappropriate.” They go on to state, “Such dissatisfaction with traditional requirements engineering and command-and-control project management strategies has lead to an interest in agile project management approaches.” These statements will ring true for those who have been burned by the limitations of traditional project management methodologies. Agile techniques embrace change; traditional methodologies seek to control it (and do so unsuccessfully, one might add). The implicit acceptance of change in agile methodologies make it consistent with the dynamic model of managerial complexity proposed by the authors.
The paper describes an empirical model of managerial complexity in projects. From my (admittedly incomplete) reading of the literature, the model is more comprehensive than those that have been proposed heretofore. Further, it captures structural, dynamic and interactive aspects of elements that make a project complex and hard to manage. The model challenges current practice as embodied in traditional, “big-bang” approaches to running projects, but is consistent with Iterative/Incremental methodologies which form the basis of agile techniques.
The authors end with a brief description of some areas for further research. Some of these include:
- Refining the dimensions of complexity and finding the key drivers of each.
- Determining whether compexity can be quantified.
- Exploring the possibility of managing complexity.
We are still a long way off answering these questions, and thus developing a quantitative, controllable understanding of project complexity. Yet, the model presented provides at least a partial answer to the question: What makes a project complex to manage?
Maylor, Harvey., Vidgen, Richard, & Carver, Stephen., Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice, Project Management Journal, 39 (Supplement), S15-S26. (2008).
1 See this post for more on structural and dynamic complexity.
Calculus is an important part of the mathematical toolkit of scientists and engineers. I’m sure some of my readers have (perhaps, not so fond) memories of many (perhaps, not so entertaining) hours spent in learning calculus during their late high-school / early college years. Calculus has two main branches: differential calculus and integral calculus. The first branch deals with a mathematical technique called differentiation, which enables one to calculate the variation of a quantity with respect to another – for example, change of distance with respect to time, aka speed. The second branch deals with integration, a technique to compute the net (or summed) effect of small variations – for example, speed*time, summed up over all time slices, yields the total distance travelled. As the examples suggest, the two techniques are the inversely related. In this post I draw an analogy between these operations of calculus and two somewhat opposite, or inverse, things a project manager has to do in order to ensure the smooth and effective functioning of a team.
Project teams consist of individuals, each with different skills, aptitudes and personalities. Yet the team has to function as a unit, pulling together, ensuring that every individual’s effort contributes to achieving the team goal. In order to do this, the project manager has to employ the inverse techniques of team differentiation and integration as I outline below.
It’s a given that no two people are the same. Yet many managers deal with all their team members in exactly the same way. This is a mistake. One has to tailor one’s management approach to suit individual personalities and quirks. But even before this, one has to take the time to understand what makes each individual tick – knowledge, skills, professional interests, approach to work, career aspirations etc. This isn’t always easy to elicit (no, a questionnaire won’t work!). One has to get to know people one-on-one, taking time to talk to them in different situations and contexts. Over time one builds up a picture of the things that make them different and unique from everyone else on the team.
Why is this important? Well, if you really understand the folks who make up your team, you’ll develop a feeling for what they will be able and willing to do on a project. You’ll get a sense for their strengths and weaknesses, both technical and otherwise. This is knowledge that is useful in all stages of a project, but particularly so in times of crisis.
Differentiation, in essence, boils down to developing individualised work relationships with each team member. All the outstanding project managers I have known have been able to do this effortlessly, and in a non-intrusive way. I reckon this (not so common) skill is one of the important factors that sets the brilliant apart from the run-of-the-mill project manager.
A few words of warning though: Although the best way to get to know people is through conversation, remember to be sensitive to differences in personality, and also to avoid topics that may be construed as personal. Further, be genuine – there’s nothing worse than false interest or bonhomie; and it shows a mile away!
Differentiation is one aspect of team management, the other is integration: i.e. integrating diverse personalities and skills into a coherent team. Most mainstream theories of team development are built around Tuckman’s four-stage forming-storming-norming-performing model. In brief: the first stage corresponds to team formation; the second to debates / confrontations between individuals on the team; the third to settling down and development of trust; the fourth to working on the task that the team has been charged with. The project manager has a supervisory (I prefer the word, integrative) role in all four phases, but especially so in the first two.
In an ideal situation the project manager has had a chance to get to know team members prior to team formation. If so, through differentiation, he or she already knows the strengths and weaknesses of each individual. The project manager can thus match project requirements to individual skills and aptitudes to come up with an optimal team. Once the team is formed, the project manager can facilitate project discussions, armed with a good sense for who might be able to contribute in specific areas. Furthermore, he or she will also be able to defuse conflicts or mediate disagreements between team members more effectively than would have been the case without this knowledge.
In mathematics differentiation and integration are the basic operations of calculus. In this post, through analogy, I have discussed the importance of the two techniques in the context of project teams. Much like the engineer who has to master differentiation and integration, the project manager has to be adept at both techniques of the calculus of project teams.
Many projects are run as collaborative efforts between customer and provider (or vendor) organisations. It is well accepted that such co-creation involving both parties is an effective way for service organisations to enhance acceptance of the services they provide. It is a common practice for IT service providers to locate their consultants at client sites for the entire duration of the project. In this period consultants and client-side employees work together in blended teams. It is clear that the (provider-side) project manager plays a critical role in such projects because he or she is at the interface, or boundary, between two organisations. A recent paper, by Sheila Simsarian Webber, entitled, Blending Service Provider – Client Project Teams to Achieve Client Trust: Implications for Project Team Trust, Cohesion and Performance, published in the June 2008 issue of the Project Management Journal, investigates the effectiveness of such teaming from the perspective of trust between the project manager (as a proxy for the supplier) and the client. I review the paper below.
Background and Objectives
Interestingly, most of the research on co-creation or co-production has focused on bringing the customer into the service organisation rather than the other way round. That’s strange (to me at any rate) because the latter situation, in which provider-side employees are placed in client organisations, is way more common in IT projects. Placing employees within client organisations gives the service provider ongoing opportunities to understand a client’s business better, and thus foster long-term relationships with them. However, this works only if there is trust between the two parties. The project manager (as a proxy for the provider) plays a key role in developing this relationship. In the paper, the author provides empirical evidence that the use of blended teams creates a more trusting relationship between the client and project manager. Further, the research also shows that gaining the client’s trust has the side effect of improving (intra-team) team trust, cohesion and performance.
Before proceeding any further, it is worth defining what is meant by trust. Following Mayer, Davis and Schoorman, the author defines interpersonal trust as the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the ability to monitor or control that party. Researchers have identified two dimensions of interpersonal trust: affective and cognitive. The first is based on emotional bonds and the second on notions of reliability, dependability and competence. Trust among business partners involves both types of trust. In the case at hand, it is important that the client not only believes in the project managers competence, but also that he or she cares about the client’s business (i.e. has an emotional bond with the client). Blended teams provide more opportunity for interaction between the client and provider and hence the basis for the author’s first hypothesis:
Hypothesis 1. Blended project teams will have greater client trust (than non-blended teams).
Katz and Kahn proposed that an organization be considered as an open system that interacts with its environment. If this is so, it is important that boundary relationships – i.e. relationships at the interface between an organisation and its environment (which could be another organisation) – be managed effectively. The open system concept has been applied to teams as well. Further, earlier research has demonstrated that managing relationships outside team boundaries is important for knowledge transfer and team success. In the case of project teams, managing external relationships is generally the responsibility of the project manager. In the present case the main external relationship (from the perspective of the provider) is the one between the project manager and the client. Based on research by Amy Edmondson , which suggests that boundary spanning relationships affect team trust, cohesion and effectiveness, the author proposes the following as her second hypothesis:
Hypothesis 2. Client trust in his or her direct project manager will be positively (or directly) related to team trust, cohesion or performance. That is, as client trust (in the PM) increases, so does team trust, cohesion and performance.
Finally, as a follow-on to the second hypothesis, the author suggests a that there is a stronger positive correlation between client trust and team trust, cohesion and performance if the team is blended. This leads to her third hypothesis which is:
Hypothesis 3. The relationship between client trust and team trust, cohesion and performance is stronger when teams are blended (as compared to non-blended teams).
Results and Discussion
The author surveyed 31 IT project teams (20 blended and 11 non-blended). Data was collected from project managers, their primary client contacts and project teams. Project managers reported on background information, nature and duration of project and whether or not the team was blended; clients were surveyed for an assessment of trust (cognitive and affective); and teams were asked about team trust, cohesion and performance. I won’t discuss specific metrics used by the author – please see the original paper for more on these.
The research results vis-a-vis the above hypotheses can be summarised as follows:
1. Clients tend to have greater (cognitive and affective) trust in project managers who are a part of a blended team.
2. The client’s cognitive trust in the project manager has significant positive implications for the team’s (internal) cognitive trust and has marginally significant positive implications for the team’s affective trust. Interestingly, the client’s affective trust in the project manager has significant positive implications for the team’s cognitive and affective trust. This seems to suggest that emotional trust between the client and the project manager carries more weight than perceptions relating to competence and reliability.
3. The results around the third hypothesis are even more interesting. The data suggests that there is a relationship between client trust / team trust, cohesion and performance and whether or not a team is blended. However, this relationship isn’t as hypothesised: it turns out that when the client does not have much cognitive trust in the project manager, a blended team has significantly less cognitive team trust than a non-blended team. Similar results hold for team performance: when the client does not have much affective trust in the project manager, a blended team will show significantly lower levels of performance than non-blended teams. Why should this be so? I suggest it is because non-blended teams, due to the lack of interaction between client and provider side team members, are shielded from the politics of the client-project manager relationship. In blended teams, on the other hand, co-location of team members and managers, and the resulting opportunities for informal communication, means that a sour relationship between the client and project manager can quickly translate to breakdown of team relationships.
The results lend empirical backing to the importance of client relationship management for project managers. Specifically, for blended teams, the research shows that trust between the project manager and the client is directly related to team trust and performance. Furthermore, blended teams tend to be more negatively affected than non-blended teams in cases where the relationship between the project manager and client is not good. This, again, highlights the critical role of client-project manager relationships for blended teams.
Although many of the results discussed in the previous may seem evident to professional project managers who work with blended teams, the research is interesting because it lends empirical support to such “obvious” notions. Having said that, the conclusions drawn by the author should not be overstated, particularly because of the small sample size and limitations imposed by the survey methodology (for example, the data did not capture the nature / scope of the project and other factors which may have an effect on the conclusions). Further, the research does not consider factors such as organisational culture and constraints, which may have a significant effect on the functioning of blended teams and the development of trust between employees from different organisations. In view of these limitations the results can be regarded as suggestive, but by no means definitive. Nevertheless, the paper is of interest to project managers and senior executives who work in service and consulting organisations.
Webber, S.S., Blending Service Provider – Client Project Teams to Achieve Client Trust: Implications for Project Team Trust, Cohesion and Performance, Project Management Journal, 39 (2), 72-81. (2008).
The word process has several different connotations – an online dictionary lists more than twenty meanings of the word. Amongst these, the following is the sense in which the word is used when we speak of a project management process:
Process (noun): a systematic series of actions directed to some end.
The key word here is systematic – which (again from the same online dictionary) means according to a method. The word process thus has a very precise meaning – a series of methodical actions which are directed to some (definite) end. The word, as used in normal parlance, evokes a world in which a sequence of well-defined actions lead to certain desired results. This may be an excellent approximation to reality on the manufacturing shop-floor, but is little more than an illusion in the messy world of projects. Having made a potentially controversial statement, I’d better clarify what I mean. I do so below.
The objective in manufacturing is to mass-produce items in a controlled and repeatable manner. In constrast, in projects the aim is to create unique products (or services). In the former case, it makes perfect sense to formalise actions required to create the product into well-defined and detailed processes. Such processes tend to be very prescriptive: e.g. immerse the widget in the solution for 3 minutes, then air dry at 200 C for 2 minutes. Such prescriptiveness is required for ensuring repeatability (of processes) and reproducibility (of results). It also confers an advantage in quality improvement efforts: such processes can be tweaked in a controlled fashion whilst maintaining a sensible baseline for comparison. In the case of projects, though, the notion of a process isn’t quite the same. Given that every project aims to create a one-off, unique product, how does the idea of “systematic actions directed to an end” apply? I take a brief look at some half-answers below.
Wikipedia defines a project management process as a management process of planning and controlling the performance or execution of a project. The definition isn’t much help, so let us start with a commonly accepted example of a project management process instead: schedule development or scheduling (as per PMI or PRINCE2). Now, although schedule development has a bunch of inputs, tools and techniques, and outputs, these leave much open to interpretation. That is, they aren’t as prescriptive as processes in manufacturing. They don’t even come close to being “a systematic series of actions directed to some end.” Yet, they are often considered by project managers as being so. That, in my opinion, is the problem. Let me hasten to add that frameworks and methodologies aren’t at fault here – most do emphasise that they provide guidelines not recipes. As I have mentioned in an earlier post, this is largely a problem of our own making. To paraphrase the Bard: The fault, dear Brutus, is not in our processes, But in ourselves, that we are obsessed with them.
The history of project management yields a clue as to why the notion of process – despite its shortcomings – is so ingrained in project management theory and practice. As Patrick Weaver points out, the roots of modern project management lie in concepts of scientific management, or Taylorism as it is called after its founder, Fredrick Taylor. To quote Weaver, “…Project management has evolved in its specialist area along very similar lines to general management theory. In early days, project management closely mirrored the classical school of management with a focus on scientific processes…” Why this early focus on scientific processes? Well, Weaver mentions that, “…it is entirely reasonable to argue that the evolution of modern project management is a direct consequence of the need for professional schedulers for a forum to discuss and develop their new discipline….” Since scheduling is arguably the most mathematical (or statistical) process in the project management process pantheon, the focus on scientific management is really no surprise.
In recent years things have moved on. In their paper on future challenges and opportunities in project management (which I have reviewed in an earlier post), Shenhar and Dvir point out that there are three central paradigms of project management: operational/process, team/leadership and business/strategic. The process-based approach, rooted in scientific management, corresponds to the first. The team/leadership view puts people at the centre of focus, and as we all (should!) know, people aren’t as simple as processes. The last perspective is the big-picture: project management as a strategic tool. As is the case with people, this too cannot be reduced to formulaic processes. The fact that the latter two perspectives have been getting more attention in recent years indicates that things are changing. So, perhaps it is only a matter of time before the practice of project management is cured of its process obsession.
Wikipedia defines the bus factor as the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed. Although most discussions about the bus factor revolve around software projects, the considerations apply to any situation where important, specialised knowledge is held by a small number of people. For example, an IT department where there is little or no cross-training or cross-over in roles would have a low bus factor.
Increasing the bus factor amounts to spreading the knowledge around so that there is a degree of redundancy in skills and knowledge within a team. This ensures that work will go on even if a key person has an unfortunate encounter with a public transport vehicle. It is clear that every manager should aim to increase the bus factor for all processes that come under his or her purview. Below I outline a few suggestions on how one might do so.
- Keep things simple: Keep processes as simple as possible (but no simpler!). This ensures that the processes are easy to maintain and hence easy to teach to others. Simplicity usually boils down to two things: a) using the right tool for the right job, and b)using the most straightforward way to achieve what’s needed. I have seen several processes that are needlessly complicated by inappropriate technologies or use of technologies. To elaborate on the latter, processes are overengineered often for no other reason than to demonstrate the cleverness of the process creator. Avoid creating such Rube Goldberg processes at all costs!
An important, simplicity related factor (from the bus point of view) is to use technologies that are familiar to more than one person on the team. This builds in a high bus factor from the start.
- Document, document, document: This is a no-brainer, but people still think they can get away with “doing it first and documenting it later.” Documentation done after the fact is often less than useful because the author forgets to include some (many?) small detail(s) which, of course, turn out to be critical ones in times of trouble. What should a process document contain? Enough to help someone figure out what, how, where, when – what it does; how it’s run; where it sits (servers etc.); and when and how often it’s run. The documentation should also include some basic troubleshooting information and references to relevant sections of manuals.
Another important point is to keep the documentation in synch with the process – i.e. to update all relevant documents whenever the process is modified. This is essential because process documentation is your only guide when the owner of a process with bus factor 1 goes under the bus instead of getting on it.
A small word about style is perhaps in order – process documentation should adhere to the 3Cs of clarity, conciseness and comprehensibility. Yes, it is possible to write in a way that achieves all three, although this isn’t evident in my writing.
- Encourage people to pick up secondary skills: The first two points dealt with process and documentation. However, in the end, it is people who make things happen. Despite well-engineered and documented processes, one can still have a low bus factor if the team doesn’t have skill redundancy. Who’ll look after the databases the when the DBA goes under (or is run over by) a bus? This question wouldn’t have to be asked if someone had been cross-trained in basic DBA tasks. As far as possible, every one on the team should have at least one secondary skill that will enable them to cover for someone else.
All this stuff is obvious. Yet I’ve seen more than a few outfits with very low bus factors (sometimes as low as zero. Yes, really!), so perhaps it isn’t taken as seriously as it should be. I therefore close with this exercise: take stock of the activities and processes that your department or team supports. Do you see any danger zones with low bus factors? If the answer’s affirmative, get moving before a bus comes around.