In this week’s blog we are to recall a project from the past that was not as successful as I wanted it to be or not at all. This is something I have had some experience with having many trial and error periods in my career. I tend to get all excited about a project and what the results will be and what will be able to do when it’s all finished. Then when I sit down and get ready to start I have no idea what to door where to go from there.
In my first job as a designer I was actually considered a functional trainer and I was tasked with writing all of the new processes and then teach them to the team including any other department involved. The first time I did this I was so excited I couldn’t wait to get to work. When I got there my manager assigned me a co-worker that could assist me with writing this first big new process that was going to change a lot of what we do in the department. It had to map out all of the changes and explain the new process for basic situations so that anyone reading it would understand what was expected. We also needed to explain what the desired outcome would be so that expectations were clear. Now this was going to be a major change so we had to get the process written in two days because our director wanted us to start training our team by Wednesday of that week.
The first thing we did was write out what the process was and how to process the new changes in the data base using the new procedure. We did all of this with screen shots and gave instructions for each section as a how to. When we were all finished the document was 35 pages long which seemed light considering all of the changes, but we read over it several times before we turned it into our manager. After reading it he called us into his office and said it was ok, but there were a few changes that needed to be made. As we began discussing the changes our manager would change the document and explain why. He changed the entire document and reworded everything stating that we did not explain it right and it was too overwhelming; that we should be able to add this process with much less document for them to follow. He re-wrote the entire document stating that we actually wrote it like we had no direction or clue where we were going with the document. Needless to say we were not longer aloud to write processes and we only taught until we proved that we had either taken classes or gotten instructions from another reliable source. Needless to say I didn’t write another process on my own for a year.
When it comes to what I contributed to the success of the process it was our screenshots of the process itself that were not changed which was actually the hardest part to make. We had to take a screenshot of every single move we made so that it was step by step. But when it came to the words we wrote as instructions and descriptions we were way off base so my manager changed them all even saying we could have used better wording in our explanations. The scolding made me feel like I needed to take English again. Something that I learned from that experience was to “Scope the Work ahead of time and get a sign off from your management team. (Laureate Education, Defining the Scope, n.d.). Always verify what is needed to be done and gather insights to how it should be approached and accomplished. Also, Review all of the possible requirements from SCORM standards to technical requirements to make sure you have everything you need to complete the project (Laureate Education, Defining the Scope, n.d.). As the PM I should have done my homework on not only writing the process, but tested it with a group for accuracy before turning it in to my manager.
Preparation is the key to a successful project.
Laureate Education (Producer). (n.d.). Defining the scope of an ID project [Video file]. Retrieved from https://class.waldenu.edu