Project: InSewer Rollout, Training Development and Training (Unix and NT)
Client: City of San Diego
Primary Collaborators: Phyllis Chapin (San Diego) and Sophia Bhatia (SDDPC)
Work Scope: Software Acceptance, Training Program Development, Software Implementation and Rollout
1995-1998
In addition to the City's GIS/InSewer Integration project, this was my primary project for the City of San Diego and the reason I moved from Florida.
Years prior, I had worked with Sophia Bhatia on an almost daily basis when I was Water Resources Certification and Support Lead at Intergraph Corporation. San Diego had the largest user base of InSewer users.
Sophia was my direct boss at San Diego Data Processing Corporation (SDDPC). We worked for Phyllis Chapin, CADD Manager for Water Resource and Capital Improvements Departments.
Phyllis's end goals, and our deliverable, were to
- define the engineering design and production procedures
- develop and deliver the training to the full departmental staff
for the Engineering and Capital Project Department - mostly Sanitary Sewer "Group Job" facilities replacement (very old vitreous clay and RCP to PVC pipe).
As the primary technical expert for the software, it was my responsibility to test and troubleshoot the software and ensure it met the needs of the City.
SDDPC direct support personnel had a tendency to work at the SDDPC office away from the clients. From the beginning I secured a cube on the production floor and spent most of my time there. Several reasons:
- Customer Service: if your clients are all in one place, why would you want to be somewhere else (if your goal is Excellent Service)?
- Relationships: ultimately it is all about relationships. The production staff and first-level managers are still the people I identify with most closely. My instinct is to remain close to production.
- Accessibility: being there facilitates relationships.
- Turnaround: I can have problems solved in the time it takes off-site support to begin to engage.
- Speed to Trust: nothing facilitates and accelerates like face time
- No downside: there really was no downside to being on-site (yes, there are interruptions, but they're the right interruptions)
- I enjoy being in the action.
This was my first "professional" training development effort and it shaped how I have approached training development ever since. What made this a fantastic learning experience includes:
- Great Mentors: Phyllis's team production vision and expertise and Sophia's experience and history with the City, SDDPC, Phyllis and the Software.
- A Clear Vision
- A Blank Slate: our training program started with a vision and little else. We didn't have existing material to start with.
- Tight Collaboration
- Full-Cycle Responsibility: Needs Assessment, Plan, Execution, Training, Ability and Responsibility to Amend
Initially Phyllis wanted that ideal text: the book that guides the user through each and every step, including references to city procedures and triggering inter-departmental work orders, etc. We tried going down that route, but it became clear that the "Training Manual" was turning into a dense labyrinth of sidetracking and legalese: it became clear that learning the software and learning City Procedures, if taught together, would teach neither. We chose to have two documents: a document teaching software skills in a typical workflow and a reference manual on City Procedures. This good, intuitive, choice is backed by much literature in the training and education discipline (back then it seemed like a revelation).
I didn't realize this at the time, but not many people get the opportunity to develop a training program and then teach it many times in succession with the responsibility to improve it as you go. Over a five year period I taught 200 people three different iterations of the course (InSewer Unix, Windows and the new Storm&Sanitary software). As a outside consultant who sat among the staff, I had no leeway for less than excellence.
Or maybe just few people take full advantage of the opportunity to ask the students what is working for them and what isn't. I've seen heated internal debates over a particular option without ever sharing the debate with learners. "What would work best for you? Workflow A or Workflow B? Here are the benefits of each..." Let the learners share their opinion on their views of our choice. You've seen the generic, barely useful Class Evaluation Forms with generic questions and a Comments line. If I'm in person, I'm engaging the audience.
At the end of a five-day guided hike through Peru, a Process Coach and I were getting some grief from the other ten in our group: "Why are you two filling out PAGES of comments on the Questionnaire?" Replies the Process Coach: "Feedback is a gift". This is obvious when you are responsible for design and satisfaction AND are eager to improve.
After we got the department standardized on the Unix platform, Intergraph ported their Engineering Applications to PCs. The City, of course, migrated to Windows PCs and InSewer NT. We rewrote and a re-taught, but, fortunately the bulk of software and operational procedures carried forward. It was a nice opportunity to update and refine a good curriculum