Tag: Change Management

Do Difficult Stakeholders Really Exist?

We hear and use the term ‘difficult stakeholders’ regularly, but is it the person that is difficult, the relationship or the situation?



It is hard to be truly objective, and the term ‘difficult stakeholder’ is almost always a subjective assessment. Sometimes the same person can be easy to work with in one context, and difficult in another. This points to particular situational issues which cause difficulties in reaching agreement. Sometimes a stakeholder seems difficult to one member of the team, but perfectly pleasant to work with to another. This may point to relationship or situational issues. And sometimes, we have to work with someone who is just difficult. With everyone. In every situation.

Despite general agreement that this person is difficult, we often tell ourselves it’s still a subjective assessment (“There are two sides to every story…” or, “They have friends and family so they can’t be like this all the time…”).

So, do objectively difficult people exist? Apparently – yes.

stakeholder 1

The Difficult Person Test

IDRlabs have developed the Difficult Person Test, which is based on research on the structure of antagonism. It uses 35 questions to create a radar chart of seven characteristics:

  •      Callousness
  •      Grandiosity
  •      Aggression
  •      Suspicion
  •      Manipulativeness
  •      Dominance
  •      Risk-taking.

Many people score highly against at least one area but a high score in only one area is unlikely to create a high overall score. A high score overall suggests, objectively, that you are more difficult to get along with than most people.

It is easy to work on the assumption that difficult people must already know they are difficult, but that doesn’t seem to be the case. Most of us think we are self-aware (95%!) but research suggests less than 15% of us are able to demonstrate good self-awareness.




We should all make increased self-awareness part of our personal development plans. Though this test, like most self-assessments, has many limitations there is always something to be learned by reflecting on how our preferences affect our behaviours and how our behaviours affect our relationships.


It is never too late in a relationship, group or team to re-set expectations. Contracting often takes place between groups or individuals at the start of a relationship to define how we want to work together, what we expect from each other and the behaviours we want to encourage and avoid. It also provides the opportunity to discuss how we will approach difficulties and unexpected behaviours when they arise. It enables an non-confrontational conversation that “as a group, we have moved away from the behaviours that we all agreed”.

Responding vs. Reacting

We learn in many ways that we cannot control other peoples’ behaviour, but we can control our response to it. Giving ourselves time to process an emotional reaction and turn it into a professional response pays dividends. Although we may feel provoked or even justified by the actions of difficult stakeholders, this legitimises the poor the behaviours and does nothing to improve the relationship.


Does it help to know that some people are objectively difficult? Perhaps not much, but it can at least provide an opportunity to reflect, consider how other people see us and even prompt a conversation within teams and organisations.

Before we label stakeholders as ‘difficult’, we need to consider the relationship and situational factors, and consider how we might try to resolve the difficulty. There are always two sides to every story, but perhaps the stories we believe about ourselves require a little more scrutiny.

Further reading: 

Have you taken the difficult person test? HBR (2021)

Why most people lack self-awareness and what to do about it. Training Magazine (2019)


The Business of IT PPM: Putting the business into your portfolio management strategy

Project and portfolio management (PPM) is designed to help organizations deliver on their goals, optimize performance and become more adaptive in a constantly changing business environment.

It is a secret weapon of IT teams to deliver value to the business, become strategically aligned with goals of the organization, and most importantly, show that value through data and reporting. If your organization has been searching for new ways to take advantage of the benefits of IT PPM through the optimization of your PPM strategy, your project management office (PMO) has the tools and the capability to do just that. Focusing on four key areas, your IT PPM can be the biggest influencer in your IT strategy and an extension of the business, rather than just a function of business.

IT helps PMOs manage projects, portfolios and investments collectively by harnessing vast amounts of data, resources and deliverables under one umbrella, then providing tools that support the distillation of that information into meaningful reporting that drives all sort of decision-making. Let’s take a look at the four key ways you can leverage IT PPM to advance business.

1.      Prioritization: The right work at the right times, consistently

In order to realize the benefits of PPM in your business, your organization needs to have a single, integrated prioritization system that takes into account all facets of your operation across all types and sources of work. IT PPM empowers your PMO and other stakeholders with the ability to make informed decisions based on capability, capacity, change readiness and other important business drivers.

