Project Management Screw-up #1: We Weren't Addressing the Right Problem
This chapter is from the book
This chapter is from the book
This chapter is from the book
Virtually every (rational) project has at its core a need to solve some problem that is perceived by someone. Problems can manifest themselves as barriers to getting something done ("We can't possibly ship 10,000 units/week with our existing systems") or as opportunity to do something better ("We need to reduce the cost of processing purchase orders by 20%"). In any event, there is a desire to do something tomorrow that can't be achieved today.
Admittedly, some of the most fun projects that I have worked on have been the "Omigosh, we need to get this done or else" projects. I have seen the greatest clarity of purpose on projects where there was a very real and tangible consequence to not completing the project successfully. One outstanding example of this that affected virtually every business on earth was the Y2K computer scare. One of my jobs was ensuring that our mission-critical vendors were adequately prepared for Y2K and that there would not be any business interruption to our company as a result of a vendor's failure to perform. Everyone knew what the problem was: computer systems that only used a two-digit year and assumed that the "19" in the first two years were going to assume a year of "1900" on January 1, 2000 and, depending on the system, everything from power grids to air traffic systems to small appliances had the potential to malfunction. You all know the story: 1/1/2000 came and went with a minimum of problems; not because the scare was overblown, but because there were billions of dollars spent worldwide ensuring that a problem didn't occur. There was tremendous clarity of purpose and a very real and tangible consequence if no action had been taken.
HOW IT HAPPENS
There's a poorly articulated mission statement
Many projects that I have seen had a mission statement that was either vague, unrealistic, or simply didn't exist. Saying, "We need to reduce costs" is admirable and desirable, but is not something a project team can surgically execute simply because it is not clear what the project is and when the project will be complete.
The best mission statements that I have seen have the following components:
-
What needs to be done
-
When it needs to be done
-
What measure will be used to evaluate success
One project that I worked on focused on vendors entering invoices directly into a company's invoicing system via the Internet as opposed to invoicing via a hardcopy document. The mission statement for the project was as follows:
"We need to reduce the cost of processing invoices by 50% by March 1, while ensuring that vendors are paid within terms 100% of the time."
The project had a clear what (reduce the cost of processing invoices), a clear when (March 1) and clear measure (50% cost of processing and 100% of the time payment within terms). In the invoicing project, we were able to stay laser-focused on what we needed to do and make sure that all the project constituents stayed in sync because we had a super-focused mission statement.
There's an inconsistent understanding of what the problem is
On projects where you have multiple stakeholder groups, there is a very strong likelihood that each stakeholder group is going to have a specific agenda that they bring to the project. Some may view what you perceive to be the problem as not being a problem at all. Very early on in your project, it is crucial to get a very consistent view of what the project is intended to accomplish via the use of the clear mission statement and ensure that the constituents understand the mission and are bought into working to resolve it.
At times you're going to have the "resisters" who don't want to complete the project because it means significant change or elimination of their job or organization. It is vital to address this early in the mission statement definition and to identify the concerns of the resister. One technique that I have used with success is to get the stakeholders in a room and to give them each an opportunity to somehow shape the mission statement. What I have found is that even if someone only adds or changes one word of the mission statement they feel that they have influenced the direction of the project.
On some projects, we've been able to turn some of the resisters around; on others, the resisters never got with the game plan. In those instances, the resister ultimately was taken off the project. It's never a smooth process to remove a resister, but it's always been necessary to keep the project moving forward.
It's a problem but there are bigger fish to fry
So, maybe you see something that isn't working as well as it should be, or you see some product or service that could benefit your organization. It very well could be that implementing the solution could reap some benefit to your organization; the questions become those of management priorities and focus.
In one organization I worked with, we developed an annual portfolio of projects that identified the project, the problem the project was addressing, the resource needs, the benefit expected, a subjective priority of the project based on management priority and focus, and the duration that the project was to take. After each project definition was completed, we put the projects in a spreadsheet, sorted the projects by priority, and did a "draw the line" series of meetings based on when resources would be consumed. As an example, if we got to a point where after five projects there were no more dollars available to work on projects, we "drew the line" after the fifth project. I'd be kidding you if I said this was purely an arithmetic exercise and everyone walked away doing cartwheels over the outcome. The process forces a lot of discussion on relative priorities and, while one organization may feel that a project is vitally important to their business, in the larger scheme of things there were projects that were more important. So, not everyone was thrilled with the outcome, but there was a prioritized project list that everyone knew and understood.
Now, things do change and the relative priorities of projects do change. Thus, it's important that the project list is reviewed periodically (we did it quarterly) to ensure that you're still working on the right things in the right priority sequence.