Skip to main content

Part II: A Simplified Approach to Determine IT Project Complexity


This paper is Part II of the paper entitled “A Simplified Approach to Determine IT Project Complexity”, (MacCue, C., 2021, March 5). Its purpose is to further explain the rationale behind the Core IT Complexity Model within the framework of the broader topic of IT project complexity. It will discuss why the Core IT Complexity model is a good approach for most IT organizations and why it is important to determine project complexity as an ongoing and integral part of the Change Management and Risk Management process.


Project Complexity, Project Risks, Managing Projects, Project Complexity Formula, Project Difficulty, Risk Management


There are many details and intricacies to consider when managing a complex project to its successful outcome. While that may seem obvious to many IT PM professionals, that is not necessarily the case with many business executives looking for payback from their expensive IT department. IT Executives are constantly justifying their department to the C-Level executives’ cries to exactly why “does IT need so many people, and what do they actually do”? IT is perceived by many as this black box where work gets done, but no one outside of IT really knows how. This is why many IT organizations are under constant pressure to re-organize or transform to new project management approaches to managing projects, improving visibility, and showing their contributions. Much credit should be given to organizations like the PMI Institute. They have made a science out of project management as much as possible and have provided roadmaps for maximizing the potential for success to the greatest extent possible. Most companies now seek project managers who follow the PMO processes like Waterfall or Agile and many C-Level executives support the PMO process. However, a formally adopted PMO process to implement and closely monitor projects and portfolios does not account for everything occurring in IT. And while meeting objectives in a project may be pleasing to stakeholders, it may not answer the question as to why does it take so long to do something that appears to be very simple? Or why can’t a task be done today rather than waiting for some other task to be completed first? Why can’t we add in a bunch of other projects to do so that an IT person can work on those when they are not doing anything? It’s this constant struggle of demonstrating an ROI from IT that makes the life of a CIO challenging. This is the reason for relatively high turnover rates of CIO and the adopted tag of ‘Career is Over’. Even IT executives who have come from the Non-IT worlds may have this perception and might explain why there is sometimes distrust within IT organizational management. 

For this, and many other reasons, as part of an overall risk assessment, the subject of project complexity should be taken seriously by executives when considering new IT projects. An understatement of a project’s magnitude can lead to an inaccurate ROI is where many IT Organizations introduce risks and instability into an IT organization. It will not eliminate all the CIOs problems, but it can help identify the projects upfront that have the greatest risk in the Initiation Phase before a project is launched. It can also indicate potential risks to existing projects. As viewed in this model, project complexity is intended to be a recurring process of evaluation and not a one-time fixed assessment at the beginning of the project. Moreover, the information derived from determining complexity can be used to rationalize overall work efforts in IT.


This paper is not intended to provide readers with a holistic view of what project complexity is. There are hundreds of papers already written on that subject. One such paper “Profiling Project Complexity: Insights from Complexity Science and Project Management Literature.” (Kiridena, S. & Sense, A. 2016) synthesized views from 42 relevant papers on the subject matter and was able to classify them into 17 categories. That paper and the authors cited is a recommended reading for anyone interested in an all-encompassing view of project complexity.

To familiarize the reader with the subject of project complexity, below are three (3) important points from that paper.

  1.       A complex project is not the same as a complicated project. “The distinction between the two is the nature of the relationships between the elements of the project system (Kiridena, S. & Sense, A.,2016)” as explained by Chapman. “For instance, large-scale engineering and construction projects are considered to be complicated projects, but they may not necessarily be complex projects (provided that the interactions with and the influences of the environment are trivial or rather predictable). If the nature of relationships between various elements of a project is such that interactions between elements are non-linear and, therefore, will result in emergent behavior of the system, then it has been referred to as a “truly” complex project (Whitty & Maylor, 2009; Maylor et al., 2008)”.
  2.       The field of Project Complexity is wide-open and not well defined. (Kiridena, S. & Sense, A., 2016) state “However, our review of the literature reveals that such broad generalized statements about project complexity to be somewhat inadequate or incomplete, in terms of providing any guidance for project management practice or the development of appropriate tools and techniques to deal with complexity”.
  3.       The natural progression for the subject of project complexity is to narrow it to a specific industry. (Kiridena, S. & Sense, A., 2016) states “There have also been several recent attempts at developing frameworks or models for capturing and measuring project complexity within particular industry sectors (Chapman, 2016; Lu et al., 2015; Dunovic et al., 2014; Lessard et al., 2013)”.