This is because IT PPM provides broad visibility into all areas of a portfolio, from deadlines and deliverables, to resources and historic results. In short, your process and technology helps determines what is possible. It is important to recognize that IT implementation is a partnership with a singular goal: the long-term success of the business. While technology determines what is possible, business provides needed context for these prioritized goals.

·         Top down alignment

·         Strategically focused

·         Based on optimizing ROI

·         Balances all sources and types of work

·         Balances innovation and time to solution

·         Eliminates gaps and inefficiencies

Managing your resources while ensuring the right people are deployed to the right projects is the tricky part of project management, which is why PPM can be so helpful in enhancing your overall strategy. Too often, PMOs get stuck in a rut that makes distributing resources more about urgency than accuracy. They can only see the crisis in their immediate vicinity and solving it quickly becomes a singular goal. When you’re putting out a fire, you don’t pause to complain about the type of hose that is handed to you, right?

2. Resources: Optimized utilization, maximize efficiency


Resourcing should be strategic and future-focused — it must consider the current and future needs, as well as time to prepare. In the midst of change and uncertainty, it is difficult to maintain a long term strategy, but it actually becomes more important to do so. Ensuring your resources align to the projects you have deemed important to the business will ensure you are delivering on those promises. Furthermore, a solid resourcing strategy must also recognize that skills can be just as important as availability when it comes to distribution. It’s not enough to have a warm body at the monitor — each task needs the right taskee to ensure it is performed efficiently. IT PPM helps PMOs balance the distribution of work across all projects and portfolios with a dedicated, single resource pool that includes an exhaustive list of the skills, certificates and capabilities of each team member so no resource is over-utilized or double booked.

Business must go on and IT PPM supports the PMO to curate data on every resource at their disposal and find them quickly and easily when it comes time to assign work. When backed by the prioritization benefit listed above, your PMO can optimize utilization by providing the right resource for the job with zero waste or overlap.

3. Pivots

Rapid, pain-free adjustments

If the developments in the last year have taught us anything, it is that business is not stable. Even the factors we all once considered a foundational element of operations, such as person-to-person meetings, physical offices or fast and simple travel, have collapsed in the face of unprecedented hardships. What we have also learned is that flexibility is the key to survival and that IT is imperative to that flexibility. In a recent Forrester report, analyst Ted Schadler emphasizes this point saying, “Digital has been the only reasonable response to the COVID-19 crisis. And it’s the only reasonable response to the pandemic recession.”1 Many PMO leaders and project managers have learned and lived the power of the pivot and the importance it plays on business today. But the truth is, pivots and change happen all the time and your IT PPM strategy needs to allow for that. Embracing a change culture and instilling measures to support change – rather than reject it – will provide business returns from your project investments.

Technology can be credited with saving thousands of businesses and helping them to pivot during recent shutdowns and dramatic shifts to the way we all do business. In the realm of PPM, technology helps PMOs anticipate, plan for, and quickly roll with the proverbial punches. IT can be leveraged to monitor changes in needs, changes in goals and changes in alignment to make the right changes at the right time in the right way 

4. Control

Oversight and governance without slowing performance.

A common theme of the past three elements is visibility. By providing your PMO the ability to see and understand what is going on in all areas of operation, you are providing them with one of their greatest assets in supporting your business goals: control. IT PPM is automation-driven and results-oriented. Instead of parsing through stacks and stacks of spreadsheets, personnel files and creative briefs, information is gathered digitally and then sorted effectively.

No matter how brilliant your PMO and PMs might be, there is no substitute for the power of technology when it comes to compiling thousands of bits of information, not only making it easily accessible, but contextualizing it into meaningful reports. In short, your PMO can provide effective management that is driven by contextualized insight.

PPM is an excellent way to improve your business and maximize its effectiveness, profitability and positive outcomes. By adding in the benefits of IT PPM, your organization can achieve next-level performance that will help you ensure rock solid footing, even in uncertain times.

1 The Pandemic Recession Demands A Digital Response. Schadler, Ted. 25, June, 2020. https://www.forrester.com/report/The+Pandemic+Recession+Demands+A+Digital+Response/-/E-RES159643?objectid=RES159643

How Working in a Bar Helped my Approach to Change Orders.

Every day, the president of our company sends a company-wide email with inspiring, motivational, and thought-provoking quotes.


