reference manual for course 211

Reference Manual for Course 211

Business Analysis Introduction: Defining Successful Projects

211/RM/F.2/407/F.1

by Genny Kelly

Technical Editor: Steve Johann

© LEARNING TREE INTERNATIONAL, INC.All rights reserved.

All trademarked product and company names are the property of their respective trademark holders.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, or translated into any language, without the prior written permission of the publisher.

Copying software used in this course is prohibited without the express permission of Learning Tree International, Inc. Making unauthorized

copies of such software violates federal copyright law, which includes both civil and criminal penalties.

211-RM-i © All rights reserved. Not to be reproduced without prior written consent.

Reference Manual Contents

Project Life Cycle Definitions ............................................................................................... 1

Requirements ...................................................................................................................... 3

Affinity Diagrams ................................................................................................................. 5

Fishbone Diagrams ........................................................................................................... 11

Feasibility Analysis Examples ........................................................................................... 15

The Basics of Process Mapping ........................................................................................ 29

Figure 13: Muffler Replacement Process—Cross-Functional Process Map ...................... 39

Interpreting Cross-Functional Process Maps ..................................................................... 41

Figure 14: Muffler Replacement Process—Cross-Functional Process .............................. 43

Interpreting the Map of the Muffler Replacement Process................................................. 45

Business Case Analysis Support ....................................................................................... 47

Sample Ground Rules ....................................................................................................... 53

Project Assumptions .......................................................................................................... 57

Project Constraints Template ............................................................................................ 63

Sample Action Item Template ........................................................................................... 65

Requirements Gathering Templates .................................................................................. 67

Sample Project Schedule .................................................................................................. 87

Requirements Document Support ..................................................................................... 95

Excerpt From a Poor Requirements Document ............................................................... 101

Excerpt From a Better Requirements Document ............................................................. 105

Requirements Traceability Matrix .................................................................................... 107

211-RM-1 © All rights reserved. Not to be reproduced without prior written consent.

Project Life Cycle Definitions

Project methodology and Software Development Life Cycle (SDLC) are often confused as the same thing

• Project methodology is managing projects within a clearly defined

set of processes; this is about managing the work — Examples: PMI, PRINCE2, homegrown

• SDLC is the structure imposed on development of software; these

processes represent the work of creating the software system — Examples: RAD, Agile, iterative, EUP, waterfall

• Cycle is a series of events that take place during a period of time

EUP = Enterprise Unified Process RAD = rapid application development


Requirements

Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis. Stakeholder Requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements. They are developed and defined through requirements analysis Solution Requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirements analysis. They are frequently divided into sub-categories, particularly when the requirements describe a software solution:

Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses. Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.

Transition Requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation. A Guide to the Business Analysis Body of Knowledge. Release 2.0. International Institute of Business Analysis, 2009. pp. 5–6.

© All rights reserved. Not to be reproduced without prior written consent.

211-RM-5

Affinity Diagrams

Example 1: Affinity diagramming session sample output Content would flow more effectively in my organization if… This example shows output from an affinity diagramming session conducted to address content management problems throughout the enterprise. Information has been altered to promote client anonymity.

More meetings were held between departments

We had better communications with other departments

We had more department meetings

We had more information/ communications from entities

Communication (internal)

Multiple QCs of one program (were not multiple QCs)

Multiple versions/ volume

We had more input on how we schedule the work because of the lack of equipment

More people did the work

More specific metrics were available

We had the necessary resources in certain areas

Equipment and resources

Communication (internal)

Policy adherence

Organizational culture

Internal departments communicated better when planning projects

We received program tapes in timely manner

We had respect for one another

We understood everyone’s functions and jobs

We had more cooperation from entities

We understood everyone’s function/job

We had more input on how we schedule the work because of the lack of equipment

Program entities shared more info about plans

Deadlines were enforced

Management communicated and shared information among each other

Deadlines were enforced

Problems were addressed in a timely manner


Affinity Diagrams (continued) Example 1: Affinity diagramming session sample output (continued) Content would flow more effectively in my organization if…

This example shows output from an affinity diagramming session conducted to address content management problems throughout the enterprise. Information has been altered to promote client anonymity.

Information access and quality

Infrastructure flexibility External partnering and communications

System compatibility

We had more information: communications from entities

We had user-friendly software (user steps to get info)

There was less last-minute work

We reduced the amount of redundant data entry

We had more cooperation from entities

Outside clients were more timely with sending tapes info

More specific metrics were available (tape format, commercial unit) to identify resources (tape machines, encoders), needs, and business plans

Program entities shared more info about plans

There were more presets in our router (dedicated routing path)

There was better communication between staff and the networks

There were better utilization of repurpose of FM Data: QC p/w, labeling, commercial billing

There were fewer information gaps

Profile were two-way through XXX or XXX (flexibility—multiple ingest resources)

Program entities shared more information about their plans

QC reports could be created in a database format


211-RM-7

Affinity Diagrams

(continued)

Example 1: Affinity diagramming—voting results This example shows output from an affinity diagramming session conducted to address content management problems throughout the enterprise. Information has been altered to promote client anonymity.

3Policy adherence

2Organizational culture

4Internal communications issues

5Equipment and resources

6Information access and quality

1Multiple versions/volume

7Infrastructure flexibility

8External partnering and communication

9System compatibility

Issue category VotesContent would flow effectively in my organization if…


Affinity Diagrams (continued) Example 2: Affinity diagramming session sample output I could be more effective and efficient in my job if…


Better communication/ education

Resource constraints Competing interests Centralized repository of information

I had better access to information, once confirmed; changes were brought to my attention more immediately

I could provide faster access to information in the archives

Decisions could be made on sound business principles rather than based on emotion, whim, or tradition

I could receive early notification of season programs/artists

I could receive early notification of institutional special projects

I had more space Politics didn’t make the job more difficult than necessary

We could solve the problem of interdepartmental communication of important issues/process

We could solve the problem of interdepartmental communication of important issues/process

I had more computer workstations

I could receive early notification of season programs/artists

Data/systems were open for seamless integration

I could receive early notification

I had more staff Various internal constituencies with competing interests were not pulling in

I had access to information notification

Communication between management and staff were more effective

There were more funds to carry out projects to catalog and preserve archival assets

Parochial concerns were not overriding institutional needs

I had easier access to historic information to better inform what we do in the future


211-RM-9

Affinity Diagrams

(continued)

Example 2: Affinity diagramming session sample output (continued) I could be more effective and efficient in my job if...


I did not have toworry about the deterioration of audio and audiovisualmaterials in thearchives

Preservation

I could use video clips as part of lesson plans that could be used for distribution on Internet

I could create a “virtual” lecture series for repeated use

I could broadcast our in class workshops, lectures on the internet, or create a video lending library

BRM limitations

We were not facing an increasingly complex societywith many moreentertainment choices

Market shift Inconsistent process /workflow

Reactive culture

Institutional leadership

Management developed a concise plan that we could

All audiotapes and videotapes were correctly identified (i.e., labels didn’tfall off)

We could address the fact that many in the organization are resistant to the organizational challenge

I could do more from my desktop rather than waiting for other people or departments

I could receive a prioritized institutional budget

All the photographs in the archive were identified

There were fewer emergencies to deal with

I didn’t have to come up with more ideas on how to make money for the organization

I did not have toworry about the deterioration of audio and audiovisualmaterials in thearchives

Preservation

I could use video clips as part of lesson plans that could be used for distribution on Internet

I could create a “virtual” lecture series for repeated use

I could broadcast our in class workshops, lectures on the internet, or create a video lending library

BRM

We were not facing an increasingly complex societywith many moreentertainment choices

Reactive Institutional

Management developed a concise plan that we could work toward

videotapes were correctly identified

fall off)

We could address the fact that many in the organization are resistant to the organizational challenge

I could do more from my desktop rather than waiting for other people or departments

I could receive a prioritized institutional budget

All the photographs in the archive were identified

There were fewer emergencies to deal with

I didn’t have to come up with more ideas on how to make money for the organization


Affinity Diagrams (continued) Example 2: Affinity Diagramming—voting results I could be more effective and efficient in my job if…


0We were not facing a market shift

4We had better institutional leadership

1We did not have a reactive culture

2We did not have BRM limitations

0We did not have to worry about preservation issues

11We had a centralized repository of information

5We did not have competing interests

2 We did not have resource constraints

5We had better inter-departmental communication

0We did not have inconsistent processes and workflow

Number of votes

Issue


211-RM-11

Fishbone Diagrams

Cause and effect/fishbone: Late pizza deliveries

Used with permission of GOAL/QPC, 12B Manor Parkway, Salem, NH 03079, www.goalqpc.com

Late pizza deliveries on Fridays and Saturdays

Machinery/Equipment People

Methods Materials

Unreliable cars

Kids own junkers

Get wrong information

People don’t show up

Poor handling of large orders

High turnover

Lack of experience

Many new streets

Don’t know town

High turnover

Run out of ingredients

Low payNo money for repairsNo capacity for

peak periods

Ovens too small

High turnoverPoor use of space

Poor training

Low pay

High turnover

No trainingNo teamwork

Drivers get lost

Poor trainingRushed

Don’t know townHigh turnover

Poor dispatching


Lack of training

Inaccurate ordering

Late pizza deliveries on Fridays and Saturdays

Machinery/Equipment People

Methods Materials

Unreliable cars

Kids own junkers

Get wrong information

People don’t show up

Poor handling of large orders

High turnover

Lack of experience

Many new streets

Don’t know town

High turnover

Run out of ingredients

Low payNo money for repairsNo capacity for

peak periods

Ovens too small


Poor training

Low pay

High turnover

No trainingNo teamwork

Drivers get lost

Poor trainingRushed

Don’t know townHigh turnover

Poor dispatching


Lack of training

Inaccurate ordering


Fishbone Diagrams (continued) Cause and effect/fishbone: Bed assignment delay

Information provided courtesy of Rush-Presbyterian-St. Luke’s Medical Center. Used with permission of GOAL/QPC, 12B Manor Parkway, Salem, NH 03079, www.goalqpc.com

Resources Timing Machine (PCIS)

MD procedures Hospital procedures Communication

Nursing shortage

Unit clerk staffing

Unit clerk training

Patient arrives too early

Transfer too early from another hospital

Call housekeeping when clean

Wait for MD Discharged patient did not leave

Wait for rideWait for lunch

Wait for resultsCall housekeeping too late

Call housekeeping too early

Think it will take more time Patient waits

for bed

System incorrectNot entered

Not used

No trustNeed more training

Not usedpending discharge

Physician did not write order

Medicine admit quota

Physician misuse—inpatient

Double roomsMany

transfers

Specialty bedsCardiac monitors

Delayedentry

Too busySandbag

Inappropriate ER admittance

Admitting unaware bed is clean

Unit switch bedReservation unaware

Not enteredUnit clerk unaware of discharge or transfer

On breakNot told

Shift change

Functions not useful

Resources Timing Machine (PCIS)

MD procedures Hospital procedures Communication

Nursing shortage

Unit clerk staffing

Unit clerk training

Patient arrives too early

Transfer too early from another hospital

Call housekeeping when clean

Wait for MD Discharged patient did not leave

Wait for rideWait for lunch

Wait for resultsCall housekeeping too late

Call housekeeping too early

Think it will take more time Patient waits

for bed

System incorrectNot entered

Not used

No trustNeed more training

Not usedpending discharge

Physician did not write order

Medicine admit quota

Physician misuse—inpatient

Double roomsMany

transfers

Specialty bedsCardiac monitors

Delayedentry

Too busySandbag

Inappropriate ER admittance

Admitting unaware bed is clean

Unit switch bedReservation unaware

Not enteredUnit clerk unaware of discharge or transfer

On breakNot told

Shift change

Functions not useful


211-RM-13

Fishbone Diagrams

(continued)

Cause and effect/fishbone: Causes for bent pins (plug-in side)

Used with permission of GOAL/QPC, 12B Manor Parkway, Salem, NH 03079, www.goalqpc.com

Bent pins plug-in side

People Methods Handling

Design Tools

004 prep VA

No Fixture

Shows pins on bench

CarelessnessAttitude

Lack of attentionOn-the-job training

Mylar tapeScribe slips

Placement on edges Assembly

difficultyComplex design

Large part #Retainer insertion

