The first moment

There are moments in life when you realize something. I had three such moments a few years back when pushing a chaotic project forward and realized that my project was not going to be successful, no matter what I was doing, with items in my power.

The first moment was in the middle of the problematic project when fighting to get required resources and plans in place to get items back on track. There was just too much work going on in parallel, and not enough resources who could master required details and have required system understanding. After hard work and some fights, I got my plans updated and required resources were becoming available. Things should have been looking good. But, during the evening walk in a nearby park I was thinking how things would now go forward, as the plans are in place. And, I realized that I knew already at that point, that none of the updated plans will be realized as planned.

Plenty of known unknowns

This was evident because my plans targeted to implement remaining tasks, solve current issues and implement known changes. But it was perfectly clear that a similar flow of issues and changes will continue to be popping up just as earlier and I did not have a plan for tackling these. We clearly had plenty of known unknowns, and unknown unknowns – to be sorted out. I had had to fight for resources for the visible work, now I should do the same also for the invisible.

Building large complex systems

Eating an elephant-approach expects that we find the elephant, kill it, and have time to slice and eat it. This means that there would be clear, fixed requirements, time to divide the work and get it done eventually. By the definition of a complex system, requirements and/or technical solutions are not clear. This then means that new tasks, details, and issues are learned during the system building.

Building large complex systems requires a solid base and incremental and iterative development. As it’s easy to get to this conclusion, so the next question is then: what is this conclusion missing? Often incremental releases are targeting the completion of too large sub-systems. Completion of planned release is then delayed as invisible requirements and details of the complex system are slowly clarified and various issues are discovered. Due to new information and related changes, delays, and issues, more resources are added, long hours worked under high pressure until eventually getting the release done. After the dust has settled, there will be an assessment of what should have been done differently. Assessment results will be that the reasons were the amount changes, new details, technical issues, and lack of resources. And this could be solved by demanding more thorough and detailed up-front specifications, more detailed agreements with customers, more strict change control, and several additions to technical checklists. My learning here is that these ‘improvements’ would not solve the problem, but would just cause increased efforts, bureaucracy and slow down the progress. 

To develop a large and complex system, we must have proper methods to get it done.

Vesa Koskela

Agile and Lean product development should help us here. Taking into use smaller, time-boxed, system releases, forming teams who can work effectively together, and protecting the teams from overload enables us to work in more predictable steps forward. Transparent communication to all stakeholders enables teams to focus on the most important items and get better support from management.

Forcing system releases into time boxes e.g. every 3-months, provides frequent checkpoints to assess the situation together with all stakeholders. When management and teams are planning the time-boxes together, we can build a more transparent and realistic view of what can be achieved and agree on the most valuable items to be built next. Only when various challenges and issues are correctly understood, they can be solved. Understanding is required in both directions; teams need to know what is most important at a time and management needs to have a realistic understanding of the situation. For this status reporting and escalations are not enough, we need true collaboration, a common language, and visualization.


High risk to enter a chaotic mode

When building a large and complex system, there will be more tasks and issues than teams can solve. If teams are not protected from overflow their productivity will drop, making the situation yet more challenging. Continuous overflow of tasks and increase of technical debt causes a high risk to enter a chaotic mode with very low productivity. This must be avoided, even at a very high cost. When organizing teams as scrum-teams, where one person is responsible for the team backlog, we can protect the team from constant interrupts, visualize all pending work to all stakeholders, prioritize the work and enable team productivity.

Agile and lean product development practices do not solve technical issues, cure difficult customer relationships, or ensure complex systems will be fully completed on a committed schedule. There are plenty of other items, in addition to these methods, to be solved as well. But, these methods enable more predictable system building and this enables more predictable value creation to stakeholders. This then makes also other challenging items easier to solve. 

When need to build a large and complex system, we must change our approach from hunting and eating elephants to building an environment where we can foster baby elephants and bring them up to well-behaving giants. This requires a new kind of collaboration also with customers, the new approach must be jointly accepted and seen as highly valuable.


Vesa Koskela

Vesa Koskela

Project manager, Murata Electronics Oy

Vesa Koskela is speaking at LPPDE Europe 2021, May 19-21. Join the Lean Innovation Virtual Knowledge Exchange!