Improving senior management's project IQ-- what's a project manager to do?
What is your senior management's project IQ? Do they buy into project management and the benefits it provides to the organization if done correctly? The most common complaint of practicing project managers is that senior management does not support the practices of good project management espoused by the Project Management Institute (PMI®). If senior management knew the process and what assistance project managers expected from them, they would be more understanding and supportive in the efforts of the project manager. Project managers have a very good idea of the things they want senior management to do to make their jobs more effective and efficient.
We asked over 400 practicing project managers to list five items that were most important to them regarding senior management support. From this input we developed a “Top Ten” list of things project managers wish their bosses knew about supporting project managers. We also asked what should be done to solve the problems. We organized the solutions into five categories. Those five categories gave us a starting place to influence senior management and their support of project management.
Although the list is not surprising to practicing project managers, the order was a bit different than expected. Let's look at the list in the true Letterman fashion, starting with ten and working our way to the number one answer.
10. Staff Development
Project managers feel that senior management is not providing enough time, money, and support for their development and advancement. This includes things like paying for the Project Management Professional (PMP®) certification.
9. Create a Project Management Office (PMO)
Senior management needs to create and support a project management office that uses standardized processes and good historical information. Project managers want to have the synergy from having a dedicated group focused on project management supporting each other.
8. Realistic Expectations
In order to provide senior management with cost, schedule and performance reliability, project managers need senior management to allow them adequate time to complete planning. Senior management must also have realistic expectations of what they can get with the constraints they apply to the project.
7. Open Communications
Project managers want their bosses to foster open, honest, and full communication. Part of this effort should be devoted to being accessible to the project team. It also involves providing the project team with feedback and being receptive to feedback from the project team.
6. Empower Project Managers
Decisions are made every day on projects. Senior management needs to empower project managers to made decisions and then support those decisions.
5. Support Project Managers
Support for the project manager and the project team is not always provided. Senior management needs to be proactive in their support, staying engaged and accessible. Finally, they should initiate projects effectively by bringing the project manager on early.
4. Clear Objectives
Giving clear project definitions, priorities, expectations, goals, and roles and responsibilities will make the project manager's job easier. Once these are set, senior management needs to stick with them and avoid changes that do not add significant value to the project.
3. Promote Project Management
As leaders in the organization, senior management must promote project management principles to the organization, sponsors, stakeholders, and customers. They must also encourage training in project management for those who are not familiar with its benefits.
2. Project Resources
To stabilize project schedules and resource utilization, senior management must acquire, free-up, protect, and budget resources. Project management activities consume time and money that needs to be programmed into the project schedule and budget.
And finally, the number one thing project managers want senior management to do to better support their project management activities is:
1. Project Management Principles
Senior management must value, understand, use and support proper project management principles.
Understanding what issues need to be addressed is only the first step. Without implementation of the ideas, nothing will change and we will continue to be plagued by the same problems. We therefore need to address how to implement the solutions and how to garner senior management's acceptance of these solutions.
When I examined at the results of the study, I found many good ideas for how to solve the problems addressed above. However, I noted that over 95% of the solutions were for someone else to take action. This corresponds well to an impression I have had for a number of years based upon teaching project managers. The impression is that project managers do not like to take responsibility for their actions. For example, you ask a project manager why their project is late and you will get all sorts of reasons; the customer added scope, the functional manager pulled my team members, the team member didn't consider risks of the activity, and so forth. All of these reasons pass the blame to someone other than the project manager and their poor project management skills.
One of the top ten issues is that project managers want senior management to empower them and support their decisions. Why would senior management want to do this if the project manager won't accept responsibility for their project's results? Although it is not a response that I found in the survey results, the results have led to the conclusion that the number one way to solve these problems is to take responsibility.
Some of the responses were humorous to me. For example one solution suggested to get senior management to value project management was to “promote me to a senior manager.” A solution for supporting the project manager and team was to “show interest in the project (but not TOO much).” And finally one that I really appreciated to solve the problem of promoting project management within the organization was to “take a class from Jeff.” But these were the exceptions; most of the solutions recommended were a well thought-out look at the problem and the solution in their own environment.
We work in many different environments and therefore a cookie cutter approach to implementation will not work. We need to look at the solutions with blinders off and on. First we need them off to be able to see the impact of these issues on our organization. Are there things that we are doing that directly contribute to perpetuating the problem? We need to put the blinders on once we understand the situation to make sure solutions will work in our political and social corporate environment.
As I said earlier, I ran into a problem that the responses were directed at others taking action, not the project managers. I called on project managers to look again at solutions to the problems, but this time from the project manager's perspective. What can YOU do to make it happen in your organization? I organized the data into five major categories. I then tried to look for actions by project managers that would take us to goal.
The five groups are communication, organizational training, cost and resource management, setting expectations and finally, using the process. Many of the solutions are repeated across the top ten list. I have indicated where the solutions below will have a positive impact by detailing the top ten items addressed by each category. We will look at each one and see specific actions building to a more project-supportive environment.
Communication (Supports 1, 4, 7 and 8)
One of the problems we have is addressing problems OF our boss WITH our boss. How do we diplomatically say they are the problem without impacting our opportunity for continued employment? One recommendation involves removing the “I” and “we” and looking at an outsider's situation. Use the list of problems above to initiate discussion. “Hey boss, I got this list of problems OTHER companies are having. I wonder how many of them are common to our experience and if their solutions might help us out.” When addressed this way, you do not isolate your boss, it is a problem with many companies; how can we benefit from their efforts?
In some organizations, shooting the messenger is the norm. You are expected to always have good news, and thus you always have good news. We manipulate the data in such a way that management hears what they want to hear. This is not only self-defeating, but is unethical. So, if they shoot the messenger, bring the message in a different way. Isn't that the same thing as manipulating the data? I would suggest the problem is in the way you present the issue, not the message alone. Many project managers encounter an issue and quickly notify senior management. Senior management feels that they have to find a solution, now! That is their job isn't it, solving problems? They get frustrated with always having to provide the solutions. To avoid this, we as project managers are responsible for not just bringing the issues, but also the solutions. This is the difference.
Another issue that came up often in the survey was the use (or lack thereof) of historical data from past projects. We complain that we do not have the historical information because there is no support for keeping it in the organization. Here we need to step up and, as Nike used to say, “Just do it!” Keep your own historical records. They will not be complete, but they are more than you would have otherwise. On your next project, start reusing the “templates” you created in the previous one. The historical results will also give you information on who to trust in estimating. When senior management sees it working, your repository will be the nucleus of the organizational repository.
Finally, if you are worried about communication, what better tool to help you than a communications plan. PMI says that we spend up to 90% of our time communicating. With this much effort, we should have a plan for how we will manage all that work. The communications plan takes the list of stakeholders and goes through one at a time to determine what information is needed and the best ways to provide that information. This is a two-way flow and thus we need to look at it from both the sender's and receiver's perspectives. Address the mode of communication, the frequency of communication, the level of detail, the urgency of the information, etc., for each stakeholder. Then, combine all the details into a cohesive plan.
Communication is important for the project manager to do right. We need to start a dialog with our bosses, present solutions, not just problems, begin keeping historical records, and use a communications plan. Doing these things will open a two-way dialog with the goal of finding solutions.
Training the organization (Supports 1, 3, 4, 7 and 8)
This solution ties into communication, but is a special subset. Here we are looking to train the non-core stakeholders. These would include end users, team members' boss' boss, financial analysts, etc. The premise here is that if these individuals do not understand the benefits of project management, they will not be on the supporting side of the fence. So, in effect, you are selling project management to a reluctant organization.
We need to look at options for selling project management. One that should be a part of every group's efforts is to train all the project managers on the process used in your organization and ensure that they use it. This seems obvious, but many companies have pockets of project management activity and each is using their own “brand” rather than having a cohesive plan for implementation.
The second place to begin is with your boss. If he is not the advocate you want or expect, you need to mentor him on the benefits of project management. Sometimes it is more palatable for senior management to hear the story from an outside source. An individual worked with a group of project managers who had been trying to get senior management to understand the benefits of project management. They also wanted support in their efforts to expand project management of the information systems department. They were unable to make forward progress until the project managers decided to bring in outside help. The outside individual met with them and came up with a political and organizational plan and presentation to senior management for moving them to the next step. The presentation was well received and made a significant push in the right direction. The moral is that although nothing different was said from what the project management group had been saying, it came from an outside source who “obviously” had more insight and knowledge than the internal employees.
Just addressing the topic with senior management is a great start, get top-down support, but you will also need to address training with the rest of the organization. How do you get functional managers and team members to understand project management well enough to support you well? Two activities have gone a long way in getting that universal support. The first is to hold a project management training class for team members and other affected stakeholders. This is a costly and time consuming option and if you don't have senior management support already, it will not be highly received. Therefore, holding brown bag sessions periodically to discuss key project management topics is very effective. Ensure that you do not try to put too much into each session, but make the sessions worthwhile. This can be used in conjunction with rollouts of additional procedures and tool improvements as you implement process improvements.
If your organization doesn't understand the benefits of project management, you need to plan for getting them the information to develop well-informed opinions of its benefit. This starts with making sure all of the organization's project managers understand your brand of project management, continues with mentoring your boss and then selling it to the entire organization.
Cost/resource management (Supports 2, 4, 5 and 6)
The survey identified the number two problem as resources and protecting them for the project. Experienced project managers know this has always been a problem in matrix organizations. They also know what to do about it. Unfortunately, the biggest issue here is project managers don't do what they know they need to do. We need to prioritize across projects and organizational commitments; to remove padding by identifying and managing reserves; to plan programmatically, not functionally, and to say “No” when required for a successful project.
These are all large changes that cannot be done alone or without possible impact to future employment. Some organizations are so set in their ways that implementing these would be a drastic change, not likely to be accepted. We need to look at how we make the transition in small steps. Let's first look at prioritization.
What can we do if senior management doesn't prioritize projects against each other and, more importantly, against the operational demands on our resources, human and other? It starts with accountability on our part. If you say you need someone for a set period of time, be sure you are ready on time and you return that person on time. Poor management of the project schedule will cause ripples across all the activities the individual is responsible for completing. If we prove that we hold to our end of the “deal,” the functional manager trusts us more and is more willing to put his people on our project, knowing they will be back “on time.”
Next we need to look at cross-project utilization. You need to have a realistic plan that can be used to forecast resource usage. Many project managers shift the blame to others because they cannot plan until they know when the resources will be available. This is an iterative process and if you have your draft plan, it can be discussed and negotiated to reach a meaningful and realistic solution. By using this process you will be “making senior management prioritize” projects. You give them the possible situation: two projects need the same resource. Which will get it? Not getting resources when needed is a risk you incorporate into the project plan and have a predefined solution built for when the risk event happens. In order for this to work we need to build from the ground up, starting with your project.
Another reason that we get unrealistic schedules is the practice of padding. We all have played the padding game with senior management. You know the game, where you get estimates for the activities and you roll them up into a project estimate. You take that estimate into your boss and she, knowing that you have padding in the estimates, tells you to cut it by 10 percent. You make a fuss but go off to work with your team to cut 10 percent. You bring the new estimate back to your boss and she tells you to take another 5 percent off. You put up more of a fuss this time, knowing that you have taken out most of the pad. However, the boss is insistent and sends you off to make the cut. You struggle with your team and come up with a 4.5 percent cut. You bring this back to the boss. She is not happy and asks for another 2 percent cut. You are adamant this time that you need every bit of the planned time and budget to successfully complete the project. You put up enough of a fuss that she realizes she has removed all the padding. What do we learn from these encounters? Negatively, we learn to pad more. Or worse yet, we get adamant early. Even worse yet, we use a combination of the two. This is NOT the solution.
Padding causes more problems than just management cut drills; it also causes bad historical data. If you remember Parkinson's Law, “work expands so as to fill the time available for its completion.” So the team members give you padded estimates. When the time comes, you give them that estimate to use in doing the work. You have given them their “real” estimate and your reserve. But you are supposed to control the reserve, why did you give it away? Work will now expand to fill the time available, to the estimate and the reserve. Your reserve gets used without your control. It would be better when the activity starts to give the team member an unpadded estimate to meet and keep the reserve to be managed by you for expected risk events. By not allowing padding, you build a reputation for realistic estimates causing senior management to be more accepting of your estimates without confiscation.
How is this going to work? If you can get your boss to support you in a prototype project, you could keep two sets of books, one going up the chain of command with the padding and one with actual estimates and reserves for use with your team. After the project you can show how the results were much better than using the accepted way. We need to get trust built so senior management doesn't “confiscate” any reserve you admit to.
As we plan, we can help or hinder communication by the way we lay out the project in the work breakdown structure. Some project managers prefer to break the project functionally. This is great in seeing the effort required by each functional organization and allows easy discussion of the activities, but it has its drawbacks as well. One of the drawbacks is that there is little or no cross-functional communication. Each functional group has their work to do and does not “see” how their activities affect other groups. Planning programmatically will allow you to build a more cohesive team by showing the cross-functional dependencies. If you are using the project life cycle as your first level, you are doing it in a way to get the best cross-functional visibility.
Finally, you need to be able to say “NO.” This would be what we called in the military a CLM (or career limiting move). My training in the military taught me to always say “Yes”. But that yes wasn't an unqualified yes. Maybe it is better to say “Yes, BUT…” By responding this way, we remind senior management or the customer of the consequences of their actions and let them say no. If they are willing to accept the consequence, DOCUMENT that acceptance and adjust the baseline for the approved change. This adds responsibilities to you and your team to do a good analysis job on the impacts and options to move forward, viable solutions within the context of the project. It is never wrong to provide senior management with the information they need to make an informed decision.
Although this area presents the most opportunity for you to make CLMs, it also is where we can introduce the most impact on the success factors of our projects. We need to build realistic plans and build trust with senior management by giving them the full story each time.
Set expectations (Supports 1, 2, 4, 5, 6 and 8)
This area must have hit hot buttons of the respondents. The respondents are pushing for open and honest communications, knowing what senior management wants up front, tracking “problem” areas and not being unrealistic about senior management's demands of the project. Balancing of the triple constraint played an important role in these responses.
Many projects start out with a quick meeting with the project champion where they list the key items and the project manager is then to go off and produce. If senior management is not “seeing” progress, they want to know why there is no work being done. Expectations that you will follow the process were not communicated well. Respondents suggest that if the project manager doesn't stand up for getting clear definition of the project up front, you are setting yourself up for failure, or at least for many changes during project execution. There are two aspects of this, defining roles and responsibilities and defining scope.
Let's first look at project roles and responsibilities. One nice thing is that project roles and responsibilities are reusable! The hard part is getting them in writing the first time. After that first time, you only need to review them and adjust for areas specific to the new project. The more people know what is expected of them, the easier it is for them to meet those expectations. Take time to define these for all the stakeholders of the project. There will be fewer misunderstandings and then subsequent changes during the project.
Scope definition has always been problematic for project managers. They have this need to make the customer happy. Saying no to a customer request will impact the customer's impression of your ability to satisfy them. In many cases, the customers are just pushing to see how much they can get away with. If you set expectations that there will be a good requirements definition done up front and then all changes will follow the change process, your project will run smoother and be far more successful. How can we get better definition up front?
First we need to set the expectation that we will require better definition up front and changes will not be accepted without the appropriate modifications to the baselines based upon the impacts of those changes. This is the old saying that “you cannot have something for nothing.” We must balance the triple constraint. I bet if you were to ask senior management what is most important on your project; time, cost or scope, they would say all three are MOST important. Since “a change in one will cause a change in one or both of the others,” there must be a precedence among the three constraints. Your job is to find out what is the order. It was suggested that you should use a what-if drill to help glean this information. If we run into a problem that will delay implementation, what should we do? Can we increase costs by adding people? Can we cut scope to meet the date or can the date slip as long as we don't go over budget and produce the right scope? By doing this for each of the constraints we will then understand the order and be able to adjust correctly throughout the project.
Next, we need to make sure we are capturing the real requirements. Many times senior management and the customer want to tell us “what to do” rather than “what they need.” Project managers feel that they are pulling teeth trying to get the real requirements from senior management and the customer. We need to have good definition up front or implementing changes will be the main effort of the project. There are a few tools in our project management tool bags to help us do it better. Understanding the new process is important. Sit down with the customer and try to flow out the new process based upon the requirements. What happens at each step; who is involved; how is the process different from today? As you walk through each step, look for issues. Identify how the issues will impact other processes and groups. Just stepping through the process will clear up many changes that could happen.
Another tool, an interview session, will work to draw out requirements from hesitant or reluctant stakeholders. Your goal is to flesh out the details as much as possible by using open-ended questions. For example: What will the end product look like? How would you envision this product being used? Have the questions drawn up ahead of time so the session runs smoothly.
Finally, there are many ways we can help the customer and senior management determine their real needs if they can't document them; working with individuals who will “know it when they see it.” Prototypes, demos, visiting installed sites to pick out the best of each, etc. will help improve the understanding of what is possible and what is possible within the constraints of the project.
Setting expectations is the role of the project manager. If you don't do it, no one will. Without clear expectations there is a high risk of project delays, changes, and possibly failure.
Use the process (Supports 1, 9 and 10)
This category offers many concrete actions the project manager can take to show and prove the value of project management to the organization. The recommended actions ranged from showing value by using it, starting with the key items and build from there, avoiding the big bang approach, starting a “users' group,” defining senior management's role during each phase, to plan, budget and schedule staff development.
Even though using the PMI process is not required, start using it. Keep accurate records, so when the time comes you can show results of using the process against not using it. This will take extra time on your part, but with a long term perspective, you will be gathering the support you will need to institutionalize the process in your organization.
If an organization doesn't currently use the entire PMI process, it is highly likely the organization is using some parts of the process. Working with the other project managers and your boss, determine which steps are most acceptable and of most value to the organization and start using those. After these become ingrained, you will be able to add to the process, additional value-added procedures.
Many companies try to make one large change to reduce the perturbations to the organization. Most find it was a bad idea! Start as we outlined above with those steps that are already being used or will add the most value and build from there. In organizations there is reluctance for large changes and we need to work to counter this. Therefore avoid the big bang method of deployment.
If senior management doesn't support a consistent process for all project managers, do it yourself. Gather the organization's project managers and create a “users' group.” The group will be led by the project managers to determine core processes and procedures to implement across the functional groups. You are building the core of the future project office. With historical information, you will be able to show the proof of return on investment of consistent project management procedures.
Senior management in immature project management organizations is often unsure about their role in the project management procedures. Two actions can have a dramatic effect on their understanding and support. The first is to prepare them with an understanding of your expectations of THEM in each phase of the project. They look to add value to the project and many times are unaware of where they can add value. By laying out the roles, you help them focus their efforts in a productive way and reduce interference. Another tool for senior management's use is a list of questions they can ask of the project managers during each phase. Since they are unsure of their role, laying out specific questions and things they should be concerned with is important for directing senior management to more positive actions.
Successful project management is a journey, it is not a destination. As we grow in our experience and abilities to manage projects, we must stay attuned to the improvements and changes in project management. We will also need to re-look at the basics periodically to refresh our understanding of what is important and why. As we work in our environments, we sometimes lock ourselves into doing project management in only one way. Training helps to take off the organizational blinders and see our actions from a fresh perspective. We need to push for support from management for the developmental funding. We also must take the step to schedule it. In most environments, there is never a “good” time to take training and thus it is never scheduled nor attended. Plan it into the budget each year, schedule it ahead of time and work to ensure issues don't get into the way of attending the training. Also, look to the local chapter of PMI. The chapters are there to help support and mentor you in better project management practices. Bring your problems with you to the dinner meeting and offer your problem as a discussion item for your table. You will be surprised at the responses and ideas you can get!
If you are not using the process, how do you expect your management to support implementing the process for all project managers?
Project managers work in many different environments and therefore a cookie cutter approach to implementation will not work. We need to take the results of the survey and assess with our senior management which items apply to our own situation. Using some of the suggestions listed above will move us in the right direction to have better communication, to incorporate training of project management into the organization, to manage cost and schedule, to set expectations and finally to use the process. I commend you for taking the first step by reading this paper. I wish you success in your brand of implementation. Please let me know how it works out.
Mulcahy, R. (2003) PMP Exam prep. Minneapolis, MN: RMC Publications, Inc.
Parkinson, C. (1958) Parkinson's law: The pursuit of progress, London, John Murray
PMI (2000) A Guide to the Project Management Body Of Knowledge (2000 ed), Newtown Square, PA: Project Management Institute, Inc.
© 2004, RMC Project Management Inc., Jeffrey S. Nielsen
Originally published as a part of 2004 PMI Global Congress Proceedings – Anaheim, California-