6 Polarizing Differences Between Managers and Leaders

1. Managers Are Reactive, Leaders Are Proactive

As a manager, you'll be given your instructions. If something doesn't go to plan, a good manager will react to the bad news (or good news) accordingly. Displaying leadership is about more than that though; if you are a strong leader, you will anticipate changes and prepare in advance, steering your team to safety and ever-increasing profits.

Leaders who are proactive typically have a calm demeanor and roll with the punches. They also have confidence that their teams can overcome any challenge that may arise. This creates a less stressful environment for teams, knowing there is a plan of action and contingencies in place for when things don't go as planned. Of course, as with all things, good leaders need to take on managing and leading rolls.

2. Managers Have Employees, Leaders Have Followers

You'll manage a group of five or 10 as a good manager at a small company. As a manager, your team will be fixed. You'll react to situations, and your team will report to you. However, if you become known as a leader, then your team will come to you for help--but so will members of other teams. Being known as the guy or girl who gets ideas and acts decisively is the way to become a natural leader, and to increase your value one-hundredfold in business.

Leaders also nurture their teams to become leaders. They do this by seeing who their employees can become with the right training and resources, and not worrying too much about what the employees are like today. Leaders also create more leaders by creating key performance indicators instead of telling employees what to do. Leaders also know that becoming a leader takes time, and they give their employees room to make mistakes and learn from them.

3. Managers Manage Groups, Leaders Create Teams

This is corollary to the point above--as a manager, you'll manage your staff. As a leader, you realize that you are the director in a play--every person isn't one of the group, they are a unique cog that is vital to the running and promotion of the system as a whole. This is a key change of attitude that will bring out the best in your workforce. Vrej Sarkissian, CEO of Anoush Catering, says "When we help our employees work together as a team, we're able to put together astounding events for our customers. Our teamwork even enables us to give back to our community in a meaningful way. We value each member of our team as an integral piece of the machine and our customers can really see how it makes us a seamless unit instead of individuals."

4. Managers Shift Responsibility, Leaders Take Responsibility

Managers delegate tasks. They also delegate blame. We've all worked for that manager who wants to try out his new idea, yet when his own manager comes and asks what's going on suddenly your manager has no knowledge of the scheme. If you want to be respected as a leader, this can never happen. Leaders take responsibility.

5. Leaders Will Stand and Be Counted

A manager will keep their mouth shut, run everything smoothly, and then go home when the work is done. A leader won't. A leader is constantly pitching. Constantlymaking it count. Constantly trying to rework things both lower and higher in the hierarchy to make things work better.

6. Leaders Will Do What Needs to Be Done

There will be times when it gets hard. Really hard. You might have to let someone go. You might have to tell the team it's time for a pay cut, or that longer hours are needed. The key feature of a strong leader is that when the time comes, you are ready to do what needs to be done.

What Successful Project Managers Do

Traditional approaches to project management emphasize long-term planning and a focus on stability to manage risk. But today, managers leading complex projects often combine traditional and “agile” methods to give them more flexibility — and better results.

1. Develop Collaboration

Since project progress depends on the contribution of individuals who represent different disciplines and are affiliated with different parties, collaboration is crucial for the early detection of problems as well as the quick development and smooth implementation of solutions. The importance of collaboration can be demonstrated by the following two examples in which projects failed.

Tim Flores analyzed the causes for the different outcomes of three Mars exploration missions initiated by NASA’s Jet Propulsion Laboratory: Pathfinder, Climate Orbiter and Polar Lander. Although all three projects were conducted under the same guiding principles, were of comparable scope and shared many elements (even some of the same team members), Pathfinder was a success, whereas the other two missions failed. Flores expected to find that the Pathfinder project differed from the other projects in a variety of factors, such as resources, constraints and personnel. Although this was true to some extent, he found that the primary factor distinguishing the successful mission from the failed missions was the level of collaboration. The Pathfinder team developed trusting relationships within a culture of openness. Managers felt free to make the best decisions they could, and they knew that they weren’t going to be harshly punished for mistakes. That trust never developed in the other two projects.6

A different NASA project, the Wide-Field Infrared Explorer (WIRE) mission, was designed to study the formation and evolution of galaxies. Its telescope was so delicate it had to be sealed inside a solid hydrogen cryostat. When, shortly after launch, a digital error ejected the cryostat’s cover prematurely, hydrogen was discharged with a force that sent the Explorer craft tumbling wildly through space, and the mission was lost.

