Project Management Screw-Up 1 - We Weren't Addressing the Right Problem

Project Management Screw-Up 1 - We Weren't Addressing the Right Problem

By [https://EzineArticles.com/expert/Lonnie_Pacelli/16297]Lonnie Pacelli

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 doing 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 done acceptably 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 in 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 use a two-digit year and assumed 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 was taken.

How it happens:

There's a poorly articulated mission statement - Many projects that I have seen had some mission statement that was either vague, unrealistic, or simply didn't exist. To say "we need to reduce costs", may be an admirable thing to do and something that is generally desirable, is not something a project team can surgically execute upon 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 by

What measure will be used to signify 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 hard copy invoice. 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% payment within terms). In the invoicing project, we were able to stay laser-focused on what we needed to do and make sure all of 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 into the project. Some may view what you're doing 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 meant 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 people that are resistant to the project because it means significant change or elimination of their job or organization. It is vital to address this early in mission statement definition and to identify the concerns of the resister. One technique that I have used with success is to get your key 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 to 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 smooth 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 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 more around priorities and focus.

In one organization I worked in 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. Once each project definition was completed, we put the projects in a spreadsheet, sorted the project 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 then we "drew the line" after the fifth project. I'd be kidding you if 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 would be 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.

Warning Signs:

You are having difficulty getting a sponsor for your project - So you've got a project that you think is important but you're having a difficult time convincing potential sponsors that the problem is significant enough that they should care and take action. It could be that the problem is truly a problem but it's not a high enough priority that warrants immediate action. Then again it also could mean that you've got a poorly defined mission statement that isn't compelling enough to take action.

The project team is confused about what problem the project is trying to address - I've seen more than one project where the project team goes through the project with different views about what problem they are trying to solve. If each of your project team members are unable to consistently recite your mission statement then you're sure to have points of confusion throughout your project.

It is difficult to keep the project team focused on solving the problem - Sometimes on projects I have encountering situations where project team members stray from solving the root problem to solving a "problem du jour" which may or may not be related to our project. At times, there could be validity to the issue being raised which help you to further articulate your problem statement and resulting solution. At other times, though, it could just be a red herring which dilutes your focus and creates confusion about what you're trying to accomplish.

Turning it around:

Keep your mission statement prominently displayed - I've seen some projects where there's a great mission statement that is developed in order to sell the project then put in a drawer for no one to see ever again. Ensure that you are re-visiting and re-communicating the mission statement through the life of the project to ensure that you're doing the right thing, that everyone understands what the right thing is, and that you're driving toward resolving the problem.

Adjust the mission if the problem changes - Problems aren't immutable; they can change in complexion and importance. If something changes about the problem make sure that your mission changes accordingly. This could also mean that the importance of your project changes because the problem is either more or less important than it was prior to the change.

Put it on hold - If you can't get support for the project, then either put it on hold or recognize that it's not something that sponsors care enough to do something about. Better you do this than try to forge ahead with the project without sponsorship. It's likely only a matter of time before the project dies.

Take away:

Make sure you've got a very clearly articulated mission statement

Ensure that your key stakeholders understand the mission statement and have had an opportunity to tweak it

Make sure that the mission statement is in line with potential sponsor priorities and focus and prioritized appropriately with other projects

Excerpted from The Project Management Adviser - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass at http://www.projectmanagementadvisor.com

Lonnie Pacelli is an accomplished author and autism advocate with over 30 years experience in leadership and project management at Accenture, Microsoft, and Consetta Group. See books, articles, keynotes, and self-study seminars at http://www.lonniepacelli.com

Article Source: [http://EzineArticles.com/?Project-Management-Screw-Up-1---We-Werent-Addressing-the-Right-Problem&id=9361236] Project Management Screw-Up 1 - We Weren't Addressing the Right Problem

‍