The demand for project management software has not let up in spite of all the economic news of today. Hence the delay in getting some of these posts out. But we do have plans to crank these out much more frequently, so thanks for the patience!

This is another post in our series on Strategies for Successful Project Management Software Implementations. The following were previous posts in this series:

Take It In Phases
Planning: Another Key Strategy
Tackling Project Management Skills
Project Management Skills and Project Management Software
Implementing Project Management Software: Common Strategies

Here's another strategy: focus on processes, not product features.



Project management software in and of itself does not solve anything. It is just a tool. Anyone can eventually learn how to mark a task as complete, enter time in a timesheet, or upload a document. But the point is not to use project management software, but to get real value out of it by being more competitive, more efficient, making better decisions, or whatever your objectives are.

By combining the software with the proper processes you achieve just that. When talking about implementing project management software, this is key. Here are some tips on how to accomplish this:

Document your Key Processes
What are the key processes that will support your primary objectives? Document these. What is the process to create a new project? To schedule a project? To update status? Running reports? For example, let's say that you are an engineering organization. Your process to create and schedule a project may be something like this:

• Create the project and fill out the project name, engineer, product type, and sales person fields.


• Use the template that corresponds to the product type.


• Reset the project start date to the approved start date.


• Designate which people will fill which roles.

That is simple but fulfills a potential objective: standardizing the project process for new products, and creating a central repository of key project information (i.e. the engineer, product type, etc.).

If you are a professional services organization, you would have a different process, and so on.

Train on Processes not Product Features
The tendency when implementing new project management software (or any software for that matter) is to train people on the use of the software. What features does the software have? How do you use those features?

The problem with that is that most of your users will not use all of those features, and the focus is on using the software instead of getting business value out of the software.

Instead, train people on how to implement the business processes within the software. That does a few things. It simplifies the process. People get trained on what they need to know instead on a lot of stuff that is unnecessary. It focuses everyone on the key objectives (instead of focusing on the software). And it produces results right away that are more inline with the primary objectives.

Do some people need to learn the software well? Sure. But I'll bet you anything that is a far smaller number of people than you think.

Use Templates Wherever Possible
Utilize project templates and other "template-like" capabilities wherever possible. This will help to instill your processes and provide some standardization so that information is valuable and not "messy". It helps to instill your processes because people are following templates and not making things up as they go along. It prevents them from doing things the way they feel like doing it.



There is a lot more that we could discuss about this, but I think you get the point. Focus on your processes and you will accomplish a lot more in a lot less time than if you focus solely on the software.

This is another post in our series on Strategies for Successful Project Management Software Implementations. The following were previous posts in this series:

Planning: Another Key Strategy
Tackling Project Management Skills
Project Management Skills and Project Management Software
Implementing Project Management Software: Common Strategies

Another successful strategy that I have personally seen is to take your implementation in phases.

A common phenomenon in really any type of software implementation is "it's gotta do this-itis". People get very wrapped up in everything that the software MUST do for it to be beneficial. Never mind that they have absolutely nothing today and everything is done via pen, paper, and email. I suppose it is quite natural. After all, it truly can be an opportunity to expand the efficiency and competitiveness of an organization. But the key words there are "can be". Like anything else it must be managed correctly.

If you are familiar with project management, you have hard of the triple constraint on any project: time, cost, and scope. By adding all of these "must haves" to your project management software implementation, you are adding what? Scope, of course. Which means it will take more time and cost you more in terms of actual dollar cost or the cost of time. Not to mention the increased risk by adding complexity to the project.

So what to do? All of these "must haves" may in fact be beneficial. And there may be a minimum set of functionality that is required (although I would often argue that the threshold is lower than most people think).

The answer is phases. You have a short term and a long term plan. The key is that you don't try and do everything at once. That allows you to get a quick bang for the buck, get everyone comfortable, establish fundamental processes, and validate that your approach works in the first place.

For example, you may start off with a simple phase one whose objective is to get all active projects into the system, and train key personnel on how to create projects and associated schedules. That's it. After that, you may train others on how to update their status or, if you need to track time, how to add time spent on projects. After that, you may focus on making this truly a strategic repository by gradually adding complexity: documents, issues, risks, costs, etc. based on what your organization needs.

However you do it, the phased approach, wherever possible, works wonders. It provides some immediate benefit, enables the recognition of that benefit much quicker, and it simply isn't as scary to a user base that may be skittish about doing something new.

I'll be willing to bet that you will be surprised what you have accomplished in six months, as opposed to the organization that tries to do everything at once.

What has your experience been?