The (3) three points above provide a basis to move forward then with the Core IT Complexity Model to achieve the objectives of:

(1) Expanding knowledge into the field of Project Complexity, drilling down into and applying it to the IT Industry,

(2) Using the guiding principle and common theme prevalent in all prior work on this subject in defining complexity as “non-linear interactions”.

Current Methods

Current methods for evaluating IT project complexity are limited and seem to fall into three (3) Tiers.

    1.       Tier 1: Non-existent. No assessment or evaluation. One can imagine a small to medium sized company with a few IT associates that are mostly supporting networking, desktops, mobile devices, where complexity is not relevant. It could be labeled production support.
    2.       Tier 2: Simple bucketing of low, medium, and high categories determined by someone who most likely has a “feel” of the project’s size. This individual would most likely be someone in the organization that has a good sense of the work involved and enters the data point into a system or spreadsheet associated with the project. Information is most likely not utilized for decision-making and has no supporting data.
    3.       Tier 3: Companies who have made an ongoing program out of determining project complexity. Methods are characterized by teams that have established a series of complexity criteria tailored to their environment and use spreadsheets or custom-developed applications. Their complexity modeling could be part of a larger overall Risk Management process.

[widget id=”custom_html-68″]

The Core IT Complexity Model in this paper fits somewhere in between Tier 2 and Tier 3 and is not intended as a replacement for Tier 3. If a company should choose to use a Tier 3 approach, it could lead to significant paybacks. One such method was successfully developed at Intel (McBride, M. 2014). Not only were they able to evaluate complexity, but they also used the data to estimate resources and project duration in a matter of minutes. It deployed a sophisticated approach referencing historical information and a scoring tailored to their environment. Another IT organization, Department of Information Technology, City of Seattle, Seattle, Washington, wrote a paper entitled “Early risk assessment in IT projects: integrating risk research into project management practice.”, (Taylor, H. A. & Artman, E. 2014). They included project complexity as a part of their comprehensive risk assessment program. There are other examples of deploying Tier 3 methods that can be found on the internet and in journals.

When appropriate, a Tier 3 model is best, but most companies do not adopt a structured method, particularly small and medium sized companies. One can imagine that the value of a Tier 3 approach would increase dramatically if it could be sponsored and accepted by business executives who could actively participate.

Proposed Method

The Core IT complexity Model states that key complexity factors of the number of resources, roles, allocations, calculated team stress, and communications provide the most valuable information in determining project complexity for a Tier 2+ approach. Chart I depicts many of the factors that have potential to affect IT project complexity, how it affects complexity, and the compensating actions. There may be other factors, however, I do not believe that it would alter the analyses in this paper. The complexity factors are presented in time order sequence, identified by their project phase using phases from the PMI institute of Initiation, Planning, and Execution. The phases of Controlling and Closing are not applicable for the purposes of this paper.

Again, the common theme for project complexity is “non-linear interactions”, as cited under the Background section above. More predictability (linear) will mean greater anticipation and preparedness to deal with the situation, identify it as a risk before it becomes an issue.


In reviewing the complexity factors in Chart I, we can see that one of the major challenges is that much of the information helpful to assess complexity is not known until later phases of a project. For example, how many lines of code, number of tasks, number of issues, number of task dependencies, the exact number of requirements, and whether or not they are understandable. And therefore, an IT department needs to use the little information it can gain based upon high-level discussions about the project, its goals, and high-level requirements. This could be the function of a PMO board that has a list of initial scoping questions that would be asked of SMEs. Whether there is a formal PMO process or not, ultimately, the assessment will require the involvement of IT department heads when projects enter the Initiation Phase. This leads to one of the fundamental understandings when applying the Core IT Complexity Model to a project.

