merck mcbm elearning - alleni.com · merck mcbm elearning for: jean grabowski ... mendota heights,...

Allen Interactions Inc. i

Merck MCBM eLearning

For:

Jean Grabowski – Merck

Submitted by:

Allen Interactions, Studio K

1120 Centre Pointe Drive

Mendota Heights, MN 55120

Todd Erickson

Studio Executive

Jeff Forrer

Producer

9/25/2014

Allen Interactions Inc. ii

Table of Contents

PROJECT SUMMARY ........................................................................................................................................................ 2

BACKGROUND ................................................................................................................................................................... 3

THE SOLUTION .................................................................................................................................................................. 3

AUDIENCE......................................................................................................................................................................... 4

PROCESS & COMMUNICATION ....................................................................................................................................... 5

PROJECT MANAGEMENT .................................................................................................................................................... 5

COMMENT MANAGEMENT TOOL ......................................................................................................................................... 5

TOOLS & TECHNOLOGY................................................................................................................................................... 6

TECHNICAL SPECS ............................................................................................................................................................. 6

LEARNING PORTAL AND AICC COMPLIANCE ........................................................................................................................ 6

TEAM ROLES & RESPONSIBILITIES ................................................................................................................................. 7

DECISION MAKING ..........................................................................................................................................................10

MANAGING SCOPE ..........................................................................................................................................................11

CHANGE OF SCOPE.............................................................................................................................................................11

IMPACT TO BUDGET OR TIMELINE ..........................................................................................................................................11

COMMUNICATIONS ........................................................................................................................................................12

WEEKLY COMMUNICATION ...............................................................................................................................................12

COURSE COMMENTS & FIXES ............................................................................................................................................12

PROJECT RISKS ................................................................................................................................................................13

PRODUCT QUALITY .........................................................................................................................................................14

QUALITY ASSURANCE .......................................................................................................................................................14

SCOPE OF QA ...................................................................................................................................................................14

ADDENDUM: PROCESS & STANDARDS ........................................................................................................................18

OVERVIEW .......................................................................................................................................................................18

PREPARATION PHASE .......................................................................................................................................................18

DESIGN PHASE .................................................................................................................................................................18

DEVELOPMENT PHASE ......................................................................................................................................................19

APPENDIX A: JIRA ...........................................................................................................................................................20


Allen Interactions Inc. 2

Project Summary

Allen Interactions is excited to partner with Merck to design and develop a highly effective

elearning course for MCBM audiences.

The eLearning solution must help MCBM audiences understand the MCBM process and the

importance of utilizing this process to improve Marketer’s commercial choices. These

identified solutions will support the development of necessary skills and competencies to

enhance the desired abilities of the MCBM audience to be successful in their roles in order to

drive and transform marketing efforts.



Background Merck needs to develop an eLearning to service the Merck Customer and Brand Marketing

(MCBM) global audience. The effectiveness of the MCBM audience directly relates to the

fulfillment and success of the GHH growth strategy and fulfillment of marketing excellence

within the organization.

The Solution

At a minimum, these eLearning solutions to be developed under this RFP will deliver:

1. An approach to developing understanding and skills for targeted audiences based on

MCBM content relevance for each audience segment.

2. An approach that ties learning to application to increase rigor and discipline in using

MCBM process/tools in strategic marketing planning consistently.

3. Emphasis on improving strategic decision making capabilities to increase level of

understanding.

4. An understanding of changing marketing environment and importance of

sponsorship and strategic mindset of MCBM transformation tools to drive consistent,

disciplined use across organization.

5. Creative emphasis and reinforcement on key subject areas (i.e., understanding full

range of customers, collaboration with Internal Customer Teams, integration of

Customer Centricity).

6. Blended design and development elements that present content in highly engaging

and flexible way to help build process skills effectively and efficiently.

7. Digestible learning content delivery to enable ease of understanding in support of

global audience.

8. Identify advantages/disadvantages to connect eLearning module and eSimulation or

be stand-alone modules.

9. An approach to assess capabilities and gaps.

10. A flexible delivery approach that factors in effective learning conditions (i.e., learner’s engagement, digestible content, seat time, flexible re-entry capability, easy

navigation, timing considerations).