No/Don’t Like Fixtures Placement—

pins on bench

Storage

General handlingRepairTest

Backplane mounting

Heavy/Awkward

In/Out of Boxes

Mount to frameGauging

StorageDamaged connector

Improper insertion

Not designed for manufacturing

2 backplanes

Large part #

Assembly difficulty

Casting ties/pliers

Designer not on site

Bad panel alignment—bare

Designer can’t react to problems

Lack of fixtures

No Stiffener Plates

Not Enough Universal

Using wrong toolsBits

Not enoughImproper sizes

New tools—long lead timeGauges

Screws come looseDamaged connectorsTest fixturesStorage

Damaged connectors

Bent pins plug-in side

People Methods Handling

Design Tools

004 prep VA

No Fixture

Shows pins on bench

CarelessnessAttitude

Lack of attentionOn-the-job training

Mylar tapeScribe slips

Placement on edges Assembly

difficultyComplex design

Large part #Retainer insertion

No/Don’t Like Fixtures Placement—

pins on bench

Storage

General handlingRepairTest

Backplane mounting

Heavy/Awkward

In/Out of Boxes

Mount to frameGauging

StorageDamaged connector

Improper insertion

Not designed for manufacturing

2 backplanes

Large part #

Assembly difficulty

Casting ties/pliers

Designer not on site

Bad panel alignment—bare

Designer can’t react to problems

Lack of fixtures

No Stiffener Plates

Not Enough Universal

Using wrong toolsBits

Not enoughImproper sizes

New tools—long lead timeGauges

Screws come looseDamaged connectorsTest fixturesStorage

Damaged connectors


211-RM-15

Feasibility Analysis Examples

Example 1: 2 x 2 analysis sample output

This example represents analysis conducted to help a non-profit organization (in the arts) prioritize potential archive related Initiatives. Information has been altered to promote client anonymity.

Ease Of Implementation

0%

20%

40%

60%

80%

100%

0% 20% 40% 60% 80% 100%

Busin

ess V

alue

Adopt a Film Program

Centralize corporate knowledge

Provide personalized ring tones

Sponsor conference

Educational Tools

Kiosks / exhibits

Consolidateinformation

DVD / CD Rom

On Demand Audio Files

Rights Management System

On Demand Stock Photography

MUST DOSMUST DOS

HIGH POTENTIALSHIGH POTENTIALS

MINIMAL EFFORTSMINIMAL EFFORTS OPPORTUNISTIC EFFORTSOPPORTUNISTIC EFFORTS

Auction sponsorship on EbayAdvertise “Save Digital

Archive” on websites

Low

High

Low HighEase Of Implementation

0%

20%

40%

60%

80%

100%

0% 20% 40% 60% 80% 100%

Busin

ess V

alue

Adopt a Film Program

Centralize corporate knowledge

Provide personalized ring tones

Sponsor conference

Educational Tools

Kiosks / exhibits

Consolidateinformation

DVD / CD Rom

On Demand Audio Files

Rights Management System

On Demand Stock Photography

MUST DOSMUST DOS

HIGH POTENTIALSHIGH POTENTIALS

MINIMAL EFFORTSMINIMAL EFFORTS OPPORTUNISTIC EFFORTSOPPORTUNISTIC EFFORTS

Auction sponsorship on EbayAdvertise “Save Digital

Archive” on websites

Low

High

Low High


Feasibility Analysis Examples (continued) Example 1: 2 x 2 analysis sample supporting data

620008Consolidate information in a centralized location251026Auction sponsorships on eBay and private auctions341143Advertise “Save Digital Archive” on Web sites

800044Leverage archive to do pay-per-view events800080Provide on-demand stock photography350008Produce tools that teachers can access on Web026035Develop an adopt-a-film program620233Streamline rights management process800017Create on-demand downloadable audio files026053Centralize corporate information for access 503251Partner with cell-phone companies to provide personalized rings

350017Set up multimedia kiosks and exhibits using archive 143044Sponsor conference about benefits of archiving

LowMedHighLowMedHigh

Ease of execution

Business impactFundraising idea

Fundraising idea rankings

620008251026341143Advertise “Save Digital Archive”

800044800080350008026035620233Streamline rights management process800017026053Centralize corporate information for access 503251350017Set up multimedia kiosks and exhibits using archive 143044Sponsor conference about benefits of archiving

LowMedHighLowMedHigh

Business


211-RM-17


(continued)


This example represents the framework used to help a communications company prioritize potential business initiatives. Each initiative represented a new potential service the client could offer on their network. The consultant recommended all initiatives above the Cut Off Line. Information has been altered to promote client anonymity.

1

1.5

3.5

4.5

1 1.5 2 2.5 3 3.5 4 4.5 5

HIGH POTENTIALSQUICK WINS

Implementation Risk

Bus

ines

s Va

lue

Cut Off Line

1

23

4

5

6

7

8

9

10

1112

Redefine Avoid

Business Value/Implementation Risk Matrix

1

1.5

3.5

4.5

1 1.5 2 2.5 3 3.5 4 4.5 5

HIGH POTENTIALSQUICK WINS

Implementation Risk

Bus

ines

s Va

lue

Cut Off Line

1

23

4

5

6

7

8

9

10

1112

Redefine Avoid

Business Value/Implementation Risk Matrix


Feasibility Analysis Examples (continued) Example 2: 2 x 2 analysis sample criteria decomposition

In this case the team decomposed each of the two criteria elements (business value and risks) to better define each criteria element and conduct more complex analysis. Information has been altered to promote client anonymity.

Business values Revenue (advertising and commerce): Does this initiative make a positive contribution to client‘s revenue stream over the next few years? Address customer wants and needs: Does this initiative contain capabilities that address the wants and needs of the client customer set? Market reach and share: Does this initiative increase the mindshare and market share in the client competitive space? Builds brand equity: Does this opportunity strengthen the view of the client as an industry leader and contribute to consumers’ positive perceptions about client? Vertical collaboration/cost reduction: Does this opportunity increase efficiencies across the client’s departments and contribute to lowered operating costs?

Risks High cost: Is the cost of implementing this opportunity unjustifiable? Time risks: Does time that it will take to implement this initiative outweigh the benefits of implementation? Technology risks: Is the technology involved in this opportunity complex and requiring significant integration into existing systems? Organizational impacts: Is this initiative too complicated to implement from an organizational standpoint (e.g., verticals, suppliers, third-party vendors, etc.)?


211-RM-19


(continued)


This example represents analysis conducted to help a communications company prioritize potential rich media service Initiatives. Information has been altered to promote client anonymity.

Phase 1• Media Hub (Distribution/Streaming)

• eLearning

Phase 2• Enhanced Media Hub• Enhanced eLearning

• Digital Library

Busin

ess V

alue

Busin

ess V

alue

Media Hub(Distribution/Streaming)

eLearning Digital Library

On Demand Video, Audio, Games

WebCasting Unified MessagingEnterprise Business Applications

Pay Per View Services

Very Active Investment Invest Opportunistically

Unlikely or No InvestmentPotential Investments

Phase 1Phase 2

Business RiskBusiness Risk

Phase 1• Media Hub (Distribution/Streaming)

• eLearning

Phase 2• Enhanced Media Hub• Enhanced eLearning

• Digital Library

Busin

ess V

alue

Busin

ess V

alue

Media Hub(Distribution/Streaming)

eLearning Digital Library

On Demand Video, Audio, Games

WebCasting Unified MessagingEnterprise Business Applications

Pay Per View Services



Phase 1Phase 2

Business RiskBusiness Risk


Feasibility Analysis Examples (continued) Example 3: 2 x 2 analysis sample criteria decomposition

In this case the team decomposed each of the two criteria elements (business value and risk) to better define each criteria element and conduct more complex analysis. Information has been altered to promote client anonymity.

Business ValueShort Term Revenue / Profit• Revenue contribution 6 months from launch of service

• Revenue either as a new source or by driving an xSP’sexisting service revenues

• An addressable market for this service exists within this time frame

Long Term Revenue / Profit• This service has a large attainable market with aggressive

growth rates

• xSP can sustain a competitive advantage for this service

• Service allows for cross selling, up-selling and/or bundling opportunities with other services

• Service has an attractive Return on Investment

Market Share and Reach• Service helps to increase or defend market share in

existing space (transport, hosting, other current services)

• xSP can achieve substantial market share in key Rich Media markets as a result of offering this service

Enhanced Brand Equity• Strengthens the view of the client as an industry leader in

the Rich Media Services arena

• Launch of the service may be strategic in order to help build brand recognition in key Rich Media market





growth rates










Business RiskHigh Cost• Fixed cost of implementing this service is high

• Return on Investment for deploying this service is not obvious

Long Time to Market• Time to develop and deploy this service may exceed

potential market window

• Competitors may beat xSP to market with this service, thus making it difficult to acquire substantial market share

Risky Technology• Technology involved is complex or requiring significant

integration into existing systems

• Technologies are emerging and not proven, especially in an xSP environment

Difficult Execution• xSP may have a hard time executing on this plan due to

organizational structure, sales model or existing capabilities within the organization

• This service is inconsistent with the xSP’s core competency or strategy

• This service may cannibalize other existing offerings

















growth rates














growth rates



































211-RM-21


(continued)

Example 3: 2 x 2 analysis sample criteria decomposition This supporting data helped the team reach overall ratings for business value and business risk. Since the team opted to weight the different criteria elements, they actually used two feasibility analysis tools (prioritization matrices and 2 x 2 analysis). Information has been altered to promote client anonymity.

Business risk

Business value

38% Difficult execution

8%Risky technology

31% Long time to market

23%High cost

25%Enhanced brand equity

17% Market share and reach

33% Long-term revenue/profit*

25% Short-term revenue/profit* (<6 months)

Client percentage weighting Business value/risk component


Feasibility Analysis Examples (continued) Prioritization matrix example

This example is from a project executed with a car manufacturer trying to make decisions about which services to install in upcoming car models. In this case the team conducted prioritization matrix analysis then plotted those results onto a 2 x 2 matrix (using 2 higher level categories). Information has been amended to promote client anonymity. This is an interactive tool and can be manipulated as needed.

Customer Value Satisfy Customer Needs / Wants

Cost Effective Easy to Buy Easily Understood

Total

Difficulty to ExecuteDifficult to Produce High Price

Doesn't Influence Vehicle

Purchase

Difficult to Communicate

Value of Service Total

Client Value Rankings Client Risk Rankings

Ordinal Rating 3 4 2 3 12 Ordinal Rating 3 4 1 5 13

Percentage Weighting 25% 33% 17% 25% 100% Percentage Weighting 23% 31% 8% 38% 100%

Service Weightings Service Weightings

Service #1 4 8 8 6 65% Service #1 7 5 7 8 68%

Service #2 7 8 8 8 78% Service #2 5 4 4 4 42%

Service #3 6 9 7 7 74% Service #3 4 3 4 3 33%

Service #4 6 3 4 3 39% Service #4 4 9 3 4 55%

Service #5 3 4 5 6 44% Service #5 5 3 5 3 36%

Service #6 3 5 3 4 39% Service #6 8 5 5 7 65%

Service #7 5 8 4 8 66% Service #7 4 4 4 3 36%

Service #8 4 5 3 2 37% Service #8 8 5 8 6 63%

Service #9 6 3 3 3 38% Service #9 4 7 3 2 41%

Max value 10

0%

20%

40%

60%

80%

100%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

CustomerValue

Difficulty to Execute




211-RM-23


(continued)

Value proposition analysis

Value Propostion Pers

onal

izat

ion

Conv

enie

nce

Qua

lity

Pric

e/Va

lue

Trus

ted

Sour

ce

(Exp

ert o

pini

on)

Prod

uct V

arie

ty

Prod

uct

Avai

labi

lity

Prod

uct

Cust

omiz

atio

n

Mul

tiple

Acc

ess

Poin

ts

Relia

bilit

y

Info

rmat

ion

Acce

ss

Secu

rity

Easy

Ret

urn

Proc

ess

Ease

of u

se

End

to E

nd

Serv

icin

g

Enri

chin

g Ex

perie

nces

Assu

ranc

e

Delig

ht /

Pro

duct

Sa

tisfa

ctio

n

