Training On Project Deliverables and RACI: April 2019

.consulting .solutions .
partnership
Training on Project Deliverables and RACI

April 2019
Agenda
1 Definitions
2 Inter-dependencies among deliverables
3 Deliverable life cycle
4 Templates
5 Examples of Deliverables
For each slide see details in Text Notes area
Interested in templates only? Go to section #4
© msg global solutions | April 2019 | Training on Project Deliverables and RACI 2
Definitions
Deliverable (Webster)
• Deliverable (Webster dictionary)

- Capable of being, or about to be, delivered; necessary to be delivered
• Deliverable (WordNet)
- Noun: Something that can be provided as the product of development; "under this contract the
deliverables include both software and hardware“
- Adjective: Suitable for or ready for delivery
Source: http://www.webster-dictionary.org/definition/Deliverable (31-May-2018)
• Note:
- Necessary to be delivered  by a contract or other binding agreement
- Can be provided / Ready for delivery  Capability, readiness, -able
Definitions
Deliverable appears 275 times in the PMBOK 5th edition
Deliverable  Any unique and verifiable product, results or capability to perform a

service that is required to be produced to complete a process, phase or project
• As part of a unique project
- Although repetitive elements may be present in some project deliverables and activities, this
repetition does not change the fundamental, unique characteristics of the project work.
- Deliverables and knowledge are transferred between the project and the operations
- The sponsor ensures a smooth transfer of the project’s deliverables into the business of the
requesting organization after project closure
• Measuring project success
- Project success and deliverable acceptance criteria
• Project phases
- The phases can be down by functional or partial objectives, intermediate results or
deliverables, specific milestones within the overall scope of work
- Project phases […] are typically linked to the development of a specific major deliverable
• Others
- In a predictive life-cycle, the product and the deliverables are defined at the beginning…
Agenda
1 Definitions
4 Templates
Inter-dependencies among Deliverables
SAP Project phases
ASAP Methodology
Project Business Final Go-Live &

Realization
Preparation Blueprint Preparation Support
SAP ACTIVATE
Discover Prepare Explore Realize Deploy Run
From Specs to Development to Test to Approval
TEST
Specifications WRICEF’s
OK?
• WRICEF’s are developed against approved specifications

• Test-cases acceptance criteria are based on approved specifications
• Test ok  Acceptance Test not ok  Go back to development
• Write good specifications and get them approved !
Infrastructure
Demo, prototyping
Infrastructure Training
Infrastructure
requirements
in place
Configuration
WRICEF’s
…
• You need the infrastructure early in the project (Blueprint, Training)
• Do not overlook the lead time to get the infrastructure in place

- Inform the customer as early as possible, even before project start
• Infrastructure requirements do not address performance, that will come later
Back to the beginning: The SoW
Statement of
All project
Work
deliverables
• The Statement of Work is a contractual document, not strictly a project deliverable

- Although it is sometimes finalized / refined during the Project Preparation (e.g. in T&M)
• On the other hand
- Agreed by all parties
- Includes list and definition of all project deliverables in scope
Agenda
1 Definitions
4 Templates
Deliverable Life Cycle
Life cycle framework for project deliverables
Define & plan

Assign roles
Scope of the
project (what) Performance Perform
Schedule Track
Approval Do it !
(when)
RACI table Test / Accept Log since the
Responsibility beginning
(Who)
Define & Plan
• What  Scope of the project

- Project deliverables defined in the Statement of Work or other contractual document
- Clear unambiguous definition of what is expected to be delivered and acceptance criteria
• When  Schedule
- When the deliverables is expected to be delivered
- One time deliverable Vs iterative deliverable
- Inter-dependency between deliverables
• Who  Responsibility
- Which contractual party is responsible for delivery
- Implication on budget
- Only high level assignment
• “What”, “When” and “Who” usually defined at the same time
- Some time “when” defined before the “what”, and finally the “who”
- Iterations between the three
Assign Roles
• Level of responsibility
- High level: contractual party (Define & Plan)
- Medium level: organizational role (User Vs IT, functional Vs technical, skills)
- Low level: name
- Medium & Low may collapse into one for small teams
• RACI table focuses on medium level
Responsible Who does the work One only

