Leadership is taken, not given: The defining moments for projects and their managers

The Defining Moments for Projects and Their Managers
Gus Cicala, President & CEO, Project Assistants

This paper addresses project managers' common challenge of leading projects without having any traditional leverage in their organizations. Project leaders most routinely meet resistance at four stages of the project: definition, planning, execution, and closeout. This paper covers the high-level theory of each of these processes, demonstrates the challenges therein, and redresses each of them with practical approaches to achieving best-case scenarios.

The priority of this paper is to present the practicable instead of the ideal, the optimal instead of the perfect. In an environment where things will go wrong, feelings will be hurt, and sacrifices will be made, how can we maximize our projects' chances for success?


Project managers face a paradox. The ultimate responsibility of project success falls on us, so clearly we are the leaders. Yet, the matrix structure of organizations leaves us with very little tangible power—we can't lead through traditional leverage (e.g., hiring and firing) and, since we're not in direct, day-to-day contact with the project, we can't even lead by example.

As easy as it is to get caught up in the hard skills that directly relate to our job description—making project documents, setting schedules, using project management technology, etc.—this isn't what separates the effective from the ineffective. The crux of project management really lies in the previously mentioned paradox—in taking the lead on projects without being given any traditional power.

Doing the Al Haig Thing

On 30 March 1981, just 69 days into his presidency, Ronald Reagan was shot. From our privileged vantage in the future we know that the president survived and had two of the greatest full terms in American presidential history, but we didn't know that then. Anyone who was following the news that day knows that the country was immersed in a frightening turmoil.

We were still in the Cold War, and the commander in chief of the US Armed Forces was “close to death” and had just been admitted to the hospital. The second in command, Vice President George H. W. Bush, was on a plane without reliable communication. A reporter asked the deputy press secretary who was in charge, and the secretary gave an uninformative response: “I cannot answer that question at this time.” No one was at the helm of the United States military, and just as importantly, no one was speaking up to reassure the public or maintain a position of power within the conflict.

Secretary of State Al Haig took leadership upon himself. He immediately passed a note to the press secretary, ordering him to step down from the podium. Haig stepped up and stated unambiguously, “I am in control here.” In one of the most important pieces of misinformation in American history, he explained: “Constitutionally, gentlemen, you have the president, the vice president, and the secretary of state, in that order.”

Al Haig at the podium

Figure 1: Al Haig at the podium

In actuality, he was two more spots removed from the helm: The speaker of the House and the president pro tempore of the Senate were still in front of him in line. But as sacrilegious as it seemed to many, the Constitution was immaterial at the time—a great theoretical framework that had run into a few hours' exception; a short window of needless impracticality.

What Haig taught us on that day is the crucial tenet, “Leadership is taken, not given.” You can't always sit around waiting for permission, wondering why people would listen to you, and securing recourse. No one on your team wants a project to fail any more than the American people wanted a lapse in presidential leadership. You have to go over the head of office politics and detrimental self-interests or else you'll be weighed down by the very things that are unilaterally hated in workplaces. Your concern is project success, which ultimately benefits everyone in the organization. If you are sincere in this desire, there will be little reason for your team to mind you wearing the target.

And so, regardless of what the manual says, regardless of the fact that you can't say “do it or else,” you can still take control of projects and earn your coworkers' respect by doing so.

Defining Moments in Project Planning

Introduction to Defining Moments

In life, there are moments that define people. Al Haig's defining moment was when he took the podium and said, “I am in control here.” When people hear 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 many of the pitfalls and lead our projects to success. This paper will outline the aspects that most often decide the success or failure of a project and that come to define the project leaders.

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 reins 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, adding another factor of project success that's (seemingly) out of your control. Similar to how we can't choose our parents or decide how they raise us, it might seem that we have no control over these crucial factors of our projects' success.

But if we take a fatalistic approach, we can never improve. The fact remains that you have an important role, regardless of what type of environment you're in. 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 choice 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.

