Voices on Project Management

Kevin Korterud

Life is full of surprises…they always seem to show up unexpectedly. As project managers, we rely on our PMI certification training—as well as our experiences—to both detect and mitigate the effects from surprises, such as missed milestones, new regulatory requirements and quality issues.

But what happens when the surprise turns out to be a short-term outage of the project manager? This can come about for a variety of reasons, including family, health and other personal matters. A recent health issue that took me away from a project for a few weeks got me thinking about how to address this special type of surprise.

In my early career days on projects, the short-term loss of a project manager meant the project was typically put on hold until the PM returned. In today’s complex, high-speed technology delivery environment, stopping a project is less viable due to market needs, dependencies, specialized domain knowledge, engaged suppliers and many other factors.

So, in addition to all of the usual risk factors, one has to consider a risk mitigation plan for the project manager should a surprise occur (this plan also applies to other key roles such as the delivery, test and PMO leads).

Let’s look at a few questions to help you prepare for surprises when they occur to the PM role:

1. Who could be a backup PM? The process of finding a backup project manager usually falls into two categories: easy…and not so easy. If there are project track leads with prior PM experience, rank order them as to the size and complexity of the prior projects they have managed. Discuss the project(s) with them and create a plan for the areas that you look to build out as part of their duties in being a backup.

If nobody on your project has any prior PM experience, another option could be to consider an existing program management office lead. With today’s complex program office operations, it’s common to have program management office leaders with prior project management experience. They could assist as a backup PM.

2. When should you have a backup PM? As one never knows when surprises will occur, the best time to identify a backup project manager is during mobilization of the project. By having a person identified early in the project life cycle, it better positions the backup PM to be successful should a surprise occur.

If it’s not possible to identify and develop a backup at the start of a project, consider an approach that takes advantage of the upcoming or current phase of the project. For example, if the project is headed into the design phase, consider your functional lead as a potential backup. Just be cognizant of the additional burden the backup PM role places on an existing team member; consider additional program office resources to help with the execution of project operational processes.

3. How do you make someone a backup PM? After selecting a backup, create a list of topics to educate them in the many facets of the project. This can start with operational topics such as risk/issue reporting, status report and work planning, and cross-training. From there, they can start to be immersed in domain-related topics with the project (e.g., how does a month-end financial close work?). The domain-related topics may require some specialized training if they have not been exposed to them before.

Keep in mind that the backup PM still has their core project duties to execute, so they should not be overburdened with immersion activities. Keep the window for these activities to a few hours each week, and continue them through the life of the project. It is also helpful to bring the backup PM along to attend key project meetings to make them aware—as well as to make other project team members aware of their provisional role in the event of the unexpected.  

The days of having a project being placed on hold due to the short-term loss of a project manager are long behind us. In particular, with the highly integrated technology project ecosystem that exists today, the stoppage of one project can impact several others—thus affecting the overall progress of a company portfolio.

Knowing who your backup project manager is offers a mitigation path when surprises occur. In addition, it’s also an essential form of career building by exposing the backup PM to the next level of delivery stewardship.

How have you selected and groomed a backup project manager for your delivery efforts?

By Lynda Bourne

Ptolemy's world map (source: Wikipedia)

Do modern project managers and their clients rely on their charts and reports too much? We all know that project schedules, cost reports, risk assessments and other reports are produced by sophisticated computer software, these days increasingly enhanced by artificial intelligence. But does this sophisticated processing mean the charts are completely reliable?

The modern world is increasingly reliant on computer systems to direct and control many aspects of life—from self-driving cars, to autonomous warehouses, to the flight control systems in aircraft. But can this reliance on computer systems be translated to project controls information, or do we need a more ancient mindset?

Modern navigators rely on the accuracy of their GPS to know exactly where they are and where they are going. The autopilots are better than the human, but the data being used is precise and validated.

The same level of reliability and accuracy cannot be applied to project controls data. Every estimate is an assessment of what may occur in the future based on what happened in the past. Even when a sophisticated risk model is built, the P80 or P90 result is based on subjective range estimates taken from past events.

