Saturday, January 24, 2009

Planning Planning Planning

So February is shaping up to be a crazy work month.
I guess this is the payment for the very relaxed January.

The most important thing on the books is the beginning of the needs assessment for our really mondo big Enterprise upgrade.

I'm going to do the needs assessment differently this time.

Old Way: Wendy takes the input from her classes/phone calls/overheard snippets of conversation and redesigns the course.

The old way worked when I was also the subject matter expert and operated in a smaller environment.

It won't fly this time.

First - because I am not the subject matter expert for this application. I train on it, yes. But I don't use it outside of the actual training.

Second - my environment is much much larger. The people impacted by this product has increased from a few hundred people to a few thousand people.

Third - the application itself does multiple things. Course registration, student accounts, HR, alumni tracking. This is our system of record. Each module does very different things. They don't link in as organized a way as, say, an electronic medical record. A key record can either be a person/entity or a course (and there may be one other type of "record" as well that I have not encountered yet).

The Project Manager for this upgrade was just assigned last week. The kickoff isn't scheduled until late March. But I knew I needed to get started much sooner. I'm not only rethinking the training - I am rethinking my entire development process. Starting with the Needs Assessment.

The last upgrade of this system, by all accounts, was considered successful. I called the PM to get his opinion and advice on how to proceed. Particularly since I didn't just want to design the Upgrade training, I also wanted to redesign the entire training / support structure for the product.

So why am I redesigning the training and support structure?

1) Just showing how to navigate the product provided absolutely no context. I already added some practice exercises incorporating 3 of the most common workflows I've been asked about this year.

2) The original course was designed with the assumption that there would be significant resources at the department level. Between employee turnover and a misunderstanding of roles, it became clear to me that those resources don't exists for most departments.

I needed to bring in stakeholders and subject matter experts fast. And I need to do it in a way that is a) organized and b) politically acceptable.

The PM's advice:

- Go to the Internal IT Enterprise meetings. The administrators, analysts and technical experts on the system gather every 2 weeks. They are the ones who get the bulk of the calls and, from experience, will have an idea of what needs to be communicated. These are also the people who will help me pull the initial metrics from the system to help me see whether what I am doing works.

- Go to the Enterprise Steering Committee meetings. This will allow me to hear some of the business issues and perceived training opportunities among the end-users out in the field. It will also give me a clearer understanding of what service the end-users expect the IT side to offer.

- Work with the Internal IT Enterprise folks to put together the training outline. Once the IT Enterprise folks bless the outline - present the outline to the Enterprise Steering Committee. The big advantage I see to this is that there will be more people to defend the plan.

- Once we get the Steering Committee's blessing, present it to the larger Enterprise Advisory Board. This is the final decision-making body. By this point, I hope to have some business-side / end-user defenders of the plan.

This will be significantly more time consuming than my normal needs assessment process. I'm thinking MONTHS longer.

I'm hopeful this will result in a more useful training and support operation in the long run.

No comments: