- Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
- Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them.
- Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase.
- Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need.
- Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources.
More posts in Project Delivery
- The current schedule position of the project. Example: "We are two weeks late."
- The current budget position of the project. Example: "We are at planned budget."
- Progress toward the next key milestones. Example: "We are 50 percent complete with the process model."
- Stoplights are not progressive. Project stoplights typically have only three indications of status. They can't show a range of progressive tolerance, trends or rates of change. For example, a yellow stoplight can be overly optimistic if the value for that stoplight is just shy of the range for red.
- Stoplight bands mean different things to different measurements. Stoplights break down into bands of tolerance ranges. For example, zero to 5 percent variance would be green, 5 to 10 percent variance would be yellow and above 10 percent would be red. The problem is, project measurement indicators might not follow a common range. For example, how realistic is it to measure customer satisfaction with the same band as test case validation? While test case validation might make sense at 7 percent, it would be discouraging if just 7 percent of your customers were happy with your project.
- Stoplights can be "gamed." A major vulnerability of project stoplights is that they can be manipulated by project managers and sponsors when either wants to defer an unfavorable status. Despite the actual value of the project measurement, the project manager or sponsor will leave the stoplight to a green (favorable) value. This "gaming" of project stoplights usually precedes the inevitable -- rapid acceleration of stoplights to a red (danger) value when hidden details are discovered.
As a project manager, many times I find myself to be the driver, serving as the catalyst for movement and action.
A driver is someone who takes on the responsibility and accountability for the project deliverables. So, in addition to day-to-day team management, I drive the alignment of the team to the project plan, maintain quality standards with the delivered work and determine the project execution and communication methods.
Enablers act as complements to the driver. They go beyond the task of effectively driving the project activities and focus on the elements that empower the team by fostering a strong work ethic, high morale, satisfaction, and attaining personal and professional accomplishments. Enablers are very good at working with all the team members -- internal and external to the project and organization -- in such a way that allows everyone on the team to:
• Align to the overall goal
• Emotionally connect to why the project's overarching goal is important
• See their own purpose on the team through their contribution and knowledge
• Feel validated for their inputs and recognized for their efforts and outputs
Enablers add life and color to the project. They are known as the glue that keeps the team together. An enabler can exist within the project team, and he or she doesn't have to be the project manager.
The great value of project managers serving as enablers is that -- when combined with their authority, they are able to drive the project and enable their teams to deliver higher quality projects and longer lasting results. This value is reflected in the quality of the product or service, processes and process adoption rate, plus greater organizational awareness and integration.
Are you an enabler or a driver? Do you think it's most beneficial to have the project manager as the driver or the enabler? Why?