Project Management systems – it’s about deployment. Sure, there are lots of functions to consider and everyone wants to know your “methodology” but if you are committed to having projects fit into a an organizational system, it all comes down to deployment. Can you assemble a system that will actually be accepted and used by the end-users who will have to use it. Deployment includes all of it: developing the concept, buying or writing the system, installing it and configuring it of course and, most importantly, getting acceptance from the end users who must populate it with accurate and appropriate data.

Over the next few issues of PM Times we’ll be looking at how to deploy a project management system. We can’t of course, give you a complete course in the few paragraphs we have here. That would take a book. We can however, raise some of the key issues and give you some food for thought in dealing with whatever your current project management system environment is today. Whether you’ve got a well established project management system or if you’re just getting started, looking at how your system should be deployed is key to its success.

In this issue we’ll look at establishing requirements for a project control system. In the next issue we’ll cover creating the deployment plan. The next issue will cover training and finally we’ll look at integrating your pm system with other elements of your enterprise.

Requirements of a project management system
It used to be hard enough to set the requirements for a pm system for the organization. Internal experts and sometimes external consultants would congregate and, after extensive interviews with staff and management would go to the market to see what might be available. From the myriad dozens of potential products, the selection team would make a short list and vendors would troop in to display their wares. With luck, the selected system would meet most of the “must-have” requirements and would also squeeze into the budget.

The pace of change in today’s world makes one nostalgic for those simpler, kinder days. Imagine that five years ago there were perhaps 4,000 organizations who had ever heard of the World Wide Web. Now, some 4,000 new domain sites are registered every day. Two years ago, Java was something you had with your donut in the morning. Now, it is on the must-have list of every project management systems requirement.

What hope is there of setting appropriate requirements for a project management system your organization when technology upon which those requirements must rest is changing faster than you can even complete your analysis.

Well, it’s not as bad as you might fear. First of all, forget for a moment about technology. Your search should focus instead on who needs access to the system and, once they get it, what they’ll want to do. The great thing about the proliferation of Microsoft Project is that it has given us a good benchmark to use in describing functionality to end-users. A little thought about your own project management process here, at the beginning of your implementation will be the highest leveraged effort of the entire exercise.

Work on some of these questions:

• Who has access to the raw data to create new projects and to update existing ones? Should they have direct access to the project management system? What benefits would they gain from direct access? What benefits would the organization gain?
• What is the project management skill level of the projected users
• Who receives now and who will receive the output of the project management system? What reports will they need? How will having that report or data make them more effective? Is there an actual purpose to the reports they are receiving now?
• What lack of project-oriented information or analysis is hurting the organization? What impact would the availability of this information have?
• Who will champion the project management system? What is their authority? Who at the most senior level of the organization is sponsoring the initiative? What are their expectations? Are they achievable?
• Are there external influences in the implementation of this system (e.g. contract requirements)? What are they?
• What other systems will the pm system need to integrate with? Are these systems open enough to integrate? Will the system need to depend on third-party interfaces?

Once you’ve answered some of these questions you can start looking at some of the key building blocks in creating a project management system which will be acceptable to multiple users across your organization. Concentrate on some of the following factors while looking for potential vendors of expertise and systems:

• Suitability to purpose. Ask the vendor what experience they’ve had with your type of industry. Get references and (don’t forget!) call them!
• Flexibility, flexibility and (did I mention this?) flexibility. An “open-architecture” system will be one which can be easily enhanced and upgraded and modified from one use to another. This is key when technology may change faster than your projections.
• Multiple levels of interface for multiple types of user. Sorry, one size does not fit all. Many enterprise-wide vendors will have flexible interfaces or multiple products.
• Open data architecture. “If you can get at the data, you can do anything.” is a bit of an overstatement but key to interfacing with other systems.
• Keeping your options open is key to success in the deployment of a project management system. Until the next issue when we look at your deployment plan, I’ll leave you with this thought from Napoleon Bonaparte: “A battle plan lasts until contact with the enemy.”

In our last issue I talked about determining your requirements for a corporate project management system. This month we’ll talk about creating your plan for the deployment of your project management system.

What?! You don’t have a plan? Well, there’s good news and bad news. The good news is, you’re not alone, many project managers have attempted to deploy their project management system without a plan. The bad news? You’re not alone, many project managers attempt to deploy a project management system without a plan! I think it’s the ‘shoemaker whose children are barefoot’ syndrome. We tend to apply our skills last to our own projects.

