Here is another common project management software implementation problem: no organizational support. I'm sure you have never experienced that one! How does this manifest itself? Sometimes openly, and sometimes more stealthily. Sometimes you are flat out told that the organization is not going to implement a project management software system in the first place. But other times, and I dare say more commonly, there are manifestations of this during the actual implementation. For example, people do not have time to work on the implementation or be trained; they are not interested in setting up the right processes; other priorities get in the way.



Organizational support and management buy-in is very important to be strategically successful with a project management software implementation (as with just about anything). What can you do in this case? I don't believe there is a simple black and white answer, but I do have some observations and suggestions:

Implement where you do have support
You may not have support across the entire organization, but you very well may have support within an individual group or department. Start there. Keep it simple. Setup the processes and implement the software within that area. Prove it out. Work out the kinks. Demonstrate the value. There is nothing like going to a meeting and being able to answer questions readily with data to back them up when no one else in the room can.

Set simple, attainable goals
You may be trying to be too aggressive and "shooting for the moon" with your implementation when you should start off with simple, attainable goals. In other words, you may need to walk before you run and think in terms of phases instead of doing everything at once. It will be easier (not guaranteed, but easier) to gain support when it doesn't seem like a daunting task to people.

Bide your time
It may simply not be the right time. The organization may not be ready or may have other high priorities that have to take precedence. Bide your time. Be ready. Have your information, pitch, value proposition, etc. ready to go. There will come a time when the organization is ready to listen. I am often amazed at how quickly this can happen. An organization just doesn't seem to want to move, and all of a sudden an event takes place that changes everything and this becomes a high priority. Usually this is some sort of emergency, such as a client threatening to cut ties because of yet another late delivery, or an executive lashing because there is no system or data to explain poor performance. Sometimes it is a new person that comes in at the right level with a mandate to improve productivity and processes. You never know. But be ready, at some point the time will come.

Labels: implementation, organizational support, project management software

I am going to switch gears a little bit to have a discussion about some common project management software implementation problems. All is well and good to pick the right tool with the right benefits and the right vendor who will partner with you, but that obviously does not ensure success. There are a number of roadblocks that can cause things to go south. These include lack of organizational support, resistance to change, competing priorities, etc.



One of those is a lack of technical expertise or availability of that expertise. In other words, to implement project management software in-house (except for stand-alone / simple solutions), it takes some technical expertise. Not everyone has that, or more commonly those resources are busy doing other things.

A simple method of addressing this is to adopt a Software as a Service (Saas) solution. These services are provided by many vendors as a way to circumvent any need for technical expertise. In this type of solution, the vendor hosts the software in their own environment / data center as a service to the customer. All the customer has to do is to log in to the site over the Internet. This is easy, convenient, and puts the burden on the vendor. This will probably cost you more in the long-haul as opposed to a direct purchase, but addresses the technical problem and is almost always cost-effective in the short term.

Here is an interesting blog I recently ran into, if you want to learn more about SaaS in general.

But what about those organizations (I'm talking about you, government) who cannot go this route because of security, regulations, or because they simply do not want to? In this case, you MUST have at least SOME internal resources to support the initiative (unless the vendor takes over complete responsibility for all of the technology, which would be very difficult). But there are a couple of things you can do. You can get the vendor more involved. A good vendor will be able to take care of many the technical aspects for you, even though it is in-house, and at least minimize the internal resources needed. This will cost you more, but it can be a good strategy. Just be careful, the vendor will not have the authority to handle everything, and you need to accept some responsibility in-house.

I would like to know what implementation hurdles you have, or have experienced in the past? Send them to blog@teaminteractions.com.

We are wrapping up a discussion series on selecting and evaluating project management software. Here are a few considerations before making your final decision.

At this point, you should have a good idea of which vendor you want to select. However, there are some remaining (but not unimportant) tasks to complete.



Ensure that you understand the complete cost of the implementation.

If you have not done so already (which you should have), obtain a written quotation of the costs involved. Review this with the vendor to be sure that you understand it. Ask questions such as "what happens if in two months we need your help", etc. Will the vendor be charging you for a lot of professional services time or is what you see up front what you get? Can you do the implementation yourself, or will you be paying the vendor to do it? What if you want to add more licenses or subscriptions down the road?

Talk to other customers as appropriate.

Talk to some of the vendor's other customers and see what their experience has been like. What type of support have they received? Did they pay more than they expected? What is the vendor like to work with?

Review the contract.

Be sure that you understand the contract (or order form) that you will sign. How will future upgrades be handled? Even if you will be doing the implementation yourself, how much will it cost to get the vendor's help if needed? Does the contract say what you believe to be the true cost?

Let me also say that you need to understand the type of software that you are procuring. If you are purchasing a $200 stand-alone desktop application, you are probably not going to get a written quotation and talk with customers, as you would with a $20,000 package. So use some common sense there.

Review your objectives again.

Go back to your comparison chart and objectives and be sure that your selection is going to help you meet those goals. It is difficult at this point to keep the emotion out of it, including the "I just want this process to be over with" emotion.

Plan the implementation.

Don't forget to plan the implementation. This is relevant to the current discussion because you want to be sure you are ready, know when you want to complete the implementation, and be sure the vendor is on board (if applicable) with your plans. Plus you don't want to lose momentum. You want to keep the ball rolling and move into executing your plan.


Don't forget to leave your comments or email blog@teaminteractions.com with your feedback on what has been successful for you.

We have just a couple of posts left before wrapping up our series on selecting and evaluating project management software.

After compiling and scoring the different vendors, as indicated in the last post (part 1), you want to decide on a final project management software tool or a couple of final tools. Either way, I recommend that you ask for a second demonstration. The purpose of this demonstration is to confirm your previous findings, identify areas that you missed in the first demonstration, and go a little deeper to make a final decision. If you still have two vendors in the running, this will help you make a final decision. If you have narrowed the list down to one, this will still help you confirm your decision. You will find things that you missed in the first go-around.

In addition, you should use this as an opportunity to start planning your implementation. How will you use and configure the software? How are you going to implement your processes within the software? What will you try to accomplish in the first phase? Second phase? This all helps to get started on the right foot and make sure you are making the right decision.

You can also use this as an opportunity to interact with the vendor about the project management software implementation. Ask questions about this. What does the implementation entail? Who will do it? What do they recommend as a best practice? This is another tool in your belt for a successful implementation.

Now there are just a couple of things to wrap up...