My company bought out a smaller technology company
and absorbed all of their assets. We planned
to incorporate their technology into our main equipment suite. I was assigned as the technical instructional
designer on the project and tasked with building the training course for our service
technicians. The majority of the design
work was already done because they already had a training course with training
materials and supporting documentation.
We conducted a front-end analysis in order to decide if the established course
would meet our training needs. It was
decided that it was adequate and would only need rebranding and interface
descriptions.
I took the course material and technical
documentation and began work. As I reached
75% completion, I was informed that our technical documentation department had
also taken their technical documentation and made major modifications and
repackaged them into completely new manuals.
This meant I had to start all over to ensure that our new course
followed the new manuals that were being provided to the service technicians. The concepts remained the same but process
and procedures were drastically changed.
It was very time consuming to go back and ensure thing were in the right
order and were referring to the right page of the proper manual. As I reached 90% completion, a software
update was released. All machines were
not going to be required to be updated.
This meant I need to go back and include information on how the new
software physically and functionally changed the machine.
Had the circumstances been different those two
changes of scope could have been detrimental to the success of the project. Because there was no hard deadline date set
for completion, every time something came up more time was allowed for its
inclusion. The preexisting course
material was used until I finished the new course with all of the changes. If I were in charge and there was a hard
deadline. The software update
information would have been left out of the formal course material. The necessary information could have been
provided to the students as a handout.
Herbert, My jaw literally dropped when I read, that they "made major modifications and repackaged them into completely new manuals." Why is that people make changes without consulting all stakeholders. This seems to be a project management oversight. Whoever was in charge of this training should have been keeping tabs on all system updates and informing you along the way. A new manual doesn't just appear out of no where. This means that while you were wasting hours creating outdated courseware, someone else was working on those manuals. If only your PM would have helped bridge the gap, the scope creep could have been avoided all together!
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteHerbert, your example takes scope creep to another level! It was fortunate that no hard completion date was set. Buyouts and mergers do present some confusing circumstances until communication procedures, roles, and working relationships are established. Without knowing all the specifics, it does seem that the project manager should have analyzed the tasks involved and communicated with the technical documentation department before having you do so much work on the training course. I assume the soft ware update was on of those unforeseeable obstacles that can occur during a project.
ReplyDeleteI read an article, Managing Out of Control Requirements and Scope Creep at http://www.gatherspace.com/static/scope_creep.html, which you may find of interest. The article states that “according to the 2004 Chaos report by The Standish Group, over 68% of large software projects end up failing to fully meet the needs of their customers or never reaching completion” (Gatherspace, n.d., para. 3). Inspite of serious scope creep you beat the odds! Gatherspace (n.d.) offers some good advice for serious scope creep:
“When you find yourself on a project where there is obvious scope creep and requirements are getting out of control, remember to keep a positive attitude and treat even a troubled project as a learning experience. Even if you can't save your current project from scope creep, do what you can to minimize the negative impact and you may find yourself saving the day and receiving important accolades. You are sure to end up on another project where your requirements and project management toolset along with your experience in managing scope creep is strong enough to bring your project to the finish line” (para. 18).
Reference
GatherSpace. (n.d.). Managing out of control requirements and scope creep. Retrieved from the GatherSpace website: http://www.gatherspace.com/static/scope_creep.html
Hello Herbert,
ReplyDeleteThanks for the great example this week. That must have been very strenuous on the nerves to be so close to done and have to basically reinvent the wheel not only once but twice. With your experience on this project do you think that both those changes could have been avoided if the right people were at the table to begin with? I would assume IT doesn't just do preemptive software installs on the fly, or that a technical writing group revisits their documentation at random. Was there an assigned PM to the project any chance? Knowing what you know now, beyond your observations above, would you have PMd or done your analysis differently? I know easy to ask in retrospect...
This comment has been removed by the author.
ReplyDeleteI am looking forward to reading your blog post concerning training and development.
ReplyDelete