Project definition within the context of the organization's mission

Figure 2: Project definition within the context of the organization's mission

Again, the previously mentioned phrase applies: “Leadership is taken, not given.” If you always defer to the hierarchy, waiting for the reins of project control to come to you, then you will often be doomed for failure before you even get started. In what ways can you take the reins? Can you say that the emperor wears no clothes? Does the process itself need to change, and do 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 to this tendency. If there is a problem, or even the potential for a problem, you have to resist the instinct to push pain into the future, hoping it never materializes; you must feel it as early as possible.

The earlier you recognize a potential problem, the more recourse you have. If the problem is caught in the definition phase, you can increase the budget and time, make adjustments to the scope, and put procedures in place to monitor risk areas. If addressed during initiation, you might already be locked into certain high-level specs, but you can still prioritize according to which parts of the project will require the most time, money, and attention, and adroit planning will still allay the risks that shoddy planning incurs. Even if the problem is recognized after the commencement of execution, if the problem has yet to materialize, you can still re-baseline, adjust the plan, and so forth.

Example of the value of proaction and the cost of procrastination

Figure 3: Example of the value of proaction and the cost of procrastination

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 moving forward. 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 given, but it's easier said than done. 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 bringing 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.

The most important painful topics to bring up in initiation are scope change and impact analysis. When your stakeholders come back during execution and say they need to add requirements, they are not going to be pleased to hear that this will require an impact analysis, which will cost time and money. If issues come up during execution that require you to negotiate the triple constraint, the stakeholders are not going to be understanding unless 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 suffer even more 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, his or her duty is counter-instinctual. This is why the leadership aspects of project management are 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 and that keeps everyone solutions-oriented.

Defining Moments in Project Execution and Closeout

The previous sections cover all of the hotspots pertaining to planning, but as the ancient saying goes, “A mediocre strategy well executed is better than a great strategy poorly executed.” The rest of the paper will demonstrate effective leadership during the execution and closeout phases of a project.

Illustration of the typical disconnect that stalls organizational vision

Figure 4: Illustration of the typical disconnect that stalls organizational vision

Defining Moment #3: Execution

Criteria for Project Control

As we discussed in the Introduction, project managers have to navigate a paradox—that is, the responsibility to control projects without tangible authority in the organization. An effective way to take control during execution with minimal antagonistic confrontation is to keep projects in a natural rhythm and cadence. The key is to always keep the balls off your side of the net. Worry about your own responsibilities and leave the aspects of the project you can't easily control to those who are responsible for them. When you take care of all the next steps that are incumbent on you, then the “balls” tend to be returned back to you in a regular rhythm.

The reason it works is because it leaves no room for the blame game: When everyone's done 75% of what they're supposed to (for example), then whenever the project isn't where it needs to be, both sides will tend to blame the other side for the 25% they didn't do. But when you go into meetings with every one of the next steps on your side ticked, it won't take long for the other members of the project to fall in line, knowing that anything that goes wrong is on them.

This is the fundamental criterion for controlling a project. Notice how objective control is in this context. When you ask project managers if they're in control of a project, they often give an answer along the lines of, “I feel like it's going well.” But control is not a matter of opinion; you either are or are not keeping execution processes on a regular, cyclical basis; collecting actuals for cost, labor, and schedule on a weekly (or monthly) cycle; and analyzing variances to the baseline.

This isn't to say that there aren't other factors in project success. Some projects that are within control fail, just as some projects that are out of control flail their way to success. The idea is to maximize your success rate, and you do that by satisfying the objective criteria for project control.

Maintaining and Regaining Control of a Project

But we operate in the real world, so we don't want to give the impression that projects will be completely free of conflict. Even when everyone does what they are expected, things will go wrong and adjustments will have to be made.

