Life by Design

Learning from a Project – “Post-mortem”

Posted on: November 11, 2010

Recently, a team member and I were given the assignment of creating instructional videos to show students how to utilize strategies that we have created to help them complete research on the Internet.  My team member and I had no prior training or familiarity with using application like Jing or SnapzPro, which are screencasting applications.  I had learned from my courses at Walden that at the very least we needed to story board our process and I did do that much.

We began in June, 2010,  to create videos demonstrating the steps a student would take to create what we call a ‘digital notebook’ and how to begin to do Web research, creating good search questions, and finally extracting relevant information from the Internet to meet their project needs.

Both of us felt that we were making good progress.  The videos were clear and did a good job of demonstrating our process.

However, when our boss reviewed the work by mid-July, we got the news that the videos were completely inappropriate.  She changed the content, the approach and made a request for a ‘more professional appearance’ with special features such as the ability to highlight text, zooming capabilities and so on.  Six weeks of work was essentially thrown out.  I have to say that my team member and I felt demoralized.  I do give us tremendous credit for stepping into a project cold, learning new applications and devising a strategy on our own to set up a small video production team.

Now, after being introduced to all the steps necessary in professional Project Management, I can see that the first major error was the lack of an initial meeting that clearly and explicitly defined the video project.  My team member and I needed a clear vision of the end product.  One of my favorite guidelines for planning anything is, “Begin with the end in mind.”

If I had to do this over again, or could function more as a Project Manager for the project I would follow the steps recommended by Michael Greer (2010):

1.     Define the project concept and get support and approval from stakeholders. In this case I want specific and very explicit definitions of the expectations of the final product.

2.     Get the team together and start the project.

3.     Figure out exactly what the finished work product will be.  This will be informed by the information gathered in Step 1.

4.     Figure out what you need to do to complete the work products.  Identify tasks and phases.  I would also include here a preliminary testing of various applications of technology, so that we choose the most appropriate tool for the job, and get adequate tutorials to inform ourselves on the process before we begin.

5.     Estimate time, effort and resources.  In our case, we need to define upfront in the initial product scope meeting, if we have adequate computer equipment and facility space to do the projects we are given.

6.     Build a schedule.  I would add that we needed to define from Step 1 the exact nature of the deadlines.  If there is a hard and fast deadline, I want our team to be able to meet the deadline with unnecessary stress.

7.     Estimate the costs.

8.     Keep the project moving.  Have face-to-face meetings with our major stakeholder on a regular basis so that reviews of our work can happen often and early into the project before we do a large body of work that is later deemed ‘inappropriate’.

9.     Handle scope changes.  I am happy to handle scope changes, as I understand that this is part of the territory.  However, the stakeholders need to realize that the time frames are greatly impacted by every content change in a project.

10. Close out phases, and close out the project.

Also, I would let the ID process guide the project starting with a needs and feasibility analysis and continue with all the ADDIE steps.  We needed a clear blueprint, project plan, Work Breakdown Structure, Project Scope Statement, Gantt chart to help schedule the project to meet projected deadlines, and checklists to keep the project moving.

By starting from a good place of planning and communication, I believe our video production would have been successful the first time around.

Reference

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate Custom ed.). Baltimore: Laureate Education, Inc.

Stolovitch, H. (2010) “Project Management and Instructional Design”. Laureate Education, Inc. Video Production.

Advertisements

6 Responses to "Learning from a Project – “Post-mortem”"

Hi Deborah-

I can see why you and your teammate would have felt demoralized. You both had already put so much effort into this project. To have it essential thrown out would have been very frustrating.

Greer’s guidelines are really very helpful when working on projects. I know I would have liked to have had these guidelines while working on previous projects. One of the things that Greer mentions about dealing with scope change is:

“Stay calm. Remind yourself that the original project scope documents were created at a time when you knew less than you know now. Given the new knowledge and circumstances, you need to modify your plan. This will likely result in your having to ask for more time, more resources, more money, and other concessions from your sponsors or stakeholders. Realize that you’ll simply need to analyze the situation and make a solid case for your new requirements” (2010, p. 36).

