Project Management Institute

Complexity management

key to maximizing your program effectiveness!

Sr. Business Systems Manager, MPI Research


adjective; consisting of many different and connected parts

complex – adjective; consisting of many different and connected parts

In today's business environment, “complexity” is a phenomenon that is ingrained in many disciplines, approaches, and solutions. Whether referred to in the context of a process, product, or personnel – one fact remains: complexity is here to stay!

The focus and emphasis on simplifying complexity have never been greater that what there are today in the domain of project and program management. Many techniques exist in pursuing the ‘perfect’ technological solution with manageable complexity for a given business opportunity. Invariably, these techniques will lead to a potpourri of systems supporting interconnected and intertwined processes. Have you ever wondered if the challenges of not addressing the program complexity factor upfront and the downstream impact it may have on your organization? Is it just the complexities of managing a program itself that need to be taken into consideration or should we also confront and address the complexity of the solution that it is meant to deliver? Establishing a methodology that allows you to be in a state of control to manage both the approach and its outcome are essential to meeting the expectations of your stakeholders and your organization.

Derived from the Latin word complexus, which means “twisted together” or “entwined,” complexity, simply put, is a subjective factor that usually refers to the difficulty of a design or build of a system. Generally, in order to create complexity in a program, you need more than one work package that is integrated in a way to establish a relationship pattern. Complexity is a concept that most program managers would like to avoid in their projects if at all possible. The general notion is that complexity tends to be undesirable because of the anxiety that it is unpredictable and hence cannot be managed. The size of the program is seen as the major contributor in determining the complexity factor; the bigger the size of the program, the more complex it may appear to be to managing the program performance at hand (Exhibit 1).

Complexity Factor

Exhibit 1 – Complexity Factor

Why do large programs that are complex fail? One of the reasons for this failure, in my experience, is because of the challenge in managing the unknown aspects of the program are the odds of something unforeseen happening that will negatively impact the success of the program. Let's take a look at other dimensions of program complexity and its impact on success of the program.


Program management necessitates a framework on how it will be managed and controlled. Establishing a process driven approach to decompose the components or work packages of the program will allow for greater latitude to identify the interaction between those elements. Identify the inputs and outputs of the sub programs or projects and the action or trigger between the inter processes, including the deciding factors. This should lead to developing the metrics to control and adapt the process to its expected performance levels. It is also beneficial to establish the standards that the methodology will use as guidance to bridge any internal best practices. Establishing a total state of control on the methodology to be followed by the program will alleviate the challenges of a “what if” situation between subcomponent interactions.

Process Dimension of Program Complexity

Exhibit 2 – Process Dimension of Program Complexity


A report from NASA published in 2007 describes (from between the period of 1960 and 2000) that the amount of functionality provided by software to pilots of military aircraft has grown from 8% to 80%. The software lines have grown from 1,000 in F-4A to 1.7 million in F-22 fighters to 5.7 million in F35 Joint strike fighters. Updating and maintaining that complex repository of code that supports a highly functional system just from a sheer size is not that easy.

Product Dimension of Program Complexity

Exhibit 3 – Product Dimension of Program Complexity

Though some may argue that complexity in system starts with user requirements, I would say that complexity is simply unavoidable in developing a system. It is a highly design-intensive exercise and engineers can come up with a unique logic to implement the same requirement. This is in addition to different variables in the environment that make it complex, such as the hardware it needs to be built on, the operating system, delivery platform, and so forth. The complexity may be hidden with a simple and user-friendly interface, but that doesn't mean that the system design isn't complex. Also, the integration with other systems leads to complexity but this potential has allowed designers to think about more ambitious and powerful systems. Requirements variability (e.g., scope creep) is a big factor that initiates a trigger to complexity challenges to other phases of a system. Requirements creep or scope creep is defined as uncontrolled changes or continuous growth in project scope and is generally considered a negative occurrence. It has all kinds of impacts if it is not handled properly, which includes budget overruns, and schedule overruns, in addition to risking the project team's focus drifting away from the initial direction into unplanned additions. The impact of this factor on complexity increases when it happens during later phases of the system development cycle.

Aren't we humans, who develop these systems, complex? We don't intentionally build complexity, but sometimes it starts creeping in when the system development gets passed on between the engineers who may not have knowledge about the previous design logic and modify them only to realize the impact later. So, there is accidental complexity that gets introduced like this but then there is also essential complexity, which is dictated by the expectation of the software driven by its stakeholders. If we have the system requirements engineering in control and know what to develop, is the actual process of testing that build easy?

