Part III: A Simplified Approach to Determine IT Project Complexity. Communications and IT Project Complexity.

Abstract

This paper examines the topic of communications on a project relative to the subject of project complexity.
It examines the role that communications play on a project, its effect on project complexity, and how and why teams should be organized to maximize the value of communications. For context, this paper is Part III of a series of papers on the subject of project complexity. See Reference Section for those papers.

Keywords

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

Introduction

The subject of project complexity is a topic of research initially raised in the mid-90s, and there have been hundreds of papers written on that subject since. For context purposes, the term “Project Complexity” is not the same as a “Complex Project”. Below is a generally accepted meaning of the term “Project Complexity”.

“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)”.

Defining Communications

Communication is critical for a successful project. One such website provides 21 examples of communications on a project (John Spacey, 2017). That source listed the following examples of communications: Project Initiation: Change Management, Requirements, Estimates, Planning, and Scheduling, Risks, Issues, Design, Status, Governance, Financial, Procurement, Vendors, Conflict, Performance, Stakeholder, Controls, Execution, Testing, Launch, and Closure. The URL below is cited in the Reference Section.

https://simplicable.com/new/project-communication 

Mapping (Chart I below) the examples cited against the different roles on a typical IT project, one can understand the sheer magnitude of communications required for a successful project. Essentially everyone on a project will need a channel of communication open for one or more specific reasons. But as can be seen, not all communications are relevant for everyone on a team. Communications begins narrowly focused, then gradually picks up as the project moves from the Initiation Phase and onto the Planning Phase and peaks during the Execution Phase. If everyone on a large project had to attend every meeting and listen to everything said, it would be a significant waste of time that could otherwise be used for productive activities. On the other hand, team members not attending meetings related to their area of responsibility can lead to information loss and could negatively affect the project. Both situations of too much communication and too little communication lead to loss of time and increases the likelihood of risks and issues developing.

 

 

In general, the more communications required on a team, the greater the potential impact on project complexity. Chart II depicts the relationship between complexity and communications. On the upper right side of the chart listed are some of the factors that increase complexity and, on the left, reduce complexity. As we can see from the chart, the larger the customer base on the right, the greater the communication level, and the more complex. On the left, where the focus is on smaller audiences, the less complex. The scale applies to other factors as well. Projects that are more dynamic where requirements are not well understood could add more communications and complexity. This is why corporate-wide software development projects on a large scale are more complex than packaged software already developed and tested.  

 

Given the sheer magnitude and complexity of communications on a project, it is easy to see why it is critical to managing communications on a project strategically.

Organizing into Sub-Teams to Reduce Complexity

Regardless of the project team size or the level of complexity, communications must be managed so that important information is channeled and filtered appropriately. Doing so has the effect of increasing the value of communications and reducing project complexity. One such strategy that management will employ is to create teams within a project referred to as sub-teams. They usually are organized by role, function, or logical grouping that focuses on a particular purpose. To illustrate why communications on a project adds complexity, the below Chart III depicts a team of eight (8) resources on a project with the possible communication channels. The formula for the number of channels is R (R-1)/2 where R = # of resources.

---

---

 

 

With eight (8) people on a team, there are 28 communication channels. One can easily visualize the chance for chaos. In a situation where meetings are occurring, and ideas are being exchanged openly, things could get out of control quickly. Add one (1) person into the team, and the communication channels increase to thirsty-six (36).

Now, if we take the same eight (8) resources and organize them as per below in Chart IV, divided into two (2) sub-teams, with a “Filter” in-between, we can reduce the number of communications channels by more than one-half, from twenty-eight (28) to thirteen (13). The “Filter” in this diagram represents resources that capture and share relevant information between sub-teams. This way of organizing the team provides for greater focus with less complexity.

 

On the other hand, if the filter is not functioning properly, important information could be lost. This situation often happens in the area of change control, where a change is made without communicating it across the entire project team, and an impact analysis is done without considering all areas of the business. Even with excellent team communication, it is a challenge. Clearly, creating sub-teams has its purpose when the focus is for a specific role where others do not need to participate or add no value. One could say that input to the sub-teams can be confined to the sub-team, but the output from the team should be communicated across the board so that everyone is aware of potential risks or issues. For this reason, we can categorically state that the sum of the sub-team communications does not add up to the required communications for the whole of the project. Moreover, that is why the overall complexity of a project remains higher with large overall team sizes even when they are most effectively organized.

 

Organizing a Project Team

As one can visualize from Chart V, organizing a project team into logical groupings is a way to channel communications and reduce complexity. This is just an example, and the chart does not imply that all project teams should have a steering committee or SMEs. The project could use a Waterfall or Agile methodology. For example, the Project Management Sub-team(s) could be one or more Scrum Masters. Represented inside the shaded elliptical are all communications on a team, including sub-teams.  Some communications are filtered between sub-teams, and very important and not depicted on this chart are the communications happening inside each sub-team. Not all communications can be filtered. Some of the unfiltered communication is informal between team members, general communications to all team members, and other communication not specific to a sub-team. Most projects have breakout meetings related to resolving issues or drilling down into the details on a specific topic. Some of the unfiltered communication is necessary; some of it may not be. In addition, some of the sub-team resources could be working on other projects. In this example, a Steering Committee could be overseeing all projects, like a PMO board. Departmental Management VP/Director/Managers only get involved to resolve issues or risks and are generally not on the formal project team. SMEs could be used to seek advice on requirements or design and usually consulted sparingly. External resources could be vendor consultants. The sub-team that poses the most risk to the project is Shared Resources. Those resources might be required to execute a set of tasks, potentially working for a sub-team. An example might be installing a server, network equipment, database creation, or even establishing a firewall rule. Most likely, as the name implies, they are multi-tasking for a variety of initiatives, not necessarily confined to just project activity.

While Chart V depicts sub-teams mostly communicating on one (1) project, there are frequently situations depicted in Chart VI, where everyone on the team is multi-tasking on other projects. Resources are communicating within the project (shaded area) and the same for other projects as well.

 

There are not only the same number of internal communications happening as depicted on Chart V, but the same resources are communicating for other projects as well. This situation can add a lot of stress for certain resources and the entire project team. One can easily see why multi-tasking dramatically adds communications, increases complexity and risk to a project.

Conclusion

Communication on a project serves a variety of purposes and is critical for a project’s success. The entire life cycle of a successful project, from Initiation to Closure, depends on a variety of purposeful communications. In order to reduce complexity on a project, resources must be organized into smaller sub-teams which has the effect of reducing the total number of communications but, at the same time, adding value to the communication process by appropriately channeling and filtering the flow of information.

 

References

Spacey, John. “21 Examples of Project Communication.” Simplicable, Simplicable, 25 Oct. 2017.

https://simplicable.com/new/project-communication

Kiridena, S. & Sense, A. (2016). Profiling Project Complexity: Insights from Complexity Science and Project Management Literature. Project Management Journal, 47(6), 56–74.

MacCue, C. (2021, March). A Simplified Approach to Determine IT Project Complexity. Project Times. https://www.projecttimes.com/articles/a-simplified-approach-to-determine-it-project-complexity.html

MacCue, C. (2021, April). Part II – A Simplified Approach to IT Project Complexity. Project Times.

https://www.projecttimes.com/articles/part-ii-a-simplified-approach-to-determine-it-project-complexity.html