Jim Watzin, a project manager at NASA and a member of the WIRE project team, had this to say regarding the official report that NASA issued following the WIRE failure: “WIRE failed because people could not or would not communicate well with each other. … Individuals ... simply were uncomfortable allowing others to see their work.” Watzin added: “The real [lesson] from this loss is that any team member that does not participate as a true team player should be excused [from the project].”7

In the next two examples, project success can be attributed to the project manager’s deliberate attempt to develop collaboration. (Note that in the discussions that follow, we use only the project managers’ first names.)

Allan, the payload manager for NASA’s Advanced Composition Explorer project at the Jet Propulsion Laboratory, has described how he developed trust between his team and the 20 groups of scientists developing instruments for the project, who were based at universities throughout the United States and Europe. Allan devised a three-stage plan. First, he selected team members who could operate in a university environment — people who knew when to bend or even break the rules. Second, he relocated his JPL team to a university environment (California Institute of Technology), recognizing that it might be difficult to develop an open, flexible culture at JPL. Third, he came up with an uncommon process for interacting with the scientists.8

The challenge, with regard to interaction, was getting the scientists to regard his JPL team as partners. Having dealt with NASA before, they tended to believe that someone coming from JPL would demand a lot of paperwork, lay out sets of rules to be followed and expect things to be done a certain way. In fact, many of the scientists weren’t sure they should share with Allan’s team the problems they were encountering along the way — problems that could slow down the project’s progress.

When unexpected events affect one task, many other interdependent tasks may also be quickly impacted. Thus, solving problems as soon as they emerge is vital for maintaining work progress.
The primary role of Allan’s team was to review the development of the instruments, and Allan believed that the best way to do this was by focusing on trust and convincing the scientists that his team was there to help them solve their problems. To facilitate this, Allan and his team of five to eight members traveled to each university and stayed on site for an extended period of time. By spending days and nights with the scientists and helping them solve their problems — not as auditors but as colleagues — the JPL team gradually became accepted as partners.9

Most projects are characterized by an inherent incompatibility: The various parties to the project are loosely coupled, whereas the tasks themselves are tightly coupled. When unexpected events affect one task, many other interdependent tasks are quickly affected. Yet the direct responsibility for these tasks is distributed among various loosely coupled parties, who are unable to coordinate their actions and provide a timely response. Project success, therefore, requires both interdependence and trust among the various parties.10

However, if one of the parties believes that project planning and contractual documents provide sufficient protection from unexpected problems, developing collaboration among all the parties may require creative and bold practices.

This was the case in a large construction project that P&G launched at one of its European plants. After the contractor’s project manager, Karl, brushed off numerous team-building efforts, Pierre, the P&G project manager, finally found an opportunity to change Karl’s attitude. Three months into construction, the contractor accidentally placed a set of foundations 10 inches inside the planned periphery and poured about 600 lineal feet of striped foundation in the wrong place. Instead of forcing the contractor to fix his mistake and start over — a solution that would have damaged the contractor’s reputation and ego — Pierre chose a different approach. Through several intensive days of meetings and negotiations with the project’s users and designers, he was able to modify the interior layout of the plant, thereby minimizing damage to the users without having to tear down the misplaced foundations and hurt the project’s schedule. The financial cost of making the changes incurred by the contractor’s mistake was significant, but the loss in reputation was minimal. As a result, Karl gradually embraced Pierre’s working philosophy — namely, “If they fail, we fail.” The realization that the organizations involved in the project are all interdependent led to the development of a collaborative relationship.

2. Integrate Planning and Review With Learning

Project managers faced with unexpected events employ a “rolling wave” approach to planning. Recognizing that firm commitments cannot be made on the basis of volatile information, they develop plans in waves as the project unfolds and information becomes more reliable. With their teams, they develop detailed short-term plans with firm commitments while also preparing tentative long-term plans with fewer details. To ensure that project milestones and objectives are met, these long-term plans include redundancies, such as backup systems or human resources.11

One key difference between the traditional planning approach, in which both short- and long-term plans are prepared in great detail, and the rolling wave approach becomes evident when implementation deviates from the plan. In the traditional planning approach, the project team attempts to answer the question: Why didn’t our performance yesterday conform to the original plan? In the rolling wave approach, project managers also attempt to answer the question: What can we learn from the performance data to improve the next cycle of planning? In particular, they attempt to learn from their mistakes — to prevent an unexpected event from recurring.12

How to Compensate For Overoptimistic Project Leaders
Successful project managers do not limit the learning process to the planning phase but also use it for project reviews. For example, after a review session in the midst of a project at NASA’s Goddard Space Flight Center, Marty was a frustrated project manager. The existing review process may have fulfilled upper management’s need to control its operations, but Marty felt it did not fulfill his team’s need to learn. Therefore, he modified the process to give his team the best input for identifying problems and the best advice for solving them. This meant doing away with the usual “trial court” atmosphere at NASA review sessions, where team members’ presentations were often interrupted by review board members’ skeptical comments and “probing the truth” questions. In its place, Marty developed a review process that provided feedback from independent, supportive experts and encouraged joint problem solving rather than just reporting.

