The presentation aims to provide a framework for calculating project complexity rather than offering a comprehensive strategy. It identifies six compound factors contributing to complexity: team member count, project challenges, technical challenges, perceived value, distributed resources, and visibility. A scoring system is provided to assess these factors, enabling project managers to align their experience with the project's complexity and manage it more effectively.

1. Calculating Project Complexity
Afshin Ganjoo - LinkedIn

2. The Intent of this Presentation
The intent is not to write a dissertation on project
complexity. Plenty have already been written.
The intent is not to propose a strategy to cover all
industries, all companies, all circumstances.
That would be a dissertation.
The intent is to propose a framework to calculate
project complexity, such that it can be adapted
to your specific company culture and modus
operandi.

3. The Advantage of knowing a Project’s Complexity
Matching the right project manager to the
right project - the right experience to the
right complexity.
Knowing the source of complexity will
allow the project manager to monitor
the source of complexity, and eliminate
or mitigate it.

4. Compound Complexity Factors

5. Factors contributing to Project Complexity
Compound complexity factors directly correlates to,
and therefore can be used as a proxy for many other
complexities.
There are 6 compound factors contributing to project
complexity:
Team Member Count
Project Challenges
Technical Challenges
Perceived Value
Distributed Resources
Visibility

6. Team Member Count
Team member count is probably the most impactful
project complexity factor, and can be used as a proxy
for many others.
The higher the team count,
The more chances of conflict
The more need for scaling project management
activities
The more difficult organizing the project
The more difficult communicating and reporting
The more challenging to run the project efficiently
The more complex the project.

7. Project Challenges
There is a series of project challenges that
contribute to project complexity.
The more the project challenges, for
example:
The fuzzier the project requirements
The more time pressure on project timeline
The more pressure on resourcing
The more complex the project.

8. Technical Challenges
Technical dimension of a project is a major contributor to
its complexity.
The higher the technical challenges, for example:
The more research oriented the project is
The more novice the technology being developed is
The less experienced the team is in what they are
delivering
The more dependency exists between various
deliverables
The more complex the project is.

9. Perceived Value
Perceived value of a project can simplify or
complicate a project.
The lower the perceived value of the project,
The more negotiation is needed
The more encouragement is needed
The less management help the project gets
The more attention the project needs to keep
it on track
The more complex the project is.

10. Distributed Resources
Distribution of resources adds another dimension
of complexity to the project.
The more distributed the resources are within
the company, for example, in various teams
that are not under the same management,
The more negotiation is needed
The more conflict management is needed
The more organization is needed
The more coordination is needed
The more complex the project is.

11. Visibility
Visibility is a proxy for many other project complexity.
The more visibility the project has, for example:
The more visible to customers the project
deliverables are
The more financial impact the project deliverables
has
The higher the management chain the
stakeholders are
The more complex the project is.

12. Calculating Project Complexity

13. The Calculus
Assign a value 1 to 5 to each of the 12
following questions
Assign multiplier to each question based on
its relative contribution to complexity
Calculate the weighted average of your
responses (should be between 1 and 5)
Once project complexity is calculated,
assign the right level of TPM experience
to the project
During project execution, keep an eye on
factors that scored high
Complexity Experience
4.34 - 5 Principal Staff TPM
3.67 - 4.33 Senior Staff TPM
3 - 3.66 Staff TPM
2.34 - 3 Senior TPM
1.67 - 2.33 TPM
1 - 1.66 Junior TPM

14. Recommended Multiplier for Each Question
How many people will be contributing work to the project? 4
What is the level of dedication of the majority of contributors to the project? 2
How much of the project requirements have been gathered? 2
With your deadline calculated and committed, how much buffer did you plan in? 1.5
How much more resources can you add to the project without escalating? 1.5
How well is the technical design understood? 1.5
How new is the technology? 1.5
How experienced is the team in handling this technology? 1.5
How much dependency exists between various components of the project? 1.5
What is the perceived value of the project? 1
How distributed is the team? 1
Who is the major sponsor? 1

15. Question #1
How many people will be contributing work to the project?
Complexity 1: 3 or less contributors
Complexity 2: 4 to 7 contributors
Complexity 3: 8 to 15 contributors
Complexity 4: 16 to 31 contributors
Complexity 5: 32 or more contributors
To be counted as a contributor, must contribute a reasonable amount of work to
the project, essential for project success.

16. Question #2
What is the level of dedication of the majority of contributors to the project?
Complexity 1: Fully dedicated to the project
Complexity 2: Time-sharing with other projects - this is their top priority
Complexity 3: Time-sharing with other projects - this has equal priority
Complexity 4: Time-sharing with other projects - this has lower priority
Complexity 5: Not dedicated to the project and resources have to be negotiated
as the project goes on