These adjustments are pivotal. If companies were to do a postmortem on each of their failed projects, the most common cause for project failure would be scope creep. As the saying goes, large projects fall a year behind one day at a time. Massive project reconfigurations are generally the result of a mixture of denial and negligence on the project manager's end. Project managers who are in control, whose fingers are always on the vital signs of the project, are able to accommodate the unforeseen by revising the plan, re-baselining, planning contingencies, etc. When the scope creeps up and the project manager goes into denial—being a wishful thinker instead of a leader—then problems materialize, which means budgets are exceeded, deadlines are missed, and specs aren't met.

As we covered in Defining Moment #2: Initiation, though, being proactive will involve confronting pain. Change management—even if it is done incrementally as part of a regular, rhythmic process—will still involve negotiating an arm of the iron triangle: You can't have better, faster, and cheaper. We also emphasized the importance of making it clear to stakeholders that unforeseen things will happen and, in those cases, an impact analysis will cost time and money, and change management will involve a compromise of schedule, budget, or scope.

The iron triangle

Figure 5: The iron triangle

Preparing stakeholders for this, though, won't make everything a cakewalk in the execution stage. Effective project leaders must be deft at operating in the gray area, negotiating the optimal solution. Notice we say “optimal” and not “perfect” because there will not be a perfect solution. As the saying goes, negotiation's done right when both sides are dissatisfied. The problem solving itself often isn't even the toughest part of this process; it takes certain acute soft skills to make the solution agreeable to everyone.

Summary of Establishing, Maintaining, and Regaining Control of Projects

The most resistance-free path to success is to keep the project in rhythm by keeping all the balls off your side of the court. When you do this, you are in control of the project, which gives the project the best chance for success (note: not guaranteed). However, projects still seldom cruise to success following the plan perfectly—customers will add requirements, servers will go down, resources will perform below expectation, etc. In these cases, project managers must remain proactive, making incremental accommodations to the plan, and when the project is impacted, negotiating in the gray area.

Defining Moment #4: Closeout

With this paper's heavy emphasis on proaction, it might not come as a surprise that the real secret to a successful closeout is success in the preceding processes. Whatever problems have gone unresolved from definition, initiation, and execution will snowball and amass in closeout. If there were unclear completion criteria in scope definition, then you'll end up delivering what you think you promised but the customer won't get what they thought they bought. When parts of the project aren't incrementally closed out during execution, then you end up trying to win with a Hail Mary instead of stringing together a series of first downs.

There are of course responsibilities that don't commence until closeout (e.g., you have to follow up on out-of-scope activities and hand them off to the stakeholders), but closeout is a defining moment insofar as it's when proactive leaders who took the reins on potential problems as early as possible shine. Conversely, it's when managers who had no control over the project start to feel all of the pain they sought to avert.


Project managers cannot be passive due to various aspects of their typical role and position in the organization for the following reasons:

  •   Because project managers are not traditionally involved in the project until several of the environmental and (literally) defining aspects of the project are already set, they cannot wait for the reins of the project to be given to them.
  •   Because they are not given traditional forms of leverage, they cannot rely on any inherent control.
  •   Because they are not involved in the delivery of the project, they cannot “control their own destiny” and simply focus on the work at hand.

As such, it should be no surprise that this paper has placed a heavy emphasis on proaction.

The four aspects that most frequently define project leaders are:

  1.   Taking a stand on the organization's environment and the project's definition process;
  2.   Confronting potential areas of pain as early as possible in planning;
  3.   Establishing control in execution through cadence, maintaining it with proactive risk management, and regaining control of execution through optimal sacrifices of the iron triangle and tactful negotiations between parties; and
  4.   Preparing for a low-resistance closeout.

Honing these soft skills separates the technically qualified project managers from the proficient ones.

Attempted assassination of Ronald Reagan. (n.d.) In Wikipedia, the free encyclopedia. Retrieved from http://en.wikipedia.org/wiki/Reagan_assassination_attempt

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2014, Gus Cicala
Originally published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA



Related Content


Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.