What is Project Complexity

Summary

This article redefines the concept of project complexity in software development projects. Traditionally, complexity refers to the degree of difficulty, uncertainty, and interdependence involved in managing and completing a project. However, this view may not adequately address the challenges unique to software development, which revolve around the acquisition and application of knowledge.

The article introduces a knowledge-centric approach, emphasizing the discovery and application of knowledge to better manage software projects. It argues that project complexity can be influenced by both the Client, who defines what needs to be delivered, and the Capability, or the project team responsible for delivering it.

The Complexity Profile (CP) is a tool that categorizes knowledge into three types that the project team must discover to complete a task, user story, or epic:

• Knowledge to be discovered on what to do: This pertains to the overall definition of the task, user story, or epic.
• Knowledge to be discovered on how to do it: This involves the specific steps or methods required to complete the task, user story, or epic.
• Knowledge to be discovered on what to do and how to do it: This encompasses both the overall definition and the specific steps or methods needed to complete the task, user story, or epic.

Project complexity is influenced by both Client and Capability factors, including requirements complexity, client collaboration, team collaboration, technology expertise, domain expertise, and the development process. By considering these factors and assigning a quantity to each quadrant, the CP provides an idea of how much knowledge is required for each aspect of the project.

This knowledge-centric approach, which combines agile methodologies, traditional project management approaches, mathematics, and empirical evidence from software development projects, leads to more accurate forecasts and improved project outcomes.

Traditional perspective

The traditional view is that project complexity refers to the degree of difficulty, uncertainty, and interdependence involved in managing and completing a project[3][4].

But what does "difficulty" mean in the context of software development projects? Does it imply developers face challenges while typing?

And what does "uncertainty" mean? Are they unsure of what to type? Uncertainty can be understood as the developers' lack of knowledge about what to type or implement. They might be unsure of the best approach to solve a problem, the most efficient algorithm to use, or the correct syntax for a particular programming language feature. This uncertainty stems from the developers' lack of knowledge in certain areas, and they must discover or acquire this knowledge to overcome the challenges and uncertainties they face during the project.

As for interdependence, a dependency is defined when the progress of one action relies upon the timely output of a previous action, or the presence of some specific thing. Research on agile software project dependencies reveals three types of dependencies:[2]

• Knowledge dependencies arise when specific information is required for a project to progress.
• Task dependencies emerge when a task needs to be completed for a project to progress.
• Resource dependencies surface when a person, place, or thing is required for a project to progress.

Aside from knowledge dependency, the other dependencies are rather mechanical and can be found in any human work, even in a factory setting. They can be applied to manual labor just as well, which means they don't account for what is unique to knowledge work - its essence, the acquisition, and application of knowledge. Software developers apply knowledge to deliver outcomes. We should focus not on the knowledge they possess but the knowledge they lack since it is this absence of knowledge that truly consumes time in developing software systems. If software developers don't have the necessary knowledge, they must discover it. The knowledge they need to uncover is the total of what they don't know they don't know and what they know they don't know.

Knowledge-centric perspective

This is where the knowledge-centric approach to software project estimation and management comes in, drawing inspiration from various sources, such as agile methodologies, traditional project management approaches, mathematics, and empirical evidence from software development projects. By emphasizing the discovery and application of knowledge, this approach is necessary and natural for software projects. It better addresses the unique challenges inherent in software projects, leading to more accurate estimations and improved project outcomes.

Project complexity refers to the amount of knowledge that needs to be discovered, i.e., the missing information acquired by the team throughout the project lifecycle for the successful completion of the project.

The missing information can be broadly categorized into two types:

1. WHAT needs to be done (the objectives or requirements)
2. HOW to accomplish the WHAT (the processes, methods, and techniques to fulfill these requirements).

It's essential to note that the observed missing information is a subjective evaluation of the actual missing information. The same project could have different observed missing information for different observers, depending on their prior knowledge, understanding, and perspective. Thus, project complexity represents the gaps in understanding or information that the project team believes they lack and need to learn.

Project complexity refers to the amount of knowledge about "What" to produce and "How" to produce it.

Factors affecting Project Complexity

The project is a system composed of the people who will deliver (Capability) and the people who define what to be delivered (Client). The Client is responsible for defining "what to do," while the Capability is responsible for defining "how to do the what."

The complexity of a project can be influenced by both Client and Capability. We group the factors into two clusters based on their ownership and influence by either the Client or the project team (Capability). Here's the breakdown:

Client-owned factors influencing project complexity:

• Requirements complexity: The number, degree of uncertainty, and intricacy of project requirements, as well as their potential for change, can impact the knowledge discovery process. In simpler terms, this factor asks whether the client has a clear understanding of what needs to be done. Projects with numerous or complex requirements, or with clients who are less certain about their desired outcomes, may necessitate more knowledge discovery and learning.
• Client collaboration: In addition to the internal characteristics of projects, it is important to consider the contexts in which projects are executed. The performance of the same project team may vary depending on whether the client is a startup or a Fortune 500 corporation, as the level of collaboration with stakeholders can differ significantly. For example, working with a small startup typically implies that questions are answered promptly and communication is more agile. On the other hand, working with a large organization like a bank often involves slower communication and more bureaucratic processes, which can impact the project's overall efficiency and progress.

Capability-owned factors influencing project complexity:

• Team collaboration: The individual knowledge, skills, and expertise of team members, as well as the interdependence between teams or groups possessing specific information required for a project to progress, can influence the amount of knowledge that needs to be acquired during a project. For example, a project staffed primarily with junior developers will likely require more knowledge discovery and learning than a project with a more balanced mix of junior and senior developers. Having an experienced architect on the team can provide a valuable knowledge base and guidance, enabling developers to access the information they need more quickly. Furthermore, effective collaboration and communication between different teams or groups are essential for sharing vital information and addressing project challenges efficiently.

  Additionally, having dedicated QA team members can help ensure that any incorrect knowledge acquired and applied is identified and addressed more rapidly. This faster feedback loop can prevent the propagation of issues stemming from misunderstandings or lack of knowledge, ultimately improving the project's overall efficiency and quality. In this context, the interdependence among team members and groups plays a crucial role in managing project complexity and ensuring successful outcomes.

• Technology expertise: This includes the intricacy of the algorithms, technologies, tools, and frameworks used in the project, as well as the overall architectural design. A project with more advanced or unfamiliar technologies will require more knowledge discovery and learning.
• Codebase knowledge: This factor enables project managers to assess the potential risks, challenges, and dependencies associated with building upon an existing codebase or starting from scratch. It plays a significant role in determining project complexity, particularly when the team needs to familiarize themselves with an existing codebase. The time and effort required to understand the existing code, its architecture, and design patterns can slow down the project's progress, especially in the initial stages. Furthermore, dealing with an existing codebase may present additional challenges, such as technical debt, outdated dependencies, or a lack of proper documentation. These challenges can increase project complexity and affect overall project estimation and management processes. On the other hand, starting from scratch might necessitate more time for initial setup, architecture design, and development, but it also provides an opportunity to leverage the team's prior knowledge and expertise, potentially streamlining the development process.
• Domain expertise: The problem domain or industry the software is being developed for can influence the amount of knowledge that needs to be acquired. For example, a project in the healthcare industry may involve understanding specific medical terminology, regulations, and processes, which adds to the complexity.
• Development process: The way the discovery of missing information is managed by the project team. When it comes to discovering missing information, Agile and Waterfall development processes handle this aspect differently:
  • Agile methodologies embrace change and encourage continuous learning and adaptation throughout the project. The iterative nature of Agile development enables teams to discover missing information and adjust their plans accordingly as the project progresses. By breaking the project down into smaller, manageable tasks, teams can identify gaps in their knowledge and understanding more quickly and address them before they become major issues. Frequent communication and collaboration among team members and stakeholders further facilitate the identification and resolution of missing information.
  • In the Waterfall development process, the discovery of missing information can be more challenging due to its linear and structured nature. The process relies heavily on upfront planning, with the assumption that all requirements and information are gathered and documented before the project begins. As a result, discovering missing information later in the development process can lead to delays, increased costs, and the need for significant rework. Teams following the Waterfall process may find it more difficult to adapt to change and acquire missing information, as doing so may require revisiting earlier stages in the project lifecycle.
  In general, for most of us, given a straight choice between working on something easy or something that is hard and ultimately shows us and everyone else just how little we understand about the system, we are probably going to choose the former. This is not only a natural, human tendency; it is also exacerbated by the pressures we experience in development, the desire to demonstrate "progress," and most of all, by the organization's and management's expectation of producing a product[1].

It's important to note that while these factors can be categorized based on ownership and influence, there will still be some degree of interdependence between them. Collaboration and communication between the client and the project team (Capability) are crucial in managing project complexity effectively.

The table below presents example combinations of the factors that affect project complexity, including requirements complexity, client collaboration, team collaboration, technology expertise, domain expertise, and development process:

You may have a portfolio of past project to pick a reference class from, but the projects may not be categorized based on the factors inluencing project complexity we listed in the previos section. Don't worry - if you have the source code you can visualize the knowledge discovery process of your previos sucessfull projects. Now you can pick a curve that matches the combinations of factors for your current project.

It is essential to emphasize that our approach does not focus on selecting similar technologies, business domains, team collaborations, development processes, or client collaboration. Instead, we concentrate on selecting projects with a similar level of ignorance, i.e., knowledge that needs to be discovered.

It is essential to emphasize that we concentrate on selecting projects with a similar level of ignorance, i.e., knowledge that needs to be discovered.

By doing so, we can use a project implemented with Java for a startup as a reference class when our new project is in C# for a bank. This knowledge-centric approach allows for more relevant comparisons and better predictions, as it focuses on the shared challenge of discovering new knowledge, regardless of the specific context or technology used.

Embracing Complexity in Projects: Unlocking Innovation and Value.

While it might seem that less complex projects are better because the project team possesses most of the knowledge required for efficiency and effectiveness, innovation often arises when there is new knowledge to be discovered.

It is through the process of exploring and overcoming challenges that team members can develop new skills, ideas, and solutions that drive innovation. Complex projects, by their nature, require a higher degree of knowledge discovery, pushing teams to think creatively, collaborate, and adapt to new circumstances. This fosters an environment conducive to innovation and continuous improvement.

Huge benefits and value that can be derived from tackling complex projects, despite the challenges they might present.

By tackling complex projects, teams can unlock significant value and benefits, despite the challenges they might present. The innovative solutions that emerge from addressing these challenges can lead to improved products, services, or processes, ultimately creating a competitive edge for the organization.

Therefore, embracing a certain degree of complexity in projects can lead to better overall outcomes by fostering innovation, while still maintaining an appropriate level of efficiency and effectiveness. Project managers should aim to find the optimal balance between complexity and simplicity to ensure project success while nurturing an innovative mindset within the team.

Complexity profile

The "problem-solution match" space is represented by the intersection of the required knowledge of what to do and how to do it. It is the space of possible alternative combinations of "problem definition - solution" that a project team needs to consider when working on a task. The diagram below illustrates this space and its relationship to the required knowledge of what to do and how to do it.

The space of alternative problem definitions is represented by the blue ellipse. The space of alternative solutions is represented by the black ellipse. The intersection of the two knowledge spaces is located at the center of the diagram and is referred to as the "problem-solution match" space.

It's important to note that the diagram is a representation of the possible combinations of problem definition and solution, rather than an exact number of elements within each set. Additionally, this diagram only takes into account the required knowledge and not the prior knowledge of the project team, which also plays a role in determining the balance of a task.

We refer to the project team's perception of their own capabilities as "prior knowledge." Prior knowledge also has two components: Prior knowledge also has two components: knowing what to do and how to do it. Having prior knowledge in a certain area can aid in the learning and application of new information. Studies have shown that prior knowledge can account for between 30% to 60% of the variance in learning outcomes[11]. Additionally, prior knowledge of different domains can jointly support the recall of arguments[12].

When we combine the required knowledge and prior knowledge, we get the diagram below:

In addition to the ellipses representing required knowledge, we now have two new ellipses. The yellow ellipse represents the space of alternative problem definitions that the project team think they know. The violet ellipse represents the space of alternative solutions that the project team think they know how to do.

The "problem-solution match" space is now divided into four disjoint subspaces. When these subspaces are highlighted, we get the following diagram:

The diagram illustrates the two types of knowledge that the project team must discover in order to complete a task:

• Knowledge to be discovered on what to do: This refers to the overall definition of the task.
• Knowledge to be discovered on how to do it: This refers to the specific steps or methods required to complete the task.

Complexity Profile (CP) explained

It is more convenient to represent the four combinations of required and prior knowledge in order to complete a task in a matrix, which we will refer to as Complexity Profile (CP).

The Complexity Profile (CP) is a tool that categorizes knowledge into three types that the project team must discover to complete a task, user story, or epic:

• Knowledge to be discovered on what to do: This pertains to the overall definition of the task, user story, or epic.
• Knowledge to be discovered on how to do it: This involves the specific steps or methods required to complete the task, user story, or epic.
• Knowledge to be discovered on what to do and how to do it: This encompasses both the overall definition and the specific steps or methods needed to complete the task, user story, or epic.

Project complexity is influenced by both Client and Capability factors, including requirements complexity, client collaboration, team collaboration, technology expertise, domain expertise, and the development process. By considering these factors and assigning a quantity to each quadrant, the CP provides an idea of how much knowledge is required for each aspect of the project.

Each of the four quadrants in the matrix represents a combination of required and prior knowledge, which we refer to as knowledge to be discovered, or the information the project team needs to gain in order to complete a task.

The vertical axis in the matrix represents whether the project team has a clear and distinct understanding of the task, that is, whether they know what to do. The horizontal axis represents whether the project team know how to complete the task. In this representation, knowing is represented as a binary variable, where the project team either know or do not know.

The green quadrant represents a state where the project team have a complete understanding of both the problem definition and the solution, and according to our definition of knowledge this means that no new questions need to be asked. No perplexity at all. If the project team chooses a problem-solution combination from this quadrant.

The yellow and orange quadrants represent states where multiple alternative combinations of problem definition and solution exist.

The color of each quadrant reflects the perceived difference between the project team's capability and the complexity of the work, measured in bits of information.

The lower right yellow quadrant represents the case when the Capability know how to do what the Client seems to want, but the Client are not sure what they need to be done. In contrast the upper yellow quadrant represents the case when the Client do know what they need, but the Capability don't know how to do it. In in both yellow quadrants the perceived difference is less than 4 bits, i.e the project team will have to explore up to 16 alternatives before picking a combination of problem definition and solution.

Orange represents the case when the perceived difference exceeds 4 bits, i.e the project team will have to explore more than 16 alternatives before picking a combination of problem definition and solution. The project team may experience anxiety and perplexity, because one of the two holds:

1. It requires: at least 5 and up to 99 questions asked, but not in a row, not in sequence and non-linearly. In this case perplexity is too much because of such a big search space.
2. They need to build knowledge and skills. They don't know what they don't know i.e. there are unknown unknowns. They don't know what questions to ask at all!

The number of bits is not only determined by the number of alternatives but also by other features of the choice set, such as the number of attributes that alternatives are differentiated upon[15]. In addition, as discussed earlier, there are limits to the cognitive processing capabilities of the mind and limited working memory.