One Stop Shop X X X X X X XOne Click Purchasing X X XGift Search X X X X X XGift Wrap X X X X X X X XGift and Wish List Services (Reminder) X X X X X X X XRetail Partnerships / Affiliations X X X X X XReliable Fulfillment X X X X X X XEasy Returns X X X X X X X XConsultative Advice X X XSite Search X X X X X X X XProduct Comparisons X X X X X X XThird Party Opinion X X X XSame Day Shipping (in Stock Items) X X X XExpected Delivery Dates X X XOffer multiple shipping options X X X X X XHelp Wizard (Tip of the Day) X X X X X X XOrder Confirmation X X X XCustomer Friendly Shipping Policies X X X X X X X X24/7 Customer Service X X X XReal Time Credit Authorization X X X X X XOnline Order Status X X X X X XReal-time order tracking X X X X X X XReal-time, on-line, Customer Service X X X X XStandardized Purchase Terms and Conditions (e.g. money back guarantee) X X X X XInter-vertical cross promotion X X X X X X X XUniveral shopping cart X X X XSSL/SET Secure Payment X XProactive Customer Solicitation (Use data mining technology) X X X X XReal time Recommendations X X XReal time site customization x x x x x x x

Customer Wants and Needs


Feasibility Analysis Examples (continued) BV-BR interactive tool

This is an interactive prioritization matrix template that automatically populates the associated 2 x 2 matrix.

Max value 10Business Value Business Risk

Attribute 1 Attribute 2 Attribute 3 Attribute4 total Attribute 1 Attribute 2 Attribute 3 Attribute4 totalaccelerators 1 3 0.7 2 6.7 accelerators 1 0.8 0.7 1.5 4Weight 15% 45% 10% 30% 100% Weight 25% 20% 18% 38% 100%

Initiative1 10 4 8 4 53% Initiative1 2 4 7 4 40%Initiative2 10 10 10 10 100% Initiative2 6 9 10 10 88%Initiative3 8 10 6 5 78% Initiative3 1 2 4 7 40%Initiative4 3 3 1 3 28% Initiative4 3 4 6 2 34%

0%

20%

40%

60%

80%

100%

0% 20% 40% 60% 80% 100%

BusinessValue Components

BusinessRisk Components

HI

HILo

Must Dos High Potentialsmitigate risk

AvoidUtilityDo as needed


211-RM-25


(continued)

Vendor analysis example

This example represents a high-level functional comparison of various vendors’ document management products. Information has been altered to promote anonymity.

Candidate for Interim Solution*

Candidate for To-Be Solution*

Capture

Schem

a Modeli

ng

Index

& Loggin

g

Manag

eSea

rchRetr

ieve

Collaborat

e/Workf

low

RT/non-R

T

NLE Integ

ration

Fulfill

Commerce/

CRS Tools

GUIInsta

llatio

nAdmin &

Rep

orting

Reliab

ility

Scalab

ility

Customiza

tion

Vendor A

RatingsStrong Medium Weak or N/A

Rights Mgmt &

Avail.

Vendor B

Vendor C

Vendor D

Vendor E

Candidate for Interim Solution*

Candidate for To-Be Solution*

Capture

Schem

a Modeli

ng

Index

& Loggin

g

Manag

eSea

rchRetr

ieve

Collaborat

e/Workf

low

RT/non-R

T

NLE Integ

ration

Fulfill

Commerce/

CRS Tools

GUIInsta

llatio

nAdmin &

Rep

orting

Reliab

ility

Scalab

ility

Customiza

tion

Vendor A

RatingsStrong Medium Weak or N/A

Rights Mgmt &

Avail.

Vendor B

Vendor C

Vendor D

Vendor E


Feasibility Analysis Examples (continued)

Paired comparison

• Each option is compared against every other option to identify the best alternative

• Best used when you have fewer than six options • Particularly effective when testing subjective preferences (e.g.,

preferred color, taste, visual appeal) • Not recommended as the only evaluation technique; better used as a tie

breaker after other techniques have been used • Steps for paired comparison: • Identify potential options (label them A, B, C, D, etc.) • Create matrix • Compare each option against every other option • Indicate the preferred option by placing the appropriate letter • Indicate the strength of preference by placing the appropriate number

(1, 2, or 3) • Tally totals for each option • Select the highest total as the preferred choice

When to use

• Every option is assumed to be “high priority” — Forces choices among options

• Testing more subjective preferences (criteria is hard to define) • Team has already evaluated options against criteria and reached an

impasse on final selection



(continued) Paired comparison sample Example: Which dessert should we serve at the team celebration?

• Sample individual assessment: “Jill”

A B C D

Chocolate cake (A) A3 A2 D1

Apple pie (B) B1 D2

Pound cake (C) D2

Ice cream (D)

Scale: 1 = slightly more 2 = moderately more 3 = significantly more *In the event of a tie, review the cell indicating the choice between the two options in question; e.g., A vs. D review yields D as selected option.

A = 5 B = 1 C = 0 D = 5*


The Basics of Process Mapping


The Basics of Process Mapping (continued)

Relationship map Cross-functional process map Flowchart

Purpose Shows supplier-customer relationships (which functions or parts of the organization receive inputs from and provide outputs to one another)

Shows functions, steps, sequence of steps, inputs, and outputs for a particular work process

Shows tasks, sequence of tasks, inputs, and outputs for a particular work process

Level of detail Least Medium Most Focus Organization

“context” Process/people interface

Process detail

Key points • Does not show processes within or between functions; treats these as a “black box”

• Relates pieces of the organization to one another

• Shows supplier-customer linkages throughout the organization

• Answers the question, “What does the organization provide to its internal and external customer?”

• Shows processes and related steps, inputs, and outputs as well as who performs each step

• Reveals what is in the “black box”

• Shows supplier-customer linkages for a single process

• Answers the questions, “What steps does the organization perform to provide outputs to its internal and external customers? And who performs each step?”

• Shows detailed tasks that make up a process

• Does not show supplier-customer linkages

• Answers the question, “How does the work actually get accomplished?”



(continued)

Tips for creating process maps • Use the group interview method and a skilled mapping facilitator

whenever possible (see “Collecting the Information Needed to Create a Process Map” [The Basics of Process Mapping, Robert Damelio] for more information).

• Select the right people to create the map. Generally speaking, the right people are those who are: — Knowledgeable of the process — Interested in improving the process — Available and will stay in the room for the duration

• Establish ground rules at the start and post them on a flipchart: — Map creation method and conventions — No comings and goings — Think rough draft; as author Robert Mager says, “First

get it down; then get it good!” — Encourage communication — Discourage finger-pointing (no-fault rule applies) — Go for quantity of information (breadth versus depth) — Keep a bin list (a list of outstanding or unresolved

issues) • Use a room large enough that people can easily move around. • Have plenty of paper to write on. • Use Post-it Notes to generate initial steps, then categorize information

by steps, output, input, measure, function, and so on. • Sequence and rearrange based on the Post-it Notes. • Consider using a laptop or other computer to record information as you

work, especially if you can project the display on a large screen. • Do not let a particular technology or software package hinder your

group process or progress. • Keep the energy flowing (you know you are successful when people

start spontaneously adding or changing items on the map themselves). • The facilitator should act as a catalyst to jump-start the group and help

participants when they stray or start to slow down. • Respect everyone’s contribution.


The Basics of Process Mapping (continued) Process mapping pitfalls The table below lists typical pitfalls and possible remedies associated with process maps. Pitfall Possible remedy“Unbalanced” map (too much detail in some areas, not enough in others)

• Compare to other parts of the map; ask, “Does this step contain roughly the same amount of effort as that step?”

Gaps (missing or uncertain steps)

• Ensure that those who help create the map are knowledgeable of the process, or have others review the draft for completeness and accuracy

Map too “busy” • Use additional paper and plenty of white space, or expanded maps cross-referenced to base map

Takes too long, or people getting bogged down

• Establish ground rules: — Outstanding items list — Move on after five minutes — Follow rough draft principle; first get it

down, then get it good — Use facilitator

Unclear terminology, or cannot remember what was said about a particular step

• Take notes while mapping • Create glossary

Group is mixed (some upper level, some lower levels) or defers to designated decision maker

• Stress that firsthand knowledge of the work process is what matters

• Strive for equal participation, even if it means redefining the group

• Try to prevent this problem by staffing the group with the right mix up front and explaining to management that they should select those closest to the work



(continued)

How to create a cross-functional process map

1. Place a large (at least 3' x 6') piece of paper on a wall or flat surface.

2. Draw one horizontal band for each function involved in the process. Bands may also be used to represent roles, such as manager, or job titles, such as production supervisor. If the process involves only one function, skip this step.

3. Label the functions, starting with the customer (internal or external) at the top, and then the functions closest to the customer.

Customer

Sales

Operations


The Basics of Process Mapping (continued)

4. Ask each group member to write on Post-it Notes the steps that make up their function's portion of the process, and place the Post-it Notes on the map.

5. Resequence the Post-it Notes until the group is satisfied that the process is accurately mapped.

Customer

Sales

Operations

Customer

Sales

Operations



(continued)

6. Add and label all inputs and outputs to complete the map.

Customer

Sales

Operations

a

b c

d


The Basics of Process Mapping (continued) Cross-functional process map interview Oscar: Let’s take a closer look at the work that takes place in the muffler

bay. Based on the information from our earlier session, here is what I understand so far. A customer drives in and speaks with someone in Sales. After Sales and the customer have discussed the work to be done, Sales writes a work order and asks for the customer’s approval. Is that right, so far?

Phil: Yes. Oscar: What happens next? Phil: Sales gives the work order to the technician, who reviews it and

prepares to start the job. Oscar: What does the technician do? Phil: He pulls a new muffler from inventory. Then he removes the old

muffler. Next, he installs the new muffler. Then he starts the car, and checks for leaks and the proper exhaust. If everything is OK, he turns off the car, and notifies Sales that the job is complete. If the job is not OK, he begins troubleshooting by double-checking the clamps, seals, and so on.

Oscar: Once Sales is notified by the technician, they prepare the bill for the

customer and collect payment, right? Phil: Right.



(continued)

Oscar: Can you think of anything else that takes place as part of a muffler

replacement? Phil: Not right now. I think we’ve about covered it. Oscar: Let’s take a look at the map of the muffler replacement process.

211-RM-39

© Copyright: All rights reserved. Not to be reproduced without prior written consent.


Figure 13: Muffler Replacement Process—Cross-Functional Process Map


Interpreting Cross-Functional Process Maps

Cross-functional process maps show the value-producing chains of the business. They also depict the pathways to customer satisfaction. Whereas relationship maps focus more on the big-picture supplier-customer links that make up a business, cross-functional process maps show us in more detail how an organization uses processes to create value for its customers. Cross-functional process maps answer the questions:

• What steps are required to produce a particular output? • What is the order in which the steps are performed? • Who (which function) performs each step? • What are the handoffs or interfaces between functions? • In what parts of the process do the handoffs occur? • What are the inputs required and the outputs produced at each step

of the process? Like relationship maps, cross-functional process maps often contain disconnects (missing or deficient inputs or outputs). Because cross-functional maps show what takes place inside one or more functions for a particular process, any disconnects that were present in the relationship map of those functions will also be present here. As you review your map, you may discover inputs or outputs that do not feed into any other steps within the same function, or into steps within other functions. You may also find missing or implied steps, inputs, or outputs. Each of these is a form of disconnect that should be noted and resolved.


Figure 14: Muffler Replacement Process—Cross-Functional Process


Interpreting the Map of the Muffler Replacement Process

How might you interpret the map of the muffler replacement process and the information you have gained thus far? Consider the following questions as you refer to Figure 14:

1. What disconnects are apparent, if any? Implied or missing steps might include: drive car into muffler bay, return car to customer, obtain or verify needed supplies and tools, and accumulate old mufflers for recycling. Implied or missing outputs might be: car in place at muffler bay, car in place at parking lot, supplies and materials, old muffler, and payment.

2. What are the critical interfaces in the process? Where do they occur? The critical interfaces are between Sales and the customer, and Sales and the muffler bay technician.

3. Who performs each step of the process? By reading each band horizontally, you can determine this information at a glance. The customer requests the work and pays the bill. Sales completes the work order, receives notification that the job is complete, and prepares the final bill. All other steps are performed by the muffler bay technician.