The first thing Marty did was unilaterally specify the composition of the review panel to fit the unique needs of his project, making sure that the panel members agreed with his concept of an effective review process. The second thing he did was change the structure of the sessions, devoting the first day to his team’s presentations and the second day to one-on-one, in-depth discussions between the panel and the team members to come up with possible solutions to the problems identified on the first day. This modified process enabled Marty to create a working climate based on trust and respect, in which his team members could safely share their doubts and concerns. At the end of the second day, the entire panel held a summary meeting. It was agreed that the review session had been a big success. In fact, other NASA project managers quickly adopted Marty’s process, including it in their managerial tool kits.13

Successful managers of more traditional projects, such as designing and building manufacturing facilities, also practice learning-based project reviews. P&G has replaced review panels composed of external experts or senior managers with peer-review panels. These last four to eight hours and follow a simple protocol: First, the project team concisely communicates its technical and execution strategies, and then the floor is opened to all the invited peers for comments, critique and clarifying questions. Out of the numerous notes documented throughout the review process, five to 10 “nuggets” usually emerge that the project team uses to improve the technical, cost and scheduling aspects of the project. Sometimes, the invited peers even take one or two of the “nuggets” back to their own projects.14

3. Prevent Major Disruptions

In their book Great by Choice, Jim Collins and Morten T. Hansen describe one of the core behaviors of great leaders as “productive paranoia.” Even in calm periods, these leaders are considering the possibility that events could turn against them at any moment and are preparing to react.15 Similarly, successful project managers never stop expecting surprises, even though they may effect major remedial changes only a few times during a project. They’re constantly anticipating disruptions and maintaining the flexibility to respond proactively.16 The following two examples illustrate that, when convinced that a change is unavoidable, a successful project manager acts as early as possible, since it is easier to tackle a threat before it reaches a full-blown state.

NASA’s Advanced Composition Explorer project, discussed earlier, was plagued from the start with severe financial problems arising from internal and external sources. Internally, the development of the nine scientific instruments led very quickly to a $22 million cost overrun. Externally, the project, which was part of a larger NASA program, inherited part of a budget overrun in an earlier project. As a result of these internal and external factors, the ACE project experienced frequent work stoppages, forcing the manager to constantly change his contractors’ and scientists’ work priorities.

Don, the project manager, believed that without immediate changes the project would continue down the same bumpy road, with the likely result that cost and time objectives would not be met. To prevent this, he made an extremely unpopular decision: He stopped the development of the instruments, calling on every science team to revisit its original technical requirements to see how they could be reduced. In every area — instruments, spacecraft, ground operation, integration and testing — scientists had to go back and ask such questions as: How much can I save if I take out a circuit board — and how much performance will I lose if I do take it out?

At the same time, Don negotiated a new agreement with NASA headquarters to secure stable funding. To seal the agreement, he assured them that, by using descoping tactics, the project would not go over budget. With the newly stable budget and the project team’s willingness to rethink its technical requirements, the ACE project gradually overcame its technical and organizational problems. Completed early and below budget, the spacecraft has provided excellent scientific data ever since.

The second example of preventing a major disruption from occurring took place during the Joint Air-to-Surface Standoff Missile, or JASSM, project. In this case, the Pentagon had decided to make another attempt to develop JASSM after the first attempt was aborted due to a cost overrun of more than $2 billion. The original project manager for the second attempt was dismissed in midcourse due to poor performance, and a new project manager, Terry, replaced him.

To keep costs under control, Terry decided to have two contractors compete for the final contract. Terry quickly realized that both contractors were approaching the development too conservatively and that unless he took a more radical approach, the project would be canceled again. Therefore, he told the contractors to completely disregard the military standards and adhere to only three key performance parameters. One of the contractors, Lockheed Martin, took this directive seriously and changed its approach dramatically. It decided to build the missile fuselage not out of metal but out of composites. And to accomplish this, it found a company that made baseball bats and golf club shafts. The company had never built a military product, but it knew how to weave carbon fiber and was open-minded. Following trials with several prototypes, this company was able to manufacture a product of the highest quality. Lockheed Martin transformed this small company from a baseball bat provider to a cruise missile supplier, which led to Lockheed Martin winning the contract — as well as to remarkable cost reductions.

4. Maintain Forward Momentum

