Jiri’s Notepad

Lack of communication, insufficient engagement from stakeholders or some other way of people not working together have always dominated various charts on causes of projects failures. The bigger the project, the more problems you get. Funny then that we sometimes make ourselves busy trying to be clever about architecture frameworks and other formal mechanisms, forgetting that a big part of project success is about people talking to one another.

This is a question of personal skills, but also institutional arrangements, which we have not been always very good at describing. Looking beyond our own back garden, there is actually quite a few examples of companies or industries that learnt how to transcend the traditional process-driven approach. One of the good ones is the development of the F22 fighter plane.

As the story goes, sometimes in the mid 1980s US military decided that to protect the country from then still imminent threat from the Soviets, they would commission a development of a new fighter jet. The objectives for the new aircraft was easy (not) -  be the ‘market leader’ for the next 40 years, use newest air and ground precision weapons and avionics, increase speed and flight range, low observability, reliability, maintainability and shorter takeoff and landing.

Around the same time the military procurement branch came to a conclusion that weapon systems take too long to develop, cost too much to produce, and often do not perform as promised or expected. To counter that they looked around and decided to pick up and use the new concurrent engineering practices that had been pioneered by Toyota. The approach (which they called integrated product development), was to get system developers to consider all elements of the product life cycle from conception through disposal, including quality, cost, schedule, and user requirements at the outset of the programme. It also involved a heavy use of integrated cross-functional teams, which is actually the reason why a I brought that story up, because …

1. Cross-functional teams are IMHO at the foundations of project success and
2. Communication and collaboration are fundamental to make these works

This is all relevant to us in IT organisations. I think we have been always pretty good at understanding technology, using it and (on a good day) pushing it to its limits. But we have not been able to exorcise some of our biggest demons, including our inability to get on with the business or unreliable delivery. 

Commenting on this subject, a report by the UK Royal Academy of Engineering on complex IT projects, which I may have mentioned here before, reminds us that “the evidence received clearly and unanimously identified management factors and human, rather than technical, issues as the prime causes of project failure.� If  the cause of project failures is human or managerial, so is the cure.  And one of the things to achieve that is to become much better at inter-team collaboration and communication.

You will probably agree that in principle, it is important to collaborate and talk to one another. It get rather tricky when we actually try to understand what makes people behave in a collaborative way and how to get them collaborate more. It is relatively difficult because collaboration is not a specific activitiy - it is more a way of doing all the activities you normally do. Also collaboration goes against the command & control mindset that seems to permeate most of the anglo-saxon business world. Because of  these reasosn, there is often a tendency talk mystically about emergent behaviour and hive minds despite the fact that collaboration is actually neither rocket science nor eastern philosophy.

This mini-series will attempt to cover this ground and give key pointers on how to get projects to behave collaboratively. I will start with enablers, things that on their own will not make people collaborate, but the lack of which can seriously slow down and block collaborative efforts.  I will then cover activities that managers and team members need to start doing to actually achieve collaboration, including oraganisation, building collaborative social dynamics, or using good project communication practices.