4. What are the inputs required and outputs produced at each step of the process?

The major inputs, those at the start of the process, are the verbal request from the customer and the completed work order from Sales. Major outputs, those at the end of the process, are the completed job and the final bill. Additional inputs required to complete the job are preparations, new muffler, old muffler, new muffler in place, engine idling, exhaust quality data, and engine off.

5. What are the requirements for each input and output? The interview does not provide us with this information.

6. What additional questions might you ask? How does the car get to the muffler bay? Who performs this step? How is the car returned to the customer? Who performs this step? What happens to the payment made by the customer? What tools or supplies does the technician need to perform each step of the process? Where do these inputs come from?


Interpreting the Map of the Muffler Replacement Process (continued) You may have identified additional disconnects or questions. It is apparent that additional information is required to produce a complete and accurate map of the muffler replacement process. To obtain the additional information, you should review the map with representatives of each function involved with the muffler replacement process. Better yet, try to observe the muffler replacement process as it is being performed.

211-RM-47

Business Case Analysis Support In summary, client content services offerings provide various opportunities for revenue generation, cost saving, or product improvement.

Potential Benefits Revenue Cost Savings Product Improvement

Enhance WIP production efficiency and quality Enable new product development Enhance Client’s relationship with external partners Position for emerging broadband and commerce model Promote creativity and collaboration Leverage WIP exploitation across business units Increase asset (program and element) reuse Reduce content review cycles Reduce overall time to market Exploit and enhance branding across multiple product categories Enable rapid customization for high growth international markets Preserve assets by reducing handling wear and tear Protect and manage intellectual property Provide effective decision support tools Reduce tedious administrative activities Increase knowledge/accuracy of asset inventory Enhance ability to track asset inventory Provide quick and easy inventory search ability Control access to media throughout system Eliminate redundant, incomplete, and/or inaccurate information sources Offset internal costs via external stock footage sales



XX

X

X

X

X

X

X

X

X

XX

X

XX

XX

X

X

XX

X

X

X

X

XX

XXX

X

X

X

X X XX X X

X XXX

X X

XX

XXX

X





XX

X

X

X

X

X

X

X

X

XX

X

XX

XX

X

X

XX

X

X

X

X

XX

XXX

X

X

X

X X XX X X

X XXX

X X

XX

XXX

X

© Copyright: All rights reserved. Not to be reproduced without prior written consent.


Business Case Analysis Support (continued) Baseline metrics should be established to provide a basis for ongoing monitoring of the effectiveness and true business impact of the content services offerings.

Service Metric Collection MethodWIP/Collaboration Production time saved General customer approximation through survey

Customer provided show cycle time data via production schedules MS project)Customer provided average cost per show

Quality improvement Customer feedback per show(better product, better Ratings or viewership per showidea generation, etc.) Internal quality measurements

Number of review iterations

Content Outreach Client services utilization Client internal metrics: clip usage rate, archive hit rate, # users orrate licenses

Customer satisfaction Customer feedback via survey

Content Exploitation Volume/cycle time of Customer provided data on volume increase of exploitative effortsexploitative efforts Customer provided data on cycle time decrease of exploitative efforts

Content Archive Reuse Archive utilization rate System generated hit rates, CSR generated usage ratesShows generated from Customer provided volume dataarchive

External Sales Sales revenue and profit System or CSR generated sales reports

Rights Management Rights information access Number of titles/hours in systemPercentage of owned content in system

Service Metric Collection MethodWIP/Collaboration Production time saved General customer approximation through survey

Customer provided show cycle time data via production schedules MS project)Customer provided average cost per show

Quality improvement Customer feedback per show(better product, better Ratings or viewership per showidea generation, etc.) Internal quality measurements

Number of review iterations

Content Outreach Client services utilization Client internal metrics: clip usage rate, archive hit rate, # users orrate licenses

Customer satisfaction Customer feedback via survey

Content Exploitation Volume/cycle time of Customer provided data on volume increase of exploitative effortsexploitative efforts Customer provided data on cycle time decrease of exploitative efforts

Content Archive Reuse Archive utilization rate System generated hit rates, CSR generated usage ratesShows generated from Customer provided volume dataarchive

External Sales Sales revenue and profit System or CSR generated sales reports

Rights Management Rights information access Number of titles/hours in systemPercentage of owned content in system

211-RM-49

Business Case Analysis Support (continued)

The five-year financial projections reflect significant contribution to the client bottom line over five years.

Long Range Management Analysis - ($000)

1997 1998 1999 2000 2001 2002 2003 2004Actuals Actuals F'Cast Plan Plan Plan Plan Plan

Cost Savings & External Rev Images - External Sales Revenue $413 $357 $275 $358 $413 $477 $551 $637 Images - Internal Cost Saving $0 $1,094 $1,300 $1,442 $1,574 $1,719 $1,877 $2,030

Onboard - External Sales Revenue $421 $460 $530 $615 $715 $787 $865 $952 Onboard - I/C Transfer Ad Sales $100 $100 $135 $175 $184 $193 $203 $213 Onboard - Internal Cost Saving $175 $350 $473 $494 $516 $543 $560 $578

XXX - Internal Cost Savings $612 $673 $750 $822 $893 $971 $1,055 $1,147

Savings from Collaboration Tools $0 $0 $0 $266 $528 $995 $1,648 $2,097

Total Cost Saving & Rev $1,721 $3,034 $3,462 $4,171 $4,824 $5,684 $6,759 $7,651

Capital Expenses: Hardware Capital $400 $500 $500 $600 $200 $210 $221 $232 Software Capital - Rights Mgmt $100 $600 $300 $800 $50 $53 $55 $58 Software Capital - Collaboration $0 $0 $0 $200 $100 $105 $110 $116 Total Capital Expense $500 $1,100 $800 $1,600 $350 $368 $386 $405

Operating Expenses: Direct Personnel Expenses $1,379 $2,461 $2,246 $2,336 $2,545 $2,771 $3,014 $3,277

Design Implementation Fees $0 $800 $750 $235 $140 $147 $150 $150

XXX $664 $429 $279 $376 $394 $413 $434 $456 Onboard & Inflight $404 $609 $460 $560 $588 $617 $648 $681 Production Group $1,376 $578 $192 $282 $291 $299 $308 $318 Rights Mgmt $105 $182 $56 $84 $100 $103 $106 $109 Exec $342 $404 $152 $140 $147 $151 $156 $161Total Operations Exp $4,270 $5,463 $4,136 $4,013 $4,205 $4,503 $4,817 $5,151

TOTAL EXPENDITURE $4,770 $6,563 $4,936 $5,613 $4,555 $4,870 $5,203 $5,557

Contribution ($3,048) ($3,528) ($1,474) ($1,442) $269 $814 $1,556 $2,095

Cume Contribution ($3,048) ($3,528) ($5,003) ($6,444) ($6,175) ($5,361) ($3,806) ($1,711)



Business Case Analysis Support (continued) Five-year financial plan—key assumptions:

Used very conservative efficiency %; client will most likely achieve 20% 2002

Key AssumptionsRevenue Images -External Sales Avg # Seconds Licensed 9,610 8,308 6,250 7,950 8,745 9,620 10,581 11,640

Rate per Sec (preferred rate) $43 $43 $44 $45 $47 $50 $52 $55

Images -Internal Sales Avg # Seconds Licensed - 27,345 32,500 35,000 37,100 39,326 41,686 43,770


Onboard -External Sales Avg # of Licenses per yr 169 184 200 228 260 278 298 317

Avg Rate per License $2,500 $2,500 $2,650 $2,700 $2,750 $2,825 $2,900 $3,000

Onboard -Internal Mrkting Value Total Trade/Barter 500,000 1,000,000 1,350,000 1,410,000 1,475,000 1,550,000 1,600,000 1,650,000

Discounted % to XXX Clients 35% 35% 35% 35% 35% 35% 35% 35%

Production Group -Internal Sales Avg # Seconds Licensed 40,000 44,000 49,000 60,000 62,100 64,274 66,523 68,851


Collaboration Tools Potential Market (HCP & Comm) $92,576 $95,439 $98,391 $110,719 $117,362 $124,404 $131,868 $139,780

Avg % of Projects supported NA NA NA 8% 15% 20% 25% 30%

Avg % Increased Efficiency NA NA NA 3% 3% 4% 5% 5%Staffing Avg $ per Staff 59,945 63,100 62,402 64,898 68,792 72,920 77,295 81,932 Avg # Staff 23 39 36 36 37 38 39 40

211-RM-51

Business Case Analysis Support (continued)

There are significant risks and costs associated with inaction.

Costs of Inaction• Loss of competitive leverage as industry leaders embrace sophist

management systems• High cost of funding duplicative efforts as various groups seekindependent

solutions to the same problem• Potential erosion or permanent loss of valuable Client assets asthey deteriorate

over time. Replacement cost high.• Opportunistic loss to do more production and potential Ad SalesRevenue• Potential erosion of Client’s core capability• Lost opportunity to solidify relationship with external producer

encourage Client loyalty and raise switching costs

• Continued risk of unexploited rights (lost revenue and unnecessary spending)• Risk of industry refusal to sell stock footage to Client• Cost of inefficient communications and workflow processes• Cost of underutilized Client department

Costs of inaction• Loss of competitive leverage as industry leaders embrace sophisticated content

management systems• High cost of funding duplicative efforts as various groups seek independent

solutions to the same problem• Potential erosion or permanent loss of valuable client assets as they deteriorate

over time; replacement cost high• Opportunistic loss to do more production and potential ad sales revenue • Potential erosion of client’s core capability’• Lost opportunity to solidify relationship with external producers and effectively

encourage client loyalty and raise switching costs

• Continued risk of unexploited rights (lost revenue and unnecessary spending)• Risk of industry refusal to sell stock footage to client• Cost of inefficient communications and workflow processes• Cost of underutilized client department



Sample Ground Rules


Sample Ground Rules (continued)


211-RM-57

Project Assumptions

Example 1: Project assumptions

These project assumptions were documented during the project planning process and shared with the client. Information has been altered to promote client anonymity.

Critical Project Assumptions• Phase 1 costs (approximately $356,000) will not be charged to the Client.

• Most work will be conducted remotely to expedite the schedule.

• Client will receive weekly email updates and periodic on-site status reviews as needed.

• Deliverable quality and timing is directly contingent on the receipt of requested pre-kickoff data before 4/10/06.

• The Phase 1 engagement provides analysis and recommendations on market segments but will not provide the Client a specific list of customers to pursue. Future consulting phases (including proof of concept) may identify a few targeted customers for rich media opportunities.

• In order to accommodate the Client’s request to expedite equipment provisioning, Consultant is amending its normal consulting solution process as follows:

• Technical preparation work will be conducted as part of the phase 1 activity • Phase 1 technical preparation will identify a majority of the critical components anticipated to

be required to support a baseline streaming infrastructure • The complete infrastructure will be designed (and subsequent equipment ordered) during

phase 3 after the appropriate needs assessment and business requirement data has been captured.

• Consultant will attempt to mitigate risk associated with this approach by documenting and communicating all technical assumptions

Critical Project Assumptions• Phase 1 costs (approximately $356,000) will not be charged to the Client.

• Most work will be conducted remotely to expedite the schedule.

• Client will receive weekly email updates and periodic on-site status reviews as needed.

• Deliverable quality and timing is directly contingent on the receipt of requested pre-kickoff data before 4/10/06.

• The Phase 1 engagement provides analysis and recommendations on market segments but will not provide the Client a specific list of customers to pursue. Future consulting phases (including proof of concept) may identify a few targeted customers for rich media opportunities.

• In order to accommodate the Client’s request to expedite equipment provisioning, Consultant is amending its normal consulting solution process as follows:

• Technical preparation work will be conducted as part of the phase 1 activity • Phase 1 technical preparation will identify a majority of the critical components anticipated to

be required to support a baseline streaming infrastructure • The complete infrastructure will be designed (and subsequent equipment ordered) during

phase 3 after the appropriate needs assessment and business requirement data has been captured.

• Consultant will attempt to mitigate risk associated with this approach by documenting and communicating all technical assumptions


Project Assumptions (continued) Example 2: Project assumptions

These critical success factors were identified and documented during the project planning process and subsequently shared with the client. This slide formed a basis for the consultant and client team to reach agreement on each of these critical success factors. Information has been altered to promote client anonymity.

