Вы находитесь на странице: 1из 37

Core Deliverable Lifecycle Training

© 2017 IBM Corporation


Objectives

 Understand the Deliverable Lifecycle


 Understand the roles of the deliverable’s Author, Reporting Team and IntQAC
 Understand DG TAXUD’s expectations of the deliverable quality

2 © 2017 IBM Corporation


Agenda

 Project Overview
 Deliverable Lifecycle Description and Importance
 Stakeholders in Deliverable Lifecycle Process
 Presentation of the Deliverable Lifecycle
 Roles and Responsibilities in the Deliverable Lifecycle
 Checklist to be used in Document Creation
 Useful Tools

3 © 2017 IBM Corporation


Project Overview 1/2

What is DG TAXUD?
DG TAXUD = Directorate General Taxations and Customs Union
DG TAXUD contributes to:
Internal market - allowing people, goods, services and capital to move more freely;
Digital single market - tearing down regulatory walls and moving from 28 national markets to a single
one;
Economic and monetary union - completing the economic and monetary union.

DG TAXUD IBM GBS Belgium CIC GBS Romania


GTS Poland

Demand

Commercial IBM Internal


End contract Agreement IBM CIC CEE Europa
IBM GBS (internal
customer Internal contract Delivery Center
Commercial customer/country IBM entity)
contract DoU
SoW

4 © 2017 IBM Corporation


Project Overview 2/2

What is ITSM3?
ITSM3 is formed of several contractors delivering IT services to DG TAXUD.

ITSM3 is organized in 3 lots:

 Operations (OPS): IBM (PL,BE,RO) & Symfoni (BE) - Systems Operations;

 Trans-European Systems (TES): external (business monitoring & trans-european systems


communication) integration - Intrasoft (GR);

 Integration (INT): internal integration & control.

© 2017 IBM Corporation


Deliverable Lifecycle Description & Importance

 This project is a deliverable based project, which means that the documentation that ITSM3 OPS delivers is
as important as the actual product! However you are involved in the deliverable lifecycle process, your
contribution is very important!
 It is the customer’s request to have a formal review deliverable lifecycle so that all stakeholders are involved
and agree with the content of the deliverable, thus ensuring its highest quality. The deliverable review cycle
contributes to the acceptance of ITSM3 OPS’s services.
 The quality of the deliverables creates a certain level of trust at the client.
 Low quality of those work products may impact:
– Quality of IT systems, projects and decisions;
– The SQIs and GQI: the timeliness of submission (4 SQI’s are applicable) and quality of the documents
produced (1 SQI);

Low quality of deliverables may lead to financial impact!

6 © 2017 IBM Corporation


Stakeholders in Deliverable Lifecycle process

 Author: IBM practitioner, owner of the deliverable;


 Contributor: Internal function or external group that provides input for the deliverable
(e.g. Deployment team, CCN2-DEV, CUST-DEV3, etc.);
 Internal Quality Assurance and Control (IntQAC): Internal function that offers support
and performs the deliverable check before the official review cycle;
 Reporting team: Internal function responsible for assuring communication between the
external reviewers and the author;
 External reviewer: External groups that perform the deliverable checks during the
official review cycle. (e.g. Quality Assurance Contractor (QAC), DG TAXUD, etc.);
 Chef de file (CdF): DG TAXUD representative, entitled to accept/reject/delay the
deliverable.

7 © 2017 IBM Corporation


Presentation of the Deliverable Lifecycle - Legend

T0

Responsibilities across the review cycle:

o Author - The author is responsible for performing these activities;


o Internal QA – The Internal Quality assurance representative is responsible for performing this activity;
o External parties (DG TAXUD/ QAC) – External parties are responsible for performing these activities.

8 © 2017 IBM Corporation


Presentation of the Deliverable Lifecycle

T0

 Deliverable Planning: Deliverable planning is a activity as it defines the scope, purpose and quality
expectations for the document deliverable. This phase therefore sets the scene for all following
activities in the deliverable lifecycle. This phase is part of T0.

 Deliverable Creation: All the steps identified in the Deliverable Creation phase are highly
recommended, as they minimise the risk of a deliverable being rejected later during the Deliverable
Acceptance phase. This phase is part of T0.

 Deliverable Acceptance: The review of documents, based on the T1/T2/T3 cycle, is a best practice
method in DG TAXUD and is applicable to all types of documents.

9 © 2017 IBM Corporation


Presentation of the Deliverable Lifecycle - Terminology

T0

 SfI: Submitted for Information


 SfR: Submitted for Review
 CCO: Consolidated Comments
 APO: Author’s Position
 SfA: Submitted for Acceptance
 IVE: Implementation Verification
 ACC: Acceptance
 T0, T1, T2, T3: Time period of each deliverable lifecycle phase

10 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Planning

T0

 It is strongly recommended to identify the stakeholders/reviewers of the deliverable at the time of


deliverable planning to ensure that their expectations are captured early in the deliverable lifecycle and
that commitment on their involvement in deliverable creation can be obtained. This avoids that during
the review the deliverable is checked against other expectations than those that were expressed during
the planning and creation phase.

 The actions performed on this phase depend on the type of deliverable.

11 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation

T0
Kick-off
It is a best practice for the author to prepare for the kick-off meeting and present his understanding at the meeting of
the above information in the form of a problem statement.
Responsible: Author
Other roles: CdF, Reviewers
The purpose of the kick-off meeting is to allow the author to clarify and confirm:
 What: scope and needs of the deliverable(s);
 Who: the final list of reviewers and contributors;
 When: deadlines for SfI, SfR, SfA;
 Define the approach in order to have the deliverable(s) accepted.

12 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation

T0
Build
The author starts building the deliverable. During this stage he/she collects information and organises interviews when
required. It is recommended that the authors clarify any uncertainties with IntQAC, early in the building activity.
Responsible: Author
Other roles: Contributors, IntQAC, Reviewers
It is good practice to invite the reviewers of the deliverable to the preparatory meetings and/or workshops that are held
during the build phase of the deliverable. This allows the reviewers to understand the expectations and agreements on
the deliverable. Specifically, the QA Contractor can be invited to these preparatory meetings to prepare their review of
the deliverable.
Recommendation:
When dealing with external contributors, such as Member States, it is important to ensure that sufficient time is foreseen to collect all
material. This is particularly true for documents concerning new subjects (new applications, functionality, etc). Some time will be spent
on analysing the existing documentation and consolidating the comments collected before creating the initial draft.

13 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation

T0
SfI & Pre-review (1)
When the document is around 80% complete, the draft should be sent for information (SfI) to all reviewers, to provide
them with an initial feeling of the content of the document. Although this step is optional, it is highly recommended.
Responsible: Author, Reviewers
 Experience shows that the effort required for the review of SfI versions of the document is often not anticipated and
feedback is not always obtained. Therefore it is highly recommended to communicate the planning of the SfI
versions well in advance and to obtain commitment of the stakeholders on the review of this version.
The pre-review should be planned so that:
 all readers can assess the content of the document;
 the author has time to complete and correct the document before the official review cycle.

14 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation

T0
SfI & Pre-review (2)
After the author implements the comments from the reviewers, the author should send the document to IntQAC for the
final internal review.
Responsible: Author, IntQAC
This step is mandatory before the document is submitted on the official review cycle.
The author must allocate enough time for the review of the deliverable as well as for implementing any proposed
changes.
It may be useful to plan several pre-reviews (SfIs at reviewers & IntQAC), especially when the document needs to be
reviewed by many people and may be subject to discussions.

15 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation – Pre-Review
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

16 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation

T0

Submitted for Review


The author sends the document to Reporting Team in order to be uploaded on CIRCABC and to start the review cycle.
Responsible: Author
Other roles: Reporting
The following information needs to be communicated by the author:
 The deliverable itself;
 Identification of the deliverable (document Title, document reference and deliverable type);
 Review planning (T1/T2/T3);
 List of reviewers.

17 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation – SfR submission
*The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

** In these examples, IntQA acted as an Author when it came to the submission and receival of the document. This is an exception made for FQP procedures.

18 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Creation – SfR acknowledgement from QA3

19 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Acceptance

T0
T1/T2/T3 Review cycle
T1= SfR date CCO date
- Review period (T1): EXTERNAL reviewers provide their consolidated comments on the SfR deliverable. A CCO excel file is received from
Reporting Team.
T2= CCO date SfA date (agreement on APO is included)
- Implementation period (T2): the author provides his position by sending the APO excel file to Reporting Team; APO is agreed by the
EXTERNAL reviewers and only after this the agreed changes are implemented into the SfR deliverable. APO not agreed implies APO2.
Several APOs may be exchanged until final agreement is obtained.
 * A review meeting may be required for discussing & agreeing specific comments that were not agreed through APO (MDE in the xls file).
If major changes on the SfR deliverable are necessary, an intermediary version of the deliverable may be sent along with APO.
T3= SfA date ACC date
- Verification period (T3): the quality contractor (QAC) performs the implementation verification of the comments (which leads to IVE OK/
NOK) and sends the acknowledgment letter at the request of the CdF (ACC). All IVE NOK should be discussed and explained further to
CdF, after consulting IntQAC.

20 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Acceptance

T0

Review (T1)
The review of documents, based on the T1/T2/T3 cycle, is a best practice method in DG TAXUD and is applicable to
all types of documents.
Responsible: QAC, Reviewers
Other roles: Reporting team
Deliverables that enter the T1 Phase of Deliverable Acceptance are expected to have passed internal Quality Control
and to be of high quality. The review cycle is not intended for major rework of the deliverable. Significant quality
concerns will result in SfR rejection and will cause substantial delays which will have a contractual impact but will also
impact the project.
The Review Coordinator dispatches review tasks to the reviewers. The Review is done according to pre-defined
criteria and the output is a consolidated set of review comments which are sent to the author at the end of T1 (CCO).

21 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Review – CCO receival
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

22 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Acceptance

T0

Implementation T2 - APO
During this period, the author first provides the Author Position (APO) for the comments received. The reviewers
assess the Authors Position and confirm their agreement with the proposed implementation or inform the Author about
their objections.
Responsible: Author
Other roles: Reporting team, Reviewers
Several APOs may be submitted before an agreement is reached. If some comments need to be discussed in detail, a
review meeting could be organised. The author needs to make sure that the proposed implementation is possible and
it is very clearly stated. The author could request input from other groups too.
Recommendation:
Preparing the APO is very important and could mean the difference between having the deliverable accepted or receiving a request for
re-SfA with financial implications.

23 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Implementation – APO submission
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

24 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Implementation – Reply to APO1 – Submission of APO2
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

25 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Implementation – Agreement of APO2 – Request for SfA
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

26 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Acceptance

T0
Implementation T2 - SfA
During this period, the author must implement the agreed APO in the deliverable and prepare it for acceptance
submission.
Responsible: Author
Other roles: Reporting team, Reviewers
All SfA deliverables must also pass through IntQAC for a review before they are officially submitted.
Between the SfR and SfA versions, the only changes that can be made are the ones in line with the agreed
implementation of review comments. Other changes to the document will be considered as “unauthorized changes”
and may result in SfA rejection.
Submitting the SfA version of the deliverable without recorded agreement on the required implementation exposes the
author to the risk of rejection of the SfA version during T3.
The implementation phase contains both the APO acceptance and SfA submission.

27 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Implementation – SfA verification by IntQA
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

28 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Implementation – SfA submission
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

29 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Acceptance

T0

SfA & Verification & ACC


The final version of the document was submitted and QAC performs the implementation verification (IVE) of the
implementation of the comments. CdF will request the closure of the review cycle if the IVE is OK.
Responsible: QAC, CdF
Other roles: Reporting team.
It should be noted that the rejection of the SfA can only be done by the Chef de File. The implementation verification
done by the QA contractor is the input for this decision. Chef de file takes their input into considerations and send
Acceptance or requests Re-SfA or SfI, as he considers necessary.

However, in most cases, the CdF does not respond to IVE NOK. In case on an IVE NOK, it is the Author’s responsibility
to request to submit a SfI version of the document with the implemented comments. (for minor comments)

30 © 2017 IBM Corporation


Deliverable Lifecycle – Deliverable Acceptance – Verification and Acceptance
* The examples provided are on ITSM2. The mail addresses, people, file name convention, etc. may differ on ITSM3. The examples can, however be trusted.

31 DG TAXUD - ITSM2 IBM Confidential © 2017 IBM Corporation


Deliverable Lifecycle – Rejection of a Deliverable
 A deliverable submitted for review (SfR) may be rejected at any point during its review (T1 period) if:
- it is out of scope;
- it is of low quality (including spelling or grammar errors);
- an abnormally high number of comments is being produced.

 If a deliverable is rejected during its review, the review process is stopped. The deliverable returns to the creation phase and a new
T1/T2/T3 review cycle is defined (new SfR date and new SfA date).

 A deliverable submitted for acceptance (SfA) may be rejected at any point during its verification (T3 period) if:
- the review comments have not been implemented;
- the review comments have not been implemented in a correct or consistent manner throughout the document;
- other changes have been made to the document without prior agreement by DG TAXUD and without being reported in the
implementation information of a relevant review comment in the review database.

*DG TAXUD reserves the right to decide whether the non-implementation or inconsistent implementation of review comments, or the other changes to the document, are of
major importance or not, and therefore the document deserves to be rejected or not.

*If a deliverable is rejected during its verification, the verification process is stopped. This generally implies that only a new SfA date is agreed (new T2 and T3 periods)
rather than a new SfR date and a complete new T1/T2/T3 review cycle, based on DG TAXUD's judgement.

32 © 2017 IBM Corporation


Additional Information

© 2017 IBM Corporation


Roles and Responsibilities during the Review Cycle in ITSM3 OPS
Author:
The author is the owner of the deliverable from beginning to end. It is the author’s responsibility to have a
qualitative deliverable at the end of the lifecycle. The author drives the T0 and T2 phases of the
deliverable lifecycle.

IntQAC:
IntQAC acts as “guide keeper” and provides assistance to authors in the lifecycle of deliverables. IntQAC
can provide templates and guidance for document creation as well as review the deliverable internally,
before submitting it on the official review cycle (SfR & SfA).

Reporting team:
Reporting team will provide any information regarding the review cycle and will act as communications
intermediary between the author and the reviewers during T1/T2/T3.

34 © 2017 IBM Corporation


Checklist to be used in Document Creation

35 © 2017 IBM Corporation


Useful Tools

TEMPO Newcomers’ Corner: https://webgate.ec.europa.eu/fpfis/wikis/display/TEMPO/Newcomers%27+corner


TEMPO: https://webgate.ec.europa.eu/fpfis/wikis/display/TEMPO/TEMPO+Home
WIKI:
https://webgate.ec.europa.eu/fpfis/wikis/display/TAXUDITOI/TAXUD+IT+Operational+Implementation+Home
CIRCABC: https://circabc.europa.eu/faces/jsp/extension/wai/navigation/container.jsp
RAM: https://ram.itsmtaxud.eu:9443/ram/home.faces
IPWC: https://w3-01.ibm.com/software/ipwc/pmeu/documents.do

36 © 2017 IBM Corporation


Questions?

© 2017 IBM Corporation

Вам также может понравиться