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

Apologies for the delay in getting this next post out. It's been a busy couple of weeks. First, it was a trip to Dallas for the annual PMI Dallas Vendor Showcase. PMI is the standard-bearing global organization for project management, and their Dallas chapter put on a showcase of various project management training services and products. Approximately 600 or so people showed up which was surprising since it was a vendor-focused event. The people were friendly and the dinner was good (although finger food doesn't necessarily equal dinner for me). We were there talking about EnterPlicity, our web-based project management software system, and some of the ways that we help organizations in general get more value out of project management software.

Second was a trip to Arizona to visit a current client, and doing a brief presentation at the PMI Phoenix dinner meeting. There was a good crowd again for a dinner meeting, and we had a lot of fun playing Who Wants to be a Millionaire project management style. We'll cycle through some of the other chapters this year so look for us. Lee Lambert was the main speaker at this dinner meeting, and if you want a speaker that is insightful, engaging, and makes the audience laugh, he's your guy.

That all brings us to our topic for this post which is the second part of why organizations struggle with project management software. The last post dealt with organizations that have no project management tools to speak of. Now lets talk about the most common scenario that we see out there, which is organizations that rely on simple or stand-alone tools.

What is the most common tool that organizations use today for project management? If you said Microsoft Project, that's the standard answer, but in my opinion you would be wrong. The most common tool is the spreadsheet. People all over use spreadsheets for everything and project management software is no exception. And boy, have I seen all kinds of different spreadsheets. There is the "see how many worksheets I can create in one file" spreadsheet with scores of projects in one file. Try and work with that one on a daily basis! And then there is the "fantastic formula" spreadsheet with all kinds of complicated analytical formulas. Of course, they take maintenance, and when the person who created it leaves, no one can use it anymore! Microsoft Project certainly is a common tool that is widely used as well, although people tend to either love it or hate it. Most people don't understand how to use it effectively, or are trying to use it to do more than it was intended to do.

Where do organizations typically struggle with this type of scenario? It typically boils down to the fact that information is de-centralized and difficult to aggregate together for good decision making. Spreadsheets or project files are located throughout the organization. Mike has his files, Susan has her files, etc. What happens when the boss asks for a high-level project status report? That information is not in one place. The Project Manager (or whoever is acting in that capacity) has to collect the information and compile it together. When I was a Project Manager working for a dot com back around 2000, we had a weekly project status report that we had to create. Let me tell you, that was an event. It took hours to complete with lots of legwork and collecting data. It was a pain! But that's what you get with a de-centralized, simple toolset.

The other primary problem is simply the amount of time is takes to manage, collect, and adminster the information. This is simply because the information is typically not standardized and is in multiple places. By definition, this equals more time to administer it.

Now, is having a de-centralized, simple toolset necessarily bad? No! It depends on your organization, and the number and types of projects that you have active. However, a lot of organizations struggle with this specific scenario.

Later, we'll review all of the options that an organization in this scenario has to address those issues.

Labels: microsoft project, pmi, project management software, spreadsheets