Critical Success Factors• Unified team with a shared vision• Agreement that change will happen• Continued support from executive committee• Alignment with strategic direction of company• Clearly defined roles and responsibilities• Organizational structure that supports goals• Common voice among the team/unified efforts• Standards based on proven technology• Continued staff development• Constant communication within and outside departments• Commitment from business partners to trial system, provide feedback, and gather metrics

Critical Success Factors• Unified team with a shared vision• Agreement that change will happen• Continued support from executive committee• Alignment with strategic direction of company• Clearly defined roles and responsibilities• Organizational structure that supports goals• Common voice among the team/unified efforts• Standards based on proven technology• Continued staff development• Constant communication within and outside departments• Commitment from business partners to trial system, provide feedback, and gather metrics


211-RM-59

Project Assumptions

(continued)


These project assumptions were identified during the planning phase of a digital asset management project. Information has been altered to promote client anonymity.

Enterprise Roadmap Analysis AssumptionsDepartments interviewed were those identified (by Client) as part of the Enterprise Review scope; departments interviewed were intended to be a representative sampleNon-Theatrical was identified as a new group during the Core Team meeting. This group has not yet been interviewed and is not included in the roadmapEnterprise Review task included “high level” discussions; Project scope included limited “enterprise analysis”. Subsequent detailed assessments (e.g., requirements gathering, system feasibility/gap analysis) will be required to support actual individual departmental implementationsFor each phase of implementation, there will be changes to the Project system (additional configuration or customization)Project scope initially includes internal system access and may evolve to include

external access in later phasesProject scope initially includes approved, finished assets only – work in progress

content management may be supported in later phasesProject scope initially excludes video and audio; future phases could provide low-res

video/audio support


Project Assumptions (continued) Example 3: Project assumptions (continued)

These project assumptions were identified during the planning phase of a digital asset management project. Information has been altered to promote client anonymity.

Enterprise Roadmap Analysis AssumptionsQualitative (not quantitative) factors were used to prioritize departmental rolloutIdentified criteria guides high level phasing but is not a specific formula for roadmap placement – 80/20 rule is used to develop a roadmap that will derive the most for the enterpriseFunctionality will be realized by groups as defined by the phases (for example, some functionality may be realized during an earlier phase and additional functionality realized in a subsequent phase).In later phases, intra-phase departmental priorities will need to be assessedAs the project evolves, the Enterprise Roadmap will need to be continually reassessed relative to any organizational changes, technology changes, and other business realities.


211-RM-61

Project Assumptions

(continued)


These project assumptions were documented during the project planning process and shared with the client. Information has been altered to promote client anonymity.

Key Assumptions:• Most work will be conducted remotely to expedite the schedule, however a one day on-

site workshop is planned and an optional follow-up meeting to present the deliverables.

• This project assumes a start date of November 26, 2001. Any change of this start date may impact the scope or resources used on this engagement.

• Deliverable / session quality and timing is directly contingent on the receipt of requested pre-kickoff data.

• Certain deliverables may be presented to Client after December 14, 2001.

• Working calls / meetings will be held as needed.

• This project will be sponsored by executive management. Access to key personnel will be critical to meeting deadlines for this project.

• This engagement is intended to provide a high level information analysis only. A detailed requirements document, a detailed implementation plan or detailed ROI is not planned as part of this engagement’s deliverables. However, the outcome of this engagement may serve as a foundation for future phases of this overall project.

• Professional fees and expenses will be covered by the Consultant for this engagement.

Key Assumptions:• Most work will be conducted remotely to expedite the schedule, however a one day on-

site workshop is planned and an optional follow-up meeting to present the deliverables.

• This project assumes a start date of November 26, 2001. Any change of this start date may impact the scope or resources used on this engagement.

• Deliverable / session quality and timing is directly contingent on the receipt of requested pre-kickoff data.

• Certain deliverables may be presented to Client after December 14, 2001.

• Working calls / meetings will be held as needed.

• This project will be sponsored by executive management. Access to key personnel will be critical to meeting deadlines for this project.

• This engagement is intended to provide a high level information analysis only. A detailed requirements document, a detailed implementation plan or detailed ROI is not planned as part of this engagement’s deliverables. However, the outcome of this engagement may serve as a foundation for future phases of this overall project.

• Professional fees and expenses will be covered by the Consultant for this engagement.


Project Constraints Template

Company X Phase: Preliminary Study

Project Constraints Required All projects have constraints. The purpose of this artifact is to capture the constraints that management places on the project. The constraints take different forms or fall into different categories. For example, management may decide that the existing database management system must be used as part of the solution; this would be an example of a technical constraint. Sometimes management is seeking a minimum return for the money that’s being spent for development. This would form an economic constraint. The constraints categorized here in this artifact are technical, risk, economic, legal, organizational, and schedule (TRELOS). We use the acronym TRELOS, to represent these constraints. They are used to evaluate feasible solutions or to evaluate design alternatives within a project. Summary Technical Is there hardware and/or software that must be used? Risk Tolerance What is the risk appetite for the organization or business sponsor? That is, is the organization willing to take on projects of high risk or must project risks be kept to a minimum Economic Economic constraints take different forms: sometimes management will be seeking to lower the operating budget to a threshold; at other times they may be seeking a minimum return on investment (ROI); or there may be a constraint placed on the amount of money that can be spent for development. Budget Impact Return on Investment Development Costs Legal Capture any legal or quasi-legal constraints here. These are things that by law cannot be incorporated into a solution. Organizational An organizational constraints requires that the solution not dramatically alter the way people currently work or change the culture of the organization. Schedule This constraint represents the total length of time that could be taken to complete the project. It is sometimes referred to as the drop-dead date.

211-RM-65

Sample Action Item Template

Action item tips • Always review most recent action items at the beginning of meetings • Allow action item owners to suggest due dates instead of arbitrarily assigning due dates • Ensure that action item owners update action item status for their respective action items • Consider using databases that will automatically notify owners of upcoming due dates • Verbally review all assigned action items at the end of meetings and include them in meeting notes • Status options: Open, Closed, Overdue

# Action Item OwnerDate

Assigned Due Date Status Comments1 Schedule interviews with marketing department DP 3/26/2007 3/28/2007 Closed Meetings scheduled for 5/7-10/072 Develop interview guide for marketing interviews SB 3/28/2007 4/2/2007 Closed Marketing interview guide posted to shared drive

3 Meet with Vendor X to review new system enhancements TP 4/3/2007 4/10/2007 ClosedMet with JM from Vendor X. New enhancements will not meet 1 click shopping requirement.

4 Research MAC compatibility issue with JM in IT JK 4/2/2007 4/10/2007 Overdue PM agreed to extend due date by x days5 Schedule team celebration JK 4/2/2007 4/12/2007 Overdue PM agreed to extend due date by x days



211-RM-67

Requirements Gathering Templates

This document represents internal documentation that a team used to prepare for a high-level business requirements gathering session with a client. Certain information has been amended to promote client anonymity.

Client X workshop agenda preparation

Timing Topic Facilitator Facilitation method Preparation required

Day 1 Obtain specific directions to client location; room number; client cell phone; request room equipment and food; ensure that note goes out to all participants prior to workshop

9:00–9:15 15 min

Assembly and welcome SR/KM and Client

NA Talking points developed and documented

9:15–9:30 15 min

Introduce workshop participants SR/KM and Client

NA Request and obtain advance list of confirmed client attendees/functions; provide client list of consultant attendees/functions

9:30–9:45 15 min

Review workshop objectives and agenda

SR/KM and Client

NA Finalize and review objectives and agenda with client

9:45–10:15 30 min

Provide Client X background/overview

MR Request that client prepare something to deliver; we need to prompt them with suggested topics

10:15–10:30 15 min

Break

10:30–11:30 60 min

Conduct vendor demo (Breakinserted during demo)

Confirm client demo readiness; prepare and give them demo scenario suggestions

11:30–12:00 30 min

Review workshop methodology and content value chain

SB Review slides with affinity diagram process and value chain defined

Create process slide; obtain all necessary materials for affinity diagram; create content value chain

Requirements Gathering Templates (continued)


Day 2 9:00–9:15 15 min

Assembly and Review Agenda SR NA Finalized agenda

9:15–10:45 90 min

Review and discuss high priority issues

SR Timed discussions of each with flipchart comments on each issue

Need to develop list of questions to probe each high priority category

10:45–11:00 15 min

Break

11:00–11:15 15 min

Review engagement deliverables and next steps

SB Review slides Prepare slides—clearly articulate what they’re getting, how it’s valuable, and how the workshop acts as an input

11:15–11:45 30 min

Debrief meeting and review actions SB Normal debrief on flipchart and action item

Identify resource to track action/parking lot items

Workshop ends 11:45–1:45 2 hours

Optional lunch and technical discussion

SP TBD Develop list of required technical information

Comments:

12:00–12:45 45 min

Lunch and generate issues SB Using large index cards

12:45–2:15 90 min

Board and categorize MAM issues and challenges

SB/SR Affinity diagram process Identify issue statement (confirm with client) and generate advance list of probable issues

2:15–2:45 30 min

Rank issue categories and break SB Ask participants to vote using dots

Obtain supplies

2:45–3:00 15 min

Summarize prioritized issue categories

SR Review high-ranking categories; clarify if necessary

Maybe review MAM Conference document

3:00–3:30 30 min

Debrief meeting and review actions SB Normal debrief on flipchart and action item

Identify resource to track action/parking lot items


211-RM-69

Requirements Gathering Templates

(continued) We need to discuss the specific purpose (end in mind) of the tour/user interviews and/or demo to ensure that we position it appropriately on the agenda and conduct the necessary preparation required. We need to be careful that we’re not spending too much of our time onsite with them getting us up to speed—we must clearly show where we’re demonstrating value. We also may want to consider including an agenda item near the beginning that allows them to provide an overview of their current state or background on their group (from a MAM perspective). To verify that we’ve got all bases covered, I suggest we start with the deliverable and work backwards to ensure that we’re going to have all the information required (and all workshop agenda items are relevant). Deliverable Information required Info capture mechanism Action required1. Workshop summary Summary of discussion and

findings Affinity diagram cards completed Get supplies and ensure that room is compatible

Summary notes Designate scribe Audio tape/video tape (opt.) Get client permission and equipment2. High-level reference architecture

Current state of pilot Pre-workshop discussions and workshop interviews

Develop template/listing of relevant questions

Business objectives/pressing business issues (desired functionality)

Workshop affinity diagramming session

Issues prelist and affinity diagramming prep

Corporate IT standards (e.g.,vendors, platforms)

Pre-workshop questionnaire; offline discussions

Develop questionnaire