The first step in making for a successful deployment of your project management system is in looking at the exercise as a project with everything that entails. Does this project have a sponsor? Who is the client? What is the schedule? What are the conditions for success? Here are a few elements you should be looking at when you are planning out the deployment of your new project management system:

Management Support
First of all, does this plan have management support. Problems with deploying project management software suffer most often from a lack of a product champion in the executive suite. Sometimes, decisions about implementing pm software come from management as a reaction to some problem (either real or perceived) about a particular project or projects in general. This might look like executive support but the support is very short term. Does management understand the scope and duration of the plan or are they hoping for an overnight fix? (You know what I mean – “As soon as that new software’s here, all our projects will be back on schedule”)

Look for management support that will last long term – It may be a year or two before the final effects of this implementation are felt. Is your project champion ready for the usual backlash that comes with a change in culture?

Also, what about funding. In this day of $300 project management software it’s easy to overlook the overall costs of implementing a change in a corporate system. Will you have the funding required for training? How about consultants to help tie your pm system to other legacy systems in the company? Has the I/T department set aside funds for technical support or people to help with the implementation?

Getting a product champion identified at the highest levels can be the most significant factor in overcoming the problem with all projects: Murphy’s Law.

Degree of deployment
While you’re assembling your plan, one of the most significant elements will be its scope. Implementation of a project management system if often thought of in one of only two camps: 1) Let every project manager do what they want or; 2) Choose a corporate-wide system and implement it everywhere. The problem of course with either plan is that few organizations benefit from them. The most common structure is one where some projects warrant a high-end project scheduling system, other projects warrant some kind of desktop planning system and yet other projects are so simple they warrant no project scheduling system at all. While you’re deciding who will and won’t be using your newfound package, think about what the payback will be for project managers at different levels. It is sometimes easier to leave small, low-risk projects out of the plan altogether. They’re numerous, they’re often very unique, very different from each other and the payback of having them in the central system is often very low.

Deciding on your level of penetration in the organization will be critical element of success. Pick your battles. If the small-project project managers want to do their own thing, it may be worth your while to get them off your list by letting them.

PM Process
Have you thought of where you’re going to gather the data for this new and improved software? Is the company ready to provide it or are you looking at cultural changes in the way they operate. One of our clients recently was working on implementing the corporate timekeeping system we publish. Management committed the company to move to a weekly time collection from the bi-monthly payroll-oriented collection they used to use in order to properly implement activity-based-costing. “No problem,” said management. Well, it has taken an enormous effort to get that message out to the rank and file who were so used to doing the work on the 1^st and the 15^th. Some resist doing the timesheet weekly despite the obvious advantages for the company. You need to look at what your new system requires and plan for it in advance.

Implementing a new package is also a perfect time for implementing process changes that may have been long-delayed. People will be changing anyway. You might as well take advantage to have them change to more productive ways of working.

Training
Can I say this enough: training, training, training. Not just in product functionality. Make sure you put aside enough funding and time to get people trained in the new way they’ll need to do business in order to support your new system. Make sure people know long in advance how much time will be required for users to come up to speed and make both an incentive to get trained and a penalty for avoiding it. It doesn’t matter if you spend $300, $30,000 or $3,000,000 on your new system; either get your people trained or plan to use the new CD for a coffee coaster.

Legacy Data
It’s a category that too many people forget. Unless you’re a start-up, you’ve got projects in progress. What will you do with all the legacy data from you existing system? That system may have been automated, may have been database-based, it may have been manual. You’ve still got to consider the value of the data in that system (or systems) and arrange the resources required to get it translated into the new system. Data conversions are often a tricky business. Get your new software supplier to check on the data and give a firm-price bid on converting it. You may need to pay them a day or two of investigative time but the back-end savings will make it well worth it.

Legacy Systems
Finally, don’t be too quick to throw those legacy systems in the trash bin. If you’ve got projects in progress, it may be less disruptive for everyone to let some projects wind down with the software that is being used on it. Make sure you’re going to give the project manager some benefit by switching his in-progress project data from one system to another before you mandate the change. If you’re keeping those legacy systems for awhile (and many do) then make sure there’s a firm plan to retire them once they’ve fulfilled their function and make allowances for moving their data and training the personnel working on them at a later date.

Conclusion
All in all, deploying a project management system can be an exciting time as the new features and functions start to impact the way you do business. It’s an opportunity for an organization to become much more effective but it’s also not risk-free. Make sure you take the time to plan before you leap.

In our next issue, I’ll be looking at how to weave your way through the myriad categories of project-oriented software in order to choose the one that’s right for you.