17. Question #3
How much of the project requirements have been gathered?
Complexity 1: Requirements have been fully gathered (90%+), in enough detail
to get a committable scope, and are unlikely to be added to by the project’s
completion
Complexity 2: Most requirements have been gathered (65% to 90%) and in
enough detail to get an acceptable scope, but some requirements will need to
be determined and detailed as the project progresses
Complexity 3: Half the requirements have been gathered (35% to 65%) but the
other half needs to be determined as the project progresses
Complexity 4: Small amount of requirements have been gathered (10% to 35%)
and most need to be determined as the project progresses
Complexity 5: Almost no requirements have been gathered (10%-) and have to
be determined as the project progresses

18. Question #4
With your deadline calculated and committed, how much buffer did you plan in?
Complexity 1: No committed deadline and can slip as needed
Complexity 2: Committed deadline with 50% to 100% buffer
Complexity 3: Committed deadline with 20% to 50% buffer
Complexity 4: Committed deadline with 5% to 20% buffer
Complexity 5: Committed deadline with less than 5% buffer

19. Question #5
How much more resources can you add to the project without escalating?
Complexity 1: As much as needed
Complexity 2: From 50% to 100% more resources can be added
Complexity 3: From 20% to 50% more resources can be added
Complexity 4: Up to 20% more resources can be added
Complexity 5: No more resources can be added

20. Question #6
How well is the technical design understood?
Complexity 1: Design is well understood and seems really easy, expecting no
complications
Complexity 2: Design is mostly understood and seems relatively easy,
expecting minor complications
Complexity 3: Design is somewhat understood and seems somewhat
complicated, expecting manageable complications
Complexity 4: Design needs more work to understand and seems complicated,
expecting major complications
Complexity 5: Design not well understood and seems really complicated,
expecting significant complications

21. Question #7
How new is the technology?
Complexity 1: The technology is nothing new, we have it already, just adding
more bells and whistles
Complexity 2: We are adding minor features to an existing technology
Complexity 3: We are adding major features to an existing technology
Complexity 4: We are fully rewriting an existing technology
Complexity 5: The technology is new, we don’t have anything like it, creating it
from scratch

22. Question #8
How experienced is the team in handling this technology?
Complexity 1: The team built this technology
Complexity 2: The team is very familiar with this technology and has experience
with it
Complexity 3: The team has a fair understanding of the technology with some
exposure to it
Complexity 4: The team has little understanding of the technology and
practically no experience with it
Complexity 5: The team has never worked with this technology and needs to
learn it as the project progresses

23. Question #9
How much dependency exists between various components of the project?
Complexity 1: Components of the project are mostly independent - significant
parallelism can be achieved by dividing the team up to many smaller teams -
critical path is 10%- of full path
Complexity 2: Components of the project have some dependency on each
other - critical path is 10% to 35% of full path
Complexity 3: Components of the project have fair dependency on each other
- critical path is 35% to 65% of full path
Complexity 4: Components of the project have major dependency on each
other - critical path is 65% to 90% of full path
Complexity 5: Components of the project are mostly dependent - parallelism is
very hard to achieve and team must function as one unit - critical path is
90%+ of full path

24. Question #10
What is the perceived value of the project?
Complexity 1: This is the top project that everyone wants to be a part of,
building their careers on it - something to put on their resume
Complexity 2: This project provides opportunities for growth and recognition -
considered exciting
Complexity 3: This is a typical project for the team with some aspects being
exciting while others less so - considered a typical project
Complexity 4: This project has little to be excited about, and provides little
opportunity for growth and recognition - considered boring
Complexity 5: Almost no one is exciting to work on this project, and they see no
value to their careers - considered a waste of time

25. Question #11
How distributed is the team?
Complexity 1: The project is highly centralized with one active boss
Complexity 2: The project is relatively centralized with two active bosses
Complexity 3: The project is fairly centralized with three active bosses
Complexity 4: The project is relatively decentralized with four active bosses
Complexity 5: The project is highly decentralized with five or more active bosses
An active boss is someone who is managing the resources that are in the project,
and the project manager has to work with to secure the resources for the project.

26. Question #12
Who is the major sponsor?
Complexity 1: Technical Lead
Complexity 2: Manager or Senior Manager
Complexity 3: Director or Senior Director
Complexity 4: VP or Senior VP
Complexity 5: Executive
To qualify as a sponsor, must be receiving frequent and consistent updates, active
in giving recommendations, and be the escalation point for the project.

27. Examples
Question
Weight
4 2 2 1.5 1.5 1.5 1.5 1.5 1.5 1 1 1
Project Complexity Q#1 Q#2 Q#3 Q#4 Q#5 Q#6 Q#7 Q#8 Q#9 Q#10 Q#11 Q#12
Project #1 2.60 2 4 1 3 5 2 2 2 2 4 3 3
Project #2 3.88 5 5 3 5 3 3 2 2 4 5 5 3
Project #3 3.28 5 4 2 3 2 3 1 2 2 5 5 4
Project #4 2.28 2 2 2 1 3 2 4 2 3 3 2 2

28. Reducing Project Complexity

29. Question #1 - How to Reduce Complexity
Consider breaking up the project into distinct phases, where each phase has
fewer contributors
Consider breaking up the project into semi-independent projects running in
parallel, and having several TPMs in a hierarchy (one senior TPM leading
several junior TPMs) managing the projects
Consider using fewer contributors in the project at the expense of prolonging the
project further

30. Question #2 - How to Reduce Complexity
Consider negotiating before the project starts, even if some of those contributors
don’t have to engage until the latter part of the project lifecycle
Consider ways to increase the priority of the project so securing resources can
be made more appealing
Consider killing the project before it starts if the value is so low that teams are
hesitant to secure resources for it

31. Question #3 - How to Reduce Complexity
Consider agreeing what the project will not deliver, if you can’t agree what it will
deliver
Consider setting the expectations of project sponsors that the requirements are
to be determined later and the explanation of the risks that are involved with
that
Consider defining what success means (if requirements are not fully identified):
What can be done in certain time, What can be done with certain resources,
What problem needs to be solved, etc.

32. Question #4 - How to Reduce Complexity
Consider asking project sponsor for more time to inject as buffer, given the
morale and roadmap impact of a slipped project
Consider reducing requirements or adding resources so some buffer can be put
in place
Consider making sure project sponsored understand that the project is at high
risk of slipping, if reasonable buffer cannot be added (20% is generally
considered minimum)

33. Question #5 - How to Reduce Complexity
Consider negotiating conditional resourcing, that is, adding resources to the
project if certain events occur while executing the project
Consider reducing requirements or prolonging the project timeline to reduce
pressure on your resources
Consider make sure resources are not taken away and remain focussed on the
project with minimal distraction

34. Question #6 - How to Reduce Complexity
Consider characterizing this as a research project or POC (Proof of Concept),
which has flexibility in resources and timeline, and light on commitment to any
requirements
Consider making the timeline and resourcing conditional on possible design
decisions
Consider recruiting an experienced team to take the project through the design
phase

35. Question #7 - How to Reduce Complexity
Consider reviewing technology outside the company, or bringing in outside
expert in the area, to reduce this complexity
Consider increasing your buffer in anticipation of unforeseen events
Consider reducing your requirements to the bare minimum for the first release,
adding more features in subsequent releases

36. Question #8 - How to Reduce Complexity
Consider allocating some time for team to get familiar with the technology
Consider running training events like pair programming, feature presentations,
postmortems, code review sessions, and so on, to disseminate knowledge
quickly and widely
Consider reducing the scope of the project or executing it in phases, with the
easiest portions handled first

37. Question #9 - How to Reduce Complexity
Consider creating a reasonable number of milestones for the project so any
slippage can be detected early on
Consider increasing your buffer as your critical path gets closer to your full path
in size
Consider breaking down tasks to smaller sub-tasks, to improve the predictability
of timeline and to reduce the number of surprises

38. Question #10 - How to Reduce Complexity
Consider making this part of a larger project to increase the perceived value of
the project
Consider killing the project if the perceived value cannot be elevated
Consider other morale boosters for the team to keep them motivated

39. Question #11 - How to Reduce Complexity
Consider breaking up the project into several smaller projects each with one boss
Consider nominated an uber-boss from amongst the bosses, someone higher in
the chain of command, or have the TPM assume the role of the boss for this
project
Consider shortening the timeline of the project to reduce the risk of changes in
roadmap or resourcing within contributing teams

40. Question #12 - How to Reduce Complexity
Consider gaining better understanding of the non-technical aspects of the
project, including business impact, legal ramifications, customer impact, and
so on
Consider identifying and eliminating parts of the project that don’t have business
or customer impact, to make the project more focussed on what really matters
to the higher management
Consider breaking the project into smaller projects, so that each project has less
business impact or impacts fewer customer percentage