Accountable Who is ultimately accountable and approves One only
Consulted Whose opinions are sought, as SME None to many
Informed Who is kept up to date Many
RACI table recommendations
• RACI table should be prepared at project start, optionally included in the SoW
• One Responsible only

- One person only to report progress
- Possibility to assign parts of one deliverable to others
• Different from “Consulted” below
• Still one responsible only, otherwise split into more deliverables
• One Accountable only
- One person to approve, within the approval timeframe
- Not referring to higher management for approval
• Consulted people optionally involved
- Support, not responsibility
• Informed
- Stakeholders, besides the Accountable and Consulted roles
Quality Review
• One more required, besides RACI

- Role Internal to responsible party, in order to ensure quality, sometime a Consulted SME
- Reviewer(s) different from Responsible
- Optional additional early review by customer to save feedback time
Prepare
Responsible Develop Submit
Amend
Fix
Review draft Review

Reviewer Unit Test Unit Test
No
Feed back Ok
Accountable Approved
Test ?
Yes
Consulted Support
Track Status
• Unique Identification
- Project deliverable ID, Deliverable Name
• Status
- In process, Drafted, Reviewed, Submitted, Accepted, Rejected, Removed (with a CR)
- Deliverables not requiring acceptance are Shared
• Roles
- Responsible, Reviewer(s), Approver
• See RACI, one Responsible only and one Approver only
• Dates
- When: drafted, reviewed, submitted, feedback, approved/rejected
• See templates later
Agenda
1 Definitions
4 Templates
5 Examples o Deliverables
Templates
Available templates in GURU
• Project Deliverable Status

- Table to log and monitor the status of the project deliverables
• Deliverable Acceptance Document

- To formally document the acceptance of a project deliverable or a project phase
• RACI Matrix
• Other template (not addresses in this PPT deck)

- Statement of Work, includes the list of all project deliverables
- See a separate training material in GURU
Templates
Deliverable Status – Fields (1/2)
Field Notes and Guidelines

ID This is automatically computed from the line of the table with 3 digits.
Project ID ID of the deliverable as per project list.
Use ID.x for versioning.
Phase Phase of the project
Deliverable Name of deliverable (e.g. title of a document)
name
Status Use a limited set of options.
Examples: In progress, in Review, Submitted, Superseded, Accepted,
etc.
Responsible The person in charge of preparing the deliverable
Reviewers The person or persons who will review / unit test the deliverable
Acceptance by The unique person who will be accepting / rejecting the deliverable
Templates
Deliverable Status – Fields (2/2)
Field Notes and Guidelines

Date prepared Date when the deliverable has been prepared and is ready for review /
unit test
Date reviewed Date when the deliverable has been reviewed / unit tested
(this date might or might not be shared with the customer)
Date submitted Date when the deliverable is submitted to the customer
Date feedback Date when a feedback is provided on the deliverable, not necessarily
as acceptance or rejection. This might trigger a new version of the
deliverable.
Acc / Rej date Date when the deliverable is finally accepted or rejected.
Note: some deliverable might not require acceptance.
Reason for List of main reasons for rejection. Details can be provided separately
rejection (see the Acceptance document)
Notes Additional info (avoid writing novels here).
Templates
Versioning
• New versions of a deliverable should be uniquely identified

- The name stays the same
- Table ID is automatically generated
- The version is reflected into the Project ID number (manually set)
• First version of the deliverable: 1.0
- Project ID Number in the table: N.1 or N.1.0
• New versions are 1.x, X.0 or else
- Project ID Number in the table: N.1.x, N.X.0, etc.
• For each new version

- Set the status of the previous deliverable as “Superseded”
• The related dates are kept as log
- Add a new row behind the last version and assign the Project ID
• Ignore the renumbering of the Table ID
- Copy the names for various roles
• In some infrequent cases they might be different from previous version
Templates
Acceptance Document template
Can be used for

acceptance of a
deliverable or of a
project phase
R in RACI
A in RACI
Templates
Acceptance Document template
Any of this can be