IT Management intuitively thinks in terms of resources, roles, and time when assessing project complexity. IT Management department heads and managers understand what is going on in their departments. They understand the inventory of skillsets, resource knowledge, approximate utilization of resources, and the backlog in their departments. Moreover, when evaluating a new project, IT management will typically enlist knowledgeable resources to tackle the early initial determination of a project’s magnitude, feasibility, and high-level costs. They will involve other department managers and SMEs who will have a series of meetings as required to discuss feasibility and overall level of effort. The feasibility of using internal resources will be heavily weighted by the novelty of the technology being implemented. That will in turn determine whether outside consultants will be required. If the project initiation analysis continues, an overall scope will take shape. Over the course of time in the Initiation Phase, depending on the magnitude of the project, details will become more apparent, and a high-level Charter stating goals and deliverables can be developed. For experienced and mature department heads and their reliance on internal knowledge and past experiences, they will be able to formulate an overall resource plan along with a ballpark cost estimate. And this can be done without knowing the details of the project plan. For example, take an IT eCommerce project; anyone experienced in this field will know right off the top, that it would need roles of business analysts, database engineers, application engineers, infrastructure server engineers, networking engineers, IT security and architects to name a few. One can safely estimate that at least 10% of the time will be needed by the department managers to understand the high-level requirements. Before the project exits the Initiation Phase, most experienced managers can provide roles and time estimates for their resources to participate in the requirements gatherings. Once requirements are understood, a good ballpark estimate can be made for detailed engineering resources.

Therefore, as we can see from the above flow, resources, roles, and rough allocation of resources can be estimated early in the project life cycle. As the project matures, other qualitative and quantitative information will help right-size the team to keep pace once the project duration has been determined.

In some cases, for novel technologies where there are no prior experiences, consulting firms will need to be brought in to perform the analysis, and therefore resource and time estimations may take longer.

Compensating factors ultimately affect resources and/or allocations. Some other important observations can be made about the complexity factors in Chart I. The compensating actions for many of the complexity factors result in an adjustment to resources or allocations of time. For example, if we look at the number of systems interfaces, we see that having the correct number of resources and time to handle the scope of the interfaces would be required. Having clear requirements means that we have the right number of BA resources allocated to the team. Similar reasoning can be applied to project duration, time zones, number of detailed tasks, number of task dependencies, number of lines of code. Each would ultimately result in an adjustment to resources or allocated time to right-size the team for the tasks at hand.

There are qualitative complexities that this model does not address and cannot be solved by increasing resources, allocation of time, or adding more roles.

  1.       Knowledge of resources
  2.       Team organization
  3.       Communications (Value-added
  4.       Changes in Scope

Knowledge of resources is, of course, very important. A project with knowledgeable resources will be more likely to complete tasks on time with fewer issues and be less likely to introduce chaos into the project. Team organization is about adopting the suitable project management methodology for the project at hand and adherence thereto, recognizing that no one approach will fit each project. For example, using an Agile process for an Infrastructure project is not a good fit. Nor is using a highly structured planned-based (i.e. Waterfall) methodology for a highly dynamic software project (Butler, C. W., Vijayasarathy, L. R., & Roberts, N., 2020). But adhering to the steps established within the framework of the project methodology selected by the company is key and deviating will add more chaos affecting all team members. Communication that adds value to the project goals is key to a project’s success.

Conversely, communication that does not add value will steal time and resources away from the project and could potentially add confusion and chaos. A team with many roles will need more value-added communications between team members to collaborate and work on interdependent tasks. Communicating status to the team’s project manager and the executive team for risk and issue identification and resolution is critical to a project’s health. But of course, the more communication required, the greater the interactions required, and the greater the complexity. Finally, Changes in Scope need to be controlled to minimize impact on the overall project goals and timeline.


As shown above, the Core IT Complexity model uses key quantifiable data elements of resources, roles, allocations, and communication (channels) that are most likely to be estimated early in the project lifecycle to calculate a value for complexity. This approach is an improvement over a simplified Tier 2 level. (It does require that the IT department collect this information). It does not replace all the other strategic and qualitative decision-making that no system could ever replace. Applied effectively, it could be used to estimate a project’s complexity, provide useful input into the project initiation process, assess the impact on other projects being executed, and rank projects relative to each other in the portfolio. This data taken together with other qualitative information will provide company executives with better information to make decisions on project initiatives.

Comments (3)