Leadership Is Taken, Not Given – Part 2: Defining Moments for Projects
In life, there are moments that define people. As we discussed in Part 1, Al Haig’s defining moment was when he took the podium and said, “I am in control here.” When one hears the name Al Haig, they think of that event and frame their evaluation of him as Secretary of State around it.
As project managers, we have defining moments, too. Fortunately, though, projects differ from life in that there are predictable points where these defining moments will arise. If we prepare for the four hotspots appropriately, we can avoid the pitfalls that commonly hamper success.
This week, we will cover the defining moments on the planning side. Next week, we will cover the defining moments on the execution side.
Defining Moment #1: Project Definition
Projects are often conceived and “raised” by stakeholders before project managers even have a chance to touch them. By the time you are handed the reigns to a project, there may already be a predetermined schedule and budget. In fact, even the adoption and governance procedures are in place for the sake of the project managers. This adds another factor of project success that’s (seemingly) out of your control. It might seem that–just like how we can’t choose our parents and decide how they raise us–we have no control over these crucial factors for your projects’ success.
But if we take a fatalistic approach, we can never improve. The fact of the matter remains that regardless of what type of environment you’re in, you have an important role. If you’re in a good environment, then your role is to execute the process that works. It’s incumbent on you to bring the project to success–there’s no excuse but to do well. If you’re in a poor environment, then you can’t simply go about your normal routine and expect results; your role is to improve the environment itself.
Again, the phrase applies: “Leadership is taken, not given.” If you always wait for the reigns of project control to come to you, you’re already on the path for project chaos. In what ways can you take the reigns? Can you say that the emperor wears no clothes? Does the process itself need to change, and you need to convince the stakeholders to change it? Will increased support from the stakeholders throughout the life of the project benefit both sides?
As you can see, a good project manager isn’t simply someone who can make schedules and build reports. It takes expertise to diagnose systemic problems, courage to point them out, and soft skills to sit down and buff them out with those who have the power to improve the system.
Defining Moment #2: Initiation
It’s human nature to seek pleasure and avert pain. The project manager’s role is to work in direct opposition of this tendency. If there is a problem, or even the potentiality for a problem, you have to resist the instinct to procrastinate. Hope is not a strategy. Head off the pain before it takes hold.
The earlier you recognize a potential problem, the more recourse you have. If caught in definition, you can increase the budget and time, make adjustments to the scope, put procedures in place to monitor risk areas. If addressed during initiation, you might already have certain high-level specs, but you can prioritize which parts of the project will require the most time, money and attention. In this case, adroit planning will still allay the risks that shoddy planning incur. Even if you recognize the problem after execution begins, you can still re-baseline, adjust the plan, and so forth.
If you simply avert the pain until it becomes a reality, then you will be left with no recourse. You’ll be wondering what went wrong instead of preparing its prevention. Realized risks cost time, effort, and money to resolve. In that case, a project will either miss its targets, make significant sacrifices in certain areas, or be cancelled altogether.
Being proactive might sound like a truism, but it’s indeed easier said than done. The problem is that addressing problems early means that you will be the bearer of bad news before execution even begins. Not only are you front-ending the pain for yourself, you’re bring it on others as well, which will not always be appreciated. It’s much easier to lie low and keep your slate clean until there’s a real reason to rock the boat.
Scope Change and Impact Analysis
The most important painful topic to bring up in Initiation is scope change and impact analysis. When your stakeholders come back during Execution and say they need to add requirements, they won’t want to hear that it will require an impact analysis. That will cost time and money. If issues come up during Execution that require you to negotiate the Triple Constraint, the stakeholders will be understanding if you let them know now (during Initiation) that a project can only be two out of three: better, faster, cheaper.
We’d be foolish to guarantee that this conversation will go over well, but whatever rancor you suffer here, you would have received the same but in much greater proportion if it came up after planning was completed. This conversation can at least be an opportunity for the stakeholder to consider placing tolerances on the scope, budget, and schedule.
As we already covered in Part 1, the project manager’s role is a bit of a paradox to begin with, now in the planning phases, their duty is counter-instinctual. This is why the leadership aspects of project management is so difficult. It takes a mix of bravery and deft soft skills to call attention to potential disaster in a way that doesn’t make others defensive, keeping everyone solutions-oriented.
In Part 3, we will discuss the Defining Moments for projects and their leaders that arise during execution.