Developing a winning attitude!
You’ve seen the motivational posters in corporate conference rooms, office supply catalogs, and on the Internet. They encompass ideas like “Success,” “Team,” and “Perseverance.” All are designed to provide one with thoughts and ideas to help guide their actions throughout the day, and focus their thoughts on the job at hand. But, what about project managers? Where do they go to get inspired about working on their project?
This paper presents some focusing thoughts that project managers can use while on a project. Quotations and short phrases, often accompanied by a practical application or “war story,” will be cited as techniques to get across some key project management concepts and themes. Some simple statements will be listed, and the relevance of each will be explained within a project management context.
Many project managers feel as if the deck is stacked against them, and that they are playing a game where a successful outcome is difficult to achieve. There are some situations outside of the project manager's control that contribute to this thought. However, as the individual most responsible for achieving successful outcomes, the project manager needs to be the most inspired, focused, and optimistic member on the project team. The team takes its cues from the actions and words of its leader, the project manager.
The PMBOK® Guide is very good at outlining the “what's” and “why's” of project management, and even does a good job listing some effective tools and techniques for performing project tasks. But it leaves the “soft skill” development and commitment of the team to the individual project manager. How does the project manager get pumped up and excited to do this demanding job? This paper introduces a number of motivational topics and thoughts that the project manager can use to not only inspire himself/herself, but also remind the team about some important concepts.
How many times does the rake have to hit you in the head before you move the rake?
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? When is it time to move the rake? When do we stop doing what is painful and counterproductive and start doing something to remove the obstacles? We need to fix processes that simply do not work!
“You cannot dig a new hole by digging the same one deeper.”—Edward De Bono (De Bono, nd)
I am still amazed that the idea of doing something a certain way “because we’ve always done it this way” is still as prevalent as it is. Project teams stubbornly hang on to processes that simply do not work rather than examine the flawed process and make some changes. Procedures that have proven to be insufficient or flawed need to be adjusted or similar bad outcomes will result.
I often ask project teams to describe their processes and to answer the important question “How's that working for you?” If they say “Good”, then I reply, “Great, keep doing it. It's working!” However, if they reply that the process doesn’t work, then I tell them to stop. It's not working! You’ve already proven that it doesn’t work. Try something different. Know when it's time to dig a new hole!
Are you the chicken or the pig?
“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!
This simple little joke underscores the importance of having committed, and not merely involved, project stakeholders. This is especially true for the project team. There are many studies that address the importance of a “shared vision” among team members and about how the appropriate number of skilled resources available at the right times being a major contributor to project success. 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.”
Carrying the analogy a bit further, a project manager needs to have pigs, and not chickens, on his or her project. As the leader of this team, the project manager also better have a plan about how to build this commitment, especially given the challenges of a mobile workforce, virtual teams, and shrinking resource availability.
Uncommitted team members can have a number of negative impacts on the project, ranging from uneven participation to “Blamestorming” to a bunker mentality amongst the members where the team shields itself from outside criticism by isolating the team from other stakeholders and develops an “Us” vs. “Them” outlook. Dealing with this problem requires that you embark on a program to build team member commitment, and that process starts as soon as the team is formed.
Stay on your “MEDDS”!
Once, I was asked if I could recommend ONE thing that I thought would best help a project manager become more effective. Without much thought, I responded that project managers should stay on their MEDS. I have a preference for using acronyms (and aphorisms) to bring an idea into sharper focus, so realize that the MEDS means more than the obvious. At the time I was asked, MEDS was short for Manage Expectations/Defend Scope, but I’ve lately taken to change the idea to Manage Expectations/Define and Defend Scope (MEDDS).
Project scope management is one of the areas where projects typically go off the rail. As project managers, we spend a great deal of time dealing with scope issues, and many of the stakeholder concerns revolve around scope. Whether it was a poor job of requirements gathering, specification, or scope creep, many projects suffer from a failure to manage the scope of the project. And scope management is an all-or-nothing proposition—you’re either managing scope or you’re not! Scope management begins with the project objectives, moves through the definition and work breakdown structure (WBS) processes, and culminates once the product is accepted. All the while, we’re trying to manage and control the scope as we move through the project.
What you see in the above process is a lot of expectation setting and expectation management. The phrase “Stay on Your MEDDS!” attempts to deal with both managing expectations and dealing with scope. If you are going to take the time to define the scope, then it makes sense to apply an equal amount of effort defending it. By “defending” scope, I mean that all scope changes go thought the scope change control procedure outlined in the scope management plan. Many project issues go away when good scope management is applied.
The higher the SPF, the less you’ll get burned!
The dirty little secret of project reporting is when one is asked for a project status (what is the overall state of the project through the current date). They are also requesting a progress report (how has the project moved forward since the last report) and a forecast (where will the project end up). Many project managers have had to explain information in their reports to address all three aspects of project reporting.
One way to remember this is through the acronym SPF, which stands for status, progress and forecasts. It is also the abbreviation for skin protection factor, the measurement of a sunscreen's ability to mute the harmful rays of the sun. It's a handy reminder for project teams seeking protection from the heat of explaining the information in a less-than-complete project report.
Everything we do, or don’t do, creates an expectation!
Actions create an expectation for future behavior. For example, you might require that team members document their assumptions, or state the basis of their estimates, as part of the planning process. Reinforcing this idea at every team meeting will make it far easier to develop the consistent and ongoing behavior of the team. In a similar manner, actions that you do NOT perform will also create an expectation as sure as if you did something! For example, if you allow team members to be late submitting status reports, the expectation set is that timely submissions is not important—it's OK to submit reports late.
The clearest example of this concept is evidenced by the presence of “scope creep.” If additional requirements are sneaking their way into your list of deliverables, and are not dealt with using integrated change control, then the expectation that is set is that there is no change control! Either you practice scope management, or you don’t. What expectation do YOU want to set for your stakeholders?
People do things for THEIR reasons, not yours!
One of the best things about managing a project is that you get to work with people. And one of the worst things about working on a project is that you get to work with people. People can be far more unpredictable than other types of resources like equipment or materials. The effective project manager has learned the importance of motivating the project staff, as motivated team members tend to behave better and produce better results.
Building an effective project team is one the primary jobs of the project manager. It is imperative that the project manager view an effective team as one of the major deliverables the project needs to produce. 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. Team-building events, team member recognition, and team norms are all effective tools in helping to promote this idea.
“There are no facts about the future!”—David Hulett
Project Risk—An uncertain event or condition that, if it occurs, has a positive or negative effect on the project's objectives (PMI, 2008).
According to A Guide to the Project Management Body of Knowledge (PMBOK® Guide –Fourth Edition), project risk is really just uncertainty, but uncertainty that matters to our project, about what will happen in the future (PMI, 2008). But, as David Hulett, PhD, has pointed out, “there are no ‘facts’ about the future” (Hulett, 2004, pp. 4-5). What can happen can either be good, bad, or neutral. This is the whole idea around risk management—developing strategies and responses before the risk is realized. It is proactive, rather than reactive, and follows a prescribed set of activities to identify, assess, respond, and control the uncertainties of a project before they become issues that will siphon off resources and time to resolve.
Many of us are only concerned about bad outcomes, so our focus is on the potential negative impacts, but a strong case can be made for addressing those positive impacts of a potential risk. The other side of risk management is to identify, assess, respond, and control those opportunities that represent the potential positive outcome of a realized uncertainty. By not practicing proactive risk management, we can miss the benefits of these missed opportunities, and thereby deny the project team a chance to get ahead of any problems or issues, by managing these benefits.
On a project, the hard part is the soft part!
The PMBOK® Guide, Fourth Edition, lists “interpersonal skills” as a tool and technique used within three processes: Develop Project Team (PMI, 2008, p. 232), Manage Project Team (PMI, 2008, p. 240) and Manage Stakeholder Expectations (PMI, 2008, p. 264). They are often referred to as “soft skills,” in contrast to the more technical “hard skills” like calculating float, three-point estimating or calculating expected monetary value.
In my experience, this is the area where many project managers sometimes struggle. Often, project managers come from technical disciplines and were they are never formally trained in the “people” side of project management. This leads them to try to engineer solutions to people problems, often with no success. There are a number places where project managers can learn and develop these skills. Many organizations have realized the need for interpersonal skills for all types of managers, and have addressed this in their professional development offerings.
It's your job to train others how to interact with you!
I firmly believe that people will treat you in the manner that you allow them. When you encounter those situations where you are treated the way you prefer, then you need to reinforce that behavior. Similarly, if someone acts in manner that you feel is inappropriate, then you need to correct that behavior. As they say, “Fool me once, shame on you. Fool me twice, shame on me!”
With this thought in mind, I think that it is our job to train others how to interact with us. Set expectations, set ground rules, and reinforce them consistently. This may not completely eliminate bad behavior, but it sure will reduce it. Look at each instance of bad behavior as an opportunity to take corrective action. Remember, if others misbehave, and we allow it, it is our fault, not theirs. They’re only doing what we’ve trained them to do.
Because on a project, it just does!
Now that the triple constraint has been enhanced to the sextuple constraint in the PMBOK® Guide–Fourth Edition PMI, 2008, p. 6), it is important for the project team to understand the interrelationships among the various project objectives. As the PMBOK® Guide states: “The relationship among these factors is such that if any one factor changes, at least one other factor is likely to be affected” (PMI, 2008, p. 7). Due to these relationships and interdependencies, every discussion and decision made on the project requires an examination of the multiple impacts any choice would cause. Options and choices take time because of this fact.
When asked for an answer to any question regarding the project, the conditional response, “It Depends,” is, in my mind, the only one that makes sense. All the parts of a project plan are interconnected; changes to one part will flow into all the others. (Why do you think it's called “Perform Integrated Change Control”?) Of course, giving this response leads to the inevitable “on what?” follow up, and that is a good thing. By asking the “on what?” questions, the stakeholder has opened the door to a discussion on the potential impacts of a change—all good things for a project manager and stakeholder to discuss. I use this phrase to begin the discussion of tradeoffs necessary in any type of baseline change. “It depends” allows one to sketch out the various scenarios that may occur should a change in the project plan, and the agreed-upon success criteria.
Where you sit is where you stand!
Andrew Schlam, PMP®, an associate of mine, uses this term to illustrate how people's opinions are determined by their role at the time. Have you ever noticed that a person's position on a particular topic is often governed by the impact that topic has upon their specific situation? For example, have you ever noticed that many of the negative stakeholders on your project are found in the area most impacted by your project? People do things for their reasons, not yours.
In another application of this idea, have you ever noticed a change in attitude toward workers once a new manager has been promoted? The attitude of the new manager has changed—he or she is now viewing things from a different chair. Understanding this idea will help when it comes to understanding stakeholder's stance on a particular issue or concern. Try to explore the root cause of their stance, and see what you can do to manage that expectation.
Create and use lessons learned!
“Those who cannot remember the past are condemned to repeat it.—George Santayana (1905)
It is for this reason that many project teams conduct a lessons learned session at the conclusion of a project. Lots of things happen on a real project, some planned for and some occur unexpectedly. There are lessons to be captured in whatever happens on a project and it is the wise project team that captures all the incremental process improvements that can be identified and used to update any related management plan.
But the real question is “Are the lessons really learned?” Before you answer, consider the following situation: How many times has the same error occurred on more than one project in your organization? How many times had this defective process occurred in the past and actually captured in a lesson learned database? And yet, in spite of our efforts for continuous improvement, the error occurred once again. So, the question is: Was the lesson really learned or was it merely recorded as our methodology said it should be recorded?
History begins tomorrow!
Most of the problems in this area stem from the methods and processes organizations use to store this information. Many organizations rely on individuals to be the repository for project management best practices. These organizations’ idea of knowledge sharing is “Mary did a project like that a year ago. Ask Mary what the top five risks were on her project.” The problem with the “Hey, Mary” database is that often Mary is not available, or no longer at the organization, or worse yet, Mary was a consultant and she's now using that information for the betterment of another organization.
Even those organizations that have knowledge repositories for this collective project information often don’t make the process of sharing easy or convenient. I have often encountered individuals in an organization who did not know about the repository, or where it was located, or how to access it. Having useful information that no one can actually use is the ultimate in ineffectiveness!
“Don’t polish BB's.”—Steve Potter
A friend of mine, Steve Potter, PMP®, coined this phrase to illustrate the idea that there is limit to just how detailed a project plan needs to be. The skill in project management lies in the understanding that you plan only to the level of detail and control that the project demands, and no further. It goes along with the concept of tailoring your processes to fit the project at hand, but gives a neat visual and catch-phrase that you can effectively use with your team.
Practice “Baby Bear” Project Management!
In his book, Just Enough Project Management, Curtis Cook (2005, p. x) states “Many organizations have embraced project management but have adopted the ‘700-page-book approach’ with dozens of process steps and associated inputs, outputs, and tools and techniques. Yet, the statistics cited by major research firms tell us that fewer than 50 percent of our projects achieve their objectives.” These days where agile and lean dominate any discussion of business processes, it is imperative that project teams use a level of process and control required, and no more. We can no longer afford to overlay the cost of an excessive process and methodology to a project. Customers are looking for ways to cut project costs, and project management is one place where they look first. We must tailor the amount of process to the project at hand using just the right amount of project management.
To give a visual to this idea, I use the story of Goldilocks and the Three Bears. If you remember the story, Goldilocks enters the house of the Papa, Mama, and Baby Bear. She tries various things in the house from porridge (why is there always porridge in fairy tales?), the chairs and the beds. Papa Bear's stuff is “too hot!” or “too hard!” while Mama Bear's is “too cold!” or “too Soft!.” But Baby Bear's stuff is always “just right!” And that's the secret to figuring out how much project management a project needs. Not too much, certainly not too little. Just the right amount will work great.
But how does one determine what “just right” is? Once again, we return to lessons learned and information from past projects. Information about how much time was spent on project management activities on past projects will give a clear indication of how much time was devoted to these activities. Having project management as a Level 2 WBS deliverable is a good way to go about capturing this information. The lessons learned process can evaluate if the time spent was spent well. Again, it is beneficial to the organization if this information is shared.
Why are all the bottlenecks at the top of the bottle?
As stated earlier, developing a project team is one of the major responsibilities of a project manager. As teams go through their development cycle, and start to become a performing team, there is less reliance on the project manager to take charge to get things done. Team members become more self-directed and self-reliant, and any interference in this process actually gets in the way of productivity.
Some project managers don’t like to relinquish the controls and actually interfere with the team development process. Instead of sharing the leadership role as the team progresses, these project leaders insist on being in charge and have their hands in everything. The net result is that they become the reason for project issues and have caused themselves problems. Understanding the team development process, and how the team leader needs to adapt to each stage, is critical if you truly want to develop a high-performing team.
It's a recipe, not a guarantee!
Project managers and professional gamblers have at least one thing in common: neither can guarantee success, but take great care in tilting the odds in their favor. That is the essence of project management—following prescribed processes and best practices to increase the likelihood of a successful outcome. Good project managers use information from the past in the present to plan the future. And since the future is uncertain, present-day activities are all focused on increasing the odds of achieving the project's objectives.
Many stakeholders have a mistaken notion about all of this. They ask for definitive estimates at the beginning of the project—the time where the greatest amount of uncertainty exists. Cost and schedule reserves are questioned and reduced, as if they were padding just to make the project team look good. It takes a strong, confident project manager to explain the rationale behind sound project management principles. Remember, it's not about guarantees, but rather about doing what's best to achieve the desired outcomes.
It's All About Me!
“You increase the likelihood of customer acceptance and delight at the end of your project if your manage stakeholder expectations from concept through delivery.”
What's your reaction to the above quote? Would you agree?
Did you observe that not once were the phrases “On Time,” “On Budget,” or “Within Specifications” used? The operative phrase used was “manage stakeholder expectations,” which interestingly was significant enough to be included as a PMBOK® Guide process—10.4 – Manage Stakeholder Expectations (PMI, 2008, p. 261). According to the PMBOK® Guide, “actively managing stakeholder expectations decreases the risk that the project will fail to meet its goals and objectives due to unresolved stakeholder issues, and limits disruptions during the project” (PMI, 2008, p. 262).
Using this quote as our guide, we can see that the primary responsibility of a project manager is to manage stakeholder expectations and a more apt job title might be “expectations manager.” If that's the case, then a phrase that every project manager can use as a guideline would be:
“It's All About ME!”
Of course, in this context, ME is short for Managing Expectations (Baker, 2006). The job of the project manager, then, is to SET and MANAGE stakeholder expectations throughout the project. This translates to defining and defending scope, identifying, analyzing, planning responses, and monitoring and controlling risks, proactively planning and delivering quality, etc. Managing communications with the stakeholders would also be a key part of this process. Everything we do should be from the point of view of expectation management. In short, expectations management IS project management!
If I don’t see you in the future, I’ll see you in the pasture!
Walter Shewhart and W. Edwards Deming gave us the model for this when they introduced the concept of (PDCA). (PCDA, 2011) The steps are simple. First, perform a gap analysis to uncover the need for a new product, service, or result. Then, develop the plan, execute it, check for variances, and act on any variance or process improvement. The model has been used since the 1950s.
It has been my experience that we’re very good at the Do and Check part. Planning has gotten better, although there are still some Nike school of project management disciples (“Just Do It!”). It's the Act part that needs improvement. We take corrective and preventive actions based upon changing events in our project, but many times fail to correct the faulty or inefficient processes that led us there. Part of “Act” is looking at what works and doing more of it, and stop doing what doesn’t work. Fix the broken processes, or at least stop using them! Albert Einstein (nd) defined insanity as “Doing the same thing over and over again, and expecting different results.”
A simple tool I like to use is a technique called Plus/Delta (+/Δ) (Verzuh, 2009, p. 130). Plus represents all the things we have been doing well as a team, and need to more of. Delta represents all the things that are not working and we need to do differently the next time. I often recommend that teams do Plus/Deltas every week to make sure that they are continually improving as a team.
This paper focused on some ideas, tools, and techniques designed to help working project managers cope with the various challenges presented to them while managing a project. Many of the ideas were presented with a story or analogy, or some pithy statements to help remember the concept.
Baker, Ernest. (2006, October). It's all about ME (managing expectations)! PMI Global Congress 2006, North America, Seattle, WA.
Bull, R. Camper. (2008, October). Project leadership: The next step in project management on the way to becoming a master project manager™. PMI Global Congress 2008, North America, Denver, CO.
Cook, Curtis R. (2005). Just enough project management. New York: McGraw-Hill
DeBono, Edward. (nd). The De Bono Group – lateral reading. Retrieved July 14, 2011, from http://www.debonogroup.com/lateral_reading.php
Einstein, Albert. (nd). Brainy quotes. Retrieved July 14, 2011, from http://www.brainyquote.com/quotes/quotes/a/alberteins133991.html
Hulett, D. T. (2004, 4th Qtr). What every executive needs to know about project risk management. Flying High [Electronic Version] Retrieved on July 5, 2007 from http://www.pmi-adsig.org/Newsletters_Print/A&D%20SIG%20Newsletter%20-%204th%20Qtr.%202004_324%20KB.pdf
PDCA (2011, 27 July) In Wikipedia, the free encyclopedia. Retrieved from http://en.wikipedia.org/wiki/PDCA
Project Management Institute (PMI). (2008). A guide to the project management body of knowledge (PMBOK® guide) (fourth edition). Newtown Square, PA: Project Management Institute.
Santayana, George. (1905). The life of reason, volume 1, Reason in common sense. New York: Dover Publications, Inc.
Verma, Vijay K. (1995). The human aspects of project management: Organizing projects for success. Newtown Square, PA: Project Management Institute.
Verzuh, Eric. (2009). Team leadership. Seattle, WA: The Versatile Company.
© 2011, Ernest Baker, PMP
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas, TX