Each eLearning solution will consider the unique needs, capabilities, diversity and experience

of the target audiences in order to develop optimal learning deliverables. These eLearning

solutions must demonstrate insight on a global scale, while helping learners better operate

within their geographic and franchise area.



Audience

The MCBM process, accompanied by tools, worksheets and guidance, need to be understood

across different target audiences. At the same time, identified audiences require different

strategic and process levels of understanding of MCBM based on their roles, such as:

• Segment 1 - Marketers (Apply the tools and develop strategy) – knowledge

skill building level

• Segment 2 - Internal Customer Teams/Supporters (Support and collaborate

with those who develop tools) –understanding overall process with skill

building elements

• Segment 3 - Global Brand Leaders/Business Unit Directors (Manage and assess

marketers)- strategic and process knowledge

• Segment 4 - Senior Leaders (Sponsor and endorse MCBM) process overview

and strategic knowledge.



Process & Communication

The sections below describe our process in detail. Our years of experience have allowed us to

develop tools, and other proprietary processes that ensure a smooth working relationship and

one that results in delivery of a successful solution—on time and within budget.

Project

Management

Our ability to partner energetically and enthusiastically with client teams while managing all

the creative and technical events is critical to our success.

Allen has worked to perfect processes for managing complex training development projects.

We feel our methods are the best in the industry. And they are unique. Some of the critical

elements include:

• A detailed Project Plan (this document which includes a schedule)

• A process that anticipates and plans for revisions

• A management approach that proactively avoids problems

• Functional and media prototypes and review cycles

• An online tool to track comments, suggestions, and quality assurance testing

• Weekly communications

• Weekly Status Reports (formal report or summary emails as preferred)

Our process is designed to promote communication between Allen Interaction project

managers and our clients, while at the same time engage the skills and experience of our

designers and developers to build highly engaging and interactive learning solutions. An

integral part of our approach is managing review cycles. Allen Interactions employs a

productivity tool, described below, that facilitates communication between the client team

and the development team as part of our Quality Assurance (QA) process.

Comment

Management

Tool

Allen Interactions uses an online commenting tool (JIRA), a small application accessed within

the eLearning course by a mouse click, which tracks course location information and stores it

within a database. As the client or the Allen Interactions QA team reviews prototypes, alphas,

or betas, the editing comments they enter are collected in this database. This online tool allows

the development team to easily associate editing comments with specific course content or

functionality so that each specific correction or adjustment can be made and then verified by

the client or QA team.



Tools & Technology

Technical

Specs

Refer to: Specifications in Merck RFP for complete Technical Specifications.

Layout

Design Specs • Content should be created in native 1024x768

Learning

Portal and

AICC

Compliance

• eLearning required to be published from Storyline 2 as an AICC compliant course for the myLearning LMS

• Course is to be published as Completed/Incomplete for LMS tracking



Team Roles & Responsibilities

Allen

Interactions

Resource management is a very involved process that requires both short and long-term

planning. As much as possible, Allen Interactions plans our resources out in advance. We are

flexible in that we can quickly scale up or down to meet unknown needs or changes to initial

plans.

Below are some of the key people who would be available to work on your project and a

description of their roles and responsibilities.

Jeff Forrer

Senior

Producer

• Serves as the project lead for Allen Interactions and manages all the day-to-day details

throughout all development cycles of the project

• Documents and helps define project deliverables

• Develops the timeline, project risks (and strategies to mitigate), Project Plan, and

weekly project status reports

• Manages the budget and weekly project progress

• Provides links to prototypes, and communicates any relevant project data

• Directs and manages the Allen Interactions project team, identifies project staffing

needs, and acquires appropriate resources

• Manages the client relationship to maintain scope and/or formally change scope

• Manages project documentation

• Is available throughout the life of the project for reviews, meetings, and re-design

Linda Rening

Instructional

Designer

• Analyzes the project's instructional strategy and makes recommendations

• Writes instructional content for the project, including scenarios, choices, feedback,

resources and instructions

• Creates prototypes during the Design phase

• Participates in SME meetings

• Reviews background material and results of SME and user interviews

• Helps prepare the instructional components of the Project Plan

• Analyzes the project's instructional strategy and makes recommendations

• Creates prototypes during the Design phase