The future may unfold within the expected parameters, and it may not. We simply cannot determine the future in advance. While the quality of the project predictions is based on the quality of the data being used in the modelling processes (and the only guaranteed fact is the model will be incorrect), predictions do not control the future. The key question is: How useful are the models in helping navigate the project through to a successful conclusion? [Remember GIGO (garbage in, garbage out)?!]

In days gone by, navigators did not need accurate charts and satnav systems to reach their destinations. The Viking and Polynesian navigators crossed thousands of miles of open ocean to land on small islands using observations of the natural environment and tacit knowledge passed down from earlier generations. They knew certain seabird species only ventured relatively short distances from land, how clouds formed and changed over land, etc., augmented by primitive technologies.

Fast-forward a few centuries, and the early European navigators (Columbus, Magellan, Drake, Cook and countless others) had steadily improving charts that made navigating easier—but they also knew the best charts available were not accurate. The general shape of the world had been mapped since the time of Ptolemy (circa 150 CE), and as better information became available, better maps and charts were created. But these are still continuing to be improved into the 21^st century.

So how did people navigate the globe without accurate maps and charts? I suggest there were four core elements in the approach, all of which can be applied to modern project management:

1. Recognize the chart is a guide, get the best possible chart available and use it to plan your course—taking into account as much additional information and tacit knowledge you can access.
2. Then, assume the chart is incorrect. Keep a sharp look out for unexpected issues and dangers, adjust course as needed, and keep collecting information along the way. You only run into the rocks you do not see!
3. Keep adapting and adjusting your course to make the best of the current circumstances, using both known and emerging information—the destination does not change, but how you get there may.
4. Then use the new information you have gathered to update the chart to benefit future voyages in the same direction.

To move from assuming controls information is correct, to seeing it as a useful guide that can be improved as better knowledge becomes available, requires a paradigm shift in thinking that sits comfortably alongside many of the concepts of agile.

The future is inherently uncertain and we can learn a lot from the way early navigators used imprecise charts to sail the oceans. Navigating the globe in past centuries and leading a project to a successful conclusion are both risky endeavours; this fact needs to be accepted, and the risks minimized by using the best available charts—while being aware of their limitations.

What do you think?

As part of starting my technology career, I augmented my undergraduate degree in computer science with a minor in economics. Over the years, I began to appreciate more the inherent wisdom of the demand and supply relationships as it pertains to labor forces. In particular, the laws of economic supply and demand are playing themselves to new heights in these uncertain times.

We see it every day in the news: Jobs by the thousands of all types are going unfilled with nobody stepping forward to fill them. In our industry, we are seeing multiple factors converging to create difficult times for project and product managers. The exponential growth in technology, changing demographics in work forces as well as COVID-19 have all greatly impacted what we do on a day-to-day basis.

For project and product delivery, I am observing that labor shortages that impact our delivery efforts take on two different forms:

1. For new projects and products, the ability to find new resources is extremely difficult. Staffing durations are taking longer and it’s ever more challenging to find skilled, experienced team members.
2. In addition, existing project and product resources are being consistently overcommitted, which leads to multiple negative outcomes—including their potential loss as they explore other options due to burnout.

As a project and product manager, these market conditions create a confounding set of risks that need some refreshed thinking in order to mitigate their impacts. Here are a few of my thoughts on ways we can manage around these challenging times:                                                           

1. Up Your Game on Scope, Schedule and Resource Management
One of the hallmarks of a great project manager is their ability to synthesize threats to scope, schedule and resources. They rigorously examine and take action to curtail creeping scope, aggressively monitor planned versus actual schedule progress, as well as frequently check resource utilization.

In addition to giving more emphasis to these areas than ever before, project managers need to look beyond their project for external threats. By taking more of a portfolio manager mindset and looking for external threats including other projects, they can better anticipate and address challenges to their own delivery commitments.

For high-speed, iterative agile product delivery, labor shortages make for even more challenging times. One of the benefits of a dedicated set of resources for an agile product team is that over time they reduce the learning curve and improve decision-making efficiency. Swapping resources in and out of agile product delivery due to labor shortages creates damaging disruption to both schedule and quality. This environment compels agile product managers to be even more vigilant when it comes to managing scope, schedule and resources.  