MAM Functional critical data (# users, amount of content, etc.)

Pre-workshop questionnaire; offline discussions

Develop questionnaire

3. High-level project roadmap

Prioritization of services/MAM functionality components

Affinity diagram session in workshop; user interview feedback

Generic MAM implementation plan?

Reuse existing plan (e.g., 14 steps from previous project)

Review document to assess applicability



4. Project critical success factors

List of CSFs for Client X MAM implementation

Review previous CSFs for generic input



211-RM-71

Department Issue/comment Issue category Priority Comments/solution Theatrical Publicity Approval workflow is a challenge because it depends too

much on individual personality Workflow Management L System won't be able to handle this

until workflow management (including all approvers) is implemented. When all approvers are required to use the same system and follow the same procedure, the workflow should be enhanced.

There are too many variables involved in approving the artwork

Workflow Management L Same as above

Deadlines are too close Workflow Management L System should address this issue somewhat, but clear policy definition and enforcement is needed

Release date is not reliable and changes frequently Workflow Management L Same as above Theatrical Print Creative Not enough disk space Digital Storage

Infrastructure M System with consolidated central

storage infrastructure will allow client to better utilize the storage capacity and more flexibly allocate sufficient storage capacity for higher priority or urgent tasks

No established mechanism to distribute finished artwork based on subscription list or distribution list

Workflow Management H System can help with automatic notification via e-mails to all parties in the distribution list

They would like to have a system allowing them to organize their own personal or departmental collection into a library

Departmental Repository

L System can assist during later phases when departmental repositories are supported to support departmental/personal use

Current distribution challenges—all vendors and in-house departments

Efficient Distribution H System won't solve physical distribution issues



They become trainers to help other people use Photoshop, FTP servers, PDF, or Web browser

Inefficient Knowledge Management and OD

L Using system will simplify access to managed content, but role/responsibility designations are organizational development issues

There are some issues with CDs failing to be read if the CDs are a few years old (4 years ago)

Digital Content Management

H System will store all content on hard disk and manage the content migration based on policy. Automatic conversion from old media to new media can also be done with appropriate customization.

Hard to find CDs and CD content Inefficient Content Search and Access

H Same as above (CD can be replaced by online, nearline, or offline storage of a digital asset management system)

They want to have a system to help find content quickly Digital Content Management

H System can help resolve this issue, but appropriate system integration may be required to ensure that system becomes the centralized knowledge base

Currently it is a low pain to manage their content, but they see the pain is growing with the growth of the content volume

Digital Content Management

L System can help alleviate department's pains before anticipated growth and accompanying increased complicated asset management issues

TV Creative (Photos) Disk storage limitations Digital Storage

Infrastructure L Storage infrastructure and

management could become a parallel effort, but system alone is not intended to directly deal with space capacity issues

Not enough physical storage space Physical Storage/Capacity Constraints

L



211-RM-73

Finding content and information is difficult and time-consuming

Inefficient Content Search and Access

H System should resolve this issue if the content and metadata have been ingested in a timely fashion

Users need look-ahead and thesaurus functionality Inefficient Content Search and Access

H System should resolve this issue if the content and metadata have been ingested in a timely fashion

Much of the content is lost and/or disorganized Physical Content Management

M System can't solve past issues like this but, going forward, if metadata and content are ingested quickly and master physical copies are archived safely, it should resolve the issue

• This sample template is similar to one used to gather comments/data from stakeholder interviews during initial requirements gathering. • Stakeholder comments and prioritization were documented during actual interviews. Business analysis team identified the issue category and documented relevant

comments after the interviews. • The final comments column provided an opportunity for the team (including Development) to begin analyzing requirements and consider possible solution

options/implications based on information known at that time. • Information has been altered to promote client anonymity.



Sample requirements gathering interview guide

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Value Chain Step Descriptions Planning is concerned with project initiation, business feasibilities, and program management, etc. Content origination involves recycling, acquisition, and creation of content into media products such as print

publications or electronic media Production or manufacturing involves the transformation of content info product masters and their replication

as media products/services Marketing involves exploitation of content, information about content, and prospective channels to deliver

media products to customers Distribution involves delivery of media products and services and the exchange of value with customers Assessment involves measuring, evaluation, and reporting financial and technical performance relative to

targets and commitments Archive involves storing and retention of content and information about content in a central or distributed

environment to retain the value of the assets

Value Chain Step Descriptions Planning is concerned with project initiation, business feasibilities, and program management, etc. Content origination involves recycling, acquisition, and creation of content into media products such as print

publications or electronic media Production or manufacturing involves the transformation of content info product masters and their replication

as media products/services Marketing involves exploitation of content, information about content, and prospective channels to deliver

media products to customers Distribution involves delivery of media products and services and the exchange of value with customers Assessment involves measuring, evaluation, and reporting financial and technical performance relative to

targets and commitments Archive involves storing and retention of content and information about content in a central or distributed

environment to retain the value of the assets

The above numerical values represent the different points in the value chain, the odd numbers (1, 3, 5, 7, 9, 11, 13, 15) represent the interface between value steps and the even numbers represent the value steps themselves.

The above numerical values represent the different points in the value chain, the odd numbers (1, 3, 5, 7, 9, 11, 13, 15) represent the interface between value steps and the even numbers represent the value steps themselves.

This slide represents a portion of an interview guide similar to one used to gather requirements for a knowledge management database implementation. Information has been altered to promote client anonymity.

Planning Origination Production Assessment ArchiveMarketing Distribution



211-RM-75

Sample requirements gathering interview guide (cont.)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 How does this value chain (workflow or product content life cycle) track to Client’s

value chain (or in other terms like publishing process, workflow, or content life cycle)? Does Client have a different representation of the value chain? If yes, what is it? If NOT, can we discuss your daily business based on this framework?

If the above numerical value represent the different points in the value chain, the odd numbers (1, 3, 5, 7, 9, 11, 13, 15) represent the interface between value steps and the even numbers represent the value steps, Which value steps (i.e., the even numbers) have been fully automated? Can you assign the priority order in terms of where you want to concentrate your

investment budget? In your opinion, which value steps are most critical to meeting the key business

needs of your group?

How does this value chain (workflow or product content life cycle) track to Client’s value chain (or in other terms like publishing process, workflow, or content life cycle)? Does Client have a different representation of the value chain? If yes, what is it? If NOT, can we discuss your daily business based on this framework?

If the above numerical value represent the different points in the value chain, the odd numbers (1, 3, 5, 7, 9, 11, 13, 15) represent the interface between value steps and the even numbers represent the value steps, Which value steps (i.e., the even numbers) have been fully automated? Can you assign the priority order in terms of where you want to concentrate your

investment budget? In your opinion, which value steps are most critical to meeting the key business

needs of your group?


Planning ProductionOrigination Assessment ArchiveMarketing Distribution




1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Pre-planning (1) Where is the pre-planning information coming from? For example, other systems

inside the company, external systems, or what else?

What are the examples of information feeds into the Planning step? (e.g., business planning data from ERP, staff profiles from corporate directory, etc.)

What other tools or applications are interfacing with applications used in Planning?

Pre-planning (1) Where is the pre-planning information coming from? For example, other systems

inside the company, external systems, or what else?

What are the examples of information feeds into the Planning step? (e.g., business planning data from ERP, staff profiles from corporate directory, etc.)

What other tools or applications are interfacing with applications used in Planning?





211-RM-77


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Planning (2) Who is involved in the Planning phase? Are they internal staff, external staff (e.g.

free lancers, other company staff, suppliers, partners, etc.), or others? What tools or applications are used to manage projects or project information? Where (or in what database) is the project information stored and managed? Please provide examples of project information (e.g., project name, project

manager, status, created date, due day, product type, etc.) Roughly how many projects are going on per month?

Planning (2) Who is involved in the Planning phase? Are they internal staff, external staff (e.g.

free lancers, other company staff, suppliers, partners, etc.), or others? What tools or applications are used to manage projects or project information? Where (or in what database) is the project information stored and managed? Please provide examples of project information (e.g., project name, project

manager, status, created date, due day, product type, etc.) Roughly how many projects are going on per month?






1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Planning to Origination (3) What kind of Planning information needs to be fed into Origination? (e.g., project

id, project manager, project due day, or what else?) How is the project information fed from Planning to Origination? Is there any content object involved in this phase? If yes, what types of content

are being handled? What applications used in Planning are interfacing with applications used in

Origination?

Planning to Origination (3) What kind of Planning information needs to be fed into Origination? (e.g., project

id, project manager, project due day, or what else?) How is the project information fed from Planning to Origination? Is there any content object involved in this phase? If yes, what types of content

are being handled? What applications used in Planning are interfacing with applications used in

Origination?


OriginationPlanning Production Assessment ArchiveMarketing Distribution



211-RM-79


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Origination and Development (4) Who is involved in the Origination phase? Are they internal staff, external staff

(e.g., freelancers, other company staffs, suppliers, partners, etc.)? What tools/applications are used

To produce content? To manage the workflow, the content, and information about content?

Where are the content and information about content stored and managed? What media are used to store and manage the content and information about content? What kinds of information about content is managed? (e.g., content type, created

date, status, modified day, contributor, rights info, etc.) What is the volume of information? (e.g., amount of content per month and

number of bytes of content and information about content, etc.)

Origination and Development (4) Who is involved in the Origination phase? Are they internal staff, external staff

(e.g., freelancers, other company staffs, suppliers, partners, etc.)? What tools/applications are used

To produce content? To manage the workflow, the content, and information about content?

Where are the content and information about content stored and managed? What media are used to store and manage the content and information about content?

What kinds of information about content is managed? (e.g., content type, created date, status, modified day, contributor, rights info, etc.)

What is the volume of information? (e.g., amount of content per month and number of bytes of content and information about content, etc.)


OriginationPlanning Production Assessment ArchiveMarketing Distribution




1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Origination to Production (5) What kind of Origination information needs to be fed into Production? (e.g.,

project ID, content ID, creator, creation date, and status, etc.) How is the information fed from Origination to Production? How are content fed from Origination to Production? What applications used in Origination or other steps are interfacing with

applications used in Production?

Origination to Production (5) What kind of Origination information needs to be fed into Production? (e.g.,

project ID, content ID, creator, creation date, and status, etc.) How is the information fed from Origination to Production? How are content fed from Origination to Production? What applications used in Origination or other steps are interfacing with

applications used in Production?

This interview guide is similar to one used to gather requirements for a knowledge management database implementation. Information has been altered to promote client anonymity.

ProductionPlanning Origination Assessment ArchiveMarketing Distribution



211-RM-81


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Production (or Manufacturing) (6) Who is involved in the Production phase? Are they internal staff, external staff

(e.g., freelancers, outsourcing or other company staff, suppliers, partners, etc.)? What tools/applications are used to manage workflow, the content, and information

about content?



What is the volume of information? (e.g., amount of content per month, number of bytes of content and information about content, etc.)

Production (or Manufacturing) (6) Who is involved in the Production phase? Are they internal staff, external staff

(e.g., freelancers, outsourcing or other company staff, suppliers, partners, etc.)? What tools/applications are used to manage workflow, the content, and information

about content?



What is the volume of information? (e.g., amount of content per month, number of bytes of content and information about content, etc.)


ProductionPlanning Origination Assessment ArchiveMarketing Distribution




1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Pre-Marketing (7) What kind of information needs to be fed into Marketing? (e.g., project ID, project

manager, project due day, status, etc.)? What tools/applications and media are used to communicate the information from

Planning, Origination, and Production to Marketing? What applications used in Other Steps are interfacing with applications used in

Marketing?

Pre-Marketing (7) What kind of information needs to be fed into Marketing? (e.g., project ID, project

manager, project due day, status, etc.)? What tools/applications and media are used to communicate the information from

Planning, Origination, and Production to Marketing? What applications used in Other Steps are interfacing with applications used in

Marketing?


Planning MarketingProductionOrigination Assessment ArchiveDistribution



211-RM-83


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Marketing (8) Who is involved in the Marketing? Are they internal staff, external staff (e.g.,

freelancers, outsourcing or other company staffs, suppliers, partners, etc.)?

What tools/applications are used to manage workflow, the content, and information about content?



What is the volume of information? (e.g., amount of content per month, number of bytes of content, and information about content, etc.)

Marketing (8) Who is involved in the Marketing? Are they internal staff, external staff (e.g.,

freelancers, outsourcing or other company staffs, suppliers, partners, etc.)?

What tools/applications are used to manage workflow, the content, and information about content?



What is the volume of information? (e.g., amount of content per month, number of bytes of content, and information about content, etc.)


Planning MarketingProductionOrigination Assessment ArchiveDistribution





1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Enabling Technologies: What kinds of technology initiatives has Client started or planned to start in the following areas? Desktop Publishing Automated Digital Workflow Management Digital Asset Management Multi-channel publishing eBusiness (including eCommerce, ePublishing, or eServices) Knowledge Management Supply Chain Management Digital Rights Management Creativity and productive tools like QuarkXpress or Adobe

Enabling Technologies: What kinds of technology initiatives has Client started or planned to start in the following areas? Desktop Publishing Automated Digital Workflow Management Digital Asset Management Multi-channel publishing eBusiness (including eCommerce, ePublishing, or eServices) Knowledge Management Supply Chain Management Digital Rights Management Creativity and productive tools like QuarkXpress or Adobe




211-RM-85

What challenges does the Client have in implementing a digital strategy? Minimizing the time to market Minimizing the cost throughout the content life cycle Maximizing returns on investment Maximizing rate of return Maximizing return on content What else?

What are the enabling technologies that the Client has already begun deploying and/or are planning to deploy in the near future to implement the digital strategy? For example, what technologies have been used To recover the value of legacy content in both analog and digital formats? To manage the current content life cycle in terms of planning, content origination,

marketing or exploitation, production, distribution, and performance assessment, etc. To store and retain the value (e.g. content and information about content) created

throughout the content life cycle To re-use, re-purpose, re-express, or share the assets already created and retained

What challenges does the Client have in implementing a digital strategy? Minimizing the time to market Minimizing the cost throughout the content life cycle Maximizing returns on investment Maximizing rate of return Maximizing return on content What else?

What are the enabling technologies that the Client has already begun deploying and/or are planning to deploy in the near future to implement the digital strategy? For example, what technologies have been used To recover the value of legacy content in both analog and digital formats? To manage the current content life cycle in terms of planning, content origination,

marketing or exploitation, production, distribution, and performance assessment, etc. To store and retain the value (e.g. content and information about content) created

throughout the content life cycle To re-use, re-purpose, re-express, or share the assets already created and retained


Sample Requirements Gathering Interview Guide (cont.)


211-RM-87

Sample Project Schedule

Deliverable: finalized interview notes from departments 1, 2, & 3

Consolidate interview notes

Conduct follow up conference calls

Interview Department 3



Develop interview guide

Schedule interview rooms

Develop interview schedule

Confirm list of interviewees with sponsor

Stage 2: Requirements Elicitation

Deliverable: kickoff/deliverable description document

Provide deliverable description document

Conduct kickoff meeting

Review phase 1 lessons learned and recap

Identify milestone meetings and schedule logistics

Confirm appropriate team members/resources—roles and responsibilities

Prepare kickoff meeting presentation

Stage 1: Project initiation

87654321TasksPhase

Deliverable: finalized interview notes from departments 1, 2, & 3

Consolidate interview notes

Conduct follow up conference calls




Develop interview guide

Schedule interview rooms

Develop interview schedule

Confirm list of interviewees with sponsor

Stage 2: Requirements Elicitation

Deliverable: kickoff/deliverable description document

Provide deliverable description document

Conduct kickoff meeting

Review phase 1 lessons learned and recap

Identify milestone meetings and schedule logistics

Confirm appropriate team members/resources—roles and responsibilities

Prepare kickoff meeting presentation

Stage 1: Project initiation

87654321TasksPhase

Weeks


Sample Project Schedule (continued)

# ACTIVITY OwnerEST. HRS

WORK PRODUCT/DELIVERABLE STATUS 26-Nov 27-Nov 28-Nov 29-Nov 30-Nov 3-Dec 4-Dec 5-Dec 6-Dec 7-Dec 10-Dec 11-Dec 12-Dec 13-Dec 14-Dec

0PROJECT INITIATION (also please refer to EM Checklist)Review SOW TY CompleteDevelop/Review detailed workplan TY Detailed Project Workplan Complete

Schedule/Conduct project kick-off meeting TYKick-off Meeting Agenda & Project Overview Complete

1Initiate Project and Conduct Kick-off MeetingDevelop engagement workplan TY Engagement workplan Complete

Identify Client team members TYRoles & responsibilities for team members Complete

Develop 2-day workshop agenda BN Workshop agenda Complete

Complete project kick-off document TYProject kick-off document (including agenda) Complete

Conduct dry run of kick-off meeting Team CompleteSchedule pre-workshop interviews TY / CM Confirmed interviews CompleteSchedule discovery workshop TY Confirmed D.W. date Complete

Schedule travelTeam (TBD) Itineraries Complete

Conduct kick-off meeting Team CompleteFinal deliverable date/time for presentation & travel

Team (TBD) Confirmed itineraries Complete

Publish MAM review for Team (tools, best practices, etc.) FL

Publishing MAM review for Team Complete

2 Gather Current State InformationDevelop Workflow Discussion Framework WR MAM pilot demo Complete

Conduct interviews/calls for data collection WR / TY Complete

Call CJ to validate objectives for Vendor demo TYValidated assumptions / Demo script Complete

3 Prepare Workshop Collateral Schedule Workshop Dry-Run BN CompleteFinalize/modify workshop agenda BN Finalized workshop agenda CompleteList of Business Issues & Challenges for Workshop BP / WR Finalized list of issues Complete

Develop affinity diagramming facilitation guide BN Facilitation guide Complete

Develop participant presentation TYPresentation for discussion in the workshop Complete

Develop workshop checklist BN All items on workshop checklist CompleteFinalize MAM functional framework WR Finalized framework CompleteConduct workshop DRY-RUN Team Complete

This project schedule is similar to one used to manage a requirements project.During the course of the project, the schedule included a due date column as well.This sample project schedule is quite detailed and could be used effectively to ensure minor tasks don't fall through the cracks.Information has been amended to promote client anonymity.


211-RM-89


(continued)

Sample high-level project schedule

This high-level project schedule was presented to a client during project kickoff. A more detailed project schedule (Excel spreadsheet) was used to manage the day-to-day project activities. Information has been altered to promote client anonymity.

Package and Present Deliverables

26Week 1

27 28 29 30 3Week 2

4 5 6 7 10Week 3

11 12 13 14November / December

Create Roadmap

Create Reference Architecture

Conduct Workshop

Prepare Workshop Collateral

Gather Current State Information

Initiate Project & Conduct Kick-off Meeting

Task / Date

Package and Present Deliverables

26Week 1

27 28 29 30 3Week 2

4 5 6 7 10Week 3

11 12 13 14November / December

Create Roadmap

Create Reference Architecture

Conduct Workshop

Prepare Workshop Collateral

Gather Current State Information

Initiate Project & Conduct Kick-off Meeting

Task / Date

Project Team Members On-Site


Sample Project Schedule (continued) Sample high-level project schedule

This high-level project schedule was presented to a client during project kickoff. A more detailed project schedule (Excel spreadsheet) was used to manage the day to day project activities. Information has been altered to promote client anonymity.

Presentation Preparation (Portugal)

On-site Meetings (Portugal)

Status Review Call #2

June 1 June 5 June 6

Financial Plan Development

Strategic Guidance Pres. Development

Project Initiation & Kick Off Call

Client Background Information Review

Project Initiation


June 7May 29May 25May 23May 21May 16Activity / Date

Presentation Preparation (Portugal)

On-site Meetings (Portugal)


June 1 June 5 June 6

Financial Plan Development

Strategic Guidance Pres. Development

Project Initiation & Kick Off Call

Client Background Information Review

Project Initiation


June 7May 29May 25May 23May 21May 16Activity / Date

Formal Project Activity with AgendaFormal Project Activity with Agenda


211-RM-91


(continued)

Sample high-level project schedule

This high-level project schedule was presented to a client during project kickoff. A more detailed project schedule (Excel spreadsheet) was used to manage the day to day project activities. Information has been altered to promote client anonymity.

ACTIVITY#WEEKJan Feb Mar APR10 17 24 31 6 13 20 27 5 12 19 26 9

1

2

3

4

5

7

8

Assemble Team, Project Preparation & Baseline, and Review ScopeKick-off Prep, Level Setting, and Buy-in Interviews

Gather Market Intelligence & Best Practices

Assess and Evaluate Current e-Commerce Processes (Order Mgmt, Fulfillment/Returns, CVM, e-Commerce)

Determine Strategic Opportunity Portfolio & Initiative Prioritization

Create e-Commerce Strategy and Implementation Plan

Present Plan

MI

As-Is

To-be & Gaps6Develop Strategic Architecture (Solution Identification and Integration Needs)

Could-be

Kick-Off

DC visits 2/7-10)Executive Interviews