• Writes instructional content for the project, including scenarios, choices, feedback,

resources and instructions

• Reviews background material and results of SME and user interviews

• Participates in SME meetings

Justin Pille

Lead

Architect and

Developer

• Develops and tests LMS coding and scripting

• Serves as the overall technical lead

• Contributes to instructional design

• Writes and tests programming code

• Troubleshoots and researches technical issues

• Writes and tests programming code

• Supports the Lead Architect throughout the project to develop the courseware

• Troubleshoots and researches technical issues



Chris Palm

Media Artist

Michelle

Kenoyer

Quality

Assurance

Manager

Todd Erickson

Studio

Executive

• Designs and creates media prototypes

• Creates media assets for task production

• Modifies the graphics related to the navigation interface

• Consults regarding screen design and information management of screens

• Manages and directs all QA processes

• Assigns a producer/project lead and project team

• Works with Allen producer to respond to needs that arise during the project

• Serves as senior consultant on project

• Checks in with the client lead to get feedback and verify project status

• Is first point of contact for any questions or concerns above the level of Senior Producer



Merck Below please find a description of Merck roles and responsibilities.

Jean

Grabowski

Project

Manager

• Manages all aspects for the eLearning project for Merck.

• Manages the day-to-day responsibilities of the project for the Merck team.

• Coordinates the team communication from the Merck side. This means communicating

with other internal stakeholders, SMEs and anyone else who may contribute to the

project.

• Works as the primary point of contact from Merck to the Allen Interactions Senior

Producer.

• Makes decisions about the project. The project manager has the authority to make (or

obtain) the final project decisions about functionality, media, and content. This

responsibility includes signing-off on project content. When the Project Manager signs

off on a deliverable or emails confirmation that this is “Final,” it is considered approved

by Merck.

• Provides feedback during design and QA phases.

Jean

Grabowski

Subject

Matter Expert

• Serves as the lead contact for Merck for the eLearning project.

• Provides subject matter expertise to the Allen Interactions team.

• Participates in the content development process.

• Confirms the accuracy of the content and scenarios.


• Provides subject matter expertise to the Allen Interactions team.

• Participates in the content development process.

• Confirms the accuracy of the content and scenarios.




Decision Making

Please use the following form to indicate the individual(s) on your team who are responsible

for the different eLearning aspects for the listed in the left column:

Who has sign-off authority on…? Name of Decision-Maker Decision is Binding? (Y/N)

Interface / Look and Feel Jean Grabowski Y

Technical issues Jean Grabowski Y

Budget / Schedule Jean Grabowski Y

Content / Subject Matter Jean Grabowski Y

Instructional design Jean Grabowski Y

Acceptance Review Jean Grabowski Y

The individual(s) listed above have the authority to make (or obtain) the final project decisions

about the specific area listed. This responsibility includes signing-off on project content. When

the individual listed signs off on a deliverable or emails confirmation that this is “Final,” it is

assumed that they have gotten sign off from any necessary parties and that the deliverable is

considered approved by Merck.

Merck confirms in this document that there are no other stakeholders who would have the

authority to see the program and request a change. This Project Plan overrides previous sign-

offs. If other stakeholders exist, this person(s) will be added to the Project Plan at that time.

Merck acknowledges that any requested changes after sign-offs by that stakeholder could

impact scope and schedule.



Managing Scope

Change of Scope

Changes of scope are a fairly common occurrence during the life of most projects, and as

such, we expect them to occur. Allen may learn of requirements that weren’t known by

the client at the time the contract, or the client may wish to add additional tasks or

content. Sometimes roles change on a project, or a new internal stakeholder may request

additions that were not expected, etc. These types of events happen regularly on projects,

and the ability to respond to new ideas or requirements is an important part of

developing the best possible solution. Some projects don’t permit much (or any)

flexibility, and must be managed to the original project plan, but most projects will

experience some change of scope.

When these changes occur on a project, we describe them in a Change of Scope

document, even if we’re not sure of the project impact. This way, if we are able to

determine an impact later, both sides can review the documentation and acknowledge

the exact moment something changed on the project.

Impact to Budget or Timeline

Sometimes the impact of adding a new requirement is negligible. Other times, something