Personally, I can say that staying calm is not one of my responses to dealing with scope change. Typically frustration, anger, irritation are the emotions that I feel! However, I am learning, especially as I work on more and more projects. Scope change is inevitable, but as you stated, ensuring the stakeholders understand that changing the scope affects everything else (time, budget), is the most difficult part of dealing with the change in scope.

Thank you for sharing you story!

Reference:

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

Deborah:

Your instructional video project sounds like it was a very frustrating experience. I must admit that I had not previously heard of Jing or SnapzPro screencasting software. Screencasting software applications are used to record activities on the computer screen, mouse movement, and often include live audio for playback at a later time (Comparison of screencasting software, 2010). The only screencasting applications that I am familiar with are Adobe Captivate and Camtasia Studio.

In the case of your instructional video project, I would argue that either the students or your organization were your client and your boss was the project manager. This would mean that the failure of this project rests on her shoulders rather than yours.

References

Comparison of screencasting software. (2010, November 11). In Wikipedia, The Free Encyclopedia. Retrieved from http://en.wikipedia.org/w/index.php?title=Comparison_of_screencasting_software&oldid=396125345.

Thank you for this great example. It offers many points of interest.

I agree with David’s comment that the students were the “client” in your example and wonder if part of the problem was lack of agreement on client needs. (In the ADDIE model of instructional design, this would be part of the Learner and Contextual Analysis. (Morrison, Ross & Kemp, 2007)) This aspect caught my attention because when I was involved with creating an online reference tool for undergraduates one of the team members added “cute” graphics (they were not kittens playing with balls of yarn, but almost that “cute”). She felt that it added “fun” to the blocks of text; I felt that it was demeaning to the over-18 age learners. This could have been avoided if we had begun with an agreement regarding “Learner Characteristics”.

Which brings me to another point of interest, the disappointment you felt when your boss reviewed your work. I wonder if creation of a project prototype would have eased the feeling of demoralization. I recently participated in a webinar featuring Matt Montagne (http://tinyurl.com/cr20live-DesignThinking) an expert in Design Thinking; he stressed the importance of creating and presenting prototypes early in the design process. His point was that by presenting your ideas soon after they are conceived, you are not as “wedded” to the idea and much less likely to have a negative reaction to revisions suggested by others. Do you think early prototyping would have made a difference in the life-cycle of your project?

Andrea Hildreth

References

Montagne, M. (2010, October 16). Design Thinking, archived at http://tinyurl.com/cr20live-DesignThinking

Morrison, G.R., Ross, S.M., Kemp, J. E. (2007). Designing effective instruction (5th ed.). Hoboken, NJ: John Wiley & Sons, Inc.

Yes, Andrea, by all means doing a proper learner needs analysis and providing prototypes early on in the process would have greatly helped the project move along with more grace. I have sure seen the value of planning everything out before you start any project and really nailing down the desired design result before the team gets started. The silver lining about my current work situation, is that I’m seeing just how valuable all the resources we have at our disposal right now in our course are to really good project quality, performance and completion. Thanks for your comments.

Hi Deborah,

I think that the following comment that you posted is very important:

“Keep the project moving. Have face-to-face meetings with our major stakeholder on a regular basis so that reviews of our work can happen often and early into the project before we do a large body of work that is later deemed ‘inappropriate’.”

You did a great job explaining the background of the project, but I wonder how much the stakeholder was at fault for letting you and your team member get so far into the project before he or she felt that it was inappropriate. It almost seems as though you were not given a clear scope of the goal of the project from your boss. Knowing what the intended goal of a project is important and if you it is not understood or specified thoroughly, then precious time and possibilty money is wasted (Portny et al., 2008).

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.

Bummer!
Its disappointing when you put in alot of work towards a poorly defined goal, at least in hindsight it seems to be poorly defined, only to have weeks or hard work be worthless. The key to success is planning, planning and more planning as our learning resources have stated. The key stakeholders must clearly and completely approve of the project goals in the early stages of the project to avoid re-work, but even then its not guaranteed that changes won’t be required. Stakeholders can be a finicky bunch. Good example Deborah, thanks for sharing.

Will

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: