Easy in theory, difficult in practice

This article was originally supposed to have been based on a poll I conducted this week on schedule compression techniques. However, a discussion from a project management fundamentals course I taught was too compelling to not share!

While teaching the basics of the critical path method, I asked the learners whether it was possible to have more than one critical path in a project's activity network diagram. As the class understood that the critical path represents the longest sequence of activities from start to finish, they all agreed that this was feasible if you had two or more paths with the same total duration.

However, one of the learners indicated that one of their clients refuses to accept project schedules from contractors which show more than one critical path. When the learner told me who the client was, I was surprised as it is a well established, large organization.

I asked how he deals with the situation and he indicated that when the software they use calculates more than one critical path, they modify the scheduling logic within one or more of the paths to ensure that there is only a single critical path.

It is possible that the client is concerned that when a schedule has more than one critical path, there are likely fewer activities possessing float or slack and hence the potential for a delay to key milestones or the overall project end date is greater.

However, this is also true when you have network paths which are close to the same total duration as the critical path. I've seen cases where project teams and senior stakeholders focused so much on the original critical activities that they ignored the fact that sufficient delays had occurred to near-critical activities such that a new critical path emerged.

Regardless of the reason why the client had this requirement, such concerns shouldn't result in artificial changes to a properly-built network diagram.

Not liking the facts doesn't make them fake.

Similar to my previous article, this topic stemmed from a discussion I had with the learners of the PMP preparatory course I taught this week.

While presenting the project risk management knowledge area from the PMBOK framework, when I indicated that while in our daily conversations risks are usually threats there can be positive risks as well, I was met with some disbelief and skepticism.

In past article I've frequently quoted Dr. David Hillson's definition of risk as being "uncertainty that matters". That definition recognizes both threats and opportunities.

However, in my past experience I've almost never seen a group of stakeholders consider the upside of risks with their project. Very few of the companies I've worked with did a great job at managing threats to their projects so expecting their teams to go that extra mile and effectively manage opportunities might be too much of a stretch. I've even recall one sponsor telling me "We have little time on our projects to do more than complete the must-have deliverables and now you want us to think about what to do if things work out better than we expected?"

So I decide to do another poll in PMI's LinkedIn discussion group, asking practitioners to vote whether they did or did not consider opportunities in their most recent projects.

The results were a little surprising.

While the majority of responses (57%) indicated that the risk management focus was solely on threats I was expecting that number to be much higher.

The comments I received highlighted why positive risks are rarely referenced in practice.

• It can be difficult explaining this idea of positive risks (opportunities) to non PM people and this sometimes gets an eye-roll from my audience when explaining why/how we should exploit it.
• If you call it an 'opportunity', it will probably resonate more. A positive risk is not something recognized outside of the PM space.
• No, for one primary reason - the idea of positive risk is largely a pm/risk mgmt construct, and one the 'regular world' doesn't share or understand. Ask anyone to invest money and they'll ask 'is it risky?'. They're not asking for the probability that they will *make* money, they're wondering the likelihood that they'll *lose* it (the risk).

So perhaps it is time to lose the term "positive risk" from our parlance, and split opportunity management off from the project risk management knowledge area. While there is a strong overlap between the practices within these two domains, the perception of each is sufficiently different that separating them might encourage stakeholders to actively manage both the up and downside of risk.

Project management standards such as the PMBOK® Guide, Sixth Edition state that contingency reserves, which are established to offset the cost or schedule impacts of realized identified risks, are considered part of the project budget and cost baseline. As the project manager is authorized to spend the budget as planned, it is assumed that they have the ability to draw upon contingency reserves directly as risks are realized.

In a recent class discussion, most of the learners indicated that while contingency reserves were considered part of the project budget, project managers in their companies were required to seek some level of approval from senior management before they could draw upon that funding. This matches my own experience from the previous two companies I worked for.

So I decided to conduct a poll in the LinkedIn PMI Project, Program and Portfolio Management discussion group to get feedback from a larger sample of practitioners. That discussion group has over 300,000 members and I received just under 2,000 responses to the poll which is a good response rate given that the vast majority of members of such large LinkedIn groups rarely contribute.

Only 17% of the responders indicated they had full authority to draw down on contingency reserves. This poll also garnered a number of comments from the group and here are some of the more interesting ones.