2. Get Back to Basics
As the complexity of project and product delivery grew over the years, the amount of supporting reporting, analysis and review meetings grew in lockstep. In addition, the complexity of indicators, metrics, narratives and other project metadata increased as well—the intent being to quantitatively identify delivery volatility before it becomes an issue.

While the increased frequency and depth of examination improves stewardship and has helped with early detection of delivery volatility, in these times there may not be enough capacity to warrant this level of detail.

To help mitigate impacts of labor shortages while not adversely impacting delivery, take a good hard look at the project and product metadata that is currently being produced. For the level of uncertainty and risk on your project or product, can the frequency of reporting, analysis and review meetings be reduced in order to spend more time on activities that directly impact delivery?

For the depth of metadata, explore simplified methods for conveying progress against a plan. For example, the use of additional done/not done milestones to measure progress would take less effort than gathering timesheets to calculate total effort. Rationalizing where it makes sense, the frequency and breadth of supporting metadata creates more capacity for direct project and product activities.

3. Restore Real-Time Individual Engagement as a Norm
People are both the most valuable and the most fragile when it comes to project and product delivery. One of my post-graduate professors in an organizational design class once shared, “The greater the level of uncertainty, the closer the level of interaction is required between people.” Loosely translated for modern times, this means: Don’t try to solve complex problems by email.

Pre-pandemic, there was a lot of personal interaction in an office or site; these days, we rely on online collaboration tools as a primary means of connection and communication. Despite the ability as a group to remotely connect audibly and visually through the use of these tools, difficulties remain in terms of the effectiveness and efficiency of personal engagement, especially at an individual level. Individual connection has always been a means of identifying both new ideas as well revealing challenges that may not arise in a group setting; all the more reason to make it an increasingly frequent activity when managing projects and products.

While modern times present new challenges, it’s still possible to connect on a person-to-person level. Outside of the normal cadence of group meetings, set up recurring individual connection sessions with team members. These can still be done with collaboration tools—but they have all the advantages of what private conversation can provide. I’m finding these individual meetings have a great propensity to really help us understand the underlying dynamics of project and product delivery. (If you happen to live in reasonably close proximity and abide by any local regulations, that doesn’t mean an espresso in person to stimulate conversation would be out of the question!)

These are indeed challenging times, the likes of which I have never before seen in my project and product management career. Labor shortages as well as volatility from resource overcommitments are all causing us to rethink our day-to-day activities on how we interact with people. While we can long for the days when walking down the hall in an office to connect with a team member was the norm, we as project and product delivery managers still need to take steps to overcome these challenges in our drive for successful delivery outcomes.

I welcome any comments on what others are doing to help reduce the impact of labor shortages with creative project and product management techniques. Share your insights below!

By Lynda Bourne

How much detail is too much? Traditional views tend to favour a management approach built on the assumption more detail is better, and to a point this is undoubtedly correct, insufficient detail in a plan of any type is a sure way to fail – ‘just-do-it’ at the overall project level does not help.

But looking at the ‘Coastline Paradox’ and using the length of a coastline as a synonym for the duration of a project suggests there is a point where too much detail is counterproductive.

The coastline paradox states that as you increase the detail by using smaller units of measure, the measured length of the coastline increases. If you use a small enough unit of measure, the length becomes infinite. For a more detailed explanation see: The Coastline Paradox Explained  https://en.wikipedia.org/wiki/Coastline_paradox

So, what does this mean for project controls and project management?  No one navigating a ship into a UK port would be happy using a map where the smallest measurement was 50 km, significantly more detail is needed, but they do not need absolutely everything about their intended destination. What’s needed is useful information at an appropriate level of detail, the same goes for you, when navigating your car in a strange city[1]:

Finessing project plans to present useful information at the right level of detail is not easy, decisions have to be made! 

Take a typical risk register, if you tried listing every conceivable risk, the document would emulate the ‘coastline paradox’, and be of almost infinite length, which means the register is never finished and the project does not start.  Conversely, miss one or two significant risks and the project team may have a very unpleasant experience, possibly causing the project to fail. Pragmatic guidelines about the risks to be considered are needed and these have to be tailored to the project.  Similar guidelines are needed for the schedule, cost plan and all of the other sub-plans needed for a project.

