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.

A question was posed on my Mastodon instance this morning about combining the roles of Product Owner and Agile Lead (e.g. Scrum Master). The requestor felt that this was a bad idea but wanted to get feedback on whether it was, in fact, possible to do so and under what conditions would it not cause problems.

To answer the question, we need to understand the responsibilities of each role.

The Product Owner has the responsibility of collaborating actively with stakeholders to help them prioritize all the potential needs and wants which might be addressed by the product or service. They are also expected to spend significant time working with the delivery team to ensure they have a clear understanding of these needs and wants and to provide ongoing feedback on product ideas and completed work items by the team.

The Agile Lead is responsible for supporting the team in becoming as effective and efficient as they can be. While the role might facilitate delivery events (e.g. daily coordination events) for the team, their greater value is in the positive changes they are able to catalyze outside of these events. While they are expected to have sufficient delivery expertise to advise the team when they need assistance, the team is expected to define their way of working.

Based on these two sets of responsibilities, there are two main concerns with having a single individual play both roles: knowledge and capacity.

An effective Product Owner is expected to have sufficient product domain knowledge and organizational awareness whereas an Agile Lead is expected to have sufficient breadth and depth of delivery experience. It is rare to find an individual who ticks all of these boxes.

Most of the Product Owners I've worked with are overwhelmed just in their roles with the responsibility of spending enough time engaging with stakeholders and understanding product domain changes along with supporting the team daily. Adding the Agile Lead responsibilities to this mix usually means something will slip which could result in valuable input into product feature prioritization being missed or the team being neglected.

So is there any circumstance where the roles would be combined?

When a new company is formed, unless the leader has sufficient confidence, funding and foresight to fill positions appropriately right away, it is common that the leader plays both roles for at least the first product or service launch. However, in most situations, as the company grows, the leader recognizes fairly quickly that they need to step out of the daily tactical work of delivery and will staff the two roles.

Are there other contexts where you've seen this work? If so, leave a comment below...

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.

When I first read it, I found that one of the more interesting characters in Tom Clancy's debut novel, The Hunt for Red October, was the political officer, Ivan Putin. His role is to ensure that the leadership and crew of the nuclear submarine were acting in alignment with the values and principles of the Soviet Union. He acts independent from the rest of the crew as his reporting relationship is to Moscow and not to the submarine's leadership team. While the role is expected to help the crew navigate the complex set of rules and regulations, Ivan proves to be more of an impediment than an asset.

What does this have to do with project management, you ask? At the risk of offending some readers, it is about political correctness and cancel culture.

As I approach my mid-fifties, I recognize that there are behaviors, beliefs and phrases which were generally acceptable when I was growing up which are no longer so. And while I am comfortable receiving constructive feedback from others on how I could modernize my mindset, I also recognize that if I were working full- time in a project management role I might accidentally violate one of our new norms with potentially severe consequences to myself.

These day many folks no longer remember Hanlon's Razor.

When leading projects, as the number of stakeholders increases the likelihood of causing unintentional offense will also increase. To prevent "cancellation" of project managers and their team members, perhaps we need a new PCO role to educate and help them avoid committing such errors. While that acronym normally stands for Project Control Officer (which is a support role similar to a Project Analyst or Project Coordinator) it might now stand for Political Correctness Officer.

Should our profession evolve (?) to warrant such a role, it would be advisable to remember the treatment which Ivan Putin received at the hands of Captain Marko Ramius.

(Before you correct me for misstating the iconic quote in this article's title, read ahead)

Over the past week, I've seen a number of posts from different practitioners on the Mastodon.world instance complaining about agile.

Here are a few of the examples I've read:

• Agile events or meetings taking up most of the productive time each day
• User stories not providing an understanding of a user's needs and wants
• Continuous delivery of changes resulting in significant unplanned outages
• Sprint burndown charts showing zero completed work till the very end of a sprint

Now if someone's experiences with adaptive delivery are limited to such examples it is no wonder that the reaction would be "Agile sucks!"

To which I respond #NotMyAgile.

Until someone invents a bracelet which delivers mild shocks to leaders and team members who ignore the basics of adaptive delivery, adoption challenges will persist.

And the more concurrent teams an organization has, the greater the likelihood of this unless each team has sufficient support and guidance to help them through these growing pains. An in the early days when there are very few people who know what to avoid, their capacity should be the constraint on how much work is done using agile approaches.

But barring that, team members can ask themselves the following question when they, the team as a whole or their leaders are deciding on what to do: "Does this result in greater value delivered to our customers, improvements to the quality of what we are doing or will it help improve our engagement or motivation?".

If the answer is "no", speak up.