10 troublesome project management ideas and how to combat them!

Abstract

Project managers often find themselves on the wrong end of a lot of misconceptions about project management. This paper discusses 10 of these misconceptions and explains the potential danger or exposure that these ideas contain. Case studies and examples will be used to illustrate the ideas and recommendations will be made on how to combat these ideas should they creep into, or affect, your project.

The objective of this paper is to help working project managers and teams:

• Recognize when a project stakeholder has a potentially bothersome idea regarding a project.
• Combat dangerous ideas and assumptions about project management, and choose tactics to re-educate stakeholders.
• Discover methods for engaging project stakeholders, and setting appropriate expectations for the project.

Introduction

There are many interesting ideas that have influence over a project manager and team. This paper focuses on 10 of these ideas and attempts to put them into perspective, not only from the idea and its condition, but also to the damage such thinking can have, especially when carried to extremes. These ideas are as follows:

1. Just Do It!
2. Rewarding Heroic Behavior
3. Do More with Less!
4. Project Management is Just Useless Overhead
5. Embarking on a 50% Confidence-level Schedule
6. Bad Multitasking
7. Proximatic Competency
8. Inaccurate Reporting
9. Breeding Chickens and not Pigs
10. Failure to Learn from History

Each idea will be presented along with some of the symptoms of the problems caused by this line of thinking. Then, some suggestions and recommendations will be given as to how to proactively address these ideas and change them to more constructive ones.

Just Do It!

In 1988, Nike, Inc. came up with the slogan “Just Do It!” that has become the mantra of many when it comes to driving the project team away from planning and toward executing the work of the project. This “Nike School of Project Management” sees the initiation and planning activities as obstacles to getting the project going, and stresses that the work of building the various project deliverables is what the project is all about. Planning is seen as inactive whereas building is active, and this activity is mistakenly interpreted as progress. The value of project management is not evidenced, as these activities are viewed as impediments to project progress.

The symptoms of this idea are fairly obvious:

1. There is pressure to build the schedule and determine milestones long before the scope is defined. The team is asked to make up the activity list and start the schedule building, so they can determine the deadline at a point where only a vague idea of the final end deliverable exists. Requirements gathering and prioritization take a back seat to meeting an end date.
2. Because the team has no time to truly uncover the requirements, is is left to read the mind of the customer or line of business manager. It is no surprise that this does not end well, as mind-reading is not one of the processes discussed in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Fourth Edition (PMI, 2009).
3. The balance between Schedule-Scope-Cost-Quality is ignored. With the focus on just the schedule, the cost, scope, and quality impacts are downplayed so severely that the end deliverable often falls short of expectations.
4. Teams are active, but not necessarily productive. The team is busy, but producing items that will need to be reworked, either in this project or the next one. They are lost as to what to produce, but are making good time in producing something, regardless of value.

Combating this idea requires some help and support from senior management, particularly the project sponsor. The project manager needs to be assured that the plan can be built once the project scope is defined, and the project's success criteria is defined and agreed to. The project team needs to be assured that it will have adequate time to practice project management best practices, and that the time spent planning will greatly reduce problems downstream.

Here are a few quick tips on how to reverse the “Just Do It!” thinking:

• Project managers need to come to agreement with their project sponsor on not only what will be built, but also how it will be built as well. Project management is not just a word, but a discipline that requires a set of structured processes be performed in order to achieve a successful outcome. Short-cutting these processes could lead to undesirable outcomes. As Joan Knutson (2008, p. 3) pointed out, “Planning is a technical process, not a political one!”.
• The Plan-Do-Check-Act (PDCA) cycle begins with Plan! Jumping into “Doing” without adequate “Planning” forces the team to be either very intuitive or very lucky to correctly build the desired end deliverables. Show the value of PDCA as a continuous improvement process model.
• Gather metrics on the level of project management activities and their contribution to the overall project outcomes. This way, you'll be able to see that amount of project management effort expended versus effort expended elsewhere.
• Make Project Management a level 1 WBS item, and track all project management activities under this item, not under product deliverables. Collect all time devoted to this effort for every project, and develop a database of values that can be used as guidelines for future projects.
• Habit 7 in The 7 Habits of Highly Effective People by Stephen Covey (1989, p. 287) is Sharpen the Saw. This habit involves looking for ways to continually improve the processes that we use and incorporate any lessons learned in a project to newer, improved processes and procedures. Planning should improve execution, and training and continuous process improvement should improve planning.