simple like “just adding one button" to an interface requires unexpected hours of re-

development. Sometimes we can tell immediately if the project budget and timeline are

impacted, other times we're just not sure.

The goal of a change of scope document is to identify any proposed changes that could

impact timeline and budget, even if the impact is not known at the time the document is

signed.



Communications

Creating eLearning is a collaborative activity. The Merck team and the Allen team will

work together as partners in this project and will communicate regularly and in a

number of ways. Allen will keep the Merck Project Lead informed regarding project

activities and status through regular telephone and email communications.

Weekly

Communication

• Biweekly status reports will be sent to the Merck Project Manager.

• We will hold biweekly status calls with the Merck Project Manager and relevant

team members as determined upon project start.

Email Protocol

• Copy supervisors on all status reports and project updates (change request,

scheduling delay).

• Although email may be used to communicate decisions, as a general rule, “official”

decisions that could impact design, schedule or scope should not be made only via

email.

• Project management decisions should be captured in an updated Project Plan or

schedule.

Course

Comments &

Fixes

• Functional Prototype comments will be gathered in a Word document, organized

by priority. Script comments may be made within the Word document using track

changes. If the script is an Excel document we will discuss how comments should

be logged.

• Any requested change from the first fully developed version of the course (Alpha

build) forward should be logged in the commenting system (JIRA).

Technical

Issues

• Project lead (on either side) initiates email and copies technical leads from both

teams. After initial contact point technical leads communicate directly, copying

project leads.

Meeting

Planning

• Meeting planning initiated via email between project leads to determine

scheduling availability. Follow-up phone call(s) as necessary.

Best Practices • For priorities and situations which require immediate attention, Allen or Merck will

send an email that clearly explains the situation, and then call the project

coordinator to discuss. This will help both teams understand the situation and

retain documentation.

• Both Allen and Merck should communicate times out of the office and or vacation

throughout the life of the project.

• Allen and Merck should be looking two-weeks forward on the project. To hear

"remember, your scripts will arrive in two days" is too much of a surprise! Both

teams should discuss upcoming events within the next two weeks.

• The Merck team lead and Allen producer will work together to have regular phone

meetings to discuss the pace and development of the project. The goal is to find a

means that communicates efficiently while maximizing each other’s time.



Project Risks

No project is without risk, especially one of this size and importance. Identifying risks

and putting in place mechanisms for addressing or reducing them can reduce

headaches down the road. Below, we have outlined a number of potential risks and

initial strategies to mitigate them.

Description Impact Managing/Minimizing Impact

Project Timeline

Our ability to meet the proposed

project deadline for the training is

influenced by many factors

High � Allen will clearly communicate schedule status and turn-around

times to stay on schedule when providing deliverables.

� If Merck or Allen team falls behind the scheduled timeline, teams

will communicate and propose an adjustment to the timeline or

be willing to work extra hours to get back on schedule.

� SAMPLE specific language: We have already experienced a project

delay due to conflict over the direction and inclusiveness of the

prototypes. At present, both parties have agreed to extend the

timeline to allow for additional discussion, document development

and review. As a result, we may also propose discussion regarding

change of scope decisions.

� Both parties may need to continue to allow for consequent

changes to overall timeline and/or budget as a result of future

discussions and slight detours.

Access to and management of

Merck SMEs for Content

Development

Low � Allen will clearly communicate schedule status for content and

turn-around times to stay on schedule when providing content-

related deliverables.

� Merck project lead will inform Allen Project Manager when more

time is needed for content development review or review

sessions.

� If Merck or Allen team falls behind the scheduled timeline for

content development, teams will communicate as well as work

extra hours to get back on schedule.

First experience with Allen

As this is the Merck team’s first

eLearning project with Allen

Interactions, additional effort may

be needed to keep the focus on

proven instructional design

principles.

High

� Allen will spend additional time to explain any part of the

process and/or reasons for the process at client’s request.

� Should Merck provide comments or request changes that Allen

deems to be contrary to the principles of sound instructional

design, the team will discuss on a call or the Allen producer will

alert the Merck Project Lead and discuss alternative ways to

proceed.

� Subject matter experts find our output, the finished eLearning, a

little intimidating at first. They tend to worry that ‘their content

