Easy in theory, difficult in practice

Tis the season - for New Year's resolutions.

Like lessons (rarely) learned sessions at the end of projects, annual resolutions have received their fair share of ridicule. For gym rats like myself, a humorous way to help shake off the doldrums of the post-holidays blues is to see all the new faces in my gym for the first couple of weeks of January and watch their numbers dwindle back as the days pass.

Daniel Pink's latest Pinkcast provides some good ideas for making annual resolutions more effective as does Elizabeth Grace Saunders' recent article in HBR.

But if we only wait till year end to reflect and decide what we'd like to change, that is likely insufficient. Resolutions might be a good way of addressing a major improvement such as getting more exercise or saving more money but what about all of the small improvements we can make throughout the year?

The same can be said about retrospectives.

While they provide a scheduled opportunity at the end of a period of work to reflect and identify improvement experiments, nowhere in the Scrum Guide or in any other framework are teams explicitly prohibited from engaging in such activities.

Informal learning just-in-time has its place as does structured, scheduled retrospection. It's not a case of choosing one in place of the other.

As this is my last article for 2021, I thought I'd share the top articles which I wrote this year from the three channels where I publish them.

• Wordpress: Trick or Treat - project management lessons from Halloween!
• LinkedIn: The PMBOK® Guide Seventh Edition - is the cup half full or half empty?
• Projectmanagement.com: Helping team members avoid the fears of working remotely

Happy holidays and see you in 2022!

"Laugh and the world laughs with you" goes the old saying, but that's not always the case in the workplace.

An HBR article covering research conducted in health care on the impact of humor in clinician-patient interactions is equally applicable in other industries. The authors indicated that humor can be a suitable side dish for an entrée of empathy, courtesy and respect but in the absence of these main courses, it backfires.

So as project managers, what can we take from this that might help us in our work?

No question, there are many project situations in which we find ourselves where a joke might help but there are equally as many where it might make things worse.

Conflicts are one such instance. If two of your team members are having a heated argument about something, a joke might be just what's needed to inject some levity into the situation which gives them time to take a step back and see things in a different light. On the other hand, if the conflict has escalated past a certain point or if you are unsure on how the participants would react to such an approach, a joke might be perceived by one or both of the team members as you egging them on or picking a side.

When the team is concerned about a looming milestone or an issue which seems difficult to overcome, well-timed humor might be just the antidote. You might be able to short circuit the rising tide of fear, uncertainty or doubt. But missing the mark could result in some team members disengaging or a full scale argument about their concerns.

Finally, we come to delivering bad news. There can be situations where you might be able to to soften the blow of learning that the project is in trouble, but this could also be the final straw for your customer or sponsor. Just imagine how you'd feel if a PM came to you and said "The project deadline can't be met, but hey, you still have your health!"

So if we feel that humor might help in a given situation, how can reduce the likelihood that it falls flat? Here are a few questions to ask yourself:

1. Have I read my audience well enough to feel they will understand the humor the way I intended it to be received?
2. Is my timing appropriate?
3. How could they possibly misinterpret my intent?

And if you are still not sure, do a dry run of your message with a trusted, impartial advisor and proceed according to their feedback.

Sir Edmund Hillary might have been speaking about projects when he said "Good planning is important. I've also regarded a sense of humor as one of the most important things on a big expedition. When you're in a difficult or dangerous situation, or when you're depressed about the chances of success, someone who can make you laugh eases the tension."

Daniel Pink's latest Pinkcast episode focuses on learning from failure.

He discusses Tina Seelig's suggestion to her students to write a failure résumé listing some of the bigger mistakes they've made in their personal, education and professional journeys along with what they learned in each instance. While this can be a humbling exercise, it is also a great way to remind ourselves of how we have grown through adversity. Such a personal exercise is not expected to be shared with others although it might be useful if you are asked that ubiquitous question in an interview "What's your biggest failure?".

But could this idea also apply within the larger context of a long-lived team or even a company?

There are a number of benefits of sharing our failures including:

• Reducing the likelihood of making the same mistakes
• Increasing the level of psychological safety
• Deflating the egos or hubris of key decision-makers

Of course, it is important that what is shared does not point the finger at specific individuals. Very rarely are work screw-ups the fault of a lone person and if we want to encourage team behavior we need to accept our losses as well as the wins as a team.

For obvious reasons we wouldn't want to share this information externally. While there might be some benefits in doing so such as increasing the level of trust others place in our team or company or in helping other groups to avoid repeating our mistakes, the confidentiality lapses and competitive disadvantages would outweigh these benefits.

So what form might a team or company's failure résumé take?

A celebratory event is a common approach but the learnings and impact will lessen once the event is over. So how about a hall of failure?

Many companies will create a gallery of the accolades they've received in the lobby areas on their headquarters so perhaps having a similar display in an employees-only area of the building such as the cafeteria might help to keep the learnings fresh. Then, whenever a celebration of failure is held, the team could create a poster detailing the mistakes made and the key learnings derived.

For dispersed organizations or for those in which the leadership team is concerned about dedicating physical space for such an undertaking, an online hall could be created but to keep it front of mind, it should be visible from the home page of the company's intranet.

“Only those who dare to fail greatly can ever achieve greatly.” - Robert F. Kennedy

I frequently see questions asked in project management discussion groups about hybrid projects. As I wrote in last week's article, projects themselves can't be waterfall, agile, traditional or hybrid but how we approach them can be.

But what does "hybrid" really mean?

The Oxford English Dictionary's first definition relates to the zoological use of the term which isn't too helpful, but the second is: "A thing made by combining two different elements; a mixture." In the context of projects, the most common usage relates to the combination of predictive and adaptive approaches.

Using this definition, we can see that there are quite a few ways in which a project can be delivered using a hybrid approach including:

• Using a life cycle which uses both predictive and adaptive phases. An example of this is "Water-Scrum-Fall" which is a common interim step which some teams adopt when moving from a predictive to an adaptive life cycle.
• Using different life cycle approaches to complete different deliverables within the overall project scope. For example, the automation of an existing business process might involve an adaptive approach for the business process and the supporting system whereas the change management deliverables such as end user training materials might be produced in a predictive manner.
• Using a combination of methods drawn from predictive and adaptive toolkits. For example, we might use a work breakdown structure to help define project scope to a manageable level of detail, but then use work boards and hold daily coordination events to support the delivery of that scope.

Given that there are so many ways of being hybrid, it is a reasonable assertion that the majority of projects will in fact follow a hybrid delivery method. Predictive and adaptive approaches are just extremes on a continuum and most projects will fall somewhere between those points.

So when someone asks the question "What is hybrid project management?", the answer should be the same as it would be for any project management approach. Tailor your approach to fit the needs of the project drawing on predictive, adaptive and any other applicable toolkits while remaining aligned with enterprise standards and policies.

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.