Easy in theory, difficult in practice

I've just finished reading The Revenge of Analog and The Future is Analog by David Sax. In both of these books, he provides compelling arguments supported by a number of case studies taken from different domains to show that while some might envision the future as becoming more and more digital, we will continue to cherish and yearn for analog experiences. The latter of the two books was written during the COVID-19 pandemic where most of us underwent a rapid acceleration into a digital future and in most cases, didn't like what we experienced.

So what does this have to do with project management, you ask?

Ever since ChatGPT hit mainstream consciousness in November 2022, a frequent topic of discussion in most project management online communities has been what progressive improvements in A.I. capabilities will mean for the profession.

As with any other disruptive change, there are some practitioners who go all in on the future for A.I. technologies whereas others marginalize their potential.

My opinion hasn't changed.

So long as the scope of projects is delivered by human beings, I find it unlikely that we will abdicate leadership responsibilities to a machine. As unique endeavors, projects require team members to be creative, innovative and able to react in a timely manner to surprises. I don't see automation being able to inspire the level of engagement and follow through required to deliver even moderately complex projects.

What I do expect is that A.I. advances will provide much richer decision support than is currently possible. Whereas there are specific use cases for such technology today such as estimation and forecasting within specific industries, I feel the scope of such support will increase as A.I. tools are able to proactively harvest relevant data sets, process those in real time, and provide probability-based forecasts on the relative merits of different options.

I also am confident that A.I. will be able to substantially (if not fully) eliminate rote, administrative work from the role. As the tools learn how a given project manager works, the quality of auto-generated reports and responses will improve. Similarly, A.I. will help to keep teams safe by providing guidance, evidence gathering and documentation capabilities for compliance and governance purposes.

And I view this as a good thing as it means project managers will find themselves with much more time to focus on analog activities such as engaging effectively with their key stakeholders, building high performing teams, and keeping their eyes on the road ahead rather than spending half or more of their time looking in the rear view mirror.

And that will make the profession that much more rewarding to its practitioners.

After taking a break from writing for a few weeks, I was planning to write about the importance of conversation in the work we do, but a late day Mastodon toot caught my attention today: "Gantt charts are lies". Based on the hashtags accompanying the post, the author works in the software development domain using adaptive approaches.

While I can empathize with the frustration underlying the post, it resonated with me in the same manner as if someone had written "Flat head screwdrivers are useless". While we might wish the folks who chose to use a flat-headed screw had used a Phillips or a Robertson instead when trying to unscrew one which has a messed up slot, depending on what you are trying to achieve, a flat head screwdriver might be just what you need. Apart from driving screws, I have found its value as a small pry bar is understated. One example has been to safely remove the sheet metal cover for my furnace filter which has extremely sharp edges.

When Henry Gantt had originally adapted the chart which is named for him, it had been used to document the activities and timelines for past operational work. Somewhere along the line, it started to be used as a tool for planning, tracking and communicating schedule information on in flight or future projects. This included adding details such as dependencies and baseline information.

The modern Gantt chart has benefited greatly from automation as prior to the introduction of rudimentary scheduling applications, they had to be redrawn any time changes occurred.

Like any tool, misusing a Gantt chart will cause problems and an experienced project manager should have the wisdom to avoid those.

Similar to a work breakdown structure, the level of detail in a Gantt chart should be based on the degree of confidence the team has in remaining activities as well as on the desired degree of monitoring of the work being done. While work whose delivery is highly predictive might benefit from the use of a detailed Gantt chart, one where a highly adaptive approach is required will necessitate the use of a chart at a very high level of detail or a completely different method of visualizing schedule information.

And like most other project management artifacts, if the frequency of updating the Gantt chart is much lower than the frequency of material changes to the schedule, the information presented can't be trusted.

Does this mean we should stop using them?

In the author's context, perhaps the risks of using a Gantt chart outweigh its benefits, but pragmatism is required to understand that they can still be useful in the right contexts and when used in the right manner.

Whether you have taken a foundational project management course which covered practices for predictive approaches or you were studying to take the PMP exam, you are likely familiar with schedule network diagrams. However, like many tools and practices in the PMBOK framework, just because we learn about them doesn't mean we will use them.

If you skip creating network diagrams, you could miss out on these benefits.

1. Building a network diagram is a fun team building exercise. Whether you do it on a white board using sticky notes or in a virtual collaboration platform, it provides a good opportunity for team members from different functional areas to figure out how we are going to get from start to finish.
2. It increases the team's buy-in to the project's timelines. By contributing towards the creation of the diagram, there is a greater sense of ownership in the final schedule.
3. It captures the scheduling logic in an easy-to-understand and explain fashion. Walking a stakeholder through a detailed Gantt chart, especially when there are multiple parallel network paths can be an exercise in frustration for both you and your audience!
4. It makes it easier to notice if you have a scheduling error. Once a few hundred tasks are entered into a scheduling tool and dependencies have been added, locating a missing activity can be like trying to find the proverbial needle in a haystack. On the other hand, navigating activities in a network path on a network diagram is more intuitive and missing activities and unnecessary or missing dependencies can be identified quicker.
5. It makes schedule creation more efficient. If you have ever witnessed a project manager struggling to enter data into a scheduling tool in front of their team, you will appreciate the reduced waste which is generated when the same project manager can take a completed network diagram and enter it offline into the tool and then share the final product with the team.

In some situations, skipping a network diagram might make sense.

If your project lends itself to a fully adaptive approach and work item sequence is changing frequently, while you might need to incorporate an understanding of dependencies when prioritizing the backlog or queue of work, a network diagram would get out of date very quickly. If the project is simple and has a minimal number of network paths, a network diagram might be overkill. Finally, if your project is very similar to a historical one and you can reuse the schedule from that previous project with minimal effort, a network diagram might be unnecessary.

But other than these situations, the benefits of producing a network diagram as the primary input to your project schedule will be well rewarded.

Regardless of what type of work your team does, work boards can be a helpful tool. But just because they can be helpful doesn't mean they are always implemented well.

The most common mistake is when teams don't keep their work boards up to date with the actual status of work that is being done. Increasing transparency is a great way for stakeholders to understand what is going on and to increase their level of trust in teams. But if the information being presented is out of date or inaccurate, it reduces the team's credibility and increases the likelihood of these stakeholders asking for separate, redundant status updates. When a work item changes status the work board should be updated immediately. For example, if the team has capacity to pull a new work item from their work queue, the item should be moved on the board just before work actually commences on that item.

Another challenge relates to whose responsibility it is to keep the board up to date. The moment it becomes the job of a coordinator or lead to do so, we reintroduce the overhead of having someone chase team members for status updates. I have seen Scrum Masters who will take time out during a daily Scrum/standup event to update the team's work board after a team member has mentioned that it doesn't accurately show the status of their work items. Everyone on the team is responsible for updating the work board based on the work they are doing.

If the work board columns are aligned with the roles of team members, that is not ideal. A work board's columns should reflect the progressive value being added to a work item till it is complete and very rarely would this evolution map cleanly to the team member's individual roles. The Goldilocks' principle also applies to the columns. Have too few, and stakeholders may not get sufficient visibility into work item status and work items might stall for longer than desired without impediments being addressed. Set up too many and it encourages silo-thinking on the part of team members and can result in increased work in progress.

Having a dedicated blocked column is also not a good idea. Blocked is not a normal step in the evolution of a work item and by moving partially completed work items over to a separate column it can affect flow as a natural tendency of a team might be to pull more work items from the queue rather than unblocking the stalled work item. A better approach would be to highlight blocked items within their active work columns.

The next sin relates to work item aging. Ideally, once the team has completed a reasonable number of work items, they will be able to determine what is a reasonable amount of time for a work item of a certain size to remain active. If there isn't some way for the team and stakeholders to see how long a work item has remained in an active column (i.e. something other than Not Started or Done), then it is hard to proactively determine whether it has been aging longer than it should.

Finally, cluttering a work item card with too much information increases the potential for stakeholder confusion and for inaccurate data. At the bare minimum, a work item card should contain the description of the work to be done, key dates (e.g. requested, started), whether it is blocked or not, and which team members are working on it. Anything beyond this can be helpful, but also increases the effort required for team members to keep information current and accurate.

Work boards can be a powerful tool to help a team visualize their work flow, but as always, with great power comes great responsibility.

The PMBOK® Guide, Seventh Edition defines a Work Breakdown Structure (WBS) as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables".

While this definition provides a good understanding of what a WBS is, it doesn't provide guidance on how to organize the structure of a WBS. This is helpful as it provides flexibility for teams to determine what is the most appropriate means of doing so for the context of their project.

Although there is an infinite variety of projects, I've found three approaches used by most teams who develop WBS's:

• Deliverable-oriented - each of the top-level components of the WBS represents a key deliverable, and the subsequent levels focus on the decomposition of those deliverables to an appropriate level of detail
• Phase-oriented - each of the top-level components of the WBS represents a phase or stage in the life cycle of the project, and the subsequent levels focus on the decomposition of the outputs of each of those phases or stages
• Responsibility-oriented - each of the top-level components of the WBS represents a contributing stakeholder to the project's delivery, and the subsequent levels focus on the decomposition of the outputs produced by each of those stakeholders

A deliverable-oriented approach helps to focus the team on everything required to complete each deliverable without worrying at that stage about who does it or when it would be done. This can work well for projects where the full scope of a project can be decomposed early on, but can be challenging when a rolling wave approach is taken unless there is a clear identification of planning packages which need to be elaborated at a later date.

A phase-oriented approach works well with a rolling wave approach as the team only needs to focus on what will be completed in the upcoming phase. However, there is the risk that the team might miss key scope elements for specific deliverables as they won't be focusing on decomposing a single deliverable at a time.

A responsibility-oriented approach works well when there are multiple stakeholders and there is the need to have a clear segregation of responsibility for planning and execution between them. It suffers from the same risk as the phase-oriented approach, but more severe as there is the potential for deliverable sub-components to be assumed by each stakeholder to be the responsibility of another.

I ran a poll in PMI's LinkedIn Project, Program and Portfolio discussion group as well as the ProjectManagement.com community to gauge the distribution of usage of these three approaches. Out of the combined 141 responses, 57% were using a deliverable-oriented breakdown, 28% used a phase-oriented approach and 9% used a responsibility-oriented one. The remaining 6% indicated they used another approach but when I reviewed the comments those participants had submitted, it seemed that they were just using a combination of these methods rather than something entirely new.

While the WBS is commonly-used tool with projects following a predictive life cycle, this doesn't mean that those following an adaptive one can't benefit from it. If we consider a user story map, it is just a WBS constrained to two to four levels and developed in a progressively elaborated manner. With a story map, the structure might be persona-oriented or theme/capability-oriented.

Regardless of how your team chooses to decompose the scope of work on their projects, a WBS or a variant thereof should be considered as a valuable tool in their toolboxes.