isn’t covered,’ because they often do not recognize that

behavioral change is the actual desired goal. We sometimes

provide a one-hour workshops on the value of learner-centric,

behavior driven eLearning versus content-centric information-

oriented training to proactively address this issue.



Product Quality

Quality

Assurance

Quality assurance, or QA, is defined simply as assuring quality in the final deliverables

that you receive for your end-users.

The QA resources on a project take on the role of user advocate, examining all areas of

the solution. The specific types of testing conducted on most projects are:

Integration Testing. This type of testing evaluates the interaction between combined

components in a learning solution. Typically, developers and/or QA team members

conduct this test iteratively during the coding of new or the addition of reusable

learning objects as they are integrated into a course.

Usability Testing. This type of testing evaluates the usability of a learning solution

and/or its components. Usability denotes a learning solution or component’s ease of

use, intuitiveness, performance, and user-friendliness.

Editorial Testing/Editing. This type of testing focuses on grammar, spelling, and other

editorial issues. The editing ideally takes place at a point in which the content is solid

and has client sign-off (at a Content-Complete stage).

Functional Testing. This type of testing evaluates the system’s adherence to the

intended design, functionality, usability, external links, and overall performance on a

complete, integrated eLearning solution.

Acceptance Testing. This type of testing enables you, the client, to review and evaluate

a final, QA-approved eLearning solution prior to its deployment to your learners. The

purpose of acceptance testing is to verify that any changes that were agreed to at the

end of the Beta Review were implemented.

Scope of QA

To most effectively address the widest range of testing coverage, the following table

illustrates the relationships among the different types of QA testing (which are defined

above), participants in these testing types, and the development phase in which these

testing types take place:

Type of QA Testing Responsibility Development Phase

Integration Testing Allen Alpha

Usability Testing Allen Alpha

Editorial Testing / Editing Allen Alpha

Functional Testing Allen Alpha

Acceptance Merck Acceptance Review

Allen Interactions is responsible for the quality assurance of the program. Merck will

provide feedback on the quality of the various elements of the program.



Internal Testing Process:

• Allen will manage an internal team of QA testers, one with editorial expertise.

• Allen will test on IE version 8 and up.

• For subsequent releases, e.g. Beta, it is always a good idea for Merck reviewers

to clear their browser cache to ensure they are viewing the latest version of the

program.



Projected Milestones & Deliverables

Allen Interactions will work closely with Merck to manage the project development schedule,

continually identifying and verifying key dates for the milestone deliverables.

Subject Matter Expert availability will play a key role in scheduling. Below, please find a list of

the interim and final deliverables for the project, brief descriptions of each task, and an

estimated timeline.

• Both teams have determined that unless otherwise stated, all deliverables are

considered to be end of day (EOD). The reviewers (Allen or Merck) will be able to

review the deliverable by the start of the next business day.

• When Allen delivers a milestone with an associated invoice, Merck will review the

deliverable, communicate any in-scope changes needed, and once changes are

approved, Merck will provide email sign-off that the invoice can be sent to the project

lead.



Addendum: Process & Standards

Overview We defined three key phases in our design and development process: Preparation, Design, and

Development. Each phase includes close collaboration with our client to determine that the

objectives of the project are met.

Preparation

Phase

The Preparation Phase is the information-gathering period before the start of the actual design.

It allows both the client and Allen Interactions to actively explore the business problem in

broad terms and prepare for the intensive design activities to follow in the Savvy Start.

Gather history, including:

• prior performance efforts

• programs, resources, and content currently in use

• organizational responsibilities for training

• known constraints, such as schedule, budget, and legal requirements

• user interviews with sample end-users to better understand their work and help identify

the current challenges and motivations

Design Phase Once the information gathering is complete and Allen and Merck have identified the business

needs and key players, the Design phase begins.

Project Planning

During the Project Planning phase, Allen and Merck conduct a strategic assessment of

remaining project development details impacting timeline and/or budget. It involves careful

consideration not only of the management of cost and quality, but of the communication, risk,

schedule, scope, and staffing related to each client project.

Prototypes

The Allen team usually builds two rounds of rough prototypes, usually in PPT or another similar

software. They are revised to

• Convey expected functionality of final interaction