One day, the subject line caught my eye. “Customer Service is not Based on Money.” On the surface, this is an obvious statement. If you visit a business or utilize a service and the first transaction is terrible, the offer of 20% off the next visit is probably rejected. But what about return customers? Many businesses know those return customers are valuable to their bottom line and have loyalty programs that reward them for coming back. Buy 7 sandwiches and get the 8th free. Spend $100 and get $5 free on the next visit, etc. In the world of contracting, there’s no option for a loyalty program. Companies submit a bid based on their understanding of the scope and the job is awarded, usually to the lowest bidder or the incumbent with a similar price. So, how could a company show loyalty to a return customer? The change order.

This next statement may make some people, especially executives cringe. I don’t like change orders. There, I said it. There’s nothing worse to me than starting a project, gaining efficiencies, and then getting a change request that adds work and causes re-work on things already complete. Sure, this change order has a higher margin than your bid, but unless the schedule changes, you must do more work at the same time. Not only does this slow down new work in the field, but you must increase manpower to cover the re-work. This also complicates tracking your budget and key performance indicators. Why? Because now you may have people billing to the base job and the change order on the same day. If you have a crew of 20 people, what could go wrong with that? Since verbal requests and approvals are not accepted, change orders also create more paperwork for you and your customer. Nonetheless, these changes must be captured and all processes followed. But how can processing change orders impact customer loyalty? Before I go further, let’s look at a real-world example at a place farthest from the world of project management. A bar.

It was 2002, I had more hair and worked in a bar in Ocean City, Maryland. In this environment, customer service was based on money. (It wasn’t the only thing, you still had to make a good drink and tell a funny joke, but I digress) There were dozens of nearby bars and for the most part, all sold the same products and had similar music. Why did some succeed, and others had small crowds? When someone came in who was a regular and spent a decent amount of money, the bartender would always buy them a drink or two. They would make sure the customer knew they got something for free. This was important because you could never assume they realized it after looking at the receipt. The result of this was more tips and happier customers that felt they were getting a deal. These customers returned and told their friends, who spent more money. You couldn’t do this for every customer or you’d be out of business. We knew the regulars would come back, while the tourists may never come back again. Some of the other nearby bars had policies to not give away any drinks, no matter how loyal a customer was or how much they spent. This left them feeling nickeled and dimed and not appreciated. One customer, who was new to our establishment and enjoyed his experiences later rented out the bar for a private party. When the bill came, he didn’t even look at it, he just handed us his card and said he knew it was fair.


So how does giving away beer have anything to do with project management and change orders? As you now know, I don’t like change orders and I also know that due to paperwork, my customers may not like them either. Sometimes a change is a result of a mistake the customer made. Something was supposed to go here or work like this but needs to be moved there or work like that. A change order may require them to visit their boss and get approval for the mix-up. So, I have an equation in my head. X= the time will I spend creating, tracking, and invoicing this change order? If the change request is easy and less than x, I don’t charge them for it. But, just as in the bar, I make sure they know that we are doing this at no cost. This is usually met with the same appreciation as in the bar. Who does not like getting free stuff? More importantly, who doesn’t like less paperwork? If the next bid does not go out to bid, it’s a win-win. The customer gets a trusted partner who offers value and then you do not necessarily have to bid very low to win the work.

I was once told I am not in the project management business, but the customer service business. As the famous quote says, “We don’t do business with companies, we do business with people”. Project managers are the face of the company and making new customers lifelong customers should be the goal of any good company, whether a bar or a fortune 500 company. Just as a bartender knows their customer, a project manager should know just as much about their customer. This may mean having lunch and talking more about family and sports than projects and timelines. So, is customer service based on money? Meet me at a bar and we can discuss it.


A Simplified Approach to Determine IT Project Complexity

This paper proposes a set of core factors that can be utilized to determine IT project complexity. It argues that the factors – number of resources, communications, team stress, and roles mostly determine IT project complexity.

Moreover, these factors can be assembled into an equation to calculate and score project complexity mathematically. The results can then be utilized objectively to evaluate a project’s relative complexity before, during, and after it is initiated. This paper also suggests that using a mathematical method to evaluate project complexity is a more objective and informative approach than using the traditional misleading one-time locked-in subjective complexity data points such as cost and buckets of low, medium, and high.


Project Complexity, Project Risks, Managing Projects, Project Complexity Formula, Project difficulty.