How much detail do you feel is appropriate for your projects?

[1]  Image source: Understanding Design, The challenge of informed consent. Dr. Lynda Bourne, 27th November 2014; maps of North Sydney

By Kevin Korterud

When I first started as a technology project manager, it was not uncommon for a project to have just one deliverable. All of the tasks in the project created the path that led to the single deliverable, which in many cases was a program, report or screen. Life used to be so easy!

As projects became more complex, the need grew for multiple project deliverables that lead to a complete solution. Deliverables now represent the “building blocks” that form a key foundational element of any project.

Whereas scheduling tasks is a fairly straightforward process that involves capturing durations, resources and successor/predecessor networks, scheduling deliverables comes with its own set of complexities. Deliverables don’t always behave in a linear manner like tasks­—so special considerations come into play with their scheduling. In addition, there are typically people and expectation factors that need to be part of a deliverable scheduling model.

Here are three essential reminders for properly scheduling deliverables:   

1. Deliverables Involve a Package of Tasks

Whereas tasks are singular items that stand alone in a work plan, deliverables have a few extra packaging steps in their path to completion.

One of the most dangerous scheduling mistakes to make with deliverables is to have a single task in a work plan that represents the deliverable. This is because of the variation in duration and effort that it takes to complete a deliverable.

Deliverables have a natural path to completion that involves a package of tasks, whose dynamics differ from normal tasks in a work plan. Project managers need to include these extra tasks that chart the lifecycle of a deliverable from initiation to completion.

For example, a sample set of deliverable task packaging would appear as follows:

You can tell from the above table that prior to scheduling deliverable task packages, project managers need to have a deliverable governance process in place. A deliverable governance process that identifies specific deliverable reviewers and a single approver are key to the effective scheduling of deliverables.

2. Deliverables May Require Task-like Linkages

We are all familiar with creating predecessor or successor linkages between tasks to form a linear series of work needed to achieve an outcome. Those linkages serve to drive schedule changes as prevailing project conditions occur.

Deliverables can require the same sort of linkages found in tasks. For example, if you have deliverables that lead to the creation of a marketing web page that involves multiple supplier deliverables, selected tasks in the deliverable package can contain task linkages. These linkages impose conditions which determine the pace at which related deliverables can be completed.

Let’s say there are three design documents from different suppliers required to create an overall design document. The build of the overall design document cannot finish before those three supplier design documents are all approved. So in the work plan, delays and schedule movements in the supplier design deliverables will drive the true completion date of the overall design document.

3. Resource Availability Impacts Deliverables

In addition to the scenario of having deliverables with dependencies, it is just as likely to have a set of deliverables that do not have any dependencies at all. These deliverables need to be completed by the end of the project but do not directly figure into the final outcome of the project. These are often process improvement deliverables that are needed for future projects that are not ready for execution.

When a project manager has a slate of unrelated deliverables, the optimal approach is to bundle them into agile-like sprints. The content of each deliverable sprint is determined by a balance of resource availability for the people who build, review and approve deliverables, as well as any form of relative priority. For example, if deliverable reviewers have low availability during a scheduled deliverable sprint, those deliverables can be pushed to a subsequent deliverable sprint.

Priority can also determine the content of deliverable sprints. Higher priority deliverables would displace lower priority deliverables to future sprints, even if work has begun on those deliverables. For example, if there is a strong need for a certain tool to be used by multiple projects, those deliverables would move into the current deliverable sprint. The deliverable sprint process allows for agility, while balancing value created from the deliverables.

As I shared earlier, life was so much easier when projects created one deliverable. Different times demand different approaches to managing deliverable schedules—especially on large transformations where there could be hundreds of dependent and independent deliverables. The last thing anyone wants to do is insufficiently manage deliverables: Leaving out one of those “building blocks” might cause the house to fall over.

What tips do you have for deliverable scheduling in today’s project ecosystem? Share your thoughts in the comments below.