Thursday, August 07, 2008

Recommendations Needed on a Sensitive Project

The Planning Group (not their real name) is trying to implement a project management tool for all of the IT folks around campus.

There is a lot of really sticky politics around this particular project and I need some feedback.

The situation as I see it.

- The planning group wants us to take over the training of the new tool.

- We have been asking the planning group to help us with our biggest project.

- The planning group won't take on our biggest project unless we train everyone on the new tool.

- The tool is currently configured so that it is useful to the planning group, but no one else.

- The tool does not eliminate the use of other tools. It's an add-on, not a replacement or an improvement to any process the proposed end-users (all IT folks) participate in.

- The other planning group that is supposed to be the secondary administrators refuse to use the tool. That refusal goes from the other planning group's associate muck on down. As a result, there is a lot of useful information that is not in the tool.

- General consensus around the rest of IT world is that it is none of the planning group's business regarding how they spend their time.

- The planning group has, thus far, not been able to communicate why this tool would be useful to anyone other than the planning group.

Our group is one of the planned end-users. We see how powerful it could potentially be. IF they configured it for our needs. As the system stands right now, however, we can't even begin to explain how it will help us with our work or why we would even use it.

I'm a pretty lousy salesperson on a good day. And a lousy liar. I've trained on too many trash systems to willingly put myself in that position again.

One round of training was performed about 5 months ago in an attempt to "implement" the new tool. The lack of enforcement mechanisms and the inability to communicate why the new tool will help the end user (please see above) meant that people wasted a couple hours of their time.

Those people included me and the rest of our team.

The director nailed the problem on the head when she said:

They consider training the implementation.

This is a group that, in my mind, should know better. From what I can tell, they aren't putting the implementation of this tool through their standard project management processes. Maybe because it is their baby...

Correct me if I'm wrong, but training is PART OF the implementation. Not the implementation itself.

Training ideally occurs after the application has been configured so that it is useful for the end user, processes for administration and use have been determined, and enforcement mechanisms have been put in place. (Stop sniggering...I'm talking IDEAL world here).

I've been working on the instructional design for this "training" for a few days now and have been racking my brain to figure out recommendations for the planning group.

I'm basing the options for the recommendations on what is in front of me right now.

Option 1 - Divide the folks that need to be trained into groups. Treat each group as an implementation. Train them on all parts of the tool.

+ Determine what information the end users need to be able to get out of the system.

+ Configure the system with ALL of their projects (not just the ones touched by the planning group).

+ Figure out which reporting items would be most useful to that group. We can then train on how to personalize the accounts with this information.

+ Help each group create custom support materials.

+ Make sure there is an immediate post-implementation support plan.

+ Once all groups are implemented and using the tool, come up with a generic training for new users. Use the custom support materials as part of a knowledge library for future reference.

Option 2 - Create one general training. Focus on the timesheet piece of the tool and ignore everything else.

+ Since the main idea behind this tool is to figure out how much of each human resource is available, this is a quick way to get that information.

+ If the reporting is limited to Projects and General, finishing up the configuration for the general good should be pretty fast. Particularly since many groups have already given feedback regarding what needs to be in the tool.

+ Create a process for the end-user to put in new projects/tasks to track their time against. Right now, non-Planning Group projects are under "General Operations." That's not granular enough for the majority of the end-users.

+ Make sure the enforcement mechanism is in place.

+ Treat the "training" as a workshop for developing the initial timesheet in LIVE so they don't have to start from scratch when they get back to the desk.

+ Emphasize the benefits TO THE END-USER of this tool. (Very important since, as it stands, this is an add-on task.)

+ Later on, do option #1 for each of the groups.

Any other ideas? Recommendations? Any and all help is greatly appreciated.

No comments: