Archive for the ‘Paper Review’ Category
Managing knowledge on IT projects
Background
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.
Introduction
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:
- 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.
- 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.
- 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.
- 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.
- 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:
- Ensure key roles have a backup: I’ve discussed this at length in an earlier post.
- 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.
- 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.
- 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.
- 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:
- Co-locate teams: This works well providing team members have their own private work spaces (see next point)
- 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.
- 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.
- 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.
- 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.
Conclusion
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.
References:
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).
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).
A model of project complexity
Introduction
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
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).
- Mission
- Objectives
- Is there a clear vision?
- Are the goals clear?
- Scale
- Long timescale?
- Large number of resources?
- Uncertainty
- Are there interdependencies with other projects?
- Are there interdependencies within the project?
- Does it involve new technology?
- Has the project been done before?
- Constraints
- Are there legislative or compliance constraints?
- Objectives
- Organisation
- Time
- Are there multiple timezones?
- Space
- Are team members colocated?
- Is there face-to-face communication between team members?
- Geography
- 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?
- Time
- Delivery
- Administration
- 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?
- Administration
- Stakeholders
- 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?
- Experience
- Do the stakeholders have realistic expectations of the project?
- Do they have domain experience?
- Do they have project management experience?
- Power
- Do the stakeholders have power to make decisions.
- Key stakeholders
- Is there senior management support?
- Sociopolitical
- Are there hidden agendas or unsurfaced assumptions?
- Do stakeholders have conflicting priorities?
- Are there any conflicts between requirements of different stakeholders?
- Interdependencies
- Are there interdependencies between stakeholders? (e.g. between suppliers)
- Stakeholder Identification
- Team
- 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?
- Group
- 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.
Conclusion
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?
References:
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.
Eight to Late 