Easy in theory, difficult in practice

When Fred Brooks Jr. wrote The Mythical Man Month, he provided project managers with the valuable caution which later was named Brooks' Law: "Adding manpower to a late software project makes it later".

While there are always exceptions, this statement is generally true. It is also applicable to most types of projects, not just software development ones.

The supporting reasons for Brooks' Law are well understood but unfortunately forgotten by project managers and senior stakeholders when delays occur.

Procuring and onboarding new team members will distract existing ones who should be focused on completing critical activities. It also requires more effort to keep everyone on the team aligned and increases the risk of personal conflict or other interpersonal sources of delay when we have more team members. And, if the majority of the remaining activities are not effort-driven, adding people won't help to accelerate them.

But does the complementary hypothesis of adding funds to a project which is forecast as completing over budget will make it go even more over budget also hold true?

Similar to Brooks' Law where it won't apply if the project was under staffed to begin with, an exception would be if the project had an inadequate budget to start with as a result of under estimation, under funding or insufficient contingency reserves.

But when a project received sufficient funding to deliver the original approved scope why might addressing a negative cost variance by boosting the budget be the wrong thing to do?

If the variance relates to under performance, low productivity or a high cost of poor quality, then adding more funds to the budget might encourage more of the same and the variance is likely to increase. If the variance is caused by scope creep, then providing more funding might result in it being used as a slush fund by stakeholders for getting additional scope.

The forecast at completion might also be suspect. If a forecasting assumption is that historical performance will persist, is that supported by the risk profile of the remaining activities? If things are expected to get easier then adding funding will just generate unnecessary opportunity costs for the organization.

Sponsors and senior stakeholders usually tend to be more open to adding people rather than funding for troubled projects which is why this situation is less common, but when it does, we need to understand why the cost variance occurred and also how the forecast at completion was determined.

One of the clichés you will run across if you read enough articles or watch enough videos about agility is that we should be using the term as an adjective rather than as a noun. Here are a couple of examples of this misuse.

"We are doing agile"

Agile is an umbrella term for many concepts aimed at delivering value, improving quality and making people awesome. But once we start talking about "doing agile", it usually implies that the focus has shifted from the outcomes we'd like to realized to the tactics of how we plan to realize those outcomes. Once that happens, the next step is usually to emphasize those tactics more than what they are helping us achieve. Never forget, "Individuals and interactions over processes and tools".

"My agile is better than your agile"

A single set of agile practices, roles, tools and techniques may be the right answer within one work context but could be less effective in a different one. Once we start to invest in a specific framework or methodology by taking courses, earning certifications or by participating in echo chamber communities focused on our framework of choice we start to treat every initiative as a nail for our (sole) hammer.

But let's not kid ourselves. Misunderstandings can also happen when we treat agile as an adjective in the wrong manner.

"I am managing an agile project" or "I am an agile project manager"

Unless your project gains sentience it can't be agile. Similarly, referring to yourself as an agile project manager might make someone ask who would want to be a non-agile project manager.

Even calling something an agile practice, tool, role or artifact isn't accurate. That implies that these might not have existed prior to 2001 and are only of use on those projects which are being delivered using an adaptive approach. Many so called agile practices emerged from lean, DSDM, Scrum, XP and other precursors to the Manifesto.

"I want to use/learn THE agile methodology"

This is on par with the "my agile is better than your agile" myth as it implies that agility is achieved by following a single recipe.

So what are some better uses for the term? How about "being agile" or an "agile life cycle"? The former treats agility as a characteristic or trait of an individual, group or organization which can be assessed objectively. The latter refers to the approach taken to deliver value incrementally and iteratively to our stakeholders in contrast to a predictive life cycle.

If it sounds like I'm quibbling over a minor semantics concern, words do matter and when folks refer to agile inappropriately it can often be a symptom of deeper issues.

The concept of tailoring has been referenced in all editions of the PMBOK® Guide but the topic starting receiving more coverage in the Sixth Edition and finally was given a full section in the most recent edition. But before we can start tailoring we need to answer the question of what context needs to be addressed.

External

Outside the performing and receiving organizations, the environment within which the project is being executed needs to be considered. These form the external portion of the Enterprise Environmental Factors (EEFs) which are frequently referenced in the PMBOK Guide.

The industry we are in will influence and constrain our approach. In the pharmaceutical industry, validation documentation for projects which are involved in the testing or production of products is required whereas in other industries, less formality might be needed.

What's going on in the world also needs to be considered. The COVID-19 pandemic imposed requirements on teams to work in a dispersed manner even if they could have previously been co-located.

Organizational

The context of both the performing and receiving organizations will influence project approaches. Organizational Process Assets (OPAs) such as standards and policies apply, but also factors such as where stakeholders are located, funding availability, and what else is going on in the organizations needs to be considered. For example, running a project in a long-standing, large organization usually involves heavier governance and oversight than that for a startup.

The terms and conditions from contracts established between the performing and receiving organizations will also affect how the work is done. For example, while team members from the performing organization might have preferred to use one set of tools for managing their work flow, their contract with the receiving organization might specify the requirement to use an alternate tool set.

Team

Characteristics such as a team's longevity, its culture, factors such as the level of psychological safety and trust within it, and its makeup will affect our tailoring approach.

We might want to encourage team members to become generalizing specialists but if some of the team members fall under a union contract which rigidly defines the type of work they can do, this might not be possible.

