Inspiration for Students of Instructional Design and Technology

Archive for the ‘Project Management’ Category

Scope Creep: Why Fight It?

einstein

Scope creep is unavoidable, say our textbook authors (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008). However, it can be controlled by the project manager through a formal change control system. If the project manager, however, informally permits changes to scope, the project will be in jeopardy. Changes to scope will require extra time and resources, which require changes to the budget and timeline.

Still, if something is unavoidable, why would we try so hard to avoid it? Scope creep sometimes occurs because customers or team members identify desired improvements as the project progresses (Portny et al., 2008). It may also result from “lack of proper identification of which products and features are required” (Lynch & Roecker, 2007). Having spent many years in the IT industry supporting software development projects, scope creep has been the rule, not the exception, and it’s usually caused by one or both of these reasons. Still, I wonder: Is it realistic to think you can perfectly design any project up front—be it a software product or an e-learning course?

Is scope creep a failure to plan, or is strict adherence to the original design a failure of imagination?

I once supported a project that delivered a hardware and software solution to our customer. We had project managers on our side and theirs. We had business analysts who tediously compiled a requirements document that exceeded a hundred pages. Yet, as the project progressed and new releases were tested, the customer realized that certain needed functionality was lacking. We were prepared and dutifully created a new Functional Specification document and a corresponding Change Control agreement. Our project followed a “waterfall” systems development life cycle (SDLC), comparable to following ADDIE in a linear fashion. Therefore, any changes were tedious, time consuming, and stressful to the team.

Instead of fighting the inevitable, why not plan for and embrace change as part of the process? That’s what an Agile development process does for software development, and rapid prototyping methodologies do the same for instructional design. With this more realistic approach, “many things that might have been scope creep under a waterfall SDLC aren’t a problem” (Yatzeck, 2012). Yatzeck describes Agile as a flexible process that starts with a high-level design and fills in the details during development. The plan includes a 20-percent contingency for “unknown unknowns,” and swapping out one thing for something else of comparable impact to the project is OK.

Yatzceck (2012) sums up the difference as follows:

An agile project is actually much less vulnerable to scope creep than a waterfall project, simply because it is built to support the need for change. Agile requirements are pointed towards “what the business will need at delivery time,” where waterfall requirements inevitably point back towards “what the business thought it needed at project charter time.” (para. 12).

So, how does Agile apply to instructional design? At last year’s ASTD International Convention and Exposition, I heard Michael Allen present his model for developing instruction. In his book, Leaving ADDIE for SAM: An Agile Model for Developing the Best Learning Experiences, he describes a successive approximation model (SAM). This model adopts prototyping and iterative cycles in the design and development phases and avoids the “analysis paralysis” that plagues the traditional linear version of ADDIE.

SAM

Source: Neibert, J. (2012)

So, fellow IDs, why not toss those Change Control forms and accept change as not only an inevitable, but valuable, part of the instructional design process?

Albert-Einstein-quotes-25

References

Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge.

Neibert, J. (2012, September 19). Book Review: Leaving ADDIE for SAM, by Michael Allen with Richard Sites. Retrieved from http://www.learningsolutionsmag.com/articles/1012/book-review-leaving-addie-for-sam-by-michael-allen-with-richard-sites

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.

Yatzeck, E. (2012, August 14). How to control scope creep in Agile. Retrieved from http://www.thoughtworks.com/insights/blog/how-control-scope-creep-agile

Communicating Effectively

This week, we viewed the multimedia program “The Art of Effective Communication” in which the following message was delivered in three ways: email, voicemail, and face-to-face.

Jane's email

Although the words were exactly the same, the message came across differently in each modality. These were my impressions.

Email

My impression from this message is that Jane feels:

  • Frustrated because she has tried to get this report from Mark before.
  • Desperate because she is about to miss her deadline, and it’s all Mark’s fault.
  • Not really concerned about Mark’s busy day and expects him to drop everything and get it done.

Although written communications provide an efficient manner for delivering facts, the author cannot “pick up nonverbal signals that suggest an audience’s reactions to the message” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 358).

Voicemail

After hearing Jane’s tone of voice as she delivers the message, my impression changed slightly:

  • Jane needs the report ASAP, but it isn’t quite as urgent as the email indicated.
  • Jane isn’t mad at Mark, nor does she blame him for the report that is missing, but she does expect a prompt response.
  • Jane appreciates Mark’s help because he’s busy.

Face-to-Face

In the final modality, the addition of facial cues along with voice tone give yet a third impression.

  • Although Jane needs the report soon, it’s not urgent.
  • Jane doesn’t blame Mark for the missing report but sees him as someone who can help her out of a bind.
  • Jane is trying to sweet-talk him because she knows he’s busy.
  • Mark could probably put her off for awhile.

Conclusion