Market Intelligence, Assessment/Strategy, Strategic Architecture, Plan

Roadmap

Technical work sessions

MI

Milestone checkFinal Report

Key Availability Dates

DC review Draft To-Be

Strategy Session

MI Report

ACTIVITY#WEEKJan Feb Mar APR10 17 24 31 6 13 20 27 5 12 19 26 9

1

2

3

4

5

7

8

Assemble Team, Project Preparation & Baseline, and Review ScopeKick-off Prep, Level Setting, and Buy-in Interviews

Gather Market Intelligence & Best Practices

Assess and Evaluate Current e-Commerce Processes (Order Mgmt, Fulfillment/Returns, CVM, e-Commerce)

Determine Strategic Opportunity Portfolio & Initiative Prioritization

Create e-Commerce Strategy and Implementation Plan

Present Plan

MI

As-Is

To-be & Gaps6Develop Strategic Architecture (Solution Identification and Integration Needs)

Could-be

Kick-Off

DC visits 2/7-10)Executive Interviews

Market Intelligence, Assessment/Strategy, Strategic Architecture, Plan

Roadmap

Technical work sessions

MI

Milestone checkFinal Report

Key Availability Dates

DC review Draft To-Be

Strategy Session

MI Report


Sample Project Schedule (continued) Sample Microsoft Project Gantt chart


211-RM-93


(continued)

Sample Microsoft Project Gantt chart showing slack


Sample Project Schedule (continued) Sample Microsoft Project Gantt chart with resource assignments

• Project takes 56 days to complete without the addition of other resources


Requirements Document Support

Sample requirements document outline

Company X Phase: Analysis Artifact Name: REQUIREMENTS DOCUMENT

Description: This document records the project’s business requirements provided by both the business and technical community

Unique identifier: Required Document Control Example: Template: SOFTWARE DEVELOPMENT LIFECYCLE ROLES/RESPONSIBILITIES Following is a roles-based view of the SDLC Artifact. It lists at a high level who is an [O]wner/author, who is a [R]eviewer, and who is an [A]pprover and who is a [U]ser. These are suggestions, and actual roles and responsibilities would be determined at the beginning of each project.

Phase/Deliverable

Stee

ring

C

omm

ittee

Bus

ines

s Sp

onso

r

Busi

ness

Pro

ject

M

anag

er

Proj

ect

Man

ager

IT M

anag

emen

t

Bus

ines

s A

naly

st

Syst

em

Arc

hite

ct

Prog

ram

mer

A

naly

st

QA

Supp

ort C

ente

r

Tech

nica

l Se

rvic

es

Trai

ning

Definition

PA.211 Business Requirements A R R R O R U R R U

CONTENTS 1. Introduction

1.1. Purpose 1.2. Related Documents

1.2.1. Related documents may include the Product Concept Brief, an MRD and/or a PRD, or a Persona artifact.

2. Scope 2.1. Product Perspective


Requirements Document Support (continued)

1.1.1. Provide a brief description of the software being specified and its purpose, including business goals and benefits. It may be sufficient to refer to a Product Concept brief if one exists.

1.1.2. Provide the context and origin of this Product. Indicate whether it is a follow-on member of a product family, a replacement product, something brand spanking new, an enhancement, etc. If the product is part of a larger effort, indicate how this product fits and what the interfaces to the larger product are.

1.2. Context Diagram and Narrative 1.2.1. Use both words and pictures to indicate what needs to be investigated in

order to build the product. Separate what you intend to work on from what you intend to not work on. Said another way, demonstrate which set of functions (typically indicated by a single process) will be implemented with the software and those that will not (typically indicated by symbols for External Entities).

1.3. High-Level Use Cases 1.3.1. Pictorial Use Cases could be used in conjunction with or instead of a Context

Diagram to show system interactions. 1.4. Product Boundaries

1.4.1. If not depicted by Context Diagram or Use Cases, indicate system interfaces here.

2. Stakeholders 2.1. Identify all classes of stakeholders. These may include clients (those commissioning

product), customers (those who will buy the product), and users of the product. Indicate for each class, the number of members in the class, the expected role they will play, skill and education levels, physical attributes, attitudes, aptitudes, etc.

2.2. Identify IT management having overall responsibility for the delivery of the product as well as members of the project team (It may be sufficient to refer to the Project Team Artifact)

2.3. Identify other stakeholders such as internal and external auditors, support and maintenance personnel, etc.

3. Personas 3.1. Personas are fictional characters that represent various segments of your user

population. Personas are based on interviews and observations conducted with a wide range of current or target users. Out of that research, patterns emerge in terms of goals, demographics, technology and subject matter expertise, attitudes and motivations. A persona is not the same thing as a role—one role (such as an administrator) may map to several different personas if significant differences exist in the areas listed above.

3.2. Personas give the development team a clear sense of who the team is designing for,

and helps the team make more appropriate design tradeoffs. By creating personas based upon a broad research base rather than based upon specific individual customers, the team can avoid designing for the idiosyncrasies of a particular user or company.

3.3. It may be sufficient to refer to the Persona artifact.



