Past Projects, the good, the bad, and seriously…

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


3 thoughts on “Past Projects, the good, the bad, and seriously…

  1. Excellent self-reflective post! I especially appreciate your candor in describing what was obviously not a pleasant work experience as many of us do not want to reveal these experiences. We all have experienced the “perfectionist” supervisors or others in positions of authority who find flaws in our best efforts and project an attitude of, “If you want something done right, you have to do it yourself.” Sometimes a good way to mitigate the negative effects of these toxic supervisors is to have an experienced peer review your work before presenting it to the “boss” for his or her overly critical scrutiny. This would become a reciprocal and beneficial relationship over time as you would perform a similar role when their project deliverable was in the quality assurance – quality control (QA-QC) pipeline. Another technique, and perhaps more effective, is to have a subject matter expert (SME) conduct a more formal review of the product. By definition, the SME should carry the day over the supervisor or project manager in regards to content technical fidelity and accuracy.

  2. I liked your post about the problems you had with the project. Sometimes bosses can be picky when it comes to projects and they want them done a certain way. I have a boss just like that, this is why when he assigns me a project I try to get as much information as possible from him so that I know what he is looking for. R.M. Wilcox made some excellent suggestions that can be used to have a successful project.

  3. Dear Eric,

    You make some excellent points in your post that highlights how many of us move forward based on our own perspective and experience. Essentially, we assume that our projects are similar to one another and are likely to benefit from similar approaches (Shenhar & Dvir, 1996). In your discussion, you comment that, while your boss was very detailed oriented, there was room for improvement on your end. That shows a lot of character to want to learn and to be better. In your opinion, would you or your co-workers have responded differently if your boss sugar coated their remarks; that is, is being truthful and blunt often better in the long-run. I welcome any thoughts that you may have.



    Shenhar, A. J., & Dvir, D. (1996). Toward a typological theory of project management. Research policy, 25(4), 607-632.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s