What are the goals or your project? Do you know? Every project has as least one and often several goals, but too often there are unspoken goals that can undermine the success of the project. Unspoken goals can be the result of unrealistic expectations, personal agendas, or just resistance to change. The problem is amplified by the fact that, in most of our organizations, staff are involved in several projects concurrently in addition to their day to day responsibilities. This increases the difficulty of making project goals a top priority.
Over the years I’ve been involved in a number of projects, most of them involving implementing a new computer system. Usually the new system has different features and workflows than the old system which can require some process redesign (yes, that means change). Often people are assigned to the project based on their role or function without giving them any background on why the project is necessary, and it’s assumed that everyone knows what the goals are. Regardless of the project there seem to be several common goals that can surface and become obstacles to success.
Here are some examples:
- Make the new system work exactly like the old system. The new system usually isn’t designed to work like the old system which makes this goal difficult to achieve. Achieving this goal usually means forcing the system to work in a way it wasn’t designed to which can cause problems later. Eventually when the system isn’t working out well it’s blamed on the vendor or the software. At one organization when the patient billing office forced their system to work like the old system it caused the patient registration process to take an additional 5-10 minutes. Fixing the problem made both departments more efficient. Review the new system and look for process improvement opportunities.
- Bring the system live on schedule. This one is tricky, it sounds like a good goal, but if it’s for the wrong reason it’s a problem. Too often the reason for this goal is so the vendor can start billing or the project team can move on. Often this results in taking short cuts or the famous “we’ll fix that later” which becomes more difficult after a system is live. In a radiology implementation I had a vendor consultant do this with security. We were having a problem that was tied to the security rights and their answer was to remove the restrictions and fix it later. It takes time set-up security correctly and it’s hard to pull rights back. Don’t let the schedule drive bad decisions, if the system is live, but not functioning properly then it’s the beginning of a bad relationship.
- Just get it done. This one is usually from someone who isn’t a stakeholder and is just responsible for a specific task. While this may sound reasonable the problem is it may not be the right task. Customers generally ask for a specific task because they believe it will achieve a specific outcome. Sometimes either it won’t achieve the outcome, or there’s a better way accomplishing the same outcome. Recently at a meeting for a project our lab was doing I was asked if we could add another order code to our system. It would have been easy to say yes and be done with it in five minutes, but I asked what they were trying to accomplish by adding the new code. I ruffled a few feathers by asking the question, but when they told me the answer I let them know that adding the new code would not do what they were trying to accomplish. We were able to discuss several options and settle on one that met their needs. Before taking on a task there needs to be a good understanding of the desired outcome and if necessary discuss alternate solutions.
You can probably come up with your own list, but they all have the same underlying cause. If your project is going to be successful everyone needs to working towards the same goals or you’ll be reaping the consequences for years to come.
Brian Ahier says
Excellent examples John! Thanks for helping getting me back on track this afternoon. Sometimes it it easy to get lost in the weeds and this post is exactly what I needed today.
jbormel says
John,
Nice post.
I wrote an article for Anthony on the topic of “Bring the system live on schedule” called Homework First.
It’s available here.
The silent backdrop is the industry practice of creating incentives for the IT department and the vendor to declare go-live on a certain date. And, one of the best practices to get there is to make sure that the end-users have no project role in the validation and testing, pre-go-live. As you succinctly pointed out, “it’s the beginning [or continuation] of a bad relationship.”
On the broader issue of goals, your post reminded me of the HAL-9000 computer system in the movies 2001, A Space Odyssey and it’s sequel, 2010. In the later, we clearly learn that HAL was given conflicting goals: 1) Finish the mission of getting to the destination, and 2) protect the lives of the crew. When HAL determined that the goals became irreconcilable, HAL’s rational, goal-directed response was to kill the crew. Aren’t parables enlightening!