My formative years were the 1980's which were the heyday for slasher film series such as Friday the 13th and A Nightmare on Elm Street. With Halloween rapidly approaching I felt it might be timely to draw three parallels between the villains of horror movies and dealing with project problems.
Never say "It won't happen to me!"
A common method of identifying which characters in a horror film are likely to be eliminated early is to look for the most arrogant or overly optimistic ones. One of the more humorous examples of this is Samuel L. Jackson's character in Deep Blue Sea who gets eaten by a shark right after he has made a wonderful, passionate speech expressing his certainty in being able to lead the survivors to safety.
Project managers and their team members should feel bullish that they can successfully deliver a project, but this confidence should come as a result of effective risk management rather than blind optimism.
Don't assume it's dead
In nearly every horror movie, just when the hero or heroine believes they have successfully eliminated the monster, it finds a way to come back to life. The first Halloween movie had one of the most unexpected comeback scenes. Whereas you knew that the villains in other slasher flicks (e.g. Freddy Krueger, Jason Vorhees) were supernatural entities and hence normal human limitations wouldn't apply, in the original Halloween movie Michael Myers appeared to be a run-of-the-mill psychopathic human being. It was only at the very end of the film after Dr. Loomis has shot Michael a few times at point blank range and he's fallen from the second story of a house and managed to get away that you finally realize he's going to come back.
While it can be very satisfying to resolve a tricky project issue, we need to remain vigilant to the possibility that it could recur. If it had been previous identified as a risk, we now have quantitative data regarding its impact which we could use to be better prepared in the future.
Never say "I will be right back!"
If there is one thing a character should never do in a slasher flick, it is to head off on their own. Just as carnivores in the wild prefer to hunt prey who have got separated from their herd, movie villains delight in dispatching foolhardy wanderers. While it can be tempting to try to tackle a problem on our own so that we are feted as heroes, for resolving really challenging ones, there is strength in numbers.
One, two, project issues haunt you
Three, four, you can't ignore
Five, Six, there's no quick fix
Seven, Eight, don't hesitate
Nine, Ten, they will come again!
A frequently asked question in the main ProjectManagement.com community discussion group is about the perceived impacts of machine learning on project delivery.
Some contributors worry that sufficient advances in AI will render the role of a project manager obsolete whereas others remain bullish about the prospects for the profession.
A recent Harvard Business Review article by Stephen M. Kosslyn titled "Are You Developing Skills That Won’t Be Automated?" would support a positive outlook on this topic. In the article, the author asserts that roles in which emotion and context play a strong influence will still need to be performed by human beings. We have enough challenges with human leaders struggling to inspire team members or effectively align stakeholders to expect that machines will have an easier time doing so.
I'm expecting that enhancements in current machine learning technology will free us from rote administrative activities which even the most senior project manager finds themselves having to perform from time to time. While such advances might reduce a full-time requirement for project administrators on large, complex projects, it might enable such roles to support a larger number of projects at the same time.
What might projec managers do with all of this extra time?
Being assigned to more projects concurrently is not the answer! If we believe that project management is a strategic role then we should be encouraging greater focus, not less.
Freed up capacity could be better utilized on frequently neglected practice areas such as stakeholder engagement, risk management and knowledge creation. Envision the potential benefits to your projects if you had even 10% more time to devote to such practices.
We could also invest more in our own personal development or giving back to the profession or the community.
Is it possible that at some point in the future, AI will have the ability to independently manage a project staffed with humans?
This seems realistic if we agree with Gene Roddenberry's vision of intelligent sentient machines such as Commander Data, but I'm equally optimistic that the next one or two generations of project managers will have little to fear so long as they continue to invest in developing their soft skills.
Since I first started to learn about project management, risk management has always fascinated me.
That characteristic of uniqueness which separates operations from project work introduces uncertainties which, in turn, generate risks. Most mega-project case studies give credit to an effective risk management approach as a key contributor towards their success. But in spite of this, risk management continues to be one of the weakest practiced knowledge areas in the PMBOK.
If eternal optimism is the prevailing mindset within a company, it can be difficult for risk owners to envision things not going according to plan. What has always intrigued me is how the same leadership teams which can be moderately effective at implementing operations or business risk capabilities will be so much weaker when it comes to project risk management. A risk averse culture will take a long time to change for an overall organization, but a project manager should be able to influence it within the ecosystem of their projects.
Unhealthy levels of multitasking by project teams and stakeholders result in those practices perceived as unnecessary being jettisoned or being given lip service only. If a team barely has time to deliver the scope of their project, how can they or equally busy risk owners be expected to expend any real efforts on considering or responding to potentialities which may never be realized? And, if we combine this limited availability with "one size fits all" approaches to project risk management, it is no wonder that many teams will do the absolute bare minimum required to meet onerous governance requirements.
If team members and other stakeholders don't know what effective project risk management looks like, how can they be expected to improve? If there are no coaches to help teams improve their capabilities, improvements in risk management will rarely happen organically. Competent risk management requires exceptional interpersonal skills in addition to some basic technical skills, so hands-on practice with feedback from seasoned practitioners is needed to improve.
Finally, there might not be a realization of the positive correlation between effective risk management and successful project outcomes. In the absence of supporting internal empirical data or strong pressure from the outside to create a valid sense of urgency, senior leaders and project teams will be unwilling to sustainably invest in the required behavior and practice changes.
Providing practitioners with risk management training or evolving project delivery standards might help in some small way, but real improvements will only come when these root causes are addressed.
The Scrum Guide calls sprints the "heart of Scrum" and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.
A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?
Their decision should consider a number of factors including:
For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.
When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.
The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team's productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.
Sprint duration is another case of Goldilocks and the three bears - finding out what's "just right" will take some trial and error!
Managing a high priority project can be a wonderful experience.
You will usually receive ample support from senior leadership in resolving critical issues, getting funding for team celebrations is rarely a challenge, and helping team members and other key stakeholders understand the importance of the project and how its success will benefit them should be simple.
But this is rarely the case. Most of the time, we are working on initiatives which, while important, are not top of mind for your senior executives.
Here are just a few of the challenges with managing such projects:
So what can you do to improve your odds of success?
"You should never view your challenges as a disadvantage. Instead, it's important for you to understand that your experience facing and overcoming adversity is actually one of your biggest advantages." - Michelle Obama