Let’s start with the definition
The complex project is the one which has at least two independent teams with their own release cycles and at least 2 interdependent components.
The multidisciplinary project is the one which has at least two interdependent teams and at least one component.
Is a multidisciplinary project the same as a complex project? It’s true and false at the same time. First of all, it is complex by its nature but the complexity itself is of different manner. It’s anticipated that complexity comes from the number of components used, number of people participating in development and so on. But multidisciplinary project has perceived simplicity and inherent complexity. Its complexity originates at the teams interdependence which effectively prevents doing “contemporary classic” of waterfall unless accompanied by infinite time and resources.
What makes it different.
It’s expected that the particular team participating in the development has enough experience and knowledge to keep complexity issues under control. Next, it’s anticipated that the integration issues and corner cases are solved by the teams in an ad-hoc manner. Last but not least, the issue is that it’s expected that the entire project is kept under tight control of the team's supervisors.
Sometimes all this might happen naturally but it’s truly a rare case. Most of the time it’s necessary to keep a project on track using special measures like dedicated and well tailored governance process, development of the project-specific methodology, audit review, etc.
The founding difference is in the development processes, for multidisciplinary project no team could live on its own, instead they have to be able to collaborate on both project and process improvements and milestones.
What makes it special.
Multidisciplinary projects rare to never needed when basic products are developed. Instead they collect basic products ranging from sketches to the off-the-shelf solutions and integrate them into something new. That’s exactly the reason for having several teams of different expertise working under a common hood. That’s exactly a very founding reason to have an additional layer of complexity compared to a complex project. It’s a complexity of habits, intentions, educations, processes – any subtle aspect might be differently understood across the teams. Interdependence of the teams adds new challenges on having efficient communication and exchange of the work products, iterating through the design updates, validating decisions and so on.
What makes it failure.
It doesn’t take much to make a complex project failure by improper architecture, time management or wrong priorities. It’s even simpler to fault multidisciplinary project by ignorance of the team needs, intentions and, of course, priorities. For the multidisciplinary project it’s particularly true to have teams running wherever they want disregarding the other teams and entire project goals. It’s extremely hard finding the right solution to fit everyone and usually it’s exactly the point where project fail. Simply put, management often is unable to align all teams' efforts which in turn leads to the project disintegration.
Going authoritative management undermines their ability to collect feedback, gather insights and tune up both product and processes. This comes from the fact that the team experts feel undervalued which in turn lowers motivation. What is more important, authoritative management often refuses to accept critics of their decisions and neglects others opinions. Having all hits project often goes crash course due to loss of the control from both management and crew perspectives.
What is necessary to succeed.
First of all, it’s a power of leadership.
It’s necessary to emphasize that leadership for multidisciplinary projects is not about the power of authority. Leadership is the ability to streamline efforts of the teams and to provide common values for everyone involved.
Next, it is a clear and understandable and of course well tailored methodology helping to align the results and work products from different expertise areas and integrate them as a whole. Methodology itself is a work product to be carefully designed, reviewed and audited by experts and teams. It needs to have decent complexity and not raise the barriers for adoption.
Another one is a solid vision of how the project is going to be done. Vision is not something ephemeral or virtual but instead it’s something documented and explicitly communicated to the teams. It’s the foundation of the entire development process and needs to be treated as such.
The last one is the regular revising of the decisions made and results achieved with teams having power and authority to interfere in the management processes. The best practices from the industry show the necessity to adopt continuous improvements process to the very founding decisions and multidisciplinary project is not an exclusion.
What to do to succeed.
As usual there’s no silver bullet here but the multidisciplinary project success expects the following properties.
Vision
Every project must be pretty clear in definition and communication of the targets and milestones to achieve. The vision is to be communicated to everyone involved to let people participate in both understanding and embodying it.
Leadership
Multidisciplinary projects require additional efforts to streamline the development. As long as different teams have different expertise areas and skill sets, the leadership style needs to promote continuous education and spend efforts to expand team knowledge. Keeping people in touch and allowing them to study from each other is the key property to success.
Governance
Doing project in a collaborative way reduces efforts to develop and assess work products from the different teams. On the other hand it adds efforts on establishing appropriate and live governance model from the decision making down to the work product reviews. Nonetheless it is vital to make everyone involved not only in the project development but in the control over the development process itself.
Methodology
The development methodology relies on the Governance model but it needs to enforce it to be open and relatively simple. Methodology itself needs to be clear, predictable and adaptable to the future team needs. Ideally it needs to be revised and updated along with the project itself based on the lessons learned.
Persistence
No efforts are to be expected as an instant and final, all goals above require continuous improvement embodied in the very heart of the project. Persistence is a key to keep every key component of success up to date, reproducible and aligned with others as well as with the team needs. Being persistent does not necessarily mean being inflexible or not able to change. Instead it allows to retain flexibility and be adaptable during all project lifetime.