If the team is new and the team members have not had a chance to work together in the past, working agreements and handoff criteria might need to be more explicitly documented than for a long standing team.

Individual

We need to consider the context of each team member as well as that of our stakeholders.

One of the principles from the Manifesto for Agile Software Development is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.". But what happens if one or more of our team members are extremely introverted and are uncomfortable with prolonged face-to-face work? Similarly, we might want to do an experiment in pairing or mobbing, but if the individual personalities and preferences of team members don't support this, the experiment might fail.

Information radiators such as a product canvas or a work board might be sufficient for most stakeholders to understand what's going on but if one of our key stakeholders insists on getting more context about project status we might need to produce a status report or hold a regular meeting to meet their needs.

Context (at all levels) counts.

A major impediment to delivery is the inability for leadership and delivery teams to learn from the mistakes made in the past. By failing to apply learnings, teams are stuck in a Groundhog Day-like cycle where similar issues continue to occur, the same lessons are captured project after project, but nothing changes.

Needless to say this has made me (more) cynical. But yesterday, I witnessed something which gives me hope for some organizations.

Living in Canada, one of the ways that many of us mark the changing of the seasons is swapping tires on our vehicles. When the temperature starts to regularly be in the single digits (Celsius), all-season or summer tire rubber hardens like a marble and you no longer have a safe grip on road surfaces. In Quebec, drivers are required to install winter tires but this is still optional in Ontario. Regardless, many Ontario drivers will prioritize safety over frugality by swapping their tires in the month of November.

I had booked an appointment with my local auto association to have a mechanic come to my house to swap the tires on my electric vehicle. For those of you who are unfamiliar with the designs of EVs, the battery normally runs the full length of the car and is located on the underside of the vehicle. As a result, care has to be taken when using a jack to raise the car as excess pressure could cause severe damage to the battery. And as an EV’s battery might be as much as 50% of the car’s cost most owners would want to avoid incurring damage due to negligence on their part!

When the mechanic arrived, he didn’t have a spacer which is needed to create a buffer between the jack and the car’s underside. I explained to him that I wouldn’t be letting him raise the car without that so he called his dispatcher. The dispatcher took ownership of the issue and called him back in a few minutes letting the mechanic know that he could pick up a set of the protective devices from a nearby auto parts store. The mechanic left and returned shortly and completed the work as expected.

I would have expected that the dispatcher would have authorized the purchase of a single set of the spacers for this mechanic’s truck. However, as I was paying the bill, the mechanic told me that the dispatcher had contacted the auto parts store and had placed an order for enough device sets so that each of the auto association’s trucks would be properly equipped.

When you identify a lesson on your project, it is good if you can apply it shortly thereafter. But why not go that step further and find a way to ensure that it becomes part of your organization’s standards and practices?

The lessons we truly learn are those which prevent anyone in our company from repeating mistakes we made.

(Thanks to Andy Kaufman for inspiring this week's article)

Those of us who have raised small children are familiar with the complaint "I'm bored!" which is almost as annoying as "Are we there yet?". This is more common currently than when I was growing up. Expressing boredom in those days was like issuing an open invitation for your parents to assign you some "interesting" chores. These days, parents are more likely to avoid the problem by providing distractions such as smartphones or tablets.

But what happens in the work place when a team member is bored? This happens a lot more with knowledge work than you might expect. And even with projects which are supposed to be unique endeavors, team members can find the work tedious, especially if they are doing the same work they've done on many past projects.

There are many published statistics about the proportion of workers who are disengaged. Sometimes this can be the result of mistreatment by their managers, insufficient pay or a general lack of trust in the company or leadership team. But boredom can also be a cause of disengagement and might be one of the easier issues to address if it is diagnosed early enough.

While there are many potential symptoms of boredom including an increased volume of complaints about work, doing work which is not in scope, distraction and even absenteeism, these visible signs might also be related to one of the other causes of disengagement.

Directly asking a team member whether they are bored or not is unlikely to help unless there is a high level of perceived safety and a culture of radical candor in place. Few of us would openly admit to being bored as this might be seen as a career-limiting move!

However, by asking open-ended questions about the team member's work, it is possible to determine whether their disengagement is boredom-born. Here are a few starting points:

• What do you like best about your job?
• If there was one thing you'd want to change about your job, what would it be?
• (Give them a piece of paper to draw on) Could you draw a simple pie chart for me, showing me how of your current role challenges you, how much is interesting but easy, and how much you could do in your sleep?

If you are fairly confident that they are bored with their work, the next step is to determine whether the work itself is boring regardless of who performs it or whether it is boring just for this specific team member as this will affect potential responses.

If the work itself is boring, options to address it include:

• Splitting the boring work with others on the team to free up capacity for work on more interesting activities
• Empowering the team member to change how the work is done or to reduce the amount of manual effort involved to make
• Helping the team member reframe the work by tying it to a higher purpose. The apocryphal story of the school custodian who enjoys his work because it creates safety for the children comes to mind.

If the issue is not the work itself, but the work assignment, understanding what the team member would like to be doing would be the first step. Assuming the desired work is not too far a leap for them, helping them to come up with a development and transition plan might be one way to rekindle their enthusiasm. But if they are being unrealistic, as their leader it is important to be candid in providing a reality check.

All jobs possess some boring activities. However, ignore chronic boredom in a team member at your own peril.

"There are no uninteresting things, only uninterested people." - G.K. Chesterton