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.
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).