In our business and personal lives, we rely more and more on email and text. In the “Communicating with Stakeholders” video, Dr. Stolovitch reminds us that communication is not just about words, but also “spirit and attitude, tonality, body language, timing, and personality of the recipient” (Laureate Education, n.d.). Not only are those cues hard to convey in writing, but I believe we sometimes say things from a distance that we wouldn’t say in person. Complicating this issue, as we send more of our messages via mobile devices, we tend to be brief and to the point, omitting the social niceties of face-to-face discourse. As a result, the recipient may find our messages to be abrupt, bossy, or rude.

A project manager should ask stakeholders and team members what form of communication they prefer. Most people will chose email, which, as this assignment proves, is the most likely form to create misunderstanding. As a remote worker, I find this particularly challenging because I can’t drop by someone’s office or pass them in the hall. Those casual meetings often reveal important information, and they can build rapport. Since completing this assignment, I’ve been more sensitive to my emails and found myself picking up the phone more often.

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.

Laureate Education, Inc. (Producer). (n.d.). Communicating with Stakeholders [Video podcast]. Retrieved from https://class.waldenu.edu

Project Post-Mortem

For two decades, I worked as both a technical writer and an instructional designer in the IT industry. My projects always supported a hardware or software rollout, rather than being the core deliverable. Rarely have I seen a project completed on time. Typically, the rollout is late and fraught with problems. Gartner Research, noting that “failure” is a subjective term, puts the failure rate for IT projects at 24 percent (Handler, 2011).

Background

One particular project involved rolling out a hardware and software solution for a large retail company. I was responsible for writing the product documentation, developing a series of e-Learning modules, and creating and teaching instructor-led training (ILT) at the pilot store. Within two months of the pilot, the equipment was pulled out and the project went back to the drawing board. This occurred for two reasons: (1) rejection of the new concept by a large number of the store’s customers and (2) buggy operation of the hardware and software.

Project planning

Both my company and our customer had project managers carefully overseeing the project. They produced all the typical documentation, schedules, and contracts. The customer’s PM and business analyst developed a detailed requirements document that laid out exactly what the product should do. Changes in scope, of which there were several, were agreed to in carefully written change requests. When it came time for the pilot, all the hardware and personnel arrived on time. For my part, I worked with the account executive to submit SOWs for the e-Learning and ILT. These documents outlined deliverables, scope, risks and assumptions, a timeline, and costs. Although the project was eight months behind schedule, overall, the PMs did their job by the book. So, what went wrong?

Needs analysis

This project introduced a new self-payment process at a retail store. Although the store touted the benefits of the new system with colorful signs and banners, the actual business goal was to reduce labor costs. The new payment method might very well have appealed to a younger demographic. However, on the day of the pilot, we (including members of our customer’s team) were all surprised to see a much older group of people walking through the door. These customers were highly displeased with the new system, and, quite frankly, many of them found it physically and mentally challenging.

Projects often fail because of “unrealistic and mismatched expectations” (Krigsman, 2012, para. 10). The project initiation phase should include building a business case, which may include a market analysis (Zaval & Wagner, 2011). Our customer clearly overlooked their customers’ needs in pursuit of cost savings. At the very least, they did a poor job of selecting a pilot store.

Resources

Although I blame our customer for the rejection of the new system by the store customers, the hardware and software problems were clearly the responsibility of my company. Murphy (1994) emphasizes the need for senior management to allocate adequate resources to a project. Success would have potentially opened up a new market for my company, but our group was understaffed all along. Nearly half of our small team resigned just as the project began, and we did not replace them. Most notably, we lost a QA person at a critical phase in the testing.

Methodology

Adding to our woes, our customer demanded that we follow a “waterfall” method of software development and testing, which is equivalent to ADDIE in the instructional design world. West (2013) suggests that the model “is risky and invites failure” (para. 3). Unlike Agile methods, our process was linear and time-consuming, injecting redundant work and delays into the QA process. In the end, the released product was fatally flawed.

Conclusion

If senior management has a flawed vision or declines to allocate adequate resources to a project, it will fail despite the best efforts of the project manager.

References

Handler, R.A. (2011, September 11). To Improve IT Project Success, Focus on Partnership, Requirements and Resources. Retrieved from http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&resId=1781845&ref=QuickSearch&sthkw=it+project+management+failure

Krigsman, M. (2012, April 16). Who’s accountable for IT failure? (part one). Retrieved from http://www.zdnet.com/blog/projectfailures/whos-accountable-for-it-failure-part-one/15451

Murphy, C. (1994). Utilizing project management techniques in the design of instructional materials. Performance & Instruction, 33(3), 9–11.

West, R. (2013, March 17). Everything you think you know about Waterfall development is (probably) wrong. Retrieved from http://changearc.wordpress.com/2013/03/17/everything-you-think-you-know-about-waterfall-development-is-probably-wrong/

Zaval, L.K., and Wagner, T. (2011). Project manager street smarts: A real world guide to PMP skills (2nd ed). Indianapolis, IN: John Wiley & Sons, Inc.

Project Management in Education and Training

This is a just a quick post to welcome my EDUC 6145 blog group.

Tag Cloud