Rewarding Heroic Behavior

You've seen this behavior all too often. It's getting near the deadline for delivery and the project is behind schedule. The project manager yells “All Hands On Deck!” and everything else comes to a screeching halt as everyone involved in the project drops everything and focuses their full effort on getting the project completed. After this Herculean effort, the project manager is rewarded and recognized as the individual who drove the project through to successful completion. No one seems to recognize that the monumental effort required to complete the project was the result of poor planning and execution earlier, and that the project manager was reacting to problems that he or she may have in fact caused. Like the firemen in Ray Bradbury's Fahrenheit 451 (Bradbury, 1953), they are starting fires instead of putting them out. In spite of this, the project manager is recognized for the effort required to bring the project home, and praised for driving the team to the finish. And the irony of all this is that the unrecognized project manager who is on schedule is forced to give up resources to help out the beleaguered project manager.

How do we combat such backwards thinking? First off, we need to recognize the difference between risk management and issues management. Risk management is a proactive discipline that attempts to account for, and provide responses to, unknown events or conditions that will impact our project in some way. Issues management, on the other hand, is an attempt to deal with the various realities that influence our project, often in a reactive manner. Doing nothing while waiting for a problem to happen, and then dealing with the consequences, is issues management at its finest (Baker, 2007). Develop a strong, proactive, continuous risk management process and follow it.

Other ways to combat this idea are as follows:

• It is the job of the project manager to set and manage expectations! (Baker, 2006). I suggest that you take a large index card and write in large letters “SAME” to remind you that it is your job to Set And Manage Expectations.
• Focus on managing the expectations of all stakeholders, including setting expectations for project management. Create, and get agreement on, what a successful outcome for the project looks like and manage to that outcome.
• The process of starting out a project should look like this:
  • Identify stakeholders and their expectations.
  • Use the stakeholder expectations to drive the success criteria (project objectives) for the project.
  • Define the scope for the project.
  • Build the schedule for the project.

Do More With Less

This particularly vicious idea has gotten a lot of play during the present economic downturn. The theory is, if you're doing alright, and being successful with your current staff, then you must be overstaffed. “Lean” is the word of the day. The thinking is that we can tighten the belt and be, not just as effective, but MORE effective than we are now. The frailty of that argument can be illustrated by the following. Substitute the words “More” and “Less” in the following sentence:

Do __________ with ________________

How many of the resulting sentences make sense? To really understand how illogical this seems, take the word “more” to its extreme (EVERYTHING) and “less” to its extreme (NOBODY), and you get:

Do everything with nobody.

The reality is you can only do MORE with MORE. You may have a smaller team than before, but if they are MORE highly skilled, or you use MORE, or better, defined processes, then you may achieve more. The unfortunate reality is that we are doing with fewer resources by forcing those resources to work more hours, making the net amount of hours, at best, equal. What that does to product quality, as well as quality of life for those resources, is not good. Of course the irony in all of this is that we are getting access to fewer and fewer skilled resources, and often settle for who's available. We now have less of less, and are still expected to achieve more.

The way out is to get everyone to realize that you can only do more with more. Specifically:

• Do more with more talent. Develop high performing project teams, and nurture them. John C. Redding (2000, p. 64) showed that project teams that focused on shortening the learning cycles are suited best for projects where uncertainty is high and speed is a factor.
• Do more/better planning. As discussed earlier, better planning leads to better (faster) execution, with less re-starts. Having a flexible plan allows the team to address those unknowns in a structured manner, and incorporate changes more effectively.
• Get more support. Constantly re-allocating resources without consideration as to the impact on projects is short-sighted, and often sacrifices the important for the expedient. Work with your senior leaders to understand how staffing decisions impact planned work.