• "Every company I worked for the PM required approval to access contingency funds."
• "PM needs to be given the "rights" to use their "authority" which generally is not the case in most organizations"
• "Agree, PMBOK is theory, real life business operations run differently in most cases"
• "The PMBOK is not living in the real world with respect to contingency reserves."
• "I think it varies depending on the type of organization/industry. For example, in construction industry Project Managers have much more authority in general and a lot of funds are on their disposal. Compared to that Project Managers in IT have much less authority and funds in their control. They generally have to request approvals even for smaller sums."

So, if in the majority of cases a PM needs to seek approval for contingency reserves, aside from artificially allocating funds to different cost "buckets", is there any real benefit in distinguishing between contingency and management reserves?

And if there is such a disconnect between what is in written in project management standards and how it gets practiced in the real world, should we continue to call it "standard"?

One of my parents' sayings which used to irritate me when I was much younger was "Act your age!". In those days, it was usually a critique of some immature behavior or action on my part.

As project managers, we usually are "acting our age" but might there be some benefits in channeling the child within us?

See the forest from the trees

Professional magicians sometimes have difficulty in fooling younger children with their magic tricks. While an adult can be easily misled by sleight of hand, small children haven't learned to focus their attention on a single thing for long and are more likely to witness the magician's misdirection.

On our projects, it can be easy to get tunnel vision.

A critical issue or a variance in a key constraint might command all of our attention but we could end up missing something else going on which could cause us bigger problems down the road.

Ask "Why?" (or "Why Not?")

For parents, one of the less endearing traits of many small children is their incessant questioning of each and every decision. Through a combination of ignorance and a belief that anything is possible, kids are seldom content with the response "Because I said so".

As we get older, we are conditioned to accept what we hear, especially when it comes from a respected source.

Asking "Why?" or "Why not?" is a great way to surface invalid assumptions and to challenge long standing practices that have ceased to be valuable.

Be curious

Most of us have heard the saying "Curiosity killed the cat". But not everyone is aware that the full saying is "Curiosity killed the cat, but satisfaction brought it back".

Kids are curious about absolutely everything and will go out of their way to experiment and explore. As we mature, we create boundaries for ourselves. John Cleese's line from Silverado "Today my jurisdiction ends here" could be the mantra for many of the project managers I have met.

But such behavior, while safe for us, might reduce the creativity of our team and, like not asking "Why?", might prevent us from improving project outcomes.

Emphasize fun

If there's one thing which small children will prioritize, it is having fun. As we get older and our responsibilities increase, we lose sight of the importance of having fun in the work we do. While there are always going to be challenges with projects, seeking opportunities to make our work enjoyable will reduce our stress and increase the engagement of our team members.

So when managing projects, its okay to NOT act your age!

When we consider the benefits of non-solo working approaches such as pair programming or mobbing, the ones which normally come to mind are related to improvements in the speed or quality of delivery. The old adage "two heads are better than one" applies as we are usually able to get more work completed faster and with fewer defects. And by injecting variety by having participants alternate between different roles frequently, we also reduce the likelihood of fatigue.

But an HBR article this week on the topic of disengagement caught my attention. The author suggested that finding someone to hold us accountable increases the likelihood of our completing an activity. She highlights the benefits of body doubling where we work in the physical or virtual presence of another. By working with someone as opposed to by ourselves, it reduces the chance of procrastination and distraction.

While I hadn't thought about this before, it makes perfect sense. By pairing up with someone else who can see what we are working on, it is a lot harder for us to tune out. The discussions we will have with our partner will also help to keep us focused and alert so long as both of us are not likely to get distracted by the same thing - this is where strategic pairing where we pick partners based on diversity of thought and background might help.

But without psychological safety, we will be less likely to explore creative ways of getting the work done and we might also lack the courage to provide direct, compassionate feedback to our partner. This is quite likely when the people we work with are at different levels of seniority, experience or influence than us.

Many of the same practices which apply to building psychological safety within a team could be applied in the context of pairing. We could take some time before we start to work with a new partner to define a few ground rules for how we will work together including how we will provide feedback. At the end of a pairing session, take a few minutes to share our perceptions of how the session went and what we might want to adjust going forward. And solicit and be willing to share our working anti-patterns so that we can watch out for one another.

So while there are many benefits to be gained by engaging in non-solo work, psychological safety is a prerequisite for realizing most of them.