Thursday, February 10, 2011

Managing The Creep!

While reflecting on the topic of "managing the creep", the term has a double meaning that evokes vivid memories of my all time worst Project from Hell. I was a fairly new senior instructional designer, also acting as the ISD Project Manager, when I was faced with an absolute nightmare in terms of scope creep. The project consisted of approximately 80 short courses that contained close to 200 Adobe Captivate simulations. The client/sponsor – a director from a business sales organization – was seasoned, smart, reasonable and would defer to the “training professionals” when it came to the training plan. The negotiated timeline, at the beginning of the project, was attainable. I had an extremely talented developer (contractor) working with me on the project. While the project was daunting and slightly complex, I felt confident that we could meet or exceed our client’s expectations. All was right with the world! My developer and I were excited and motivated to “knock it out of the ballpark” for this client, who was such a joy to work with. We were equally committed to creating a dazzling product for her! Then the shoe dropped. There was a reorganization that was taking place and downsizing was imminent. Our sponsor had to deal with more pressing business issues. The client hired a contractor (previous employee) to manage the project for her. She gave total control and authority to the PM. This was when our lives changed. Our previously stable timeline and steady progress became a daily battle in an effort to “manage the creep”. The new PM insisted on adding audio to the simulations – and declared that she would narrate them! Her voice was less than professional sounding. (I’m being kind) This was exacerbated by constant changes and moving targets created by the PM. What was a stable training plan and scope of work, became a constant wrestling match to deal with the PM moving the targets. When I tried to reach out to the project client/sponsor for help and a voice of reason, the PM became a wedge between us and put her spin on the message. So much so that the client would simply defer to the PMs decision because she was simply overwhelmed with the well being of her organization. And as the client deferred to her, the PM became more aggressive and demanding. This nightmare culminated in a weekend that brought some professional regrets on my part.

It started when one last round of changes required that my developer and I work around the clock to meet the deadline. We started early Friday morning – he in Chicago at 8am CST and me in San Francisco at 6am PST – and we worked around the clock adding the narration audio files that she had continually revised. We spent hours adding the audio files and adjusting the Captivate simulation timelines… a tedious and time consuming process as some of you might know! We finally finished at 3pm PST on Saturday afternoon… after working through the night. I think I developed carpel tunnel syndrome in a single weekend as a result of manipulating those simulation timelines! But, we were so proud of ourselves at that point – we had met the challenge! We agreed to regroup on Sunday morning after getting some sleep. At that time, we’d fine tune and polish up our final products. And we did. And we were proud of the dedication we’d shown in meeting the deadline, despite the changes.

Next… a meeting on Monday morning with the PM… and we couldn’t wait to say “We did it! We busted our behinds… but we got it done!” [What was unsaid: “Despite your ridiculous demands, your disrespect and ignorance of the process and the unreasonable timeline, we’ve produced something good… even if your speaking voice sucks!”] So… we “arrive” at the virtual meeting (audio conference call)… and announce that we had completed adding the narrations to the simulations, meeting the project deadline. And without acknowledging our effort and achievement, the PM begins browbeating my developer. She begins complaining about some insignificant document that he hadn’t updated or sent to her. She said she had additional changes – she had rerecorded audio over the weekend – and expected the updates to be completed within the week. This was the last straw for me. A quiet storm came over me and I calmly asked her not to speak disrespectfully to [let’s call him Jason] and that we both had worked tirelessly – for 33 hours straight on Friday/Saturday – to integrate the audio files that she had insisted upon and were outside the original scope of the project. The call duration was up and the call ended. I wrote a scathing email to my boss, her boss, both our bosses’ boss, and hit send. [Always good to calm down before hovering and plowing down on that SEND button!]

I won’t go into the coaching I received from my boss nor the drama that ensued as a result of the escalations. Quite honestly, it was worth it! The PMs abuse and misuse of power had become too much to bear. However, I am sad to say that later that day my dedicated, talented developer walked out on the job. I had never experienced that nor have I experienced it since. He called me later that evening and said he was sorry and that he loved working with me but he wouldn’t work with her any more.

Bottom line: I will always see this as my failure. I was a naïve, new ISD PM and I didn’t know how to say “No” or deal with the dynamics of a very complex situation. If I had it to do over again, I would have implemented a change management plan and communication plan (Stolovich, 2010). I would have managed the scope creep much more aggressively and methodically. This was a huge learning experience that matured me professionally. It was painful, but it made me stronger as an instructional designer and project manager. Portny, et. al. define scope creep as: “The natural tendency of the client, as well as project team members, to try to improve the project’s output as the project progresses.” What Portney, et. al. don’t say in this definition is the power and importance of … “Just say NO!”

References

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.

Stolovich, M. (2010). Creating a resource allocation plan. [Online video]. Laureate Education, Inc. Retrieved from http://sylvan.live.ecollege.com/ec/crs/default.learn?CourseID=4744643&Survey=1&47=6446186&ClientNodeID=984650&coursenav=1&bhcp=1

Thursday, February 3, 2011

Estimating Training Project Costs

Don Clark’s Big Dog & Little Dog’s Performance Juxtaposition – Performance, Learning, Leadership, & Knowledge site has a lot of great information on it – from the basics of Instructional System Design (ISD) to topics like estimating costs for training programs. This site provides a variety of ISD related information with details that you may find helpful when building a budget. The Estimating Costs and Time in Instructional Design page presents design ratios and case studies that are helpful. Design ratios are invaluable in estimating costs associated with training projects. Keep in mind that design ratios are estimates and you can find a variety of them by different resources. One of the most comprehensive and accurate that I’ve seen is by Brian Chapman. His blog post, How long does it take to create training?, is available on a great Training & Development research site called Brandon-Hall.  (Also see the Brian's blog on the Chapman Alliance website. The Cost Estimator tool, on Clark's site, is a very basic tool that assists with estimating and tracking costs for training projects.

The Project Smart site presents the “Three Point Estimating” technique that offers a more accurate method of estimating costs using Best Case, Most Likely Case, and Worst Case estimates (Haughey, 2010). The formula is:

Estimate = ( B + 4 M + W ) / 6
• B = best case (1/6)
• M = most likely (4/6)
• W = worst case (1/6)

Another great nugget found on the Project Smart site is the Project Management Proverb: The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times. Estimating project costs is as much an art as it is a science. There are methodologies and tools that can guide the exercise of estimating project costs and building budgets, but there is usually that element of adding our “best guess”.

References

Chapman, B. (2007, December 5). Estimating development times. Message posted to http://brandon-hall.com/bryanchapman/?p=7

Haughey, D. (2010). Estimating project costs. Retrieved from http://www.projectsmart.co.uk/estimating-project-costs.html

Phillips, J. (2010). Project cost management. Retrieved from http://www.projectsmart.co.uk/project-cost-management.html

Piskurich, G.M. (2006). Rapid instructional design: Learning ID fast and right (2nd ed.). San Francisco: Pfeiffer. Copyright by John Wiley & Sons, Inc. Used by permission via the Copyright Clearance Center Retrieved from: http://sylvan.live.ecollege.com/ec/courses/56607/CRS-CW-4744643/EDUC_6145_readings/6145_Wk5_Piskurich_39-47.pdf

Sommers, A. (2010). 12 tips for accurate project estimating. Retrieved from: http://www.projectsmart.co.uk/12-tips-for-accurate-project-estimating.html