• Round 1 and 2 Prototypes are functional enough to “play-through” but content and all

media/graphics are still placeholder. The code used in these prototypes is “smoke and

mirror” – not final code.

Media Prototypes

After Prototype sign-off, media elements are prototyped to establish “look-and-feel.” The

prototypes are presented as static images (i.e. jpg).

• Depending on the client’s reaction, we may have 1 or 2 rounds of static comps for client

review and provide feedback

NOTE: It is critical to have the technical specifications regarding screen resolution and minimum

color standards established before delivering this first media prototype.



Development

Phase

Alpha

The Alpha is a complete version of the instructional application set to be validated against the

approved design, in this case, as laid out in the course outline. The Alpha version implements

the majority of the content and media.

In-scope changes to Alpha include content editing, functional bugs, and minor instructional

design changes. Requests for design changes must be reviewed to assess impact on schedule

and budget. Additionally, the Alpha is ready for additional testing, possibly with a few folks

beyond the project team, including “play-through” of the program.

• Alpha version of course is ready for review and testing via the Studio K webpage for the

course

• JIRA (see Appendix A) is used to document and process issues and gather feedback from

the client and other users

Beta

The Beta phase of the Validation Cycle is a modified version of the Alpha that reflects changes

identified during evaluation review. The Beta is often implemented on the final platform for

dissemination.

The Beta review should produce few errors, and those should include only minor typographical

errors, word changes, or functional glitches. Implementation errors are not: content accuracy,

media look and feel, navigation structure, or instructional design. Allen Interactions will make

changes for implementation errors identified and agreed upon during Alpha and Beta reviews.

• Revisions indicated and agreed upon during Alpha review are completed

• Beta posted on Merck myLearning LMS or final destination for course for review

• Beta communicates with myLearning LMS according to AICC requirements

• JIRA is used to document and process issues and to gather feedback from the client and

other users

Gold

The Gold Master is the final phase of development. At this phase the course is free of functional

glitches or errors of any kind and is fully functional within the parameters of established project

guidelines. Additionally, documentation such as the Golden Sign-off, Project Archive, and

Lessons Learned Report are provided at this time.



Appendix A: JIRA

Automatic Collection and Management of Reviewer Comments

via Internet Software Eases Quality Assurance and Teaming

Allen Interactions uses a productivity tool that facilitates communication between the client

team and the development team as part of their Quality Assurance (QA) process.

JIRA is a small application that resides within a larger eLearning application and can be

activated by a mouse click. As the client or the Allen Interactions QA team reviews prototypes,

alphas, or betas of the eLearning application, JIRA collects typed comments from the reviewer

and stores a ratings of the severity of the issue and information about where the reviewer was

in the eLearning application. The development team can easily associate comments with

specific content or functionality so that a correction or adjustment can be made.

FIGURE 1. While reviewing an eLearning application, a reviewer launches a JIRA

window to enter a comment, bug report, or feature request. JIRA

automatically fills in the Location field to identify the comment with

the appropriate location in the eLearning application.



The reviewer types in his/her name in the Reviewer field (the above window scrolls to relieve

reviewer field), and enters the comment.

JIRA writes collected information to a local text file and, when an Internet connection is

available, sends the information to the project database.

Once a reviewer has entered a comment via JIRA, the project manager at Allen Interactions can

select any specific comment in order to assign it to a team member for resolution, enter notes

to guide the development team, or provide feedback or rationale to the client reviewer.

Members of the client team also have access to the comments database and can track the

progress of their comments and receive feedback from the project manager. Reviewers can see

that their requested changes have been made and tested, or learn why they haven’t been

implemented (e.g., request is out of scope, deferred until later, or developers need more

information).

FIGURE 2. The project manager or client can see a list of project issues and

comments at any time, using the JIRA web interface, and that requested

changes have been made and verified – or why they haven’t been.


PROPRIETARY NOTICE

The information contained in this document is the property of Allen Interactions Inc. and may not be communicated to third parties without the express

written permission of Allen Interactions Inc. The purpose of this document is to serve as an indication of how Allen Interactions Inc. would approach this project. The only instrument that

will bind either party as to scope, schedule, and fee would be a mutually executed services agreement, statement of work, or similar contractual agreement.