used, potentially all
if the document logs
past feedback
Conditional Acceptance: We can

proceed with next activity or
phase, but there are minor
defects/errors to fix
Templates
RACI Matrix
Customize
roles
Preset choices as
WRICEF.
Change validations
as appropriately
Data Validations:
R, A, C, I
In any row: Use only

one R and one A
Agenda
1 Definitions
4 Templates
Examples of Deliverables
Infrastructure
msg responsible for

Customer Infrastructure
Customer No
able to
premises
manage
Where Installed at Infrastr ?
the customer
Infrastr.? Yes Customer responsible for
Infrastructure
msg at Need remote Optional msg support
start, then connection
customer (initially)
Customer
Cloud /
able to Yes
outsourcing Need remote Customer responsible
install
connection for SAP SW
SAP
SW ?
No msg responsible for
Supplier support in Fixed Price projects ? SAP SW
Add assumption on max effort and rules of

Yes, but support Customer responsible for SAP SW
engagement
needed msg support
Data Migration
Provide ROM for support

Define baseline effort after BBP
Automated Large
Manage as T&M without Cap
loading
Customer to
Customer Medium
Migration extract, enrich Provide ROM for support
needs
in scope? & cleanse Manage as T&M with Cap
support ?
Automated
& manual
Low or limited Generic support
loading Customer to Manage as T&M
manually load
Yes Customer responsible for functional verification

Manual Loading Optional msg support as T&M
No msg
deliverable Customer
performs
No Migration functional
verific ?
Some/
Large (If Large) Add msg support as activity
No deliverables for support Manage Support as T&M without Cap
Migration
Optional msg
support
No
msg support in Fixed Price projects ? Msg responsible for functional verification
Assumptions on number of load cycles
Add assumption on max effort and rules
of engagement
Interfaces
Customer to develop inbound Interfaces

No or limited msg support
Yes
Interfaces
Customer
in scope?
Yes able to
Customer to develop inbound Interfaces
dev
msg Support as T&M
inbound ?
Interfaces Some/ Large (if Large) Add msg support as activity
No Requirements in BBP support
No
msg to develop inbound and
other interfaces
No Interfaces Requirements in BBP

No Interface development in Realization
msg usually in charge of outbound interfaces
Test Cases and Performance Test
Yes
msg to support Test execution, with boundaries
Customer responsible for test cases
Optional msg support as T&M
Customer
able to
prepare Customer responsible for test cases msg responsible for Performance Test
TC’s? Some msg support as T&M Assumption to limit expectations
No support
Yes
Large
support
Add msg activity as optional
Performa to be requested as CR
nce Test Optionally
Add test cases support as activity required
?
No
msg responsible for test cases preparation Assumption: Performance Test is out of scope
Assumption on max number and complexity
Training in later stages
Training activities, without tangible

Yes msg responsible for Refresher training deliverables subject to acceptance
Assumption on duration
Refresher
Training
Optionally Customer responsible for Mass Training
before
UAT ? Yes Msg support as T&M (add estimates)
Refresher training to
be raised as CR
No
Mass Optionally Customer responsible for Mass Training
Training msg support raised a T&M CR
support ?
No
Assumption: Refresher Assumption: Customer fully responsible for
Training is out of scope Mass Training, no msg support needed
No Mass Training
required
Assumption: No Mass Training before Go-Live
Organizational Change Management
Yes, by customer Customer fully responsible for OCM activity

No need for msg to review any doc
Any OCM
activity ?
Yes, by customer,
None with msg support Customer responsible for OCM activity
msg support as T&M
Yes, by msg
Carefully estimate OCM activity and deliverables
Add as many assumptions as possible
Risk: Subjective acceptance criteria
Assumption: No OCM activity in scope
Post Go-Live support
Fixed duration Add activity in the project scope

Assumptions on duration, onsite / remote support,
staffing (when onsite), business hours, etc.
Post Go-
Live
support ? On demand
msg support as T&M or part of a new
contract after implementation
No
Assumption: Post Go-Live is out of scope, may be considered as
Change Request or as a new contract (e.g. AMS)
Sample: SAP-RI project
Project Business Realization Realization Realization Final Go-Live &

Preparation Blueprint (1/3) (2/3) (2/2) Preparation Support
• Infrastructure • Current • Workflows • Conversion – • Integration Test • Operating • Post Go-Live
Plan Business • Forms Extraction & Cases Manual Support
• DEV System Process • Reports Enrichment • User • User Manual • Handover to
Installation • Business • Interfaces – • Conversion – Acceptance • End User Support Team
• Blueprint Requirements Inbound Data Cleansing Test cases Training (Mass • Project Closure
Phase Plan • QA System • Interfaces – • Conversion – • Refresher Training) • Post
• Kick-off Installation Outbound Transformation Training • Cutover to Implementation
Meeting • Key User and • Enhancements & Load session Production Review /
System Admin Development • Conversion – • Integration Test • Approval to Lessons
Training Technical • User Go-Live Learned
• Test Strategy verification Acceptance
• Realization • Conversion - Test
Phase Plan Functional • Performance /
verification Stress Test
(high level) • Cutover Plan
• Conversion - • End-User
Functional Training
verification Strategy
(detailed) • PROD System
Installation
1. https://community.msg.de/site/mgs.Community-Project-Management/KMDocs/Methodologies%20and%20Templates/1.%20Project%20Initiation%20templates/
Statement%20of%20Work%20and%20Commercial%20Offer/Reinsurance%20templates/Project%20Deliverables%20for%20RI%20projects.zip
Marco Perezzani msg global solutions ag (Headquarters)
Project Management Community Leader Eichwatt 3, 8105 Regensdorf
Switzerland
Marco.Perezzani@msg-global.com
www.msg-global.com
.consulting .solutions .partnership

Training On Project Deliverables and RACI: April 2019

Uploaded by

Copyright:

Available Formats

Training On Project Deliverables and RACI: April 2019

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Training On Project Deliverables and RACI: April 2019

Uploaded by

Copyright:

Available Formats

.consulting .solutions .

Training on Project Deliverables and RACI

2 Inter-dependencies among deliverables

3 Deliverable life cycle

For each slide see details in Text Notes area

Interested in templates only? Go to section #4

• Deliverable (Webster dictionary)

Source: http://www.webster-dictionary.org/definition/Deliverable (31-May-2018)

Deliverable appears 275 times in the PMBOK 5th edition

Deliverable  Any unique and verifiable product, results or capability to perform a

2 Inter-dependencies among deliverables

3 Deliverable life cycle

SAP Project phases

Project Business Final Go-Live &

Discover Prepare Explore Realize Deploy Run

From Specs to Development to Test to Approval

• WRICEF’s are developed against approved specifications

• Write good specifications and get them approved !

• You need the infrastructure early in the project (Blueprint, Training)

• Do not overlook the lead time to get the infrastructure in place

Back to the beginning: The SoW

• The Statement of Work is a contractual document, not strictly a project deliverable

2 Inter-dependencies among deliverables

3 Deliverable life cycle

Life cycle framework for project deliverables

Define & plan

Define & Plan

• What  Scope of the project

• RACI table focuses on medium level

Responsible Who does the work One only

RACI table recommendations

• One Responsible only

• One more required, besides RACI

Review draft Review

• See templates later

2 Inter-dependencies among deliverables

3 Deliverable life cycle

Available templates in GURU

• Project Deliverable Status

• Deliverable Acceptance Document

• Other template (not addresses in this PPT deck)

Deliverable Status – Fields (1/2)

Field Notes and Guidelines

Deliverable Status – Fields (2/2)

Field Notes and Guidelines

• New versions of a deliverable should be uniquely identified

• For each new version

Acceptance Document template

Can be used for

Acceptance Document template

Any of this can be

Conditional Acceptance: We can

In any row: Use only

2 Inter-dependencies among deliverables

3 Deliverable life cycle

msg responsible for

Add assumption on max effort and rules of

Provide ROM for support

Yes Customer responsible for functional verification