project management and complexity theory

I am presenting on the topic of complex projects at the Australian CPA congress in Sydney on October 17 2006...actually, I'm double booked and will be roping in my colleague Sarah Quinton to do the presentation for me but I haven't told her that yet (it will be interesting to see if she reads these blogs and finds out through this communication medium or when I tell her on Friday this week). Anyway, one thing's for sure, I'll have to write the paper and do the presentation slides and as it was due a week ago, I better get cracking. The reason I have taken so long to get around to doing this task is that I'm not really sure what I want to say. Complexity theory and how it relates to management practices is something I have been reading about and musing over for 3 years. However, it is still a very disparate field of study and compiling coherent content is difficult. My gut feel says management complexity theory could solve a lot of issues I have encountered when managing projects.

Mixing complexity theory sciences with control based project management is akin to adding oxygen to magnesium. Adding a volatile substance to something that appears stable and watching it become extremely unstable. Project management appears stable and established in terms of practice, so why try to destabalise it? Because it doesn't work. Organisations that have mature project management practices and are at the forefront of project management still have projects that are a mess and perform poorly. In organisations that have less than best practice project management, project failure is more common and is blamed on the environment (we do it well but sponsors and managers don't understand it and hence it fails). And yet, surely, a project manager has to manage the environment they work in. This is the fundamental flaw in all things currently residing in that representation of how to project manage, the project management body of knowledge (PMBoK); It is built around inputs, processes and outputs not around outcomes. Outcomes are environmentally based, inputs, processes and outputs are control based. You can control the process to create the output based on the inputs, but, if the output is invalid, so too will be the outcome.

In terms of process, the PMBoK is excellent. There are tools and techniques to manage almost any process. In terms of outcomes, it is devoid of content. This has led to a culture in the project management community (represented in functions attended at the Australian Institute of Project Management and Project Management Institute) of people driven to deliver. Project managers will deliver at all costs. The concept of projects being cancelled not because they are performing poorly on a time, cost or quality basis but on an outcomes basis is an anathema to industry and will be seen as a blight against them.

A potential solution to the train wrecks that still occur in project work is applying complexity sciences to management principles. The area focused on with regards to complexity by us is the area of complex adaptive systems. The best example of this is in the method of creating automated characters in computer animation. This method was developed by Craig Reynolds in 1986. The basic premise was focused on how birds flock. To enable birds to flock in a computer animation, the focus of an individual bird is on the birds immediately around it. It ignores all other birds outside a specified region. This method of steering means that the birds are self organising and flocks of birds form spontaneously. This has been described as "the edge of chaos". How does this relate to project management? This has been the basis of my musing for the past three years. I have come up with three key points which when added to one point from the traditional project management body of knowledge and one point outside both complexity and PMBoK give you principles to apply to all complex projects.

Complexity principles
1) Each project is unique and hence cannot be managed in the same way. Blindly applying a project methodology to each project and following the body of knowledge input requirements, processes and outputs will not lead to a successful project every time. Complexity philosophies and principles must be overlayed on top of a project methodology.
2) The most effective way to manage a project is for the project team to be as self organising (on the edge of chaos) as their capability allows (again, will vary for each project as the allocated resources vary). High performing teams are those that need no or very little direction. Of course, if you are handed a team of novices, then it is going to take longer than if your team is experienced and more importantly, has experienced self organising projects before.
3) Communication is key in achieving the edge of chaos required to successfully manage complex projects. The medium, frequency and content of communications will change dramatically from project to project. There is some interesting research as to current forms, frequency and content properties used on complex projects (see Determinants for external communications of IT project managers by Ralf Muller) However, as this is current practice and we are proposing radically new methods be formed, one cannot rely on this as a basis for future practice. The best current research on complex communication processes within organisations is a book by Ralph D. Stacey: Complex Responsive Processes in Organizations. Learning and Knowledge Creation. We have included a link for a review of this book.. This area of complexity theory is where we will be turning our attention to over the coming months.

Most organisations structure themselves around themes or functions. In this way, information is communicated within certain known paradigm. Knowledge is not created, it is only transferred from one individual to another. The tacit knowledge of one person is shared with another. However, when information is given outside this theme or function to another theme or function, it is interpreted without the central paradigm or framework. In this way, its interpretation could lead to new knowledge being created as the receiver applies the information in a way outside the senders paradigm. Organisations that are silo based restrict the potential of new knowledge being created and when knowledge is transferred outside the silo, the chances of new knowledge being created is limited and the chances of misapplication of knowledge increased. Our number one proposition in this area is that cross functional teams are the means for knowledge creation. Informal communication from heterogeneous teams allows for the creation of new knowledge which could be crucial in achieving an outcome. Evidence of this would be projects delivering solutions that are significantly different from what was originally scoped but still delivering the benefits identified. Within these heterogeneous environments, acronyms would be of limited use as they would not be understood by all team members. New processes and methods will be formed as existing paradigms are challenged by those who don't have the cultural baggage of the current norm. All of this needs to be tested in the real world. The difficulty will be finding teams that are truly heterogeneous and have created that edge of chaos environment.

Project Management Body of Knowledge principles
1) Theory of Constraints is the number one method for estimating. Estimating is inherently poor on a lot of projects. Typically, project schedules are a pain to project teams, requiring them to do work in an order that is not valid (i.e. as soon as possible rather than when required) and hence the self organising principle is broken. Benefits, costs and time estimates are constantly changing. As we need to pre-plan things, we need to be able to manage this change and hence a project manager's job should involve the constant updating of the schedule, the benefits and the budget of a project and analysing its impact on the existence of a project. Typically, this review is done too infrequently to be effective. Alternatively, it is overdone to the point of micro managing.

Theory of Constraints scheduling is about managing the project to a project deadline not a task by task deadline. In Theory of Constraints, the project manager is efficient at altering the schedule and does so to determine the optimum path of work activities. This becomes a communication tool to the project team. It takes into account factors typical to teams that are not high performing such as multi-tasked resourcing and student syndrome and allows for the basic assumption that close enough is good enough. It also manages client or sponsor expectation through the project buffer. Theory of Constraints knows a schedule will always be wrong, hence doesn't go for perfection. Theory of Constraints is the most important control based method for project managers managing complexity.

Principle outside complexity and PMBoK
1) Only outcomes matter. Complexity and uncertainty should be managed through a regular re-evaluation as to the fundamental reason for the project's existence (i.e. its outcomes). The only reason the project exists is that its benefits outweighs its costs. This varies depending on the value proposition of the organisation and of the project itself (see Managing by Project article below). Re-evaluating timephased costs and benefits is fundamental to complexity management, it provides the means around which teams will re-organise themselves.

the managing by project philosophy

Central to all that we do at mbh is the managing by project philosophy. Unfortunately, as people seem to have very short attention spans, a lot needs to be conveyed in a name. We tried to encapsulate what is an exhaustive philosophy and underpinning methodology into a name by using the term managing by project. Unfortunately, this has created two problems when first introducing the concept to a new audience. The first is that as there is such an array of definitions for what a project is, the term conjures up different images depending on the definition being used by the receiver of the term. The second issue is that many people assume managing by project means running lots of projects. Never has there been a more erroneous assumption. Business as usual, or the role of current operational functions are of immense importance to the managing by project philosophy as they reflect the current industry position of the organisation (in essence they are the outcomes of the series of projects that have been undertaken in the organisations history to get to this point in time).

I will attempt, over the next few blog entries, to articulate what the managing by project philosophy is and would welcome any comments you have as to how I have succeeded in this articulation.

Firstly, managing by project is a business management philosophy, therefore it applies to organisations only. However, it is a philosophy that we believe should be applied by all organisations. managing by project begins with two basic assumptions; 1) Any organisation's aim is to maximise the value they can create for their stakeholders and 2) Most value is created at the interstices of the array of functions that make up an organisation.

The reason managing by project works for all organisations is that all that changes from organisation to organisation is the value proposition. The philosophy and methodology used to deliver that value should not. For example, a for profit publicly listed company has a value proposition to maximise shareholder value. A non-profit charity organisation might have a value proposition to eliminate/alleviate poverty in a certain area. managing by project is in our opinion, the best philosophy and methodology available to both organisations to achieve their respective value propositions.

The first managing by project observation is that organisations are in a constant state of change. The drivers of this change are both external and internal. Management's job is to manage the change in a way that optimises the potential for the organisation to move towards a vision defined by the leaders of the organisation (the trick comes when the organisation attains its vision - more about that in a future blog).

The most effective method for managing the change is to create and amend an evolving portfolio of projects that are designed around delivering the vision for the company. This change management model involves principles represented in the managing by project triangle below:


Each principle has a plethora of information about them. Any casual browse through the business section of a bookstore would see books specialising on one of the principles of managing by project. However, without the holistic method that binds it all together, the pieces of the puzzle don't match and the cohesiveness of the organisation fails. Each principle is dependent on the effectiveness of others. A weak vision results in an underachieving strategy, poor project selection and implemented projects that offer little value add. An inspiring vision not backed by a coherent, measurable strategy leaves too many projects being delivered in the rush to reach the end goal (with still no idea as to what to do when you get there). Projects are never implemented as resourcing is limited and multi-tasking rife. If both the vision is inspiring and the strategy right but the projects are selected based on political rather than objective means then value is destroyed and the strategy is never executed (only the PMs are). And finally, if the Vision is inspiring, the strategy right, the projects prioritised on objective lines but the implementation, the hardest element of all, is poor then again, the strategy cannot be executed and the vision remains a pipe dream.

One of the keys to implementation is for projects to be delivered by heterogenous teams that focus on the stated metrics or outcomes that drive value in the project, not just on the delivery of the project. The culture of these teams is one centred on value creation and hence it is the team that is likely to kill a project that no longer adds value (obviously this requires a non-blame culture and may even include rewards for teams that spot early when to cancel a project). This type of "fall on your sword" approach to projects relies on limited machiavellian activities and an environment where adapting to change is the norm.

The main method for implementing the filtering of projects is known as the funnels and filters or stage gate approach. This is best represented by the following diagram:

One can see from the diagram that there is a certain Darwinian evolution going on with the ideas that are thought of; only the fittest survive. The funnels and filters method is so commonly preached by our business and is often implemented by organisations, but without the cultural elements described above, the method again becomes a tick a box management method.

current research

We're currently researching the following topics at mbh:

- Complexity theory and how it relates to management,
- Theory of constraints and its applications in project management,
- Option pricing on real assets,
- Why return on investment models are not applied in some organisations,
- Management structure models from matrix and cross-functional to functional,
- Methods for creating optimised portfolios of real investments and how these portfolios might be modelled.

We will be updating this blog with progress and findings in each of these areas of interest.

mbh consulting blog purpose

Welcome to the mbh consulting blog. This blog is where mbh consultants will compile anecdotes and experiences from our daily consulting lives. Hopefully, sharing this information will help others and prevent some of the pain and suffering that is project and change management in a commercial environment.