(continued)

1. Product Functionality 1.1. Summary of Major Business Functions 1.2. Breakdown of Major Business Functions

This may include: Event Lists Process Descriptions Process Steps Business Logic

1.3. System Interactions (I/O) 1.4. Audit and Control RequirementsData Requirements 2.1. Types of information used 2.2. Frequency of use 2.3. Accessing capabilities 2.4. Data Entities and Relationships 2.5. Integrity Requirements 2.6. Data Retention 2.7. Ownership (System of Record)

3. Documentation Requirements 4. Non-Functional Requirements

4.1. Look and Feel 4.2. Ease of Use 4.3. Personalization and Internationalization 4.4. Ease of Learning 4.5. Accessibility 4.6. Performance 4.7. Safety 4.8. Precision or Accuracy 4.9. Reliability 4.10. Maintainability and Recovery 4.11. General Availability 4.12. Capacity 4.13. Security Requirements 4.14. Scalability and Longevity 4.15. Portability 4.16. Security 4.17. Compliance to Standards 4.18. Operational 4.19. Other

5. Assumptions 6. Appendices (Optional) 7. Index (Optional)


Requirements Document Support (continued)

Artifact Name: REQUIREMENTS QUALITY REVIEW Unique identifier: AN.600

DOCUMENT CONTROL Author: Date created: Contributors: Revision history:

Date Reviewed Reviewed By Approver Disposition

CONTENTS Print without Buttons

1. Completeness ?

2. Correctness ?

3. Ambiguity ?

4. Consistency ?

5. Verifiability or Testability ?

6. Modifiability ?

7. Relevancy ?

8. Ranked for Importance and/or Stability ?

9. Freedom From Design Detail or Constraints ?



(continued)

Sample requirements document checklist

Item

1. Are all your requirements decomposed into single requirements?

2. Do all your requirements include a subject, a capability, and a criterion?

3. Do all your requirements have a unique identifier (usually a number)?

4. If you have used text formatting (for example, italics or bolding), have you clearly indicated what the formatting is meant to indicate?

5. Are your sub-headings related to questions that the users would ask?

6 Have you put what is important to your users first in your sub-headings?

7. Is there enough white space in your document?

8. Is the font size of your body text big enough?

9. Does each of your heading levels have sufficient size difference between it and the next heading level?

10. Is there a glossary for terms that your users may not be familiar with?


Excerpt From a Poor Requirements Document

Detailed requirements

Import & Store Indices • Provide ability to capture and store benchmark data from index level down to constituent

level. In this context the index is equivalent to the overall published index, the sub-index is equivalent to the sector or node level within the benchmark hierarchy, and the constituent level is equivalent to security level.

• Provide the ability to bring in index level and instrument level attributes independently, i.e. without deriving the index (node) level attributes from the instruments. Attributes to be captured include: descriptions, identifiers, value/market capitalisation, nominal values, published weights, index values and returns.

• Provide the ability to import the index weights automatically. • Provide the client options to populate published index data across a model structure,

assigning multiple indices and sub-indices to models and model nodes. • Provide an interface feed mechanism able to interface from multiple source; i.e., index data

providers. • Provide the ability to review and manually enter index level and/or instruments level data. • Provide the ability to store a published benchmark index/sub-index in one of the currencies

it is published in and calculate returns in any other currency. • Similarly, provide the ability to store and maintain a published benchmark index by its

income status; e.g. on both a Total Return basis (with Dividends reinvested), and a Price Return basis (without Dividends reinvested).

• Provide the ability to amend the indices and benchmark data historically. Blend Indices • Provide the capability to create, generate and store blended benchmark data at index/sub-

index level with multiple member indices. • The Blends should allow for saving changes forward and “as of” (historically), thus

providing blended return recalculations. • Provide the facility to create blends from a mix of currencies. • Facility to apply supplied index weights or manually entered fixed weights. • Provide the capability to re-base to 100%. Drift • Provide the facility to drift manually entered benchmark weights on a daily basis. • Provide the ability to drift either using the Price return or the Total return. Controls & Audit

• Ability to manually override all indices, benchmarks, blends etc.


Excerpt From a Poor Requirements Document (continued)

Rewriting one requirement

• Provide the ability to review and manually enter index level and/or instruments level data. This single requirement is really four separate requirements, with a large amount of information missing. If we separate out the capabilities that are requested into individual requirements, it is easier to spot the missing information:

The user <subject> shall be able to review index level data <capability> within <criterion>. The user <subject> shall be able to enter index level data <capability> within <criterion>. The user <subject> shall be able to review instruments level data <capability> within<criterion>. The user <subject> shall be able to enter instruments level data <capability> within<criterion>.

In no case is the user role identified; this will make it difficult for readers who are skimming the document looking for “their” requirements. The capabilities are all present, but in the original requirement they are not separate, meaning that the requirement is not verifiable and testable by IEEE standards. No criteria are specified, meaning that it is likely that the finished software will be either over-engineered or under-engineered from the point of view of the user. Here’s what a further rewrite might produce:

Stock market traders shall be able to review index level data within thirty seconds of initiating an enquiry.

Not perfect—we don’t have the industry knowledge to do a perfect job—but it is now easy to identify who the main actor is, what they want to do, and what is a reasonable time to expect them to be able to do it in. Users will find it easier to locate and comment on their requirements, and downstream in the development process the people responsible for producing the software will have a clearer concept of what is being asked of them.


Excerpt From a Poor Requirements Document

(continued) Other issues Bullets and numbering There are some other issues with the document that are worth commenting on. Why are the requirements a long list of bulleted points? Bullets are used to indicate that information is part of a series, not just a collection of stuff that belongs together. Most people can only remember seven plus or minus two pieces of information at a time, so there is nothing to be gained from formatting these requirements in this way. It would be better to number these requirements, so that we had a consistent cross-reference for them in this and other project documentation. Text formatting Some of the text is bolded and italicized, some of it underlined, but nowhere in the document is it indicated why this is done. These might be references to a glossary or some other cross-reference, but how are we to know? Headings Ideally, headings should relate to questions the users are likely to ask about the project. So “Import and Store Indices” can be made more useful by adding what you import and store indices for. For example: “Import and Store Indices to Assess Stock ROI.” Or even better (because assessing the return on investment of a stock is probably what interests the reader): “Assessing Stock ROI by Importing and Storing Indices.” Fonts and layout The body text in the requirements document is Times New Roman 12 pt. This is fine, but it’s worth knowing that Arial at 12 pt (which is what you are reading now) will appear about 20 percent larger, but takes up little more space. How old is your average reader? Remember what is legible at 30 is unreadable at 50 for many people. If you want readers to be able to differentiate between heading levels, there needs to be approximately 30 percent size difference between levels. You should strive to use only four levels of headings, and in practice this means that your Level 1 heading needs to be around 28 pt if you want your Level 4 heading to be appropriate. The heading levels in the business case template in this course are about right for most readers.

The document also looks very dense: more white space will work to make it more scannable by your readers. Introducing a numbering scheme and indenting each level of it will both add white space and give a clear indication of what information belongs together.


Excerpt From a Better Requirements Document

Document Conventions The following conventions are used in this document:

This icon indicates a tip—extra information that will make your life easier.

This icon indicates a warning—something you must or must not do.

This icon indicates a note—something that will happen in specific circumstances, and may be unexpected.

Example icon with monospaced text—indicates examples that you can modify to achieve quick results.

Italicizing of words such as vestibule indicates that there is a Glossary entry for the term.

Specific User Requirements Entering the Book Depot

2.1.1. The book depot customer shall be able to enter the Book Depot within one minute of arrival at the outside door of the vestibule.

2.1.1.1. The book depot customer shall enter the vestibule using an Access Card to be provided by TBI (see “Obtaining an Access Card”). 2.1.1.2. Upon the customer entering the vestibule, the outside door of the vestibule shall close. 2.1.1.3. When the outside door of the vestibule is closed, the inside door of the vestibule shall open and the customer can enter the Book Depot. 2.1.1.4. While in the vestibule, the Book Depot customer shall be able to exit the vestibule through the outside door using their TBI Access Card. In this eventuality:

2.1.1.4.1 The inside door shall close. 2.1.1.4.2 The outside door shall open. 2.1.1.4.3 The Book depot customer shall be able to exit the vestibule.


Excerpt From a Better Requirements Document (continued)

2.1.1.4.4 What happens next??? If they open the outside door and stay in the vestibule, do they have to exit or do we provide another option on the vestibule card machine? TBD.

Glossary of Terms The Book Depot The operation of TBI store locations between the hours of 9:00 p.m. and 9:00 a.m.

Inside Door The automatic door that opens onto the book depot on one side and the vestibule on the other.

Outside Door The automatic door that opens onto the street on one side and the vestibule on the other.

TBI Taylor Booksellers Incorporated.

Vestibule The book depot entry system comprises two automatic doors with a space between them. One door opens onto the street outside the book depot (this is defined as the outside door), the other opens onto the book depot itself (this is defined as the inside door). The area between these two doors is defined as the vestibule.


Requirements Traceability Matrix

(If you would like a modifiable version of this document, please contact DoTS Project Mgmt at 303-764-3570)

Requirements traceability matrix

User requirements (List the title or number of the user functional requirements)

System requirements (When applicable, list the title or number title of the corresponding system requirement)

Design specification (When applicable, list any specifications that must be satisfied by the design)

Coding component reference (When applicable, code units, subroutines, or modules that implement the requirement)

Integration or system test case reference (Include number of the test script for the requirement)

Copyright by Ellen Gottesdiener, 2002 www.ebgconsulting.com 1 Practitioner assets for Requirements by Collaboration, by Ellen Gottesdiener, Addison-Wesley, 2002

Permission is granted to use, modify and distribute this document

Ways to Elicit Workshop Ground Rules

Reference Chapter 6 in Requirements by Collaboration by Ellen Gottesdiener, Addison-Wesley, 2002.

If you have drafted a list of ground rules before the workshop, you should consider them “working,” or draft, ground rules. Provide time early in your workshop—during the opening—for participants to consider what ground rules they need. Here are some ways to introduce, verify, and adjust ground rules for your requirements workshop. Before the Workshop • Ask participants to send you a list of potential ground rules. • Ask participants to name ground rules during your pre-workshop interviews. • Work with your planning team to devise a draft list of ground rules. • Include a list of proposed ground rules in the agenda that is sent to participants before

the workshop. • Post the proposed ground rules on a wall in the workshop room. During the Workshop • Review the proposed ground rules during the workshop opening activities. Ask for

any modifications to the list. • Have dyads (groups of two people) or triads (groups of three people) list proposed

ground rules as your opener activity. Then share each group’s list in a plenary (whole group) discussion; clarify, combine, and document a final list that everyone agrees to.

• Ask small groups or the whole group (if the group is seven or fewer people), “What could get in the way of achieving our outcomes today?” Facilitate a discussion and then ask, “What ground rules—specific guidelines for our behavior—can we name that will help to remind us about the key points in our discussion?” List each rule on a wall poster.

• Ask dyads or triads to list “anti” ground rules—ones that will result in a miserable, time-wasting session. Share them in a plenary discussion, and then solicit “pro” ground rules. List these on a wall poster.

• Ask participants to recall a time in their lives when they were on a “really great team” (any group situation—work-related or not). Ask them to recall how they behaved as a group. Form dyads or triads to share these experiences. Next, ask dyads to suggest ground rules that can promote that same kind of experience in the workshop. In a plenary discussion, list them and check for agreement on them.

• Several hours into the workshop, pause to check how the ground rules are working. Ask questions to test whether the ground rules are being adhered to and whether they are necessary, valid, and useful. Adjust them as needed.

• Conduct regular check-ins of your ground rules. If the group will be reconvening for multiple workshops, use a check-in ritual to revise and adjust the ground rules.

Copyright by Ellen Gottesdiener, 2002 www.ebgconsulting.com 2 Practitioner assets for Requirements by Collaboration, by Ellen Gottesdiener, Addison-Wesley, 2002

Permission is granted to use, modify and distribute this document

After the Workshop • Facilitate a debriefing discussion on how the group interacted, including questions

about the ground rules. • Ask participants to think, in retrospect, what ground rules they would add, modify, or

remove. • If this is one in a series of workshops, ask participants to name which ground rules

they want to use next time.