One can look up the definition of project complexity under the PMI Institute, but essentially it is the sum of all factors that could affect the project’s outcome. There is no one widely accepted definition for project complexity. A definition provided (Hass, K. B. & Lindbergh, L. B., 2010), state that “Team size and composition, project duration, schedule, cost and scope flexibility, clarity of the problem and solution, stability of requirements, strategic importance, level of organizational change, inter-project dependencies, political sensitivity, and unproven technology” as the factors affecting project complexity.

Understanding a project’s complexity is essential to know in advance before a project is approved. Management needs to understand the risks involved as failure of a project could mean loss of money, valuable time, and lower employee morale. In this day and age of fast-paced technology, falling behind can sink a company. However, project complexity rarely gets the attention it should receive from executive management at corporations. Most companies do not spend the time doing a thorough analysis of a project’s complexity at the conception or later at the initiation phase. Many only look at the hardware, software, and consulting costs and do not consider the impact on internal resources or the probability of success. This view is particularly true for growing small to medium-sized corporations with no PMO function that review and evaluate projects considering all projects as part of a portfolio (a group of related projects). Most of the time, projects are selected into the portfolio based upon project payback and costs, and project complexity, if evaluated, is bucketed in low, medium, and high categories. And these determinations usually remain a one-time fixed occurrence. Moreover, once a project has been evaluated as having significant payback at the executive level, it becomes difficult to reverse course, even when the project has considerable, yet unknown complexity, and the risk of failure is high.

Quoted from a paper on the subject of project complexity by (Williamson, D. J., 2012), “Even the relatively general findings of this study indicate it may be helpful for practitioners to incorporate an assessment of project complexity into the initiation, planning, and execution phases of all IT projects. Wherever possible, proactive steps to mitigate the likely effects of IT project complexity may help improve the likelihood of IT project success. Further research into the relationships among individual factors and elements will help clarify these relationships”.

Many other scholarly papers have scrutinized a broad spectrum of possible influences on a project’s complexity. Some of these papers have developed evaluation criteria for measuring and determining project complexity. One such paper, (Yugue, R. T. & Maximiano, A. C. A., 2012), cover this topic quite extensively. There are others (Kathleen B. Hass, n.d). However, all the methods detailed in these papers require very knowledgeable and experienced staff who have an intimate understanding of a company’s culture, organizational capabilities, and project requirements. And for companies that do not have that level of sophistication in their organization, using an overly simplistic approach to determining complexity is inadequate and misleading. It allows risks to be introduced into the project or portfolio, which can later turn into major issues. Ultimately driving inefficiencies and waste into the organization.

Some companies utilize enterprise-wide portfolio management systems to evaluate the impact of proposed projects on resources and determine risks. These systems can provide a sophisticated analysis of a portfolio of projects looking at the complete picture of cost, resource conflicts, and an ROI. However, the output of these systems is only as good as the information entered. Implementing such a system in a large organization needs to be holistic and is a monumental project unto itself, and many fail to achieve their goals. Once the system is implemented, it requires corporate investment in highly skilled, trained, and dedicated committed resources. For the companies that can afford it and have many projects, it is a good approach in the long run. But many of these systems do not comprehensively provide methods for determining project complexity on an ongoing basis.

A Different Approach

Wouldn’t it be better to have a more straightforward way of determining project complexity without performing a full-blown assessment but would be more extensive than the standard bucketing approach? Most projects do not have all possible variables influencing their complexity. For example, resources at most companies are knowledgeable, have adequate tools, or the tools they have do not negatively impact projects, and usually, Business Analysts can generate clear requirements, similarly with other resources. It’s reasonable to assume that companies employ qualified resources and do not take on projects that are not a good fit for the organization. In this proposed model, we consider only the major factors that influence at least 80% of a project’s complexity, which is more than adequate for most company projects, particularly IT projects. These factors are referred to as core complexity factors in this paper.

Let us look at a basic way of determining core complexity that is quantitative in its approach and uses information that would be readily available via a project’s charter or some other research provided early in the project. This paper will proceed first to describe in detail each of the four (4) core factors that heavily influence a project’s complexity and then will proceed to explain the impact of each factor on overall project complexity. And finally, tie them together in a formula and describe how it can be applied in an organization.


Dimension 1 – Resources

