Abstract
Project management has been accepted in many businesses as a discipline critical for continued growth. To improve project performance, companies have levied rules on how projects should be run, defined common reporting requirements for all projects, and pooled and shared their project management resources. Even with these functions, projects still struggle to meet the needs of the customer. This is because in order to improve project outcomes, the ways in which they are managed must change. Project managers must become leaders, paying more attention to soft skills, managing their stakeholders, and identifying solutions to organizational issues that are limiting project success. This paper discusses techniques developed by the author to address these needs and improve project success rates.
The Justification for Project Leaders
“Project management is easy. We have been managing people for hundreds of years. Just take any manager, give them a project, and they will get it done.” Experienced project managers will accurately predict the end of this story—there is a disproportionately high chance this project will fail. Instead of focusing on management, leadership is required to deliver project value. To distinguish the project manager further, functional managers need only manage subordinates while successful project managers lead extended project teams. This fundamental difference drastically increases the project manager's scope of responsibility, as the project team includes the entire flock of stakeholders.
The Project Managers Purview
Functional managers are primarily responsible for their direct reports, as shown in the classic organization chart (refer to lower portion of Exhibit 1). On regular occasions, they coordinate with their peers or a boss, but their focus is on their staff. Project managers, on the other hand, must align a significantly larger array of people. Beside their project team and peers, they have an entire organizational chart above them consisting of the project's stakeholders. In actuality, this loosely knit collection can be a significantly larger population than their well-organized subordinate project team.
In many projects, the quantity of stakeholders greatly outnumbers the project reports. For an extreme example, Portland Oregon's northern city limits and Oregon's northern state line is the Columbia River. For twenty years, there has been an effort to start a project to build a new bridge on Interstate 5 to cross the river. The two, currently steel, structures—one built in 1917 and the other in 1958 (Columbia River Crossing, 2012)—were constructed long before seismic design techniques became mainstream. They are arguably the weakest link and the only drawbridges in the in 1,400-mile-long freeway that stretches from Canada to Mexico, traversing Washington, Oregon, and California. There is a legitimate concern about either bridge's ability to sustain a reasonably sized earthquake. Without a doubt, it will be a massive project building this multimodal, dual-decked, mile-long bridge. It will take thousands of designers, managers, and construction workers. However, consider the stakeholders involved. They include: multiple federal transportation agencies, the U.S. military (a reserve airbase is nearby), Union Pacific, Amtrak, and Burlington Northern Railroads, the Coast Guard, two state and two city governments, two transit agencies, light-rail proponents and opponents, bicyclists, pedestrians, local potentially toll-paying citizenry, state tax payers (both Oregon and Washington have broad political differences between their western and eastern populations), boaters, businesses, truckers, commuters, environmentalists, Native Americans, and the list could go on. All have special interests; all can slow or stop progress, wreaking havoc on the best project plan. Few of them know anything about project management; none of them cares about the woes of the project manager. Without a doubt, the project manager will need to navigate more obstacles from the stakeholders than from the team actually building the bridge.
Exhibit 1– Comparing Functional and Project Management
To accomplish completing this project successfully, the project manager must be a leader—someone, who (with no authority over the diverse set of stakeholders) can get them aligned and supporting the project. This can only be achieved through gaining trust based on his or her transparency and objective problem-solving techniques. Attempting a project of this magnitude with a checklist of tasks for the project team to perform will result in disastrous failure.
The Problems with Accommodating Corporate Management
The best approach for discussing these challenges is by examining the areas that most often require leadership. The two most common factors that raise red flags are budget and schedule. Both are easily measured and inextricably intertwined. As the timeline extends, there is a commensurate increase in cost; similarly, as cost goes up (usually from increased scope) the timeline increases. However, time is different. Benjamin Franklin said it best, “Time lost is never found again” (Bartlett, 1980). Work can stop (controlling the burn rate), extraneous features can be removed (decreasing the required work), but time marches on. We cannot control time. Although intuitively obvious, the concept is elusive to a large number of managers and executives.
Some Projects Start Red
More than once I have been asked to work on projects that are red, only to find the root cause of the failure was that they were started improperly. One in particular, I was aware of and watched as it slowly drifted toward the crimson end of the spectrum.
This project was a small part of a much larger program. The program had a twelve-month delivery schedule, with an immutable due date, which was based on specific government regulations. The project in question was initiated on the date the program started; however, there was significant confusion on how to utilize a large software vendor. Beside selling software, this vendor also had systems integration (SI) responsibility for the product's implementation. The client wanted to engage the SI group on a fixed price contract and the vendor wanted to use a time and materials model. The internal debate on whether to use the SI and negotiations on the statement of work took six months of the allotted year.
To make the project fit, numerous compromises were struck with the end user and one of the three software packages from the vendor was only partially deployed. Because of the compromises, the end user had to implement dozens of labor-intensive processes. Nonetheless, the government requirements were met and the project was considered a success. The complete functionality was deployed nearly eight months after the initial deadline. The cost to the company was huge, but paled in comparison to the hundreds of millions of dollars in new revenue.
Case Study 1. Squeezing a Project to Meet a Due Date
Scheduling on Trouble Projects
From years of experience investigating troubled projects, the timeline is often the entire problem. Auditing the schedule starts by looking at the parameters around which it was built. Three primary methods are followed in building a schedule:
- Backward pass: start with the end date and build the schedule backward to arrive at the start date.
- Forward pass: begin with a projected start date and add tasks and dependencies to determine the end date.
- The squeeze method: set an end date and change durations and dependencies until the project fits in the time allowed.
The first two are sensible approaches for building a schedule. All too often, though, the third option is used, creating an unrealistic schedule. Assuming task time estimates are correct, the only way to squeeze projects reliably into a timeline is to change the methodology, remove scope, or, most likely, a mixture of both. (Refer to Case Study 1.) Simply making it fit is a common problem with project managers who want to please executives, rather than leading their managers with realistic expectations. Agreeing to a known unrealistic schedule is, at best, unethical. It is the project manager's fiduciary responsibility to develop and propose innovative plans to meet the organization's needs.
When a Due Date Cannot Change
When a project must be completed by a specific date, the primary triple constraint is obviously the schedule—scope, budget, or both must suffer. Contrary to popular belief, money does not solve everything, so scope must be cut until a forward built schedule achieves meeting the required end date.
Projects with absolute time constraints are abundant. These would include any project related to tax cycles, school sessions, elections, census data, or government regulations. Missing the deadline by days may postpone the project's usefulness by years. Consider what would happen if one of the multiple U.S. personal tax programs used by millions of people was delayed until March, when taxes are due on 15 April. The impact would be devastating to the software company's business. In these cases, the missed opportunity cost from the delay is so large that everything else is subordinate to the release date. Canceling the project is not an option, as that would be tantamount to closing the doors on the business. The only option is scope reduction.
Reducing scope does not require removing any items; it may simply mean delivering some functionality later. One option is to segment the deliverables providing the core requirements on time and other less important functions later. As an example, the tax programs mentioned above all deliver the core program by the end of the year; however, during the first few months of the year, they provide updates for last-minute changes in the tax laws. If forms are incomplete, the program warns the taxpayers, telling them to postpone submitting the taxes. Most taxpayers are able to submit taxes as soon as their income statements arrive, others must wait for the final tested forms.
A similar option is phasing projects. Phasing divides deliverables into sets of prioritized features. The most needed features are deployed first and others are delivered later. Configuration of the delivery packages is highly dependent on the specifics of the project and usually requires significant negotiation with customers and end users. For example, if a project is supposed to acquire data on sales to allow managers to see trends, data are needed prior to reporting. It could take months of data collection before enough data are available to generate meaningful reports. Moving reporting to a second phase is a feasible approach. Many end users will be upset at the inability to generate reports from the data as soon as the system goes live. This option is better, however, than losing months of critical data waiting for the design and completion of the reports.
Phasing has another benefit—it makes the project smaller at any given point in time. Although the project may run longer, breaking a project into multiple phases makes the number of people fewer and the total scope smaller for any given phase resulting in projects that are easier to manage (not to mention it reduces risk). This is quickly seen in determining the communication channels. The number of communication channels is determined by the equation N*(N-1)/2. If there is one person, there no communication needs and if there are two people there is one channel—between the two people. Increase a project size to 50 people, and the communication channels jump to 1225. Redesigning a 50-person project into two equally sized 25-person projects and the communication channels drop to 300—half the team size produces one quarter of the potential communication issues.
Identifying Project Issues in the Organization's Culture
Often the failures in projects are based on simple sounding concepts that are amazingly difficult to achieve in an organization's culture—lack of vision, honesty, transparency, or some combination of these factors. These three traits are critical to project success. It is paramount that project managers lead their projects with these qualities, regardless of the organization's culture. Perpetuating poor leadership is not an acceptable excuse for project failure.
Honesty's Virtue
Honesty is at the core of any healthy organization's culture. Without honesty, all is lost. It must permeate the company from the boardroom to the individual contributor. Project teams in healthy, honest organizations, report status accurately. Unpleasant news brings offers of assistance as opposed to criticism.
Honesty requires trust. Trust, however, cannot be blind. Representative slices of humanity live in every organization; unfortunately, this includes people who may not hold honesty as a virtue. These individuals may filter input from team members who have the insight to prevent trouble. For reasons like this, every trustful manager has to quietly and discreetly verify intentions. Rather than a sign of mistrust, it is a prudent measure to ensure the organization as a whole is functioning properly.
Vision's Guidance
Without identifying a goal, the team is directionless. Without a doubt, failure to develop and communicate a vision falls at the feet of executive management. It must maintain a clear vision and clarify any adjustments made to meet changes in the business climate. Most executives in companies with an inadequate vision are in denial that this condition exists. Their organizations are steeped in mistrust and dishonesty. It starts at the top, where management denies there is an unclear direction and the trouble manifests in the organization as apathy creating a team unwilling to take the political risk of highlighting management's error.
Projects in these environments languish in indecision. Without knowing the proper direction, no one can make critical decisions and projects stall. The project leader works with executives to define the goals and make the decisions.
Transparency's Test
Transparency is a requirement in an honest organization. Honest organizations have nothing to hide. However, honest cultures are no guarantee of transparency. Within any organization, denial and ego can create pockets of problems that management must diligently uncover. In trusting, honest organizations, these enclaves of opacity are difficult to discover. Offenders produce enough data to maintain a façade of openness. Even in non-covert conditions, transparency requires confident teams and executives reinforcing constant communication.
The best of intentions to complete a set of difficult tasks can create an environment where groups, focused on their goals, forget to ask for help. Timelines elongate, people become over-optimistic, and small risks become big issues. Opacity creeps in slowly like a morning fog, enveloping the workday, eliminating the ability to stand back and assess the state of affairs. Transparency needs management's help. Project managers must be involved with their people, mingling, asking questions, looking for stress, and proactively proposing solutions.
Silent Projects are Dangerous Projects
Much like a canary's silence in a coalmine foretells dangerous gases, projects in a poisoned organization also go silent. There is little realism in the reports and managers must surface the problems. If the organization is unhealthy, it often takes an outside party to untangle the mess. Auditors must call attention to honesty's absence, abused trust, and unclear visions. They need to look inside the opaque box and point to the political problems hindering a transparent operation.
The Changing Role of the Project Manager
Project management has seen significant changes over the past few decades. In this time, the field has grown to be recognized as a professional discipline and many have benefited from the changing views on how to run projects. There are formally documented and implemented processes and procedures as well as project management offices to help prioritize enterprise portfolios and manage resource loading. To handle the issues outlined above, the role of the project manager must continue to morph and the project manager must work beyond his or her assigned project.
In the last couple of years, project management has drifted toward being a commodity. Various organizations push their certificates as the end all of employment requirements and companies have created checklists to qualify “good project managers,” just as one might look at the functions required from a personal accounting program. Employment firms, relying on high-volume placements, capitalize on this attitude, realizing the cost effectiveness of a certification-based screening process. Meanwhile, thousands of people continue clamoring for their certification so they can jump into the resource pool.
It takes more than a certification to make a good project manager. Attaining expertise requires the ability to work with others and coordinate people to achieve a common goal. These traits are difficult, if not impossible, to acquire in a class, let alone grade on a test. Process is a vital component; however, project managers must step beyond utilizing process and aspire to be leaders. This manifests itself in three tiers of project managers (Exhibit 2).
Tier One: The Coordinator
Today's certifications equip project managers to be coordinators. They can herd cats. They work reactively at the rear and the flanks, keeping the cats all going in the same general direction.
This is a comfortable non-confrontational role occupied by a majority of project managers. Most companies require this trait; many feel this is all that is needed. The coordinator implements processes and procedures, monitors timelines, reacts to problems, and escalates out-of-control issues. This is the “commodity project manager,” who can manage a project as long as it stays inside the bounds of process.
Exhibit 2 – The Three Levels of Project Manager
Tier Two: The Negotiator
The negotiator has a different set of skills—he or she runs with the cats and applies reason in getting them to head in the correct direction. This requires that the project manager understands the stakeholder's needs and values and regularly mediates compromise.
Once the portfolio develops past the point of repeatable projects, there is no longer a single possible goal for a project. The project manager has to coax people to compromise and develop a mutual endpoint that provides value to all stakeholders. This is the first level of leadership.
All negotiators understand negotiation is a process—planning the approach, exploring options, proposing and bartering a solution, and then executing the plan. However, few question that a majority of negotiation is truly art. The method in which people support their viewpoint, handle their demeanor, show confidence in their beliefs, and deal with rebuttals can make or break a successful negotiation. These are key traits to being a leader.
By managing in this manner, the team becomes self-correcting, adjusting their course, realizing their collective power and ineffectiveness of running off on tangents.
Tier Three: The Leader
The project manager who walks in front of the herd, the cats following, has reached the pinnacle of the project management—leadership. Leaders understand their mission, mold and maintain a vision aligned with the strategic goals of the organization, communicate the direction to the team, and inspire people to achieve that vision. The team becomes self-directing.
Leadership can be learned, but not from books or classes. It is acquired from understanding and repeated use of the tools. It requires experience and an open mind.
Leadership roles present themselves to everyone. People need to recognize the circumstances and know how to step in and lead the team to success. The biggest obstacle is knowing the cats will follow and having the courage and confidence to move in that direction. The first few attempts often lack the polish and finesse of the accomplished leader, but experience brings it rewards.
Becoming a Project Leader
Crucial to any project manager's future is acquiring the soft skills and aspiring to new levels of leadership. Minimally, this requires education in organizational development, sociology, business management, and leadership. However, the cornerstone is real-world experience. As with any discipline, education pales in the shadow of experience. It is critical that project managers move from a reactive to a proactive approach, where they identify and address problems prior to them morphing into issues. This requires adopting a calm, methodical approach and open communication channels with all stakeholders. The result is project managers that create high-performance, self-directing team that drive any project to its appropriate goal.
Tips and Techniques
Leadership cannot be taught, nor can tests identify one's leadership competency. It is a set of traits people develop that are reflected in their core values and how they relate to others. Studying, learning, and mimicking various techniques are a start. However, until these qualities become part of one's values and persona and are as natural as breathing, managers will fall woefully short of being leaders.
Being a leader is a great aspiration, and requires more effort than is needed to attain a simple certification. To understand what necessitates being a leader, one can turn to the corporate world. FedEx® specifically calls out nine traits to identify a person's leadership potential: charisma, individual consideration, intellectual stimulation, courage, dependability, flexibility, integrity, judgment, and respect for others (Fast Company, 1998). Here, they are paraphrased and grouped into three main categories.
Outward Actions
Leaders are role models for others in everything they do. They have charisma to instill faith, respect, and trust. They respect others' opinions. Instead of berating, they carefully listen and function as a coach and an advisor. Using these skills, they develop the ability to get others to think in new ways. They identify and question unsupported opinion and, in its place, use evidence, logic, and reason. This brings a fresh new approach to problem solving in the organization.
Defining Direction
Leaders refuse to yield to popular views or demands and have the courage to withstand the naysayers who resist any ideas that are out of the mainstream. True leaders do this regardless of the personal cost. They are adaptive and effective in rapidly changing environments, with an ability to discern issues, simultaneously handling a variety of problems, and making course corrections as required.
Internal Responsibilities
Based on a strong sense of mission, leaders are dependable, keeping their commitments, and taking responsibility for their actions. A foundation of internal integrity guides them to what is morally and ethically correct. Superior judgment allows leaders to evaluate multiple action plans objectively, using logic, analysis, and comparison. They are pragmatic decision makers. They do what is right, even when no one else is watching.
Delegating Up
Of course, a project manager's job is to run the project; however, if he or she confounded by a problem, it is better to ask for guidance than to flail and fail. The best discussion is an example. A few years ago, I was called in to fix a project that was going to be 200% over on both budget and schedule. It was projected to complete at three times the cost and three times the overall duration. As part of the preliminary description, the client indicated that the project was building a product that would benefit two departments; however, only one was funding it. A short investigation showed that nearly all of the problems were “above” the project in the executive hierarchy. The leadership was dysfunctional. The vice president for the non-funding department requested one of the project's team members to blind-copy her on all emails and communications regarding scope. The VP would then use this information to have her team bias the requirements in her department's favor. Upon discovering this, I bundled up the evidence and trudged into her boss' office—an executive three layers above me in the organization and second-in-command for the multi-billion dollar company. I made the case in a logical and dispassionate manner, asking for his assistance to stop the covert action. Upon returning to my desk (three blocks from the executive's office), the reverberations had hit the project team, with a memo reprimanding the use of the blind copy feature. He took care of the situation with all due haste. He wanted to help, he was unaware of the problem, and when he became aware, helped me regain command and control over the project by removing the meddling, some might say subversive, executive.
Less than a month later, I had to invoke the assistance of another executive, this time the VP of Information Technology, asking him to stop the drone of negativism from one manager regarding the recovered project's team. The offender apologized for hindering our progress.
These two examples show that executives want to help; they simply need us to tell them how.
Training Superiors and Stakeholders
Even small projects need project managers who can lead without authority and can train executives and stakeholders who are ignorant of their project management deficiencies. Never expect others to know what project managers need to execute their jobs properly. It is paramount that project managers use these people as tools to get the project completed, which means training them on their jobs. Project managers must unapologetically assign them tasks just like everyone else on the project. Every stakeholder (see Exhibit 1) is a resource for the project manager. The sooner they realize this, the better the project will run and it is the project manager's job to educate them.
To underscore the point, think back on the last few sponsors assigned to your projects. Did they volunteer for the roles or were they assigned? Had they ever done this job before? Did they ask for reports on progress rather than request assignments to help the project? Too often, projects inherit sponsors appointed under duress as an afterthought to meet some process. Sponsors need the project manager's help in delineating what is required of them for making the project successful. This includes clarifying and constraining the project's scope, acquiring subject matter experts, and finding the extra money when it is obvious that the project is bigger than anyone thought.
The same is true for executives, although they have a different role. They should be mentoring project managers, helping with costs, and cutting through the politics. If they are not doing this, the project manager must teach them to do so.
Leadership and Project Management
With all that leadership entails, it is easy to understand why someone would make the distinction that all they want to do is manage a project. Minding the scope, schedule, and budget sounds quiet and peaceful, even mundane. Taking a subordinate, individual contributor role, or managing team members to someone else's direction, is tranquil in comparison to a leader's responsibilities. One must remember, though, there are multiple paths in project management, ranging from leading the most difficult of projects to being a coordinator simply herding cats. The demand will increase for the former, whereas the latter will be commoditized and relegated to any resource, remote or local. To advance the project management discipline, leadership qualities are essential.
Leading in the Absence of Authority
As mentioned above, leadership is more than leading subordinates. It requires leading people over whom you have little or no authority. The absence of a hierarchical advantage adds a challenge, but is ideal in training on how to deal with managers, customers, and difficult people. The key is making them feel the direction chosen is theirs. One of the best methods of doing this is storytelling.
Start by Listening
To start, listen nonjudgmentally. Too often, people jump to conclusions, share observations, blurt out solutions, and fail to give others time to talk through their problems. This needs to change.
A few years ago, I was meeting with a potential client who had a very successful data analysis company. The problem they were having was with a custom piece of proprietary hardware they had designed and built to collect the data. The business development manager, who loved hardware design, was managing the product development and relaying the current situation. He sighed as he told me his tale of woe.
The first release was a success, but after a short time, a key supplier of one of the core components, a small company, went out of business. This made him look for a new supplier. Adding to the frustration was that all the other suppliers were significantly more expensive. We talked about the functionality and a few other particulars on that version. He continued by saying that about a year later they revised that same component's functionality to use firmware so reprogramming would be easier. They contracted with an individual who was desperate for work to design the part. As a result, they got the design at a very aggressive price. Unfortunately, the protocol used was nonstandard and no other suppliers knew it. When the contractor found fulltime employment, they were again without support. Version 3, the version in current use, had another component losing support and they needed to find a new vendor.
The present problem was on a contract with the new component supplier, a company started by a recent college graduate. He was running into multiple problems, various vendors were arguing that he had designed the interfaces incorrectly, and now he had taken on another client out of state who was consuming all of his time. The business development manager was left with money invested in an unusable product. He insisted the problems were unavoidable and the company's strategy was prudent and fiscally conservative.
Building the Story
Returning to my office, I set out to determine how to approach telling them that they needed to focus on gathering and analyzing data, not building hardware, and the business development manager's pet project should be given to a company that specializes in developing custom hardware. I sent them an email asking about their growth plans for each business unit and clarifying a few other points from our conversation. From this information, I developed the following agenda:
- Summarize the information he had told me, ask how they are going to achieve their aggressive growth goals, and what role the business development manager would have in that.
- Ask how they were going to address the common issues of any growing company—security, cross training, hiring new staff, etc.
- Have them identify how they are going to continue managing a custom product development while doing this ramp.
- If required, list the previous versions' problems, highlighting the areas that were a result of not having an established hardware company managing and building their custom equipment.
As I replayed his story, the business development manager and the other executives started filling in the answers, arriving at the conclusion that they should focus on their core business of collecting and analyzing data, rather than building hardware. There was no need to address the last bullet; they came to that conclusion on their own. Investing time in building a trusting relationship with a reputable product development group, whose responsibilities would include architectural design, product development, and supplier management, would free up time of the business development manager to find new markets.
Making It Their Decision
Telling the client in the first meeting that product development was not their forte, and that the business development manager's pet project was costing them dearly, would have slowed down their realization and acceptance and I would not have been invited back. As obvious as some answers seem, when situations have evolved over time, the people in the middle have difficulty seeing the most obvious answers. Replaying their words in a different context is the key to shedding light on the proper direction and draws them to the correct conclusion using their own words. You simply facilitate the process.
Conclusion
Stepping up and being a leader, helps you, your peers, and the entire organization. Leadership begets success and success is contagious. Peers mimic the victories. Your actions will improve the company's culture and the changes persist because everyone benefits.
It is essential that project managers communicate a vision for the project that aligns with the corporate goals. They must:
- Lead by being honest and transparent, reward the same behavior in others by greeting unpleasant news with positive reactions.
- Trust all the stakeholders, but verify their information by staying closely involved with the team.
- Refuse to let projects languish in indecision, be bold and make evidence-based decisions, even if they are unpopular.
- Lead the people over whom you have no authority using three simple directives:
- I need you to help me by…
- I need mentoring on …
- I need you to clarify…
These traits gain respect among all of the project's stakeholders. This change, which helps everyone and will not meet the same apathetic demise of other changes, will persist and grow.