Let's use an example of a binary system, such as a simple light switch. To test the functionality of the switch, we can test it by giving one input at a time: ‘an on and an off test,’ resulting in two test scenarios. But if we have a system that takes in 16 inputs, it will take 2^16 = 65,000 test scenarios to full test it and if it's 32, then its 2^32, which equals 4.3 billion test case scenarios. The point being that test cases increase exponentially every time you double the number of inputs to the level that if every test takes 2 seconds to execute, it will take us 272 years to complete the entire testing for a 32 input system!

The point of these scenarios is that 100% coverage of testing is virtually impossible and there is no system that can be completely free from defect. Testing can be potentially endless. We cannot keep testing until all defects are unearthed and removed – it is simply impossible. But we do need to strive to unearth all critical defects that will impact the functionality or negatively impact its use.


What are some of the complexities posed by people involved in the program management undertaking? Do they have experienced personnel in the team with adequate training? How much do they stay abreast of new technologies that they will potentially have to work with?

Personnel Dimension

Exhibit 4 – Personnel Dimension

Organizational changes at the executive level will also add complexity in providing direction and strategy to the program in question, especially if the resources get re-assigned to other priority projects.

How about qualified program managers who truly understand program management methodologies and techniques? Also, are there sufficient domain-specific program managers in the market to keep up with the fast paced growth of project PMO units and their demand? Program managers with operative skillsets and domain specific experience will enhance the effectiveness of handling program complexity when it arises during execution and implementation.


✓   Establish clear program goals; what does the program intend to deliver or accomplish? Goals need to be specific, realistic, and measurable. Senior leadership needs to provide support and empower the program manager to successfully manage the relationships among the team units who have to work together in synergy. Communicate the goals of the program to the rest of the team members. Managing expectations is a key for a project that is complex. Communicating changes to the scope and its associated impact on the cost and schedule to the team and sponsors can reduce any negative outcomes of program delivery.

✓   Have an effective methodology and framework that guide you on how complexity will be managed in your programs. If it is not documented and enforced as a discipline, it simply can't be managed. Communicate the methodology to both your internal and external team members.

Managing Program Complexity

Exhibit 5 – Managing Program Complexity

✓   Decompose the program into components or a work package with relative affinity. What is our style of managing programs that involves technology as a solution? Do we approach execution of a system with all the requirements from the get go or do we actually prioritize those requirements and take a phased approach (iterative/agile) in delivering it at frequent intervals based on those requirement priorities? My experience for medium to large-scale projects has been that stakeholders prefer incremental delivery at regular intervals over waiting for one time full delivery after a lengthy period of time.

✓   Traceability matrix is a great tool overall in program management but especially during the scope change management over the life of the program. A simple spreadsheet that maps goals to high level business requirements to specific project requirements to its design, to its test cases, to its documentation can prove to be very beneficial to understanding and tracing the impact of program complexity across its various dimensions.

✓   Proceed with caution when the latest technology or new method is used during program management. The program team members may need to quickly adapt to changes via training and become proficient in the use of the new approach. Pay attention to integration. When you connect processes or sub systems, you need to know the decisions made on one process and how they may affect the others. Units/packages that are complex need to be tested in isolation first before they are integrated with other work packages.

✓   Where is the program going to be implemented? Is it in a known environment with a few years of experience or is it in a new environment. Establish a Program Complexity Level Assessment and Management Plan that identifies and documents program areas that are complex in nature and how to address them. This will assist in determining the level of planning and testing that will need to be completed to manage the complexity of that area.


Complexity in program management has to be addressed proactively to increase the program's success rate. Embracing unpredictability and planning to adapt are essential to managing complexity. The importance of addressing complexity in program management has never been greater than it is today. With so much in life these days being dependent on projects that result in systems that are inherently complex, managing program complexity is an essential and integral part of the technology world, leading to a need for the imperative understanding of its challenges and the need to managing them.

Who is responsible for managing the complexity of the program? Everyone involved in that exercise! Yes complexity is unavoidable and it poses undesired challenges. But by taking a critical look at your program initiative to plan and manage complexity accordingly, it can maximize the effectiveness of your program offerings.

Definition of complex, Retrieved from

keda, J. (2011). Why Large Complex Projects Often Fail (June 2011 blog).

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2013 Murali Krishnan
Originally published as a part of 2013 PMI Global Congress Proceedings – Istanbul, Turkey



Related Content