The most crucial data used to determine a project’s complexity is its people resources. The number of resources on a project establishes the magnitude of a project and is a core determining factor for a project’s complexity regardless of the goals. In general, as the number of resources increases, so does the complexity. There must be adequate resources to complete the tasks according to the project schedule, and adding more resources to a project may reduce the duration for some activities. For example, a project that requires 2,000 lines of code could be distributed amongst four Developers to generate 500 lines of code each. Nevertheless, as the number of resources increases, the coordination effort, and the communication between resources grows, and so does the complexity, regardless of the duration of selected tasks. Anyone making a required contribution to a project will need to be included as a project resource. These include core participants but also should include subject matter experts, stakeholders, and shared resources. Many times, project management do not include these as part of the team. Anyone participating in a project needs to be accounted for. It also should be noted that a project with knowledgeable resources will be able to complete tasks most efficiently without confusion and delay. However, it is assumed that for this model, all resources are knowledgeable.

Dimension 2 – Communication Channels

As the number of resources increases on a project, the number of possible avenues of communication increases. The PMI Institute defines these as Communication Channels. The formula from PMI Institute is CC = R (R – 1)/2, where R, in this case, is the number of resources. Communication Channels (CC) grows exponentially as R increases. For example, a project with resources A and B will have one communication channel. A project with A, B, and C resources will have three communication channels: A – B, A – C, B – C. There is a high correlation between the number of communication channels and complexity. A task in a project that is not dependent on communication between people is a lower risk task than the same task that requires significant communications.

Below is a graph (Graph I) followed by a chart (Chart I), depicting the relationship between the number of resources and communication channels. As one can see, as the number of resources increases linearly, the number of communications channels grows exponentially. The greater the number of communications required to execute a project successfully, the greater the chance for misunderstanding and risks developing in the handoff between resources. And the greater the complexity.

maccue 1

Another way of looking at the communications channels is to depict it as shown below in Chart 1. Each resource (R) can speak with any of the other resources on the project. As we see in this example of a project with 25 resources, there are 300 possible combinations, or using the formula R(R-1)/2; we have 25(24)/2 = 300 Communication Channels.

maccue 2

Dimension 3 – Roles

Expanding the communication channels into further dimensions, one must look at the different levels of expertise required or roles on a project. We will define roles as a group consisting of one or more resources who have the knowledge to perform a set of distinct functions in an organization. Roles add another layer of complexity on top of Communications Channels. Each role consists of a subset of team members working with the entire team to define the requirements, translate the requirements into tasks, and then execute those tasks for one or more customers. Communication between roles is more complex than within the same role. For example, take a software project with five (5) people who all perform the role of Developer. If the project is managed properly, each Developer will already understand the requirements, and each would develop the code required. Since each Developer speaks the same “Developer Language”, communications should be well understood between Developers without significant complexity. Now take another project that needs (1) BA, (1) Developer, (1) DBA, (1) QA Analyst, (1) Network Engineer. Both projects need five (5) resources, the same number of Communication Channels, but the latter project would require handoff and communication between the roles to define, understand, and execute different activities. The Business Analyst (BA) would state the requirements, either as an Agile Story or other requirements document. The requirements document would then need to be reviewed and approved by Stakeholders. After approval of the requirements, Developers will need to review and interpret the documents and develop the code. The Developers would then need to work with the DBAs to define and create the databases. In most situations, the outcome of the coding always needs testing by QA followed by some revamping to align with requirements. It would be a similar situation with the Network Engineers; the requirements such as firewall rules and IT Security would need to be defined, reviewed, and executed.

Therefore, in this simple example above, it is entirely clear that as the number of roles increases on a project, so does its complexity. Furthermore, it is not unreasonable to state that the size of the team significantly influences its impact on complexity. The exact determination depends on each project, but in general, roles on a large project have more requirements to satisfy, more communications, and more work to execute. Chart II below depicts that work effort as the possible combinations of communications. As can be seen, the greater the number of roles, the greater the complexity.

maccue 3

Roles in Chart II consist of eight (8) groups of people; each role has two (2) resources for illustration purposes. Each role will need to work with the other individual team members to define and execute the requirements. So, for Role 1, R1 communicates with resources R2 – R16.  For Role 2, R3 communicates with R1, R2, and R4 – R16, so on and so forth. Therefore, the equation that states the magnitude of that relationship is given by the formula:

Role Complexity = Number of Roles X (Resources – 1).

Unlike the Communication Channels, the order of the relationship is important so that for example, the relationship of Role 1 – R2 is not the same as R2 – Role 1.  

Dimension 4 – Stress and Average Team Allocation %

The dimension with the most significant potential for risk and complexity on a project is Stress (S).

Stress is defined as:

S = 1 / Team Average Allocation %

Stress is the average % of time the team is allocated to the project, totaling each team member’s average allocation % and dividing it into 1. The higher the number S, the greater the stress on a project, the greater the complexity, and risk to the project. The ideal situation for a team working on a project is a dedicated co-located team setting where everyone is close by and spending 100% of their time on the project. In this situation, communication between team members flows most efficiently. There are no shared resources or multi-tasking on other projects. All resources to complete all the tasks are on the team. In this approach, Stress (S) is equal to 1 and is the lowest value for S.


This “co-location” approach also happens to be the most expensive of the options. Most companies will have multi-tasking resources working on several projects across a portfolio of projects. Resources that multi-task fall into three categories: shared resources, subject-matter experts (SMEs), and part-time team members. Shared resources are usually those that belong to resource “pools” like DBAs, networking, server engineers, etc. SMEs are those people who have knowledge in an area that can benefit a team, particularly when defining up-front requirements or design of a product. Part-time resources are those resources that are splitting up their time between projects. And the greater the number of multi-tasking resources on a project, the greater the stress. As stress levels increase on team members, communications must be tightened for multi-tasking team members, and execution must become more precise. Sometimes the team members must work overtime to meet total work commitments, but the risk of making errors increases dramatically. Everyone has heard someone say, “Don’t rush me, or I am going to make a mistake”. In these situations, project stress factors can vary weekly, making the project manager’s job much more difficult.

In this complexity model, all resources that could add complexity to the project must be accounted for. There is no one-size-fits-all approach; the Project Manager using this model will need to distinguish between ‘availability’ of a resource and ‘allocation’. If shared resources are well-staffed and have virtually infinite capacity, then it would be best to leave those resources from the Stress equation. The same reasoning could apply to SMEs if their time requirement is low. The more concerning of the multi-tasking resources are those who are stretched thin, bouncing between projects. Examples of these could be Project Managers working on multiple projects, Developers, Network Engineers, or QA resources.

Each project resource allocation will have to be evaluated appropriately by the Project Manager or Analyst performing the complexity evaluation.

Complexity Formula – Describing Complexity as a Formula

Using the four core complexity factors as described in detail above, we can state the Complexity formula as:

Complexity = (Communication Channels + Roles Complexity) X Stress.


Communication Channels = [# Resources X (# Resources – 1)  ] / 2,

Roles Complexity = # Roles X (# Resources – 1),

Stress = 1/Team Average Allocation %.

If we let:

C = Complexity,

CC = Communications Channels,

R = Number of Resources,

O = Number of Roles,

A = Average Team Allocation %,

we can rewrite the above three (3) equations as:

maccue math 1

Substituting 1/A, for S we can further simplify to:

 maccue math 2

As we can see from the formula, the size of Complexity (C) is most heavily influenced by resources and the average team allocation (A). That can be shown with several graphs. Below is Graph II depicting the impact of increasing resources (R) on Complexity (C) holding both Team Allocation (A) at 100% and Roles (O) at a constant value of five (5).

maccue 4

The effect of increasing the number of resources on a team is exponential.

Similarly with Stress (S) as depicted in Graph III below, decreasing the Average Team Allocation % (A), thereby increasing team Stress also has an exponential impact on Complexity (C). In this example, Roles (O) has a constant value of five (5) and Resources a value of twenty (20).

maccue 5

Lastly, examining the impact of increasing the number of roles on a project, Roles (O), while increases complexity, does so at a linear rate, as shown in Graph IV. In this example, the number of Resources (R) has a constant value of 20, and team Allocation (A) has a value of 100%.

maccue 6

Taken all together, this would lend credence to what most Project Managers already know that resource allocation is the most important factor for project success given that all other factors remain constant and that as the team size increases, complexity grows quickly. Roles have an initial impact early on in the project once the scope and requirements are understood, and the team is formed. As more resources are added to the project, their purpose is usually to support existing roles, and/or reduce the project’s duration. Therefore, complexity is impacted, but at a slower rate.

Analysis – Comparing Traditional vs New Model

Let us apply a traditional approach to determine project complexity using a list of five (5) hypothetical projects as shown in Chart III below and then compare it to the complexity model described in this paper. The “traditional approach” described below assumes that the company does not have a PMO board role evaluating project complexity as a part of its intake process. Instead, the process of evaluating complexity typically uses factors such as costs of hardware, software, consulting, and possibly a team size factor of small, medium, and large. Later during the Project Initiation Phase, the number of core or full-time resources are usually detailed by the Project Manager. But generally speaking, at the business executive level, a resource is a resource, it does not matter what they do. Those are generally considered details that the IT Project Manager would need to know. In many organizations, once the PMO Initiation Phase of a project starts, the train has already left the station, so to speak, and the project is launched based upon a very high-level analysis using costs and payback. It then becomes the responsibility of IT Management to figure out how to get it done. And once the traditional complexity scores are determined, they are forever locked in, even as changes are made to the project scope, resources, or allocations. Let’s illustrate a typical traditional approach to determining project complexity using the data below in Chart III.

maccue 7

Projects shown in Chart III are ranked by complexity from highest to lowest. Each has the same duration, and the same team size of twenty (20) associates. Applying the traditional model’s reasoning, shown are the hardware, consulting, and software costs for Project 1 and notice that they are higher than the other projects, implying more complexity. Failure of this project could mean a significant loss of hardware and software investment to the corporation and unrealized gain. Based on that information, this project seems to be the most complex project from an executive-level viewpoint. Looking at Project 2, a similar argument could be made based upon the high cost of the hardware and has high payback, but not quite as high as Project 1. Project 3 has a medium payback, but its cost of consulting and software are the same as the others, but it does not have the hardware cost. Its payback is lower than the project’s 1 and 2. Project 4 has a low payback and no hardware costs, so it is placed at the 4th most complex project. Project 5 is a Corporate Training System that has lower consulting cost, but because its payback is low its been decided to make it a part-time implementation, but keeping to the duration of 60 days. The reasoning is that if it does not get done, the payback is low, and the costs are relatively low, we can always extend the timeline if need be.

Using the same data but applying the complexity formula proposed in this paper, we need to ascertain additional information, as shown in Chart IV below.

maccue 8

The additional three columns added is a further breakdown of the Roles, Allocation percentage, and calculated Stress factor. The calculated Complexity Score column replaced the one used in the traditional model. Much of this new data would not be available generally during the project conceptual phase. It would require a more detailed assessment by an analyst on a PMO team or a knowledgeable Project Manager. The critical point is that the assessment should be done early on, particularly for high payback projects before they get approved. Also, the assessment must consider the impact on other projects already approved and in the portfolio. Approving a new project and moving it into the portfolio could kill another project and completely change its complexity. This is a common mistake made by IT organizations assuming that complexity is a fixed entity.

Based upon the Complexity Score calculated, we get entirely different results. The most complex project is project 5, Corp Training System, with a Complexity Score of 760. There are two reasons for this result. The team size is twenty (20), the same as the other projects, but the team requires ten (10) roles, and the team is part-time based upon executive payback determination. A stress factor of two (2) implies that most everyone on the team is multi-tasking, which means that mistakes will be made, schedules will be missed, meetings will not be well attended due to other obligations. This scenario will make the project manager’s execution and coordination very difficult and complex, even though the process and technology may be relatively simple. The likelihood for successful completion in the time frame of 60 days may only come at the cost of other projects. It is for this reason that this is the most complex project in the list. The next most complex project in this list is project 4, New System 2, it has only two (2) roles, making it less complex than Project 5. Similar to Project 5, it is heavily influenced by its Stress factor of two (2).  Project 3, New System, is the next most complex project. It has ten (10) Roles, but has a fully dedicated team. Skipping to Project 1, while it has the highest cost and payback, it is the second least complex project because it has a fully dedicated team with only three (3) roles. Communication handoff between team members is relatively simple compared to the others. And finally, the least complex project is Project 2, only slightly lower than Project 1 because it has only one (1) role.

In conclusion, as we can observe from the analysis of complexity above, the results between the traditional approach and using the complexity model vary quite significantly.

Conclusion and Practical Application

How can the approach described in this paper be utilized in companies that do not currently have a good practice for determining complexity? The complexity model as proposed in this paper, can most effectively be used by ranking complexity between projects in a portfolio. Project complexity should be recalculated on a recurring basis to identify potential risks as part of the ongoing change management process. The complexity model described in this paper does not consider team knowledge, clarity of objectives, costs, and all the other factors that other complexity models have suggested, so it is not a complete picture for some. However, for most companies, factors of resources, communications, roles, and resource allocations represent 80%+ of the core factors influencing IT project complexity. If these can be managed, then the project and portfolio risks and complexity can be managed resulting in a more efficient and effective organization. Moreover, because the determination of complexity in this model is mathematical, it can be calculated systemically as needed on an ongoing basis with or without a portfolio management system. The additional data points should be welcomed by management. Additional research needs to be done to quantify other variables influencing project complexity and further improve the process of evaluating project complexity.


Williamson, D. J. (2012). Assessing the relationships among information technology project complexity, complication, and success. Paper presented at PMI® Research and Education Conference, Limerick, Munster, Ireland. Newtown Square, PA: Project Management Institute.

Hass, K. B. & Lindbergh, L. B. (2010). The bottom line on project complexity: applying a new complexity model. Paper presented at PMI® Global Congress 2010—North America, Washington, DC. Newtown Square, PA: Project Management Institute.

Yugue, R. T. & Maximiano, A. C. A. (2012). Project Complexity and Management Processes. Paper presented at PMI® Research and Education Conference, Limerick, Munster, Ireland. Newtown Square, PA: Project Management Institute.

Hass, K. B. H. (n.d.). Introducing the New Project Complexity Model. Part I. PM Times. Retrieved January 31, 2021, from https://www.projecttimes.com/articles/introducing-the-new-project-complexity-model-part-i.html

Organizational Culture within The Walt Disney Company

To be sustainable does your own company culture need to change? How?  To be sustainable does your own company culture need to change? How?

Perhaps Walt Disney expressed it best when he said “It’s kind of fun to do the impossible.”. The Disney corporation has managed to be sustainable within it’s organizational culture, by doing what might appear as the impossible. That is, by building franchises while adapting to change. 

Walt Disney did a fabulous job in embedding a solid foot print in the franchise business. Later Michael Eisner, as CEO of the Disney corporation, filled those leadership shoes well, by focusing on creativity, branding and synergies. But by the late 1990s, Eisner’s centralized management style had created a rather contentious culture. Older management styles were not working. A sign of the times no doubt.  Walt Disney did a fabulous job in embedding a solid foot print in the franchise business. 

Since change is constant, Robert Iger, having taken over the reigns as CEO from Michael Eisner in 2005, showed fresh modern visionary thinking. Iger’s more unifying framework helped to integrate executives internally. This allowed him to better align with the external environment, such as promoting cooperation by mending sore wounds between Disney and Steve Jobs of Pixar Animation Studios. But most importantly, Iger’s early sustainable strategy was to adapt to changing competition and market forces by embracing a less rigid, and more flexible system with self-managing teams, allowing employees a wider span of creative control. Walt Disney’s horizontal organizational design with a flattened non-hierarchical structure, needed to become highly organic under Robert Iger, which is better suited to a faster changing business environment. Especially, where the emphasis is on the Internet and increasing globalization. By delegating autonomous business units, Iger increased trust and accountability throughout all levels of the business. 

By incorporating creative content, technological innovation and global expansion, Iger had the recipe for modern day success. This combination had a disruptive effect because Iger recognized how to take an external market force, like technology, and make it an opportunity to expand Disney’s financial arm to reach across the world, enveloping many complex and sometimes simple-unstable forces. Thus, Robert Iger restructured Disney to comfortably fit into the external environment, by using their resources and capabilities to create a competitive advantage.

Iger created a business vertical whereby the Disney corporation could produce and distribute its own products and services, and diversify in investments and acquisitions of companies like Lucas Film, Touchstone, Marvel Studios, worldwide theme parks, media networks like ABC, licensing deals, comic strips, TV, and publications. Take a box office hit movie and capitalize on it with merchandise and product spin offs: an impetus for proud profits. Adding a video streaming platform was the icing on the cake. And, accessing emerging markets like Latin America, Europe and China helped to bolster beyond predicted profit margins. 

By focusing on core business drivers for change, Iger was able to overcome key obstacles. And, by exploiting technology, what might appear to be a threat to some, the Disney corporation was able to succeed and thrive substantially in the external environment. 

Though it might be impossible to believe, I’m sure that Robert Iger found changing Disney’s company culture to a more efficient and effective business model, kind of fun to do.