As noted earlier, when unexpected events affect one task, many other interdependent tasks may also be quickly impacted. Thus, solving problems as soon as they emerge is vital for maintaining work progress. As Leonard R. Sayles and Margaret K. Chandler wrote in their 1971 book Managing Large Systems, “In working to maintain a forward momentum, the manager seeks to avoid stalemates. ... Another penalty for waiting is that in a good many situations, corrective action is possible only during a brief ‘window.’ … The heart of the matter is quickness of response.” In a study of project managers on construction sites, it was found that they addressed (not necessarily solved) 95 percent of the problems during the first seven minutes following problem detection.17

In a recent knowledge development meeting, a group of 20 project managers at The Boldt Company, a construction services company based in Appleton, Wisconsin, focused on how best to cope with unexpected events. It became evident that most of the managers employed three complementary practices: hands-on engagement; frequent face-to-face communication; and frequent moving about.

Regarding hands-on engagement, one project manager, Charlie, said that to solve problems he often engaged in activities such as making phone calls, convening urgent meetings and taking trips to local retail stores to purchase missing parts. Documenting the time it took him to resolve 10 recent problems, Charlie reported that three were resolved within 30 minutes, three within 60 minutes, and three in less than one day; one problem took two days until it was resolved. Charlie also said that, because of his quick responses, he made one mistake. However, he was able to quickly repair its damage the following day. The entire group at Boldt agreed that maintaining forward momentum was more important than always being right.18

The second practice, frequent face-to-face communication, was described by Matt, one of the project managers, in terms of “daily 10-minute huddles” with all the on-site team members (the superintendent, field engineers, project coordinator and safety officer). Matt used these informal morning meetings to share the latest instructions from the client and to ensure that team members understood one another’s current workloads and constraints and understood how they could help one another. Very often, the meetings enabled the team to identify and resolve conflicting priorities before they became problems. Matt noted that, while the primary purpose of the huddle was to update everyone, it also reinforced a spirit of camaraderie and a sense of shared purpose. As a result, these meetings turned out to be very valuable for sustaining teamwork.19

As for the third practice, frequent moving about, one project manager, Tony, described the three primary outcomes of spending 30 minutes a day roaming around the project site. First, he was able to develop rich and open communication with his team members. Tony explained that while many workers did not feel safe asking him questions during various formal meetings, they felt very comfortable interacting with him freely during his on-site visits, which had a great impact on their motivation. Second, receiving immediate information, and in particular a greater range of information, enabled him to identify problems early on. At times, he was able to detect conflicts before they actually became an issue. Third, Tony developed a much better understanding of where the project was with respect to the schedule, rather than having to take someone’s word for it. He found that coming to the weekly and monthly planning and scheduling meetings equipped with firsthand, undistorted information allowed him to address questions and solve problems much better. The Boldt project managers did not agree on the preferred timing for moving about and, in particular, whether one should schedule the visits, as Tony did, or leave their timing flexible. However, they all agreed that moving about is a most effective practice that should be applied as often as possible.20

These three practices are not limited to construction projects. For example, in the previously mentioned JASSM project, which was geographically dispersed, all three practices necessary to maintain forward momentum were employed by the various project managers at each production site. Additionally, Terry, the customer’s project manager, spent much of his time moving about between all the different production sites.

Implications for Senior Managers

Although every project manager tries to minimize the frequency and negative impact of unexpected events, in today’s dynamic environment such events will still occur. Acknowledging the emergence of a problem is a necessary first step, allowing the project manager to respond quickly and effectively. Some organizations assume that almost all problems can be prevented if the project manager is competent enough — resulting in project managers who are hesitant to admit that they are facing an emerging problem. In fact, a recent study indicates that project managers submit biased reports as often as 60 percent of the time.21 When upper management fosters an organizational climate that embraces problems as an inherent part of a project’s progression, project managers are able to detect and resolve problems more successfully.

Management scholar Henry Mintzberg argues that today’s managers must be people-oriented, information-oriented and action-oriented. In contrast, the two prevailing project management approaches, the traditional approach and the agile approach, do not require project managers to encompass all three orientations. The traditional approach (primarily intention-driven) stresses information, whereas the agile approach (primarily event-driven) stresses people and action.

By assuming the four roles discussed in this article, the successful project managers we studied are both intention- and event-driven and embrace all three orientations. Developing collaboration requires them to be people-oriented. Integrating planning and review with learning requires them to be information-oriented. Preventing major disruptions requires them to be action-oriented. Finally, maintaining forward momentum, which is pursued throughout a project, requires them to adopt all three orientations. Senior managers must ensure that all three orientations are considered when selecting project managers and developing project management methodologies.22

Why the Best Bosses Are Flexible

I still remember my manager instilling in me the importance of consistency. Be firm but fair, he said. Set expectations, create the ground rules – and then hold everybody to those standards equally.

There’s a lot of logic to that approach. But having managed people for more than 30 years now, I can also tell you that one of the most important traits any manager needs to develop is flexibility.

You’re managing people, after all, and we all know that life can be unpredictable and messy. Manage long enough and you’ll find yourself dealing with a wide range of issues that aren’t covered neatly in your organization’s policy manual.

My years have taught me that the best managers go with the flow, doing whatever it takes to support their people.

This isn’t just my opinion, either. A growing number of academic and workplace studies suggest that a flexible and adaptive leadership style generates higher productivity, worker satisfaction, and retention.

For instance, a recent survey by WorkplaceTrends.com and CareerArc found that 75 percent of the employees polled ranked workplace flexibility as the most important benefit. Management consultant Roslyn Courtney argues that “ruthless flexibility” is also one of the key drivers of innovation.

I learned this lesson just months after I’d been assigned to manage other workers at a UPS package hub — many of whom, like myself, were working part-time to help pay for college.

Handling and sorting packages has always been tough work, but maybe more so back then when there was less automation. You were expected to move at a brisk pace, safely, while assuring packages are where they’re supposed to be at any given second.

I remember one night during the busy holiday season, one of my employees – let’s call him Joe – came to me and said, “I’m sorry to do this to you now, Alan, but I’m going to have to quit.”

Share

“Manage long enough and you’ll find yourself dealing with issues that aren’t covered neatly in the policy manual. ”

I knew Joe had been struggling to juggle college and the heavy number of hours he needed to work to pay for school.

Between work, school and whatever else he had going on in his life, Joe was feeling the pressure. He also knew how much UPS counted on him and his fellow employees to work during the holiday season, and assumed that requesting time off for school during the holiday season wouldn’t make him popular.

But I saw a lot of potential in Joe and thought he was worth doing whatever it took to keep him. I figured if I gave him a few days off — even if I had to cover for him as well while ensuring that his co-workers didn’t get wind and all ask for time off too — Joe might come back refreshed and ready to go again.

[Also on Longitudes: Diversity doesn’t thrive without inclusion. Here’s why.]

There was more than altruism at work. Sure, I cared about Joe as a person. But I also greatly valued Joe’s work and didn’t want to hire and train a new loader at what was our busiest time of the year.

So I gave Joe five days off and told him to go focus on his exams. Joe accepted my offer and when he returned, he was ready to work.

I hadn’t thought about Joe in probably 30 years and a couple of months after I was promoted to the UPS Management Committee, I received a kind email one day from Joe.

In that letter, Joe said his time at UPS – particularly when I gave him time off in a crunch – was a pivotal point in his life. And one of the lessons he learned at our company was the importance of putting the needs of others ahead of his own. That’s a lesson that served him well both in the military and in his personal relationships, he recalled.

Joe’s note was gracious, but in some ways I was simply following the lead of UPS’s founder, Jim Casey, who left a legacy of supporting his people.

Many, many years ago, the company was negotiating a critical business deal, and during a particular late-night session Casey realized that he didn’t know enough about the legal intricacies to help from that point on.

Casey noticed that his lead negotiator was suffering from the flu, so he quietly slipped out a side door and trekked through the bitter cold to a pharmacy to buy a bottle of cough syrup for this employee.

That story always stuck with me – and helped me appreciate that sometimes the best way for managers to lead is by serving their people.

Whether it’s producing a bottle of cough syrup or giving an employee the time off to tend to personal affairs, the best managers provide the right mix of motivation, accommodation and flexibility. 

An Objective Method for Evaluating Project Managers' Performance

Project managers are ultimately responsible for making sure projects are completed on time, on budget and with the features and functionality specified by the project's stakeholders. So one would presume that project managers' performance would be evaluated based on those same criteria. It sounds obvious, right?

In fact, it's not always the case that project managers are evaluated on the basis of whether their projects are completed on time, on budget or with the required functionality.

RELATED LINKS

Six Attributes of Successful Project Managers

The Secret to Successful Project Teams

5 Things Linus Torvalds Has Learned About Managing Software Projects

Why Your Project Management Practices Are Failing

At EDS, for example, project managers are reviewed based on subjective criteria, such as their communication skills, passion for achieving business results and business ethics, according to Jed Zaitz, a senior project manager with EDS's Medicaid Management Information Systems Group. Zaitz says objective, measurable criteria, such as whether a project manager's projects are completed on time or on budget, are not factored into performance appraisals for project managers at EDS because in many cases those metrics aren't available.

But Zaitz wants that to change.

"Project managers, unlike business analysts, testers or developers, have responsibility for project delivery, and they should be measured on their success or failure. That should at least be factored into the appraisal," he says. "To ignore objective metrics makes no sense."

Objective Metrics Are Key to Company Success

Zaitz, who earned his PMP (project management professional) certification from the Project Management Institute, believes objective metrics can help improve project managers' project delivery rates. If, during performance reviews, project managers find out exactly where their performance is falling short, their managers can talk with them about ways to improve their performance.

"Improvement of one or two percent in a project manager's performance would add huge numbers to the bottom line of a company," says Zaitz, who's worked for EDS for 32 years. "Even a small improvement would have very significant results."

Zaitz developed a methodology for evaluating project managers' performance about nine months ago, while he was managing a team of 15 project managers who completed five to six projects each year. The methodology is based on the traditional definition of a successful project: one that comes in on time, on budget and with few defects.

Zaitz's Performance Review Methodology

Here's how Zaitz's performance review process works: Project managers earn 100 points for completing a project. But if the project isn't completed on time, the project manager gets points docked from his score—say two points for every week the project is late.

Similarly, if the project comes in over budget or is implemented with defects, the project manager loses points—such as a half a point for each defect found within 60 days of the project going live or a half a point for each one percent the project went over budget.

Project size is also taken into consideration. Zaitz measures the size of each project according to its number of function points.

Zaitz notes that organizations can subtract more or fewer points from a project manager's score depending on which elements of project success (e.g. time, budget and quality) they wish to emphasize. For instance, if an organization prizes speed over quality, and if a project manager misses the go-live date, the project manager could be docked five points for each week the project was late instead of two.

Though Zaitz's methodology is focused on objective metrics, it takes into consideration stretch goals, such as early delivery of projects and technical productivity (getting more done with fewer resources or for less money), and soft skills. For example, if project managers complete their projects ahead of time or under budget, they can earn bonus points (especially if quality is not compromised.)

EDS hasn't adopted Zaitz's methodology, but the senior project manager says one group within the company plans to pilot it. He adds that rolling out the methodology throughout the company, which was recently acquired by HP, will require a significant cultural change. But the reward may be greater than the risk.

Says Zaitz: "For an organization like EDS, which probably has 1,000 project managers, it's very important to know its true top performers because if a new project comes up that's very challenging for a very important customer, you want to pick the right person to work on it."

If you're interested in learning more about Zaitz's methodology (he's written a white paper on it), you can contact him at jed dot zaitz at eds dot com.

Project Management: The 14 Most Common Mistakes IT Departments Make

It's no wonder only 29 percent of IT projects are completed successfully, according to The Standish Group. Project management consultants and software providers say they see IT departments making the same project management mistakes over and over: IT groups don't follow standard project management processes. They don't have the right staff working on projects. They don't assess the risks that could imperil their projects or determine ways to mitigate those risks. The list of mistakes unrolls like a ball of yarn.

MORE ON PROJECT MANAGEMENT

How To Spot a Failing Project

ABC: An Introduction to IT Project Management

When Project Failure Is Not an Option

How to Create a PMO and Select PM Software

Most of the project management mistakes IT departments make boil down to either a lack of adequate planning or breakdowns in communication (either among the project team or between the project team and the project sponsors). These mistakes can be fatal. They can also be avoided. And who better to point out the most common project management mistakes than project management vendors and consultants. (They also suggest ways to avoid them.)

The following list of the 14 most common project management mistakes ought to help you pinpoint where your projects are going wrong and measures you can take to improve them. The upside of avoiding these most common project management pitfalls is tremendous. Not only will your project success rate increase, you'll also improve satisfaction among internal customers, IT's stock inside the organization will increase in value, and the business will benefit from systems that make them more competitive that get delivered on time and on budget.

Staffing Mistakes

Mistake No. 1: Projects lack the right resources with the right skills.

Impact: Proper project staffing is critical, yet improperly allocating resources tops the list of most common project management mistakes. Not having the right people on a project can kill it. "The key to getting a project successfully accomplished is getting the right people with the right skills," says Joel Koppelman, CEO of project management software vendor Primavera. "All the planning in the world won't overcome an insufficiency of talent."

Solution: IT and project managers need full visibility into the skills and workloads of all of their resources, including consultants, contractors and outsourcers, who often get left out of skills assessments even though they're doing a "huge" proportion of work, says Koppelman. Project management software can provide such visibility into everyone's skills and workloads.

Once IT and project managers know who's doing what, they have to figure out how to allocate resources across myriad projects and day-to-day work.

"There are all kinds of organizational models," says Richard Scannell, co-founder of IT infrastructure consultancy GlassHouse Technologies. "I've never seen anything that works well. There's no easy answer [to the resource allocation question]."

You just have to try synchronizing people and projects as best you can, says Koppelman, adding that one potential solution is to appoint a resource manager who's responsible for figuring out who will be assigned to each project and for ensuring there's a fair allocation of talent across projects.

Scannell suggests setting up "tiger teams" where people get taken out of their traditional job responsibility for a year or more to work on a specific project. Ken Cheney, director of HP Software's PPM Center, recommends assigning resources at a project level as opposed to a specific task level, which he says is much more arduous.

If you're still hard-pressed to adequately staff projects, you may be able to free up resources by cancelling a "discretionary" project (e.g. one that isn't tightly tied to the business strategy), says Cheney. He suggests looking at your entire portfolio of projects your IT staff is working on to identify ones that aren't mission-critical. "By stopping those projects and reallocating resources to projects that will have the biggest impact, the organization as a whole can be much more successful," he says.

Mistake No. 2: Projects lack experienced project managers.

Impact: Projects can quickly grow out of control without a savvy project manager at the helm.

Solution: Hire project managers with certifications and the finesse required to manage stakeholders. Matthew Strazza, vice president of services (North America) for CA, says good project managers have to have strong soft skills. They need to know how to facilitate meetings, manage risk and handle a variety of different stakeholders—the business people who are looking for functionality, the IT people who care about security, and the financial people who are worried about the budget.

"If you're not addressing the financials, managing the budget on a week-to-week basis and notifying the client of any change, you can get into trouble pretty quickly," says Strazza.

Good project managers also need to possess technical expertise in whatever technology is being deployed, he adds.

Process Mistakes

Mistake No. 3: IT doesn't follow a standard, repeatable project management process.

Impact: This is the second of the most common project management mistakes. Lack of methodology increases the risk that tasks related to the project will fall through the cracks, that projects will have to be re-worked, and ultimately that a project won't be completed on time or on budget.

Solution: A project management methodology helps you tackle projects efficiently and makes you aware of all the activities involved in the execution of a project.

"Having in place a baseline of standards and methodologies will remove a lot of the risk associated with IT projects," says HP's Cheney.

Douglas Clark, CEO of Métier, a provider of project portfolio management solutions, recommends establishing repeatable processes for scoping, scheduling, allocating resources and communicating with stakeholders. "Those are the things you want to get a handle on first because they would probably give you the biggest payoff," he says.

Mistake No. 4: IT gets hamstrung by too much process.

Impact: Too much process makes the project team inflexible, and their inflexibility frustrates stakeholders.

Fumi Kondo, managing director of NYC-based consultancy Intellilink Solutions, once observed an exchange between a software developer and a project manager where the developer told the project manager that he could add extra features to an application with no additional effort. The project manager told the developer not to add the extra features because users hadn't asked for them. "My response would have been, 'Go to the users and see if those features are useful,'" says Kondo. "I see nothing wrong with over-delivering if it doesn't impact the budget or the schedule."

Solution: Be flexible and communicate with project sponsors and stakeholders.

Mistake No. 5: They don't track changes to the scope of the project.

Implication: The budget for the project explodes. So does the timeline.

Solution: CA's Strazza recommends following a formal change request process: The individual requesting the change in scope (e.g. additional features or functionality) needs to explain the specific changes on a change-in-scope document, and the project manager needs to determine how that request will impact the budget and timeline. The project sponsor has to sign off on the change-in-scope request.

Mistake No. 6: They lack up-to-date data about the status of projects.

Impact: You can't manage what you can't measure, as Peter Drucker would say. Nor can you coordinate resources or react to changes in scope, says HP's Cheney.

Solution: Software.

Mistake No. 7: They ignore problems.

Impact: Problems don't solve themselves. They fester the longer you ignore them and ultimately compound the cost of the project.

Solution: "If you do something wrong, it's about how well you fix it," says GlassHouse Technologies' Scannell. "Most people batten down the hatches and look up in the month. Understanding when you're starting to fail and quickly being able to engage as many stakeholders as possible to fix it is critical."

Planning Mistakes

Mistake No. 8: They don't take the time to define the scope of a project.

Impact: If a project's scope isn't well-defined by the business and IT up front, the project can end up ballooning like Friends actor Matthew Perry in the sitcom's later seasons. What's more, IT lacks the clarity and direction it needs to complete the project on time and on budget and meet the business's expectations.

Solution: Ill-defined projects are best served by a business case and a scoping exercise, says Intellilink Solutions' Kondo.

Mistake No. 9: They fail to see the dependencies between projects.

Impact: Projects don't happen in isolation. They're often dependant on other projects going on at the same time. When project managers fail to see the dependencies between projects—such as staff assigned to one project are needed on another&mdashh;projects get held up. Such slowdowns can have a ripple effect on all projects.

Solution: Take dependencies into account during project planning, says Métier's Clark. Talking with stakeholders and diagramming the project can help uncover dependencies.

Mistake No. 10: They don't consider Murphy's Law.

Impact: Stuff happens, and IT gets surprised by it. Consequently, the project goes off-track while IT tries to clean up a mess it didn't anticipate.

GlassHouse Technologies' Scannell recalls a company in the U.K. that his firm acquired, that was moving its mainframe to a new data center. The IT group devoted an entire Saturday to taking down the mainframe so that they could move it to the new data center the next day, he says. While the IT staff were en route to the new data center with the mainframe on Sunday, they ran into a gay pride parade, and they couldn't reach their destination due to roads blocked off for the parade. They had to drive back to the original data center and put Humpty Dumpty back together again. The lack of planning caused the IT staffers to do more work than was necessary.

Solution: Perform a risk assessment as part of the project planning. With your team, brainstorm what could happen to slow or derail the project, to make it go over budget, or to prevent you from delivering the expected requirements. Then figure out ways you can mitigate those risks, says Primavera CEO Koppelman. "If they sit down and think about those risks, they'll come up with a pretty good list," he says. "This exercise doesn't take a long time, and it's enormously helpful in understanding the soft spots in a project before it even gets underway."

Mistake No. 11: They give short shrift to change management.

Impact: All the time, money and hard work that went into delivering a new IT-enabled capability can be for naught if users don't adopt the new technology.

Solution: Spend time up front during the project planning phase to consider where resistance to a project will manifest itself and ways to address it, says Métier's Clark. Identify the stakeholders whose jobs will be impacted by the new capability, adds Intellilink Solutions' Kondo, and plan how you'll communicate changes to their processes and workflows with them. Not all of the changes will be negative.

Mistake No. 12: Project schedules are incomplete.

Impact: Project team members don't know what is due when, which makes completing the project on time a challenge.

Solution: Clark says a quick way to come up with a schedule for a project is to determine all the activities involved in getting the project done (e.g. scoping, getting requirements, testing and implementing) and then attaching due dates to those activities based on the deadline for the project. Project management software can also help create schedules.

Communication Problems

Mistake No. 13: IT doesn't push back on unreasonable deadlines.

Impact: IT sets itself up to fail and gets a reputation for not being able to deliver projects on time.

Clark says IT departments will scramble to accommodate project deadlines set by the CEO. But tampering with dependencies and with the plan only creates more problems that make delivering the project on time even more difficult, he says.

Solution: IT management has to explain to the CEO what it's going to take to meet that deadline in terms of cost and resources and has to get the CEO to choose between cost, scope and schedule, says Clark.

Mistake No. 14: They don't communicate well with project sponsors and stakeholders.

Impact: IT fails to deliver the expected requirements.

Solution: Project communications need to be catered to the audience, says Kondo. She sees misunderstandings about the scope of a project or a systems' requirements arise when IT departments hand over a spreadsheet to the business with thousands of lines describing the systems' functionality and specs. Because the business owners don't have time to look over such detailed technical documents, they ignore them.

"One side is communicating, but in a language the other side can't understand," says Kondo. "Then IT gets frustrated and they say, 'We described this to them. How come this isn't what they want?'" (Business analysts play a critical role as the liaisons between users and IT.)

Kondo recommends giving every stakeholder who will be impacted or involved in the project on the business side a high-level overview of the entire project, from design to rollout. The overview should highlight the activities that require interaction with the business and should explain why the business is needed, she says.

In general, IT needs to put more effort into educating the business about the steps involved in executing a project, says Kondo.

"If you have an open dialog about what's needed, what you're really delivering, and you have fluidity built into the process, the budget and scope becomes a dialog so if you go over budget, it's not necessarily a failure," she says.

Kondo's firm once worked with a client that was deploying a financial system and whose employees had never been involved in a large system implementation before. When design of the system was complete and Intellilink was beginning to plan for testing, Intellilink explained to the employees why testing was important.

"We told them about different kinds of testing and what they did and didn't need to be involved in. We talked about why we needed user input, what kind of input we'd need and how much time it required," says Kondo. "That gave people an idea of why it takes so long to test."