An aspect of preparation not to be overlooked is buy-in. I am referring to getting key management personnel to "buy-in" to the project management software implementation. That means that they understand its value, recognize its strategic importance, support its implementation, and hopefully even help to set the strategic goals.

This is important for several reasons...

Project management software in and of itself does not solve anything. There are several strategies that rely strictly on the software that do not work. It must be married with strategic objectives, accountability, and proper planning. Management buy-in is important because by definition they should be determining what is and is not important. They will decide whether project management software and the implementation of it is important. If it is not important to them, then there will always be other projects that are higher priority that will detract from the implementation.

In addition, they provide the accountability. I know that people do not like that word, but if team members are not accountable for using the new system, it is not going to happen all by itself. Management needs to provide the accountability to be sure that people use the system and use it to further the organization's processes and goals.

Management also can go to bat for you. There will be a time where others in the organization will act as nay-sayers, have their own opinions about the implementation, or conveniently prefer that it goes away. There is where management buy-in comes in by re-emphasizing its strategic importance.

There are more reasons, but I think you get the idea.

The biggest question you probably have is how to you get buy-in? Good question. There is no black and white answer, but here are some thoughts from my own experience.

Sometimes you need to think smaller. It may not be possible or prudent to implement project management software for the entire organization. You just may not have that level of buy-in. But...you could start with an area of the organization for which you do have buy-in. This could be your own team, department, project, or group. Keep it simple, but follow the same principles (on a small scale) and demonstrate its value. When a manager can see the value, such as being able to access data real-time, that will help them to "see the light".

Sometimes you also just need to plant the right seeds and wait for the right time. The organization may not be ready right now, but you can plant the seeds by passing on the occasional article or tidbit of information. At some point (you will know when it is), the organization will suddenly be ready. I have seen this happen when an emergency occurs (such as when a key customer is ticked off because of a lack of project management), or when new management comes into place. You can be ready with ideas and suggestions on how to move forward. Have lunch with some people and gradually with tact, slowly make your case.

Comment on ideas you have had from your own experience on how to achieve buy-in.

It is almost always a good idea to solicit feedback from others in the organization about their needs before starting down the road of selecting project management software. I'll explain why this is important, how to do it, and add some words of caution.

Why is it important? Three reasons. First, you will not be the only person using the system. Other people in the organization will be using the system as well. What do they need and even like? Two, you have your own objectives, but others in the organization may have a different outlook and may have objectives of their own that are equally important. Three, it will help your implementation. How? They will feel like they were consulted, and may even feel some ownership with the project. You will need their support during the implementation.

There are various methods of soliciting feedback, some formal and others more informal. Formal methods including asking them to formally submit requirements from their group, or conducting a meeting to collect feedback. I find informal methods, in general, to work the best. This is because it is the one-on-one interaction, the trust developed between you and other parties, that makes the biggest difference. Informal methods include going out to lunch with someone, chatting in the office, and asking their opinion informally. For example, I may go out to lunch with another manager and say "Hey, we're looking into selecting project management software to do x, y, and z. What would be some things that you would like to see that would benefit your group?" Or "what problems do you need solved?" This then becomes one of those situations where listening is better than talking.

The scope, size, and complexity of the project will determine how formal you need to get. A large organization will need to employ more formal feedback mechanisms, such as those that are a precursor to a formal RFP process, whereas a small or mid-size organization can be much more informal.

The types of feedback you need are problems that people are experiencing, what tools they are using now, and what they are trying to accomplish. Features are nice, but if you can solve a problem, so much the better. If you can solve a problem and help them accomplish a key objective, that is better still. It is good to understand what tools they are currently using as that will help you ascertain what type of system to employ: one that is more complicated, or one that is more middle-of-the-road.

I promised some words of caution. You need to solicit feedback from the right scope of people. Do not solicit feedback from everyone. Where are you going to implement this? Within your group? Across the department? Across the whole organization? Do not tread much outside of that target group of people. Otherwise you run the risk of diluting your requirements unnecessarily or causing your selection project to get much more complex than it has to because someone else wants to be involved in it. If you are not sure where you are going to implement it, ask yourself where you have buy-in from management. That is probably where you want to target, at least initially.

