Project: TOPs – Service Management

Situation

We were migrating ITSM Application Suites from a customized version of Remedy ARS to a customized version of Remedy 7.6. About a year into this process, we received the green light on dedicating a project to do an overhaul of the documentation. This was a huge win as we were utilizing outdated documentation, even by the old application’s standards, and projects were not running as smoothly as they should.

Task

My objective was to author and/or revise documentation that would support our Transition Project Managers in Service Management from initiation to closing. My goal was to make the documentation as detailed as possible but organized in such a way that the detail wouldn’t slow someone with more experience down. I was given full autonomy on what was needed to be produced with the end goal in mind.

Action

I worked with a couple of other tenured individuals that had experience on both systems—which was not much at the time—during this process. When creating documentation, you want to follow a certain order. This is similar to what we were taught as kids in English class. You start with an outline, go into the draft, and then deliver the final document. In this situation, my outline was 3 documents—the WBS (work breakdown structure), a Workflow utilizing Visio, and the Process document. I created a standard WBS based on a typical ITO (IT Outsourcing) project that was decomposed to three or four levels. According to the PMBOK 5th Edition, you want to break it down to the work package. “The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed.”

The more methodically I approached these documents, the easier the rest would be. These documents were the plan for the 47 or more documents to follow. I wanted to ensure I was setting myself up for success. As President Lincoln said, “Give me six hours to chop down a tree, and I will spend the first four sharpening the ax.”

Once the outline of a typical project was complete, I transferred the necessary information over to the procedure document to create the title headers for each section. Comparing the old documentation to the new, I identified the gaps and resolved them. Around the time of the third revision of the procedure document, I interviewed the tenured individuals to enhance the document or make any corrections.

Once the procedure was completed—which I want to say was over 200 pages with screen shots–the other supporting documentation was authored. This included a couple more procedures that had to be separated out due to the fact that the Transition individual could do the tasks or the Operations individual. The existing training documentation and application on-boarding templates were verified and updated where necessary.

Results

In the end, I authored or revised over 50 documents that supported both our newest team members and our most seasoned during a typical ITO project. These documents were intended to guide the Project Manager through the entire process and from a technical standpoint, also instruct on how to do most tasks. As part of the process, there is a CMO (Current Mode of Assessment), an FMO (Future Mode Assessment), and a gap analysis that is conducted. The Project Manager knows that due to the customer strategy, the uniqueness of the project, and / or the industry the customer is in, that there will be tweaks that need to be done along the way.  The overall documentation included four workflows, three processes, four procedures, six reference documents, 25 standard templates, training materials, and more. The documents are loaded to the knowledge management database and based on ISO:9001 (Quality Management Standard), they are reviewed and updated, if need be, at least once a year.

I was very honored to receive the Quarterly Rewards & Recognition Award for successfully leading and considerably improving our processes during this project.

Lessons Learned

What should you take away from this? Two things in my opinion. First, plan, plan, plan, and then plan some more. When most of these documents were done from scratch, it was a huge undertaking. Going through the WBS, Workflow, and Process in a methodical way is what I believe made this a success.

Second, set your team up for success rather than failure. When implementing a new tool or process, take the time to document it properly before rolling it out, not a year later. Sure you won’t be making money hand over fist at first, but think of all the money saved from doing it right the first time. As a side benefit, things run more smoothly, employees are less stressed, and the customer is happier.