The document discusses why learning projects often fail and how to prevent failure. It notes that only 16.2% of software projects are completed on time and on budget according to research. Project failure can be prevented by clearly defining requirements, expectations, scope, and terms upfront in a requirements document. Maintaining open communication and ensuring all parties agree on timelines and responsibilities can also help avoid failure. Additional reviewers, scope creep, and changing project managers are some issues that can impact budgets, timelines and lead to failure if not properly managed.

1. 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.

2. SoftAssist, Inc. 700 American Avenue Suite 205 King of Prussia, PA, 19406 610.265.8484
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

3. SoftAssist, Inc. 700 American Avenue Suite 205 King of Prussia, PA, 19406 610.265.8484
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

4. SoftAssist, Inc. 700 American Avenue Suite 205 King of Prussia, PA, 19406 610.265.8484
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.

5. SoftAssist, Inc. 700 American Avenue Suite 205 King of Prussia, PA, 19406 610.265.8484
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.

6. SoftAssist, Inc. 700 American Avenue Suite 205 King of Prussia, PA, 19406 610.265.8484
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