Why Learning Projects Fail

SoftAssist, Inc. 700 American Avenue Suite 205 King of Prussia, PA, 19406 610.265.8484

WHY LEARNING PROJECTS FAIL Karen Beckman, Project Manager David Goodman, Principal SoftAssist, Inc. December, 2013

The Standish Group research shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. Internet view, 12/10/13 www.projectsmart.co.uk

Successful projects are completed on time and on budget. “On time” is dependent upon a firm start date and an equally strict receivables schedule. Clients, either internal to a training department or external clients with a vendor, will push back the start date for a variety of reasons: SME availability, financial constrictions, change in practice or requirements, technical issues, etc. Sometimes the client will push back the start date but expect the final delivery date to remain the same. This is why it is imperative to have a kick-off meeting with the client whereby each team member can know and accept the terms and conditions of a project. Time needs to be spent with the client defining terms such as prototype, alpha, beta, scope and creep prior to the beginning of any project. Deadlines and delivery dates need to be determined and it must be made clear to the client that if the start date is changed and receivables are not delivered on time the final delivery date will be delayed. A great approach to keep the client on track is a weekly email or online web session outlining the status of the project; or if time permits, a weekly telephone conference. An email or TC serves several purposes. It is a gentle reminder to the client that the internal training provider or vendor is expecting a receivable, e.g., a storyboard, access to software, copies of existing materials, revisions, a sign-off, etc and if it is not delivered on time the final delivery date will be pushed back. It also shows the client that the vendor is dedicated to their project and this personal attention builds a strong client/vendor relationship. Another issue that can wreak havoc with a project is the turnover of the project manager or primary SME. Although this predicament can often push back the delivery of a project it does not always lead to project failure. Because PMs and SMEs are passionate about the work they do they like to leave their “personal stamp” on the project they’re assigned.


Some incidents: A prototype that lasted six month due to focusing on minutiae e.g., the correct size of a character’s iris) rather than on the learning A first time manager who rejected recommendations and could not back away from their own ideas, causing multiple reviews and out of scope work A client review that included lying on the office floor reviewing the course for screen glare from all angles The SME who stated at the kick off meeting “I am a perfectionist – it will be hard to please me ” – was correct. The project was stopped within 2 months. A global project that crossed-over two fiscal years, multiple project manager changes, numerous reviewers, cultural clashes which precipitated numerous restarts

When a PM or SME “inherits” a project “wordsmithing” becomes an issue. Minor adjustments or changes to an existing project are expensive and time consuming. When a new PM or SME comes on board it is important to walk them through the project and stress that although the course may not reflect their personal style, if the content is correct, then the project should not require significant changes. Sometimes, there’s no convincing an SME to leave a project as is and then it is your responsibility as the vendor or internal client manager or PM to establish new delivery and receivable dates and possible budget revisions. Sometimes learning that the project will be delayed and additional costs will be incurred is enough to keep the project from being reworked. Long before you begin work on the project a solid requirements’ document needs to be written and agreed upon. Problems occur when: • There are no written requirements or the written requirements are not fully discussed, explained and agreed upon. • Terms are not well defined; example, what is a prototype? Is it 10 screens that represents an entire module; 10 random screens; 10 screens that portray some content screens, a knowledge check screen, two different levels of an interaction, etc? • Expectations are not discussed in detail and agreed upon •Client hires a vendor or agrees to use an internal resource for the expertise that a person brings but then wants things done their way and refuses to accept their opinion or recommendations • Unwritten rules, e.g., our company never uses humor, clip art or graphic characters in training • What is out of “in scope and out of scope” • Service level agreements and consequences are not defined • Uncertainty of the review process, who is involved, how many reviews are expected and the time limitations of a single review • Invoice payment dates and anticipated turnaround time for payment processing


A well-written requirements’ document should cover all these areas plus more. The purpose of the requirements’ document is to remove as much ambiguity as possible and how to revise the project when some unknown uncertainty arises. Each area of the project should be clearly defined and if questions do arise during the design and development of the project both the vendor/internal manager and the end client can refer back to the requirements’ document as base document for solution resolution.

We’ve discussed briefly the importance of a kick-off meeting and defining the terms involved with any project but it bears repeating. Scope, in scope, out of scope and scope creep are terms that must be defined and agreed upon or this issue can lead to project failure. At SoftAssist we define scope as the work that needs to be accomplished to deliver a project with specific features and functions based on content that is provided by the client. Scope creep refers to the incremental expansion of the scope of a project which may include and introduce more requirements that were not part of the initial planning. These issues may require adjusting the scope and payments of the project.

Goals Not Defined

Poor Expectations

Client’s Organizational

Procedures

Design Creep

Perfectionist

Too Many Reviewers

Extending Timelines Too

Often

Limited Access to SMEs

In-Scope, Out of Scope

Changing the PM or SME


Clients are often surprised to learn that their changes or revisions are out of scope and will affect the budget and timeline. As a project manager I will state that scope creep is the biggest problem I deal with on every project. Clients, especially those who do not have prior experience with developing online learning, often forget the budget and timelines during the reviews of the project and will ask for additional interactions and content. Scope creep also occurs when the primary SMEs ask for additional reviewers. It is imperative to convey to the client that yes, these changes can be made, but there will be additional costs and impacts on the final deliverable. We touched on the issue of multiple reviewers but it’s an issue that deserves a more in-depth discussion since it can impact scope, timelines and budget. The scenario goes something like this. You’re nearing completion of a project, the audio has been recorded and you’ve scheduled the Beta review (the next to final deliverable)… you are in the home stretch. And then you hear the words you never want to hear from a client, “I’m having additional reviewers take a look at the project.” Additional reviewers are problematic for many reasons. As we discussed earlier, each SME/PM has their own personal design/content ideas and would like to see them expressed in the project. This “wordsmithing” can lead to scope creep if their changes need to be incorporated. New revisions will also lead to additional costs, especially if the changes are numerous and audio needs to be re-recorded. Timelines will definitely be affected and the project deadline will be extended. Extending the timeline can also lead to a lack of interest in the project which can lead to project failure. When a client mentions the need for additional reviews/reviewers a very frank discussion about the issues that arise from additional reviews needs to take place. Once the client learns about additional costs and timeline delays they may decide that these reviews may not be necessary. At this point a face-to-face meeting may be necessary to convince the client that the course adheres to the expected outcomes and the project requirements.


Projects will fail. There are some clients who will never be happy no matter how hard you work on their project. But, the fact is, that if terms and expectations are clearly defined in the requirements document and communication is constant and open project failure can be dramatically decreased. Below is an illustration of a typical project flow. There are five points of client approval prior to proceeding to the next step. The requirements document and expectations are defined and agreed upon during the client “kick-off” meeting.

In summary, projects may fail due to any of the issues

mentioned. Project failure can be prevented but if it does occur, there are means to recover. Project Recovery Tips is another article that you may find of value. Contact us for further information.


About us: SoftAssist designs and develops custom learning for the classroom, online and mobile implementations. Some of our core services include:

Curriculum Development

Rapid Course Development (Camtasia, Studio, Storyline and Captivate)

Flash to HTML5 course conversions

Off the shelf HTML5 and Flash interactions

After market learning interventions to capture, retrieve and apply long term learning

Organizational learning strategies

US and Global training implementation

Classroom facilitation, documentation and exercise development

Documents

Why Learning Projects Fail