You also want to be careful what you do with the feedback you receive. You may have to run it through the "strategic objectives and true business value filter". People love to throw out features and wish lists, some which are good, some which have no real business value or necessity. But you will find key nuggets of information that can make a big difference in your selection and implementation.

Finally, you can solicit feedback ad nauseam, and never actually get to selecting anything. Don't take it too far. Get the feedback that you can in a reasonable time frame, then take action.

The bottom line, feedback almost always reveals things you did not consider, develops relationships, and helps your organization in the long-run.

One of the questions we get from readers is how to select a project management software system. I mean, when you get right to it, what should that process look like? Where do you begin?

The first step that most people take is to bring up Google and begin an immediate search for project management software. That is all fine and good if you simply want to educate yourself and what is available in the marketplace. But you will quickly become overwhelmed, and you will not know what to look for if you do not first complete some initial tasks in preparation.

We recommend that you first determine your objectives, as you would any other project. What are you trying to accomplish? Why now? What does success look like? What strategic objectives is the organization trying to accomplish and how will this system fit into that?

This is important because if you do not have any measure of success, you won't be successful.

Here are some examples of possible objectives.

A product development company may be struggling with properly scheduling and maintaining customer commitments. Their objectives may be 1) create a central location where everyone can see current project schedules to reduce data collection time and misinformation; 2) make current project and resource assignment information readily available to make better, more informed promises to customers on new projects; 3) give salespeople information to know how their projects are progressing, and thus keep the customer informed; 4) develop an alert system to identify important items that are "falling through the cracks".

A professional services company (such as a company that does customer implementations) may have similar but also different objectives: 1) create a central location to show all active customer engagements; 2) create an issue management system to identify and track important issues with customer projects; 3) create an easy system to collect billable and non-billable hours worked by associates, thus reducing manually intensive operations; 4) automate the process of reporting for customer billing and informational purposes.

One of our government clients that utilizes EnterPlicity PM Software offers a unique and value-added service to other government agencies. But they had no hard data to back up what they really did (which made audits tough), and they needed to change to become more effective and even competitive (yes they have to compete). Their first objective was simply to find out where people were spending their time: which projects, deliverables, and deliverable types.

Other organizations may want to automate key processes in a workflow setting to be more productive, combine systems, stop things from falling through the cracks, centralize project management information to enable faster and more informed decision making, etc.

Document and prioritize these objectives. You will probably not be able to accomplish them all at once. You may need to go in phases. What is strategically more important and focus on that in the first phase. But have all of your objectives documented and in mind for future use during your evaluation.

This will be a working document meaning it will change over time as your business conditions and strategic situation changes.

Next: part 2...

Let's wrap up tips on implementing project management software.

There are lots of suggestions, best practices, tips, and advice on implementing project management software (or any software). We have mentioned some of them: accountability, communication, processes, going in phases, planning, seeding project management skills.

Here are some areas that we missed:

Buy-In: achieving buy-in on your implementation so that you have the proper organizational support. This doesn't have to be the top of the organization (though that would be the ideal), but it could be the top of the "sub-organization" in which you will implement pm software. This could be a department, group, team, location, etc.

Continous Training: I mentioned in a previous post to train people on what they need and not overwhelm them with all the irrelevant ins and outs of features and capabilities - focus on their key processes. Following that thinking, be sure that you provide continuous training opportunities, especially after they have had an opportunity to get their hands dirty using the system for a while. You could also gradually expand on the training content over time - again geared towards the function that you want a particular group to accomplish. In other words, don't expand just for the sake of expanding.

Work Closely with your Vendor: ideally, develop a close relationship with your project management software vendor. I recognize this is dependent on the type of software you obtain - a low-end / stand-alone system is probably not going to be conducive to this, but a mid-sized or high-end system certainly should be. A good vendor will want to support you, understand your needs, work towards making the system as effective as possible for you, and if nothing else listen for the purpose of continuous product improvement.

Leadership and Oversight: it is important for someone to be the point person for the implementation. It will simply not be as successful if you simply "hope" it will take hold. You need someone to manage it as a project (even if this is only a part of what they do), drive it, be a resource for people, and ensure it is meeting your objectives.

There are a lot more areas that we could spend a lot of time covering. Hopefully these are some helpful starting strategies and tips for you.

We are going to transition into various other topics, including some practical advice on how to go about selecting a specific tool.

As always, comment or send us a note at blog@teaminteractions.com.