Project Management System Training Wheels

Over my last 2 columns, we talked about establishing the requirements for a project management system and creating a deployment plan for its implementation. Now, I’d like to take a few moments to talk about training.

Training in project management perspective is always different based on your own perceptions. If you have been implementing project management software for a number of years, you may have notions of a full-blown training schedule that covers all aspects of your system. If you just bought your first package last month and went for a desktop tool such Microsoft Project, then your notion of training may be 4 two hour classes at the local library.

Which one is appropriate? The answer is: the first one, the second one, neither, both. There is, of course, no more accurate answer than there was for the selection of project management system. Training has to be looked at in the context of what the organization considers a priority. Over the next few paragraphs, we’ll look at the various training choices before you and give you some guidance on where to start.

The first thing to know about training in project management software is what the assumptions are of people who write it. To do that we need to take a small step backwards in time to the early 80’s. Software for project management prior to 1981 was not available on PCs – of course not. PCs really came into being in 1981. It’s worthwhile to note however, that the kind of software purchased for project management really meant it was a large centralized system installed and deployed over a mini or mainframe computer. As was most of the software of its time, the interface would have been quite user-hostile. (Think of a character-based airlines reservation system and you get an idea.)

The cost of such software would have ranged from $250,000 to $1,000,000 depending on the size of the organization. There was lots included with the software of course. For that kind of money, there was lots that could be bundled in. Installation, training, assistance to get things running and so on were all typically part of the total budget for implementation. Clients thought nothing of budgeting 20% over the software price for training and implementation assistance. For a $250,000 installation, this meant about $50,000 to be spent on direct training and technical assistance with getting it running.

These services were made more effective by the fact that almost all pm software of the time was centrally managed through a project office or some similar organization so the training that was delivered was delivered to one closely held group. This resulted in this tightly knit group being a highly trained, efficient group of professional project managers. They acted as a resource for the rest of the organization.

Well, throughout the 80’s, the personal computer revolutionized how people think of project management software. Suddenly everyone was able to do it. Within a 12 month period, costs of project management software tumbled to 10% of what they had been. In the 90’s the introduction of Windows and desktop software for end-users has revolutionalized the industry yet again. PM Software available for only $20,000 in 1985 was available in a much more user-friendly package for only a few hundred dollars by 1995.

Throughout all of these software changes, the relative importance of project management software training remained unchanged. People still expect to spend 10-20% of their software purchase on training. The problem is the physical amount of money available. Now, training that had, only 15 years earlier, been budgeted for $50,000/team now had to get accomplished within a $200/user budget! Clearly it is impossible to deliver anything like the training that was once available inside these numbers. The problem is compounded by the diverse deployment of the software. Now that the price has dropped so low, it is possible for almost any individual in an organization to authorize the purchase of a desktop project management too.

From management’s perspective, the problem is insidious. That’s because the output from today’s modern pm packages is every bit as professional looking (in fact, with recent color printing techniques much more so) than the packages of the mid-eighties. So, from management’s perspective, the data looks just as good now as it once did. However, the assumption that this data carries with it the same expertise that would have put together such a report 15 years ago is now almost always false.

With a widespread deployment comes an additional challenge – that of standards of use for the pm system. The users do not receive the same amount of training and, unlike the 80’s, not at the same time. This makes implementing such procedures and standards difficult. This only makes the training issue tougher still.

If you are looking at deploying pm software within your organization today, you must consider a few elements in the training arena:

Ø Standards
First of all, look to spend time on your project management standards. With the state of software being what it is today, less and less time is required to effect training in the use of the interface itself. You can get huge “bang for your buck” by spending a little extra time with an expert or an external consultant in project management systems to establish a small number of data and reporting standards.

Ø System requirements
Here’s a huge area of training that can be avoided or improved when we talk about system requirements of your pm system and it’s almost never mentioned. If you spend some time early on in your implementation determining how you want to manage projects and what features you will require in a pm tool, then this information becomes invaluable during the training cycle. If, for example, you won’t be working on project costs within your tool because that’s being handled elsewhere, you’ve just eliminated a huge area of training that no longer needs to be done. Look to your requirements document from when you chose your pm tool to determine what elements of training are important

Ø System Interface
There is always, of course, basic training required for the standard interface of the tool you’ve chosen. Get your training from accredited sources where possible. These people will have not only knowledge of the existing tools but will be able to give you indications of where the software development is headed and helping you prepare for future versions.

Ø Interfaces
One element of training that is almost never considered is how this pm tool will relate to other elements of our enterprise systems. Deciding on this in advance and being prepared to identify the areas of your pm system that are essential to these other systems working properly will help get you buy-in for the training you’re going to do.

Ø Basic PM Concepts
This is an area that is often overlooked and couldn’t’ be more important. If your personnel don’t understand the underlying principles that the software is trying to accomplish, however will they be able to determine if the analysis matches any kind of reality check. We recommend strongly that basic project management methodology be a must-have for any deployment plan.

Finally, if there is only one thing to remember in the creation of your own project management software deployment plan it is to make sure that training is a planned element. Don’t have training be included as an afterthought or as a reaction to poor initial use of the product. Plan on it from the beginning. Think of who will require what level of training and decide before you get your software when that training will happen. You can tie your measurements of success to when training will happen.

Next time we’ll be looking at how your project management system integrates with other systems within your organization.

Originally publisehd Summer 2000 in PM Times

Write A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.