One tool that is effective in describing decisions and their impact is IF … THEN (Baker, 2004). Analyzing the effect of a decision and linking it to a root cause is a good way to illustrate outcomes prior to their occurrence. Use the phrase “Let's Pretend” (Baker, 2004) to take the discussion to the future and treat the outcome as real. Then, lead the discussion back to the present to examine the options to address the situation before it actually occurs.

Project Management Is Just Useless Overhead

This idea is closely related to the “Just Do It” philosophy where the whole concept of project management as a discipline is ignored and summarily dismissed. There is no perceived value to project management activities; in fact, they are viewed as obstacles that must be overcome to get any work done. The argument presented is that project management is just overhead—something to prevent the team from getting any real work done. My response to that argument is that if project management is inhibiting things from getting accomplished, then you're doing it wrong! Project management is all about getting the project done, within the agreed-upon success criteria.

This type of idea has many symptoms. “Just Do It” is one of them. Claiming that there is no value to project management activities is another. But the one most often encountered is the slow ramp-up, frantic-scramble-at-the-end syndrome. Many times, a project takes an overly long time to get going, waiting often to get the appropriate approvals. However, once the approval is given, there is a scramble to get going and a rush to get to the building of the required deliverables. Requirements are often fuzzy or misleading, and attempts to clarify them are treated with disdain. There may be some disciplined processes in place, but they are circumvented or rarely followed.

Fixing this problem can be difficult, as it often is with an organizational issue. The problem with this, as Ian Whittingham, PMP, (2009) pointed out, is that “In organizations, bias is manifest as a culturally engrained behavior that constrains decisions and actions to a fixed and limiting set of perceptions and responses. Often, the behavior is institutionalized to the extent that it becomes the norm.” If a PMO exists, one could leverage it to assist in changing the organizational mindset. Otherwise, it will be up to the team to demonstrate the value of project management activities. The project manager may need to embark on a personal quest to show this value. One way to do this is to collect all the data regarding the amount and usefulness of the project management activities, and all the typical problems solved by effective processes, and present them to senior leadership in the form of a Pareto Analysis. Build a business case for structured project management by showing the value of these activities in terms of real impact. Show the value of “Doing it right the first time” (Crosby, 1984, p. 59) instead of constantly doing it over.

Embarking on a 50% Confidence-level Schedule

In 2009, NASA made it a policy that all cost and schedule forecasts be at the 70% confidence level for future programs (NASA, 2009). Given that NASA has some history of slipped dates and considerable overspends, this policy gives one a new sense of urgency and realism at the agency. In light of that, how many projects and programs proceed with even less confidence than that? Does it make sense to agree to a schedule that the project team feels that there is a 50/50 chance of achieving?

Then, why do we do it? Certainly pressure from customers and organizational management has something to do with it. But wouldn't stakeholder management be easier if we had more confidence in our schedule, budget, and requirements? A risky schedule is a problem that we could face early in planning or later in execution. It should be something to be concerned about.

There are several manifestations of this problem that plague project teams:

1. Agreeing to the deadline before the requirements are defined. This idea makes sense if the time side of the triple constraint is the governing one. Then, the scope could be scaled back based upon the time available, the budget available and the quality requirements. But many times the deadline is just set, and the requirements then prove to be too large to accomplish within the time constraint.
2. Having the order-of-magnitude estimates interpreted as definitive ones. How many times have your early estimates been taken as facts, and used against you later on when the schedule starts to slip? Even though you were very clear that these estimates were preliminary ones, the dates or numbers given were passed on to others as hard estimates.
3. The desire to “produce something” overwhelms the business case. In the initiation phase of the project, care was taken to produce a business case that quantified the benefits of the project in terms of the cost and time invested in the project. Then, the project is funded, and the pressure is on to show some results and demonstrate some progress. The schedule is frequently crashed to resolve this perception, often with mixed results.
4. Failure to account for risks when developing estimates. How many times is risk management an afterthought or an activity that is attempted once the schedule and budget is set? Then, risk responses are retrofitted into the schedule, and contingency plans hastily developed. Schedule reserve is viewed as “fluff” or padding, and is quickly removed from the project schedule.

Combating this idea requires that the project manager and team build more confidence in the project schedule by taking the following actions:

• Agreeing to realistic schedule deadlines. Challenge overly optimistic and pessimistic estimates and take into account resource utilization when developing the schedule.
• Reducing scope as an option to meet an aggressive schedule. Multiple versions or releases may work well, especially in the situation where the requirements are not clearly specified.
• Use the evolutionary life cycle to build the product slowly over time. Each version of the product can incorporate changes requested in prior projects, and product robustness can be delivered in stages.
• Use Schedule Reserve not only as a project management concept, but also as a project reality to plan and manage the schedule. If a project buffer cannot be used for an organizational, political, or any other reason, aggregate the reserve at the end of each phase, and roll any remaining reserve into the subsequent phase.
• Manage schedule risk proactively. Identify those areas of the project that contain the most uncertainty about the schedule and develop plans to address them. Either you manage schedule risk, or it will manage you!

Follow project management best practices when developing and managing the project schedule. Fight the temptation to abandon all plans and rush headlong into execution in order to make up time.

Bad Multitasking

Make no mistake about it—multitasking is here to stay! It may be the output of a distracted society, or access to too much data, but there are examples of problems attributed to bad multitasking everywhere. Tom DeMarco (2001, p. 18) calls this the “task-switching penalty” and Robert Newbold (2008, p. 49) calls it the “Multitasking Maelstrom.” Most of the time, multitasking forces us to split our focus among several concurrent events, and the schedule, communications and project quality all suffer. Of course there are also examples of good multitasking, like when you eliminate the waiting time between tasks by performing some other, unrelated task. Regardless, there are potential dangers when you try to do more than one thing at a time.

Bad multitasking can be defined as dividing one's attention to more than one activity for some length of time so that one achieves less than optimal results for one or more of those activities. There are many reasons why we do this:

1. We “spread our paint too thin.” Due to the daily demands of the project (or multiple projects), we overschedule our day leaving little time for the coordination required for these multiple activities.
2. Interruptions in our schedule cause many inter-activity or inter-project starts and stops. Each start and stop introduces a loss in productivity as we close out one thought process and open another.
3. We want to report progress on multiple items. So, instead of focusing on completing one item, we start many in order to show movement on multiple fronts.

There are many unfortunate outcomes from this practice, but chief among them are as follows:

• Progress is painfully slow as a result of splitting our focus on more than one item. Instead of completing a one-day task in one day, we take several days because we're simultaneously working on multiple one-day tasks.
• Slipped schedules often require a heroic, focused effort at the end of the project. The irony, of course, is that if we applied the focused effort earlier, we wouldn't need the heroic action.
• Multiple quality issues arise. In addition to product and process quality slips, there is an impact on the individual and team's quality of life, as they try to juggle multiple priorities just to appear productive.

Recommendations for fixing this problem are as follows:

• Don't multitask. Before you dismiss this idea, consider the successes reported by users of Critical Chain Project Management (CCPM). Even if you don't apply all the CCPM principles, find ways to allow team members to focus on individual activities.
• Use Focus Days to arrange time in the schedule to focus on particular activities or deliverables. Focus days are days in the schedule where you focus the team work on only one activity or deliverable. It's like the “all hands on deck” presented earlier, without any of the stress of an impending project end date. It will take careful scheduling, but the benefits of improved communication, higher quality and the team sense of accomplishment cannot be ignored.
• Take control of your devices. Not every ringing phone or email received demands immediate attention. Decide where best to spend your time. Focus on the important things, not just the urgent ones.

Proximatic Competency

Proximatic Competency is defined as “the concept whereby any and all resources within a certain distance of a discipline or skill has the same level of knowledge, skills, and ability as the entire group within that discipline or skill.” I'm not sure of the origin of this idea, but there is a definite tendency to believe that everyone within a department has the same level of skills as anyone else in that department. It's true that I invented this term in response to this tendency, but it is nonetheless a demonstrable one.

The symptoms of this concept are also demonstrable:

1. Instead of getting the required resource, we get a substitute because “He's available.” It's the classic “warm body” theory, and it causes all kinds of issues. One example occurs when your estimates were based upon using a certain resource and now that resource is not the one who ends up doing the work.
2. Having a substitute resource can cause issues at project meetings. The proxy resource does not possess the knowledge that your first choice has, so he or she often has little to contribute. Due to their perceived lack of expertise, they won't help to drive any decisions and often have to get back to you after they check with the qualified resource.
3. The department providing the substitute resource sometimes gets a bad reputation as not being cooperative due to the impression that the resource assigned is not the first choice. Often, the reticence of the new resource to substantially contribute drives the project team to perceive that the resource is not as committed to the project outcome as they are. He or she as “not a team player,” a deadly proclamation about any team member.

To deal with this problem, embark on a campaign to educate your stakeholders about the importance of correctly identifying and utilizing a competent resource. This process is part discussion and part action. The discussion part is obvious, but the action part requires courage and discipline. It requires that you recognize the tactic, and deal with it proactively. If the substitute resource will not work, state so. Describe the problem in cause-and-effect language (If...then…), and elicit their cooperation. Use questioning techniques to control the conversation and get to the root cause of the resource substitution issue.

Inaccurate Reporting

What are the odds that your project will experience a variance sometime along the way? It is probably near certain. And most reasonable individuals would agree. Then, why do people get upset when the project doesn't go exactly according to plan? Shouldn't we expect to see variances as part of project execution, and wouldn't you be nervous if all team members reported that everything was being accomplished exactly as planned? Then why, when project progress is being reported, and the news is not good, do we have a tendency to shoot the messenger? If we come down hard on a project team that delivers bad news, the logical reaction would be for the project team to start changing how they reported the actual status of the project, especially when blame and criticism is hurled upon the offending party.

A danger to such a response is that project managers will start reporting favorable numbers rather than true actuals. We'll notice a few instances of “watermelon projects” (green on the outside, red on the inside), as people try to avoid the unpleasantness of reporting inadequate progress. Besides, without any guidelines from senior management or the PMO, status reporting is extremely subjective, with each project using a different set of standards upon which to base their progress. So what if I report a troubled project as fine, as long as I avoid criticism for as long as I can. And to make matters worse, this process is compounded by the fact that PMOs aggregate this faulty information in summary reports to executive leadership, so now no one in the organization knows exactly what's going on regarding their projects.

Dealing with this issue requires that project teams use a multifaceted approach:

• Insist on defined, and agreed to, project objectives. These measurable success criteria are the North Star for the project and each project decision should be based upon the impact to these important metrics.
• Common agreement on the reporting formats and metrics. Develop and use a standard reporting template for communicating project status and have guidelines in place for the tolerances for any important reporting metric. If using a stop light report, be specific about how a color is used. Have guidelines in place for choosing when a project metric is reported as red, yellow or green. Vary the metrics by phase and by project, if applicable, but be sure to get agreement from the project sponsor as to how results are reported.
• Use your Project Communications Management Plan. In this plan, all the rules, templates and processes for reporting status should be outlined, along with the guidelines for their use.
• Personal outreach, not just to executive stakeholders, but to all key members of the project team. Take the time to communicate actual project status, good and bad, to key stakeholders as part of your stakeholder management strategy. Many stakeholder issues can be avoided through careful communication of what's really going on in your project.

Breeding Chickens and not Pigs

“What's the difference between a chicken and a pig with respect to a bacon and egg breakfast?”

• The chicken is involved
• The pig is committed!

There is ample proof that a committed team, working with the appropriate tools and skills, can accomplish great things. But how many projects have team members that are not truly committed to the project or its outcomes? As R. Camper Bull (2008, p. 5) pointed out, “A true team should understand not only their jobs, but is committed to and has a sense of accountability for the entire organization.”

Using this analogy, a project manager needs to have pigs, and not chickens, on his or her project. And the project manager better have a plan about how to build this commitment, especially given the challenges of a mobile workforce, virtual teams and shrinking resource availability.

Not having committed team members can impact the project in several ways:

1. Uneven participation among team members, leading to resentment and discord within the team.
2. Untimely handoffs, as team members have priorities other than the project.
3. “I could have told you that” syndrome, where team members sit back and fail to warn the project manager about a problem that could have been avoided until it's too late.
4. “It's not me, it's THEM.” Looking at the project team as two or more groups rather than a single team. Often an Us vs. Them mentality prevails, which each faction vying for resources, or more time. Frequent “blamestorming” sessions occur.
5. Team members become sensitive to outside criticism, and distance themselves from the rest of the team. No one likes to be the subject of “watercooler” jokes, so when the project is subjected to negative comments from outside the project, the team member separates him-or herself from the project to avoid being blamed for its perceived problems.

The only way to deal with this problem is to embark on a program to build team member commitment, and that process starts as soon as the team is formed. According to Vijay Verma (1995, p. 36), “Project managers must create an environment that facilitates real teamwork and fosters human synergy.” There are many ways to do this, and there are lots of resources available for getting information about building an effective team. Here are a few quick tips:

• Create a set of ground rules for team behavior. These rules govern the work environment and contain such things as the decision-making process, how to conduct brainstorming sessions, meeting rules and behaviors, handling conflict, etc. These rules need to be set up at the outset of the project, while the team is still in the forming stage, as they will need to be enforced when the team gets to the storming stage.
• Use Responsibility Assignment Matrices (RAM). RACI charts (PMI, 2009, p. 221) are a good means to show the areas of the project that each team member is involved in.
• Create task and deliverable completion requirements. This way, each individual on the team knows what needs to be achieved to consider an item complete.
• Share ownership with individual team members. As the team starts moving into the norming stage, the project manager should begin sharing the leadership role. Parts of the project can be “owned” by individual team members, making them more committed to results in that area. Naming a team member as a risk owner would be one example of this.

Failure to Learn from History

“Those who cannot remember the past are condemned to repeat it.”

George Santayana (1905)

Santayana's advice is often cited as the reason project teams perform a final Lessons Learned session at the conclusion of a project. The whole process of performing a project's work, from initiation through closing, gives the team many areas in which to improve. Hopefully, lessons are learned and recorded throughout the project, and are analyzed and recorded as process improvements.

But, are the lessons really learned, and are they learned individually and organizationally? Take the following situation:

You are in your home, and you walk out the back door into your yard. There is a rake on the ground, tines pointing up, that you don't see. You step on the end of the rake, and the handle jumps up and hits you in the head. It hurts.

How many times would that have to happen to you before you decide to move the rake? Hopefully, the answer is one time!

Now, take the same situation, and substitute the phrase “your organization” for “you” in the above scenario. How many times would your organization have to step on the rake before it decides to fix the problem? Would it be more than 1? 10? 100?

Part of the problem revolves around how we store organizational information. Although we have access to large databases of information, and knowledge repositories, the fact remains that a large part of the lessons we learn on a project is stored in some individual's head. And when it becomes time to leverage that information, one has to find that individual, and extract the needed information. Let's hope that the individual still works for the organization, or can be found!

Look around your organization and see if you recognize any of these symptoms:

1. No knowledge repositories for collecting and retrieving information about projects and project management best practices. Or, if one is available, it is seldom used, or used sporadically.
2. No defined Process Improvement Plan for your project or any project.
3. Failure to collect and analyze project data to locate areas for improved performance.
4. The tendency to make the same mistakes from project to project.

If any of these symptoms look familiar, here are some tips as to how to proceed:

• History begins tomorrow! Become a data collector and observer of what works and what doesn't. Store the information in an accessible, central location to share among team members.
• Analyze the information. See where the problem areas are, and use the Pareto Principle to address the most frequent offenders.
• Change processes that don't work, or add no value. Know when it's time to do something different (move the rake).
• Make Lesson Learned an agenda item for each status meeting. Capture what you've learned in the last reporting period that can be put to use in the next reporting period. Don't wait until after the project is over to get better.
• Create categories for common problems. Use risk categories and issue categories to help in the identification, as well as responses to, these items.

Summary

This paper focused on 10 potentially dangerous ideas that organizations hold regarding project management and its use and practice. These ideas need to be recognized by the project manager and team and proactively addressed as part of the project planning processes. Examples of these concepts were examined along with suggestions for combating them and limiting their influence.