Table of Content

Page 1 DRAFT

Table of Content

• Summary

• SW development process overview

• Flow of deliverables

• Process descriptions

• Deliverable description

• Roles descriptions

• Process models

• Operational processes

• Appendix A: Testing process and approach

• Appendix B: Quality assurance

• Appendix C: Test categories

• Appendix D: Test documentation

• Appendix E: Testing team

• Appendix F: Possible metrics to collect

• Appendix G: Service Level Agreements

• Appendix H: Capability Maturity Model

• Appendix I: Model cards

Summary

Page 3 DRAFT

Summary of impact of IT distribution on IT processes• SW Development and Support Processes

– Processes are described in details in process models and narrative part of this document.

• Software Configuration Management

– All project deliverables including intermediary releases must be placed in the central repository to be available everywhere in the distributed environment.

• Infrastructure Development

– Distribution of environment must be supported by a specific infrastructure:» central repository » remote user’s desktop» videoconferencing facilities» scanning facilities» electronic wall board» telephones

– All environments e.g. development, test or operation should be maintained only by IT operations.

• Metrics Management– Current informal and intuitive measurements based on common sense will disappear in distributed environment. Formal

measurement process should be installed.

• Reuse Management– Current informal reuse information sharing spread among people will not work anymore in distributed process environment,

therefore a formal process has to be introduced using the central repository of knowledge.

• Vendor Management

– The process is not affected by distribution, it must remain centralized.

• Risk Management– The risks related to distributed organization should be properly planned, assessed and mitigated.

Summary

Page 4 DRAFT

Summary of impact of IT distribution on IT processes (cont.)• Security Management

– Remote sites usually use to be less loyal an organized as people in headquarters. Distributed organization creates bigger IT security risk that should mitigated e.g., formal security policy and procedures should be in place.

• Quality Assurance– Quality Assurance features for projects are incorporated in new SW development processes and supported by new role of

Quality Assurance people.– Quality Assurance features for IT operations should covered by SLAs (for major applications at least).– New IT Support process has been designed, using the central Help Desk.

• Standards, architectures and tools administration– All tools and standards must stay unified, administrated centrally, while access will be distributed. Architecture should be

developed and maintained by group of architects responsible for particular groups of the system.

• IT operations management/administration– Major functions and services should be controlled by the mean of SLA.

– IT operation function will stay centralized, only operating staff will be distributed among sites.

• People Management and Training

– The people evaluation process will have to be more formalized (based on the Assess process). Nevertheless there will remain the HR soft issues, to be sensitively managed in distributed environment. The training process itself will not be affected by distribution, only the training planning will have to reflect more remote location.

• IT Function Management– Capability Maturity Model (CMM) is a method for continuous improvement of the IT organization.

– Distribution of the organization should be ideally justified with the risks related to each level of CMM. The higher level of CMM, the lower risk resulting from the distributed environment.

• IT functions planning– The process is not affected by distribution, it must remain centralized. Workflow distribution will come due as an additional

element of the planning process.

Summary

Page 5 DRAFT

Summarized features of the new SW development processes

• SW development process was formalized and broken down in several smaller processes

– Break down of processes can support their better distribution

– Follow-up of the procedures will increase quality and stimulate knowledge sharing

• New roles in IT were defined or some existing roles were redefined:

– Problem Manager– to take care about resolution of an assigned problem in SW support

– IT Project Office – to assure project infrastructure in IT

– Analyst Cleaner – to document applications developed in extreme mode

– Document Writer – to create SW manuals

– IT Tester, Test Designer – to perform SW testing

• New roles outside of IT were recommended:

– Project Manager from user side (PM user) – should assure that the process is moving ahead and all required resources from user departments are available at the right time.

– Project Office – First approves, that an effort should be invested to develop detailed project definition (Project Charter). In the second phase approves, that project can start. – Project Office should coordinate also smaller projects, if they concern more departments, have multiple sponsorship or are business critical projects.

– Regular IT vs. other department meeting (IT vs. dpt. Meeting) approves small projects in the same way as the Project Office does for big projects. It releases resources for project specification and project itself.

• Some process deliverables have either new or enhanced structure

• IT should maintain one shared repository that should be used by all teams. This repository should be able to store documents of all eventual types which should be later retrievable at any of RadioMobil’s location.

Summary

Page 6 DRAFT

Summary of changes in SW development processes

• Projects will start only after approval of their detailed definitions (Project Charter). Development of a Project Charter is now considered as a part of the pre-project phase, but as it requires participation of both parties i.e., users and IT personnel, it is also subject of approval (approval of Project Definition). This will improve the project planning and prevent from unmanageable exceeding of project scope. Note: Current Specification of Requirements activity will be split between creation of Project Charter and development of Business model in the modeling phase of the project.

• If project will divert more than by X% in later phases the project will be returned back to the initial phase by the means of the change management procedure an later even be redefined in a new project.

• The Extreme approach was defined for cases when standard approach is not applicable e.g., due to time constrains. This process will bring results sooner however it is still well managed and documented process. Consequently, it costs more resources than the standard approach.

• Separate Modeling process precedes the programming.

• Once programming activities are finished, generalization activities will start. Through the generalization the source code is optimized and cleansed to better support new upgrades and maintenance.

• All processes pay attention to utilization and creation of reusable fragments and also to creation of group memory and knowledge sharing.

• Testing procedures are more formalized. Testing process actually starts with definition of acceptance criteria already in the Project Charter.

• Pilot operation phase, which is to prove SW under live conditions, is a planned activity properly teamed up. Project is closed after pilot is successfully finished.

• All requests or problems are processed through the Help Desk in the Support process. More difficult problems are handed over to the Problem Manager, who is responsible resolution that takes longer time.

Summary

SW development process overview

Page 8 DRAFT

Principles for different types of the projects

• There are three types of projects:

– Standard - the recommended approach whenever it is possible.

– Extreme - for cases when standard approach is not applicable e.g., due to time constrains. This process mode will bring results sooner however it is still well managed and documented process. Consequently, it costs more resources than the standard approach. It is assumed, that not all projects will be treated in this way, and those ones, must be properly staffed.

– Tiny development - for very small development activities, when standard project administrative time would significantly exceed the development time. Typically such project should not exceed X mandays. This project does not require formal approvals.

• CIF receives all Requests for Support, consults the expected scope of potential projects with other IT teams and finally classifies projects in respective categories.

• Proceeding a project under Extreme approach is purely an IT internal decision (done by the IT meeting), however the involved risk must be reported. Both parties i.e., users and IT, must be able to release appropriate resources.

• Standard and Extreme projects have also another dimension - they can be either Big or Small (measured by their impact, size and complexity). If CIF classify the project to be a “Big” one, it should imply that a project manager from user side will be nominated.

Process Overview

Page 9 DRAFT

Process model structure for Initiate and Construct phases

ModelsModel content

• Gather initial requirements

• Cathegorize requirements

• Approve requirements

• Develop detailed

project charter

• Approve projects

• Develop and approve

Business model

• Develop and approve

Conceptual model

• Develop program code

• Generalize program code

• Perform system test

• Initiate documentation

Define management documents

Model

Program, generalize and

test

Tiny development

projects

Small,Big standard projects

Small,Big “Extreme” projects

Tiny projects

Init

iate

Co

ns

tru

ct

Define requirements

and justify

Program, generalize, test

and model - extr. projekt

Process Overview

Page 10 DRAFT

Process model structure Deliver and Support phases

ModelsModel content

• Develop all manuals

• Provide training

• Perform tests

• Release SW

• Prove SW under

real-life conditions

• Manage SW problems

during pilot

• Close project

• Evaluate project

• Record “lessons learned”

• Manage user problems

• Fix SW defects and

user problems

Pilot

Support

(Small, Big)

Standard / “Extreme” projects Tiny projects

Support in pilot

ModelProgram, generalize, test and model - extr. projekt

Tiny development projects

ModelProgram, generalize, test and model - extr. projekt

Deliver and test

(Small, Big)

Assess

De

liv

er

Su

pp

ort

Process Overview

Page 11 DRAFT

10 Features of Extreme Projects in Contrast with Standard ProjectsIn our approach, the concept of extreme project is inspired by the Kent Beck’s theory (www.xprogramming.org), but saves the sequential/waterfall development style in major development phases. From this viewpoint, our extreme project concept stays between the standard project concept and “pure” extreme programming style.

Extreme project is not an overloaded standard project, where is no time for deliverables other than code. Extreme project is well driven and follows its process map.

1

In extreme project, software is produced earlier, but there are also generated all other deliverables as those of standard project. (manuals, models, metrics, ...)

2

The privilege and responsibility for selecting the project as extreme or standard has IT and not customer. This decision must be done in initial phase of the project before project itself is started.

3

If the project is selected to be extreme, this information must be visible in PD (project definition) and PC (project charter) documents.

4

In extreme project, the user must be more involved in the development process. The user must be properly trained to be able toassist developers during construct phase. (Or IT must help users with this role)

5

In extreme projects, there are required exceptional skills from development team. Not every developer is suitable for this approach. As the consequence, all projects can not be Extreme.

6

Extreme project has more risk than standard project. (Because of higher dependency on development and user experts and technologies, for example)

7

Extreme project is more expensive than standard project. (Shorter software development time is not for free)8

Extreme project requires better quality management. Quality administrator needs strong assistance of programmer and analysis specialists, because each recognized problem must be immediately repaired.

9

The success of extreme project is dependent on well working technical infrastructure (shared repository, for example).10

Flow of deliverables

Page 13 DRAFT

Phases Initiate and Construct for standard projects

Phase Proj. mgmt. System

Deliverable type

Test Manuals

Define requirementsand justify


Model

Program, generalizeand test

RFSRFS

Project Definition

Approved PD

Project Charter

Approved PCH

BusinessModel

ConceptualModel

ProgramCode

UpdatedPCH

UpdatedPCH

Init

iate

Co

ns

tru

ct


Page 14 DRAFT

Phases Initiate and Construct for tiny projects


Deliverable type

Test Manuals



Model

Program, generalizeand test

RFSRFS

SmallProject Charter

UpdatedBusinessModel

Updated ConceptualModel

ProgramCode

BusinessModel

Conc.Model

Init

iate

Co

ns

tru

ct


Page 15 DRAFT

Phases Initiate and Construct for extreme projects


Deliverable type

Test Manuals


Program, generalize, test and model

RFSRFS

Project Definition

Approved PD

UpdatedPCH

BusinessModel

ConceptualModel

ProgramCode

SimpleProject Charter

Init

iate

Co

ns

tru

ct


Page 16 DRAFT

Phase Deliver


Deliverable type

Test Manuals

Deliver and test

Pilot

Assess

UpdatedPCH

Pro

gra

mC

od

e

User manual

Operationalmanual

Testscripts

Trainingmanual

Testresults

UpdatedPCH

Pilotresults

UpdatedPCH

Projectevaluation

Bu

s.M

od

el

Co

nc.

Mo

del

De

liv

er


Page 17 DRAFT

Phase Support


Deliverable type

Test Manuals

Support,Support in pilot

User problem

User problem

Trouble report

InternalRFS

Pro

gra

mC

od

e

Bu

s.M

od

el

Co

nc.

Mo

del

User manual

Operationalmanual

User problem

Su

pp

ort


Process descriptions

Page 19 DRAFT

Define requirements and justifyEntrance conditions checklist• vision for the project has been defined by user community

• appropriate maintenance changes for previous versions have been identified

To be performed checklist • user requests (RFS) have been documented, validated and prioritized

• technical requirements have been documented and validated

• operation and support requirements have been documented and validated

• reusable artifacts have been identified

• team roles were identified

• implementation alternatives were identified and considered, including decision about Extreme project approach

• economic feasibility of each alternative was determined

• cost/benefit analysis was performed

• risk assessment document has been developed

• alternatives were suggested to senior management (Project office/IT vs. dpt. Meeting) for approval

• senior management (Project office/IT vs. dpt. Meeting) approved or rejected project

• decisions (both made and forgone) were documented into group memory

• metrics have been collected

• in case of Extreme project approach the project Kick-off workshop was organized

Process description

Exit conditions checklist• requirement documents have been validated and accepted by the user

community and senior management (PD was approved)

• initial version of the project plan has been accepted by senior management and by the development team

• initial version of the risk assessment has been accepted by senior management

• feasible implementation alternative has been accepted by senior management

• group memory has been initiated

New process features, process issues• Project manager from user side (PM user) should have the primary

responsibility for requirements specification (creation of Project definition). He should assure, that process is moving ahead.

• For small projects, this role can be substituted by CIF.

• If CIF substitutes PM user in bigger projects, it creates significant risk, that should be evaluated.

• CIF can aggregate more RFS to one, but should ask for confirmation Project office or IT vs. department meeti ng.

• Only projects treated as Extreme projects, will start directly after this phase. All other projects will be in next phase evaluated in bigger detail.

• This process does not concerns urgent SW defect fixing. On the other hand, some impacts of this fixing can result in issuing internal RFS.

• Projects can also be initiated internally by IT. If this affects other RDM departments, a formal approval should be obtained from those departments, before project can start.

• About Extreme project approach must decide IT meeting, based on CIF recommendation.

Page 20 DRAFT

Define management documentsEntrance conditions checklist PD was approved by senior management

user community and IT department are committed to the project

access to key users, technical experts, and financial experts has been obtained

the project objectives have been identified and agreed to (in PD)

initial requirements have been defined (in PD)

development of the risk assessment has begun (in PD)

definition of the project infrastructure has begun (in PD)

development of the project plan has begun (in PD)

the feasibility study has been at least started (in PD)

To be performed checklist business process requirements have been documented and validated technical requirements have been documented and validated reusable artifacts have been identified build-versus-buy decisions have been made application release schedule has been defined or updated project estimate has been developed and accepted metrics plan has been developed and accepted project plan has been developed and accepted assumptions and constraints have been documented test plan has been developed and accepted implementation alternatives were identified and considered economic feasibility of each alternative was determined cost/benefit analysis was performed technical and operational feasibility of each alternative was determined alternatives were suggested to senior management for approval project team has been defined

Process description

skill assessment for each team member has been defined potential subcontractor/ vendors have been contracted project deliverables have been negotiated with senior management and

agreed to risk assessment document has been updated group memory has been organized decisions (both made and forgone) were documented into group memory metrics have been collected

Exit conditions checklist project plan has been accepted by senior management (PCH was

approved)

the scope of the project has been defined and accepted - definition of the functionality that will, and will not, be implemented

risk assessment document has been updated

the team has been accepted by senior management

New process features, process issues• Project Charter is developed and approved during this process, as the full

project description. If project will in later phases divert more than by X%, the change management procedure will return project back to initial phase to be redefined like new project.

• Project Charter is being updated during all phases of the SW development process.

• Significant user community involvement is required and should be assured, as the project has been already approved by senior management in previous phase.

• As project is assessed in bigger detail now, it could even happen, that it will not be finally approved, even if it was approved in previous phase.

Page 21 DRAFT

ModelEntrance conditions checklist project plan has been accepted by senior management (PCH was

approved)

the scope of the project has been defined and accepted (PCH was approved)

the team has been created and accepted

subject matter experts (expert user) have been scheduled

To be performed checklist business and conceptual models were assembled and validated

assumptions made during modeling were challenged and documented appropriately

manual processes, legacy applications, and new system development was identified and modeled accordingly

requirement allocation matrix was updated/developed

reusable artifacts have been identified and used

risk assessment document has been updated

decisions (both made and forgone) were documented into group memory

metrics have been collected

Process description

Exit conditions checklist business and conceptual models have been appropriately documented

and validated

test plan has been updated

business and conceptual models have been accepted by the team and by senior management

New process features, process issues• All requirement are already defined before project starts. Therefore the

purpose the modeling phase is not to specify requirements, but to transform them into business and than conceptual models.

• If requirements and project scope have to be changed anyway by more than X%, project should be redefined (in Initiate phase).

Page 22 DRAFT

Program, generalize and testEntrance conditions checklist appropriate business and conceptual models are available

project plan has been accepted by senior management (PCH)

the team has been created and accepted

To be performed checklist programmers worked with the designers to understand models

models were reviewed and walked through and accepted

(user interface prototypes were reviewed and tested)

source code was written and documented

source code was synchronized with models

code testing was performed (code was inspected)

integration plan was prepared

reusable artifacts have been used

potential reusable items have been identified

generalization sessions were held

potentially reusable items were refactored

reusable items were documented

examples of how to reuse reusable items were documented

reusable items were released into the repository and made accessible to all developers

test plan was updated appropriately

source code was inspected and improved before being tested

Process description

system testing was performed

defects were recorded and analyzed

risk assessment document has been updated decisions (both made and forgone) were documented into group

memory metrics have been collected

Exit conditions checklist source code has passed inspection

the source code works

the source code has been optimized

the application has been packaged for the delivery

generalized items have been submitted to the reuse repository

all developers have been made aware of new items

all items have been tested during system test, reviewed and updated accordingly

master test has been updated for “test in the large”

New process features, process issues• The process contains activities related to reuse. Reuse components

should be identified even before generalization.

• The purpose of generalization is to optimize and clean (already functional) source code. Generalized code should be easier to maintain and to release new versions.

• The user and software documentation has been started already in this phase.

Page 23 DRAFT

Program, generalize, test and model - Extreme projects Entrance conditions checklist IT meeting decided about application of Extreme project approach

PD was approved by senior management

user community and IT department are committed to the project

access to key users, technical experts, and financial experts has been obtained

the project objectives have been identified and agreed to (in PD)

initial requirements have been defined (in PD)

development of the risk assessment has begun (in PD)

definition of the project infrastructure has begun (in PD)

development of the project plan has begun (in PD)

the feasibility study has been at least started (in PD)

To be performed checklist programmers worked with the Expert users to develop requirements

(user interface prototypes were reviewed and tested)

source code was written and documented

code testing was performed (code was inspected)

integration plan was prepared

reusable artifacts have been used

potential reusable items have been identified

generalization sessions were held

potentially reusable items were refactored

reusable items were documented

examples of how to reuse reusable items were documented

Process description

reusable items were released into the repository and made accessible to all developers

test plan was updated appropriately

source code was inspected and improved before being tested

system testing was performed

defects were recorded and analyzed

business and conceptual models were assembled (based on source code) and validated

assumptions made during modeling were challenged and documented appropriately

manual processes, legacy applications, and new system development was identified and modeled accordingly

risk assessment document has been updated decisions (both made and forgone) were documented into group


(cont.)

Page 24 DRAFT

Program, generalize, test and model - Extreme projects (cont.) Exit conditions checklist source code has passed inspection

the source code works

the source code has been optimized


generalized items have been submitted to the reuse repository

all developers have been made aware of new items

all items have been tested, reviewed and updated accordingly

master test has been updated for “test in the large”

models have been appropriately documented

models have been validated

test plan has been updated

models have been accepted by the team and by senior management

New process features, process issues• This Extreme approach saves time, but is more demanding on resources,

comparing to standard approach. All major activities from standard approach are applied, but some in reverse order or in parallel with slight delay.

• The project is also more demanding for user experts, who must work closely with programmers, to develop requirements in parallel with programming.

• Project starts based on approved PD. At this moment therefore are not requirements and project plan fully defined. Project manager should develop simple variant of Project Charter as his first activity in the process.

• Models and documentation are being developed during programming (with slight delay). Programming is not normally backward influenced by modeling.

Process description

Page 25 DRAFT

Tiny development projects Entrance conditions checklist vision for the project has been defined by user community

To be performed checklist user requests (RFS) have been documented, validated and prioritized technical requirements, operation and support requirements have been

documented and validated reusable artifacts have been identified economic feasibility was determined project estimate has been developed and accepted project plan has been developed and accepted assumptions and constraints have been documented test plan has been developed and accepted technical and operational feasibility was determined project team has been defined risks has been judged and documented “Small Project Charter” has been created programmers worked with the Expert users and analysts to develop requirements source code was written /SW was customized and documented code/customization testing was performed (code was inspected) integration plan was prepared reusable artifacts have been used potential reusable items have been identified reusable items were documented examples of how to reuse reusable items were documented reusable items were released into the repository and made accessible to all

developers test plan was updated appropriately source code was inspected and improved before being tested

Process description

system testing was performed defects were recorded and analyzed business and conceptual models were updated and validated decisions (both made and forgone) were documented into group


Exit conditions checklist source code/ customization has passed inspection

the source code / customization works

the source code / customization has been optimized and tested

project plan (incl. test plan) has been created


New process features, process issues• This process is applicable only for very small development projects, or

even just customization projects, where administrative activities would take longer than development work itself.

• No senior management approval is necessary to start the project.

• This process can not be used for projects with vendors evolvement. The only exception is when already proven vendor supplies only manpower and is managed by RDM IT manager.

• About Tiny project approach must decides CIF.

Page 26 DRAFT

Deliver and testEntrance conditions checklist• development activities finished

• the application has been packaged for delivery

• unit tests passed and test results are available

• draft user manual submitted

• the master test/QA plan in available

• team members are trained

To be performed checklist system test kick-off was conducted

• the master test/QA plan was accepted

• test procedures, cases, scripts were developed

• all particular tests were performed

• discrepancies have been recorded and assigned for resolution

• artifacts that are potentially reusable by this project team have been identified and used

• decisions, both made and forgone, have been documented in group memory


• train the trainer process was started

Process description

Exit conditions checklist the application has passed system testing

• test results were documented

• no serious discrepancies with heavy impact on application are left

New process features, process issues• testing is done in structured manner going through a sequence of

tests each having different purpose

• master test plan and test objectives are developed in early project phases

• testing effort is supported by adequate team

• acceptance test is responsibility of users

Page 27 DRAFT

Pilot operationEntrance conditions checklist all development efforts are finished and all development programs are

fully integrated tested and accepted (formal signed off)

conversion procedures tested, static data prepared

• all programs and customizing settings moved from test environments to the production environment using the configuration management procedure

users trained and confirmed readiness for pilot

senior management and project office informed

IT operation staff properly trained

helpdesk procedures defined and staff properly trained

IT trouble shooting team prepared

pilot support team established

To be performed checklist pilot operation kick-off meeting conducted

provide user support and monitor performance of all developed programs

establish infrastructure to support post implementation development

prepare a SW implementation cutover workplan for all of the development work required to cutover if necessary

• review the Integration Test Scenarios to determine the data loading sequencing, include the check reports into the workplan as well as manual tasks that need to be done between runs

Process description

Exit conditions checklist system satisfies acceptance criteria (contracted)

pilot result submitted to project office, users, helpdesk and supporting team

system acceptance (sign-off) reported to vendor

New process features, process issues• pilot operation is planned activity and properly teamed up

• system in pilot operation is monitored and status is reported what requires extra effort to do and evaluate

Page 28 DRAFT

Support in pilotEntrance conditions checklist pilot operation successfully started

pilot supporting team established


IT trouble shooting team in operation

To be performed checklist all problems are properly described and recorded at helpdesk

problems are either resolved or have problem manager assigned

pending problems are evaluated as having no major impact on system or operation

all trouble reports sent from trouble shooting are either closed or evaluated as having no bad impact

request for support was promptly and politely responded, requester was informed about the escalation and consequencies of the request

Process description


operation runs without serious problem, no stopshow errors are occurring

all problems are either resolved or documented with problem owner assigned

major problems and their resolution generalized

recognized defects and solutions were recorded

New process features, process issues• pilot support is planned activity, support team is properly appointed

• all problems are passed through helpdesk that resolves them directly or escalates them further in the organization

• IT trouble shooting describes any problem solving in the Trouble Report which is submitted for impact assessing before it is closed

Page 29 DRAFT

AssessEntrance conditions checklist• management support exists

• project members and key user representatives are available

• project deliverables, including the group memory and collected metrics are available

• team members are trained

To be performed checklist • project deliverables were reviewed

• metrics collected during the project were presented and analyzed

• the performance of individual team members was assessed

• the involvement of user community was assessed

• the involvement of support community was assessed

• the involvement of operations community was assessed

• the project assessment was documented

• the learning history was developed

• the software process improvement plan was developed

• risk assessment document has been updated



Process description

Exit conditions checklist• all staff assessments are complete

• the project assessment has been presented to senior management

• the software process improvement plan has been accepted

New process features, process issues• whole concept of assessment is new, should be only used as vehicle

to improve, not to solve HR issues

• process of developing learning history is new

Page 30 DRAFT

SupportEntrance conditions checklist pilot operation successfully started

supporting team established


IT trouble shooting team in operation

To be performed checklist all problems are properly described and recorded at helpdesk

problems are prioritized and either resolved or have problem manager assigned

pending problems are evaluated as having no major impact on system or operation

all trouble reports sent from trouble shooting are either closed or evaluated as having no bad impact

• maintenance changes were allocated and impact of each maintenance change was determined

• each maintenance change was scheduled

• the initiator of each change request was notified of the status

• reusable artifacts were used

• risk assessment document was updated



Process description


operation runs without serious problem, no stopshow errors are occurring

all problems are either resolved or documented with problem owner assigned

major problems and their resolution generalized

recognized defects and solutions were recorded

New process features, process issues• all problems are passed through helpdesk that resolves them directly

or escalates them further in the organization

• IT trouble shooting describes any problem solving in the Trouble Report which is submitted for impact assessing before it is closed

Deliverable description

Page 32 DRAFT

List of deliverables

• Request for Support (RFS)

• Project Definition (PD)

• Project Charter (PC)

• Simple Project Charter (Extreme Project)

• Small Project Charter (Tiny Project)

• Business Model

• Conceptual Model

• User Manual

• Operational Manual

• Training Manual

• Test Scripts

• Test Results

• Pilot Results

• Project Evaluation

• Program Code

Deliverables

Page 33 DRAFT

Request For Support (RFS)

Purpose

Request For Support is document containing the definition of user

request.

Content1. COVER SHEET

1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsorProject manager UserProject manager ITStart dateEnd date

1.2 Comments1.3 Document history1.4 Checked / approved by

2. CURRENT STATUS DESCRIPTION3. PROJECT GOAL4. PROJECT SCOPE

4.1 Project scope4.2 Out of project scope

5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables

Deliverables

6. PROJECT IMPACTS6.1 Dependencies

7. PROJECT ORGANIZATIONProject SponsorProject Steering CommitteeProject Manager UserProject Team (user side)

8. ASSUMPTIONS AND CONSTRAINS9. ENCLOSURES

Legend: Italic letters shows new items comparing to current PM documentation

Page 34 DRAFT

Project Definition (PD)

PurposeProject definition is a document containing the definition of user

request and and high level description of the approach, how project can be realized. If potentially exist more implementation alternatives, it is expected, that they will be described separately in sections 6-13. After PD is approved, more detailed definition will start.


1.1 General InformationProject nameCode nameDescriptionCategoriesProject sponsor:Project manager UserProject manager ITStart dateEnd dateBudget, SAP IDInternal resource (MD)




5. PROJECT OUTPUT/DELIVERABLES5.1 Project Output/deliverables5.2 Acceptance criteria

Deliverables

6.TECHNICAL SOLUTION6.1 Technical approach6.2 Reusable artifacts that can be used6.3 Reusable artifacts that will be developed

7. PROJECT IMPACTS7.1 Dependencies7.2 Organizational impacts7.3 Risks

8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN8.1 Work breakdown and time plan8.2 Test plan8.3 Summary of internal resources8.4 Metrics plan8.5 Quality plan

9. BUDGET9.1 Summary

CAPEX: … ths. KčOPEX: … ths. KčTotal: … ths. Kč

9.2 Timing9.3 Major deliveries (suppliers)

10. ECONOMIC STATEMENT (cost benefit analysis)11. PROJECT ORGANIZATION

Project SponsorProject Steering CommitteeProject Manager UserProject Manager ITProject TeamQuality Assurance

12. FEASIBILITY STUDY12.1 Technical feasibility12.2 Economical feasibility 12.3 Operational feasibility

13. ASSUMPTIONS AND CONSTRAINS14. ENCLOSURESLegend: Italic letters shows new items comparing to

current PM documentation

Page 35 DRAFT

Project Charter (PCH)

PurposeProject Charter is the detailed and final project definition, containing all

justified user requests and proposed technical approach. PCH is assembled after approval of PD, when the project has been accepted. It builds on PD but it provides more details and accuracy. Project can start only after PCH is approved (with the exceptions of Extreme project approach and Tiny development projects). PCH follows only the selected implementation alternative.







Deliverables











14.1 vendor contract14.2 vendor PCH (equal to vendor accepted proposal)Legend: Italic letters shows new items comparing to

current PM documentation

Page 36 DRAFT

Small Project Charter

PurposeSmall Project Charter is the detailed and final project definition,

containing all justified user requests and proposed technical approach for Tiny development projects. Small Project Charter should use simpler forms than PCH.







Deliverables








Project SponsorProject Manager ITProject TeamQuality Assurance



Page 37 DRAFT

Simple Project Charter

PurposeSimple Project Charter is the project definition for Extreme project.

Simple PCH is created after project starts and its purpose is to facilitate management and document process of definition of requirements and construct phase and develop deliver project plan. It should assure the quality of the development process even in Extreme approach.







Deliverables











14.1 vendor contract14.2 vendor PCH (equal to vendor accepted proposal)


Page 38 DRAFT

User manual

Purpose• User manual is part of system documentation. It explains how to use the system.

Content• System background

Reason and purpose of the system, basic properties.• Relations to other systems

Interactions to other systems, main interfaces, transferred data.• Brief descriptions of system functions

Overview of major functions with basic description to get initial understanding• Description of system functions

Description of functions from the user point of view.• Processing of non automated activities

Descriptions of related actions which are not automated by the system. Activities which were automated by previous system but not by this one.

Deliverables

Page 39 DRAFT

Operational manual

Purpose• Operational manual is part of system documentation. It explains how to administer and operate the system.

ContentAdministration part• List of system components.

List of system components like programs, libraries, parameter files etc. including their location.• Installation

Installation of the system, sequence of particular installation activities, verification of installation.• Configuration, static data and parameter set up

System configuration (primary and ongoing), list of static data, meaning static data and their setting, description of static data.• Maintenance of users

User administration.• System security

Description of system security. Used security features.• System maintenance

Description of activities assuring system operation, e.g. archiving, cleansing of work areas.

Operational part• Description of daily operations

Picture of daily operations, description of operators’ activities.• Description of batches

List of system batches and their description.• Error messages

Dictionary of system error messages, reactions, error resolution.• Handling of exceptional statuses

Outline of exceptional statuses handling, e.g. technical disaster, communication line break-down.• Archiving

Outline of data archiving and backup, data backup and restore organization.

Deliverables

Page 40 DRAFT

Test scripts and Test results

Test Scripts

Purpose• Test scripts is the name in common jargon for whole set of test documentation that is used to control test execution, describe individual tests

and the way of executing them. See appendix Test documentation for more details.

ContentTest Plan• Explanation why particular set of tests is being run, when they will run, and what will be required in order to run them.

Test Design• List of test cases each listed explicitly referring to one or more objectives in the test plan so that completeness of coverage can be evaluated

and so that test execution can be prioritized.

Test Procedure Specification• Definition of how a test case will be applied to the system, detailing actions, inputs, expected outputs and Pass / Fail criteria for each test.

Test Results PurposeResults of particular test runs and test cases. Documentation of any test discrepancies.

ContentRun Management Log• Log detailing where defects have been found or resolved in the application under test.

Test Incident Report• Data on the nature of the incident, who is dealing with the problem, and when it is likely to be resolved.

Deliverables

Page 41 DRAFT

Project evaluation

Purpose• Project evaluation is to conduct and document assessment of project mission and objective, project management, project team and return on

investment after the project is finished and to write “Lessons Learned” for future projects.

Content• Project management functions, project plan quality, scope management, deliverable vs. deadline management, budget management.

• Knowledge of project methodology, design methods, development tools, adherence to standards.

• Team organization, clarity of team’s roles and responsibilities, teamwork and personal interactions, communication processes among parties involved in the project.

• Evaluation of project team members — their performance during the project (formal and informal way). These appraisals shoul be used for career planning and development.

• Familiarity with process models and concepts, ability to translate models, policy, procedures to training content.

• Quality of deliverables, testing process, system installation and cut over.

• User training, fit of training with project goals and timelines, initial user satisfaction.

Deliverables

Page 42 DRAFT

Pilot Result

Purpose• Description of pilot operation

Content• matching with acceptance criteria (to be signed off)

• user satisfaction and experience

• observations from IT operations and helpdesk

• overview of errors or problems reported, status of their solution

• overview of system performance and results from system monitoring

• remarks and requests for enhancements

• lessons learned

Deliverables

Roles descriptions

Page 44 DRAFT

Roles description

Project Manager User (PM User)• have the primary/ overall responsibility for the project• his major role on the beginning is requirements specification and project

definition (creation of Project definition and Project Charter). Later in project assures that project follows project plan, decides about project phases closing and solves problems.

• assures, that Project is moving ahead• In technical issue relies on PM IT

Project Manager IT (PM IT)• manage IT side of the project• hands over project deliverables for Quality assurance

Quality Assurance (QA)• assess deliverables quality in QA check-pointsThis role is not explicitly described in process maps, as QA always acts on the

request of PM IT at the end of each process phase and also inside of processes, if defined.

Ordering User• clearly formulates user or business requirements in the form of RFS• contributes to Project definition

CIF• gather RFSs, plays role of interface between users and IT. For small projects can substitute PM User role. If CIF substitutes PM user in bigger projects, it creates significant risk, that

should be evaluated.

IT Meeting• represents decision maker role for IT dept. global issues.• decides about Extreme project approach.

IT vs. Dept. Meeting• regular meeting between IT and other departments• approves smaller projects (PD, PCH)• receives project status info

Project office• approves bigger projects (PD, PCH)• receives project status info

IT Architekt• responsible for consistency of all IT architecture components.

IT Project office• creates IT project infrastructure to support PM IT

• maintains group memory•gathers metrics•gather and provide reuse etc.

• formally checks completeness of project phases

Senior Management• approves bigger projects (PD, PCH) • receives project status info• is not contacted directly but through Project Office or IT vs. Dept. Meeting

Business Analyst• transforms user requirement into business model• requires strong communication and modeling skills, partly knowledge of user

business

User Expert• subject matter expert from user side, represents user requirements.• knows user business

Roles description

Page 45 DRAFT

Roles description (cont.)

Environment Specialist• assist to all other functions with technical advice and expertise on

architectural components

Programmer• develop program code according to the design• maintain and keep the system repository up to date• execute unit test

Technical Documentation Processor• gather supporting documentation and develop system documentation

Userguide Writer• gather supporting documentation and develop user manual

SAP Superuser• responsible for assigned module• during a SW customization project plays the role of PM User, and

coordinates even IT personnel from SAP team.• control module development - gather and sort out all requests, sign off all

changes• responsible for application access and security control, grant access to

other users• control user training, couch the train the trainers approach

Analyst• do analysis on given subject, creates conceptual model• document the results

IT Operations• responsible for the operation e.g., running of the system HW, network and

software• operation, tuning and maintenance of the systems processing units.

IT Tester• execute integration and system tests and performance tests• record test results• prepare run management log detailing the test results

Test Designer• create test designs and test cases according to the testing process• work with the business users to confirm test objectives and acceptance

criteria

User Tester• execute system integration and user acceptance tests and regression tests,

prepare testing scripts• record test results

End User Support (Help Desk)• receive user requests, document them, refine description• resolve simple problems• escalate difficult problems

User Trainer• deliver training to users• update training material

User• responsible for applications and their proper use• own the applications and are responsible for the data• clearly specify requirements that should be communicated through CIF only• visit user training

Roles description

Page 46 DRAFT

Roles description (cont.)

IT Support Team• assist the users in the new process operations• monitor process performance e.g. systems operations, preparation of input

forms, processing of transactions, generation of system reports and provision of user support

• resolve process problems as the occur • stabilize process operations and fine-tune all procedures to address

identified problems

IT Trouble Shooting• be on disposal for resolution of difficult problems• resolve problem, document properly all activities done• cooperate during the impact assessing and problem closing

Administrator• administration of the systems assets including current hardware and

software inventories.

Problem Manager• lead all activities related to problem resolution• contact other specialists and experts to cooperate on problem resolution

Roles description

Process models

Please print from attached file on A3 paper format

Page 48 DRAFT

Define requirements and justify

IT Project Office

Ordering User

receiverequirem

ents

subm itrequ irem ent

com pleterequirem

ents

PM User

receiverequirem

ents

rece ivedrequ irem ents

coord inateevaluation andpropose team

roles

fin ish andpresent PD

w ait fo r decis ion

com pletePD

receivedecis ion

aboutpro ject

CIF

recordrequirem

ents


consultreguirem ents

pass overrequest

and startPD

w ait fo r decis ion

receivedecis ion

aboutpro ject

Project Office

receivePD

has P D

consult PD

re jectpro ject

IT vs. Dpt Meeting

Analyst &Programmer &Expert User &EnvironmentSpecialist& ITArchitect

assessfeasib ility

afte r feasib ilityassessm ent

am endPD

request for support

am endPD

necessaryPD

PD

PD

if necessary

draft PD

big pro ject

if necessary

PD

PD

if needed

receivedecis ion

aboutpro ject

if necessary

gatherm etrics

com pleteand present

PD

sm allpro ject

approvepro ject

receive PD

has P D

consultPD

re jectpro ject

approvepro ject

providereuse in fo

receivedecis ion

aboutpro ject

assem blePD

before P Dbefore P Dassess

feasib ilityassess

feasib ility

organizek ick -off

workshop

extrem e pro ject

IT meeting

judgedevelopm ent

through extrem eprojectin case of conflic t

(tim e, resources)

PM IT

be in form edabout h is /her

team nom ination

w ait fo rdecis ion

receive decis ionabout pro ject


com pletePD

sm all pro jectb ig pro ject

approved PD

com pletePD

PD

nom inatePM IT

if ne

cess

ary

Page 49 DRAFT


PM Vendor

specify technica lso lution

specifiedtechn ica l so lu tion

propose vendorProject C harter

c lose contract

PM IT

PM User / CIF

has approvedP D

re finerequirem ents -develop P ro ject

C harter

obta inedtechn ica lpro jectspecifica tion

re fineresources

Project Office

receiveProjectC harter

has P ro jectC harter

IT vs. Departmentmeeting

receiveProjectC harter

has P ro jectC harter

Analyst &Programmer &Expert User &EnvironmentSpecialist

re finetechnica lso lution

specifiedtechn ica lso lu tion

re fineresources

IT Architect

re fine technica lso lution

w ait fo r p ro jectdecis ion

receivepro ject

decis ion

SeniorManagement

receivepro jectstatusreports

Vendor PC

fina lized P C H

hand over PC H forapproval


receiveapprovem ent

receivedeny

receiverequest

foram endm

ent

consultPC H

approve

deny

requiream endm

ent

big pro ject

approverequire

am endment

deny

sm all pro ject

w ait fo rpro jectdecis ion

receive pro jectdecis ion

consultPC H

IT Project Office

organizeworkshop,

c lose"IN IT IAT E"phase and

open pro ject

co llectm etrics

Project Charter

PCH

PCH

m etrics

Ordering User

adjust teamand specify

requirem ents

refineresources

re finedrequ irem ents



refine technica lrequirem ents

re finedtechn ica lrequ irem ents

re fine resources,assis t w ith PC H


w ait fo rpro jectdecis ion

closevendor

contractapproved PCH

if necessary

before c losingcontract

Page 50 DRAFT

ModelExpert User

consultbusinessm odelling

fin ishedbusiness m ode lconsu lta tions

partic ipate inbusiness

m odelworkshop

PM User / CIF

startm odelling

w ait fo rm odeling fin ish

receivebusiness

m odel andpartic ipate in

workshop

receiveconceptual

m odel

PM - IT

appoint businessm odel team

w ait fo rbusiness m ode l

receive businessm odel and reuse

inform ation

has businessm odels

conduct businessm odel workshop

afte rbusinessm odelw orkshop

requestfor

businessm odel

revis ion

appointconceptualm odelling

team

Business Analyst /Vendor

develop businessm odel and provide

reuse in fo

fin ishedbusiness m ode l

presentbusiness

m odel

EnvironmentSpecialist &Programmer & ITArchitect

consult bus inessm odel

fin ishedbusiness m ode lconsu lta tions

partic ipate inbusiness m odel

workshop

afte r businessm odelw orkshop

consultconceptual

m odel

fin ishedconceptua lm odelconsu lta tions

partic ipate inconceptual

m odelworkshop

afte r businessm odel isfin ished

afte r businessm odelw orkshop

IT Project Office

develop conc.m odel and

provide reuseinfo

fin ishedconceptua lm odel

presentconceptual

m odel

gather m etrics

consultconceptual

m odel

fin ishedconceptua lm odelconsu lta tions

partic ipate inconceptual

m odelworkshop

w ait fo rconceptua lm odel

receiveconceptual

m odel and reuseinfo

has conceptua lm odels

conduct conceptualm odel workshop

afte rconcept.m odelw orkshop

requestconceptual

m odelrevis ion

TechnicalDocument W riter

gatherunderlying

m ateria l andupdatem odels

receive reuseinfo

provide reuseinfo

businessm odel

m odelapproved

m odel notapproved

m odelapproved

m odel notapproved

con

cep

tual

mo

del

acceptvendorproduct

PM Vendor

receiveacceptance

Page 51 DRAFT

Program, generalize and test

PM Vendor

receiveacceptance

SeniorManagement

receiveproject s tatus

info

PM User / CIF

w ait fo r phaseend


info

Programmer /Vendor

program

fin ishedprogram m ing

test code

EnvironmentSpecialist& ITArchitect

consultprogram m ing

fin ishedprogram m ingconsu lta tion

consult codetest

Analyst/Vendor

consultprogram m ing

fin ishedprogram m ingconsu lta tion

consult codetest

afte r code test a fte r code testa fte r code test

IT Project Office

generalize code

fin ished codegenera liza tion

partic ipate ingeneralized

code test

co llectm etrics

consult codegeneralization



code test




code test

w aits fo rfin ished code

accept code,conduct

workshop andclose

C O N ST R U C Tphase

Project Office / ITvs. Dept. Meeting


info

Userguide W riter /Vendor

TechnicalDocument W riter /Vendor

gathersupporting

m ateria l

gathersupporting


receivereuse

IT Tester /Vendor

IT Operation

prepare testenvironm ent

preparetest

report testresults

in system test

test

updatem odels

fin ishedgenera lizedcode test



acceptvendorproduct

code

partic ipate insystem test



PM - IT

appointprogram m ing

team

w ait fo rprogram m ing

receive code

has code

check code testresults

afte r codetest

re turncode forrework

startgeneralizati

on

w ait fo rgenera lized code

receivegeneralized

code

has genera lizedcode

check genera lizedcode test resu lts

afte rgenera lizedcode test

requestrepair o f

generalized code

hand overcode and

in itia tesyst. test

code O K

w ait fo r systemtest resu lts

check system testresults

afte r system test

handovercode

requestrepair o f

generalized code

code after systemtest

code O K

generalized code

generalized code

Page 52 DRAFT

Program, generalize, test and model - extreme project

SeniorManagement


inform ation

PM User/ CIF

w ait fo r phaseend

receiverequirem ents


info

PM - IT

appointprogram m ing

team

w ait fo r p rogramcode

rece ive codeand requirem ents

step by step

has code

check code testresults

afte r codetest

requestcoderepair

in itia tegeneralizat

ion

Programmer/Vendor

program

fin ishedprogram m ing

test code

EnvironmentSpecialist & ITArchitect

consultprogram ing

fin ishedprogram ingconsu lta tion

consult codetest

code

afte r code testa fte r code test

IT Project Office

generalize code


testgeneralized

code

collect m etrics


fin ishedgenera liza tionconsu lta tion

partic ipate ingener. code

test

w ait fo rgenera lizedcode

receivegeneralized code

has genera lizedcode

check genera lizedcode test resuls

afte rgenera lizedcode test

requestrepair o fgeneralized code

w ait fo r fin ishedcode

accept code,conduct

workshop andclose

"construct"phase

hand overcode and

in itia tesyst. test

Project Office / ITvs. Dept. Meeting


inform ation

Userguide W riter/Vendor

TechnicalDocument W riter /Vendor

gathersupporting

m ateria l

gather supportingm ateria l and

update m odels

receivereuse

IT Tester/Vendor

IT Operation


preparetest

report testresult

in system test

test



Analyst-Cleanser /Vendor

Expert Userconsultpro ject

prepare form odel

c leansing

"c leanse" a fte rprogram m ing

developbusiness

m odel

developconceptual

m odel

fin ishedrequ irem entsspecifica tion

receive pro jectstatus in form ation

and accepts results

create S im pleProject C harter

partic ipate insystem test partic ipate in

system test

w ait fo r system testresu lts

check system testresults

afte r system test

handovercode

codeO K

requestrepair o f

generalized code

acceptvendorproduct

code after systemtest

PM Vendor

receiveacceptance

gen

eral

ized

cod

e

Page 53 DRAFT

Tiny Development Projects

PM - IT

in itia teprogram m ing/custom ization

Programmer

EnvironmentSpecialist & ITArchitect & ExpertUser

Analyst

IT Project Office

program /custom ize

fin ishedprogram m ing/custom ization

partic ipate intest

co llect m etrics

consultprogram m ing/custom ization

fin ishedconsu lta tion

partic ipate intest

consultprogram m ing/custom ization

fin ishedconsu lta tion

partic ipate intest

w ait fo r code /custom ization

rece ive code/custom ization

has code /custom ization

checkcode/custom ization

test

afte r code/custom izationtest

requestcode

custom izationrepair

w ait fo r fin ishedcode

accept code/C ustom ization

and c lose"C O N ST R U C T "

phase

handover

code/custom .

andin itia tesystem

test

IT vs. Dept.Meeting

rece ivepro ject s ta tus

inform ation

TechnicalDocument W riter

gathersupporting


take overreuse

IT Tester

IT Operation


preparesystem

test

report testresu lts

during systemtest

test

updatem odels

fina lized test fina lized test fina lized test

Ordering User(SAP Superuser)

send requirem ents

send requ irem ents

com pleterequirem ents

CIF

recordrequirem ents


consultrequirem ents

Code

if necessary

tiny project

create Sm all P ro jectC harter and hand

over to developm ent

sm all projectcharter

w ait fo rsyst. testresu lts

check syst.test results

afte r syst. test

hand overcode/

custom ization

requestcode/

custom ization repair

partic ipatein system

test


test


test

code

assessfeasib ility

w ait fo rpro ject sta rt

assessfeasib ility

assessfeasib ility

w ait fo rpro ject sta rt

w a it fo rpro ject sta rt

Page 54 DRAFT

Deliver & Test

PM Vendor

receiveacceptance

IT Operation

PM User / CIF PM IT Technical DocumentW riter /Vendor

partic ipate in thestart m eeting

after start m eeting

take over draftoperational

m anual

before test p lan

partic ipate in testp lan developm ent

before testing

coord inate andexecute tests

w ait fo r test resu lts

receive andinterpret test

results

hand over draftoperational

m anual

subm itted dra ftvers ion

subm it fina loperational

m anual

update m anual

operationalm anual

organize andconduct test s tart

m eeting

after test startm eeting

take over draftuser m anual

before test p lan

in itia tedevelopm ent o f

test p lan

before testing

start and contro ltesting

w ait fo r test resu lts

re turn pro jectback to


Userguide W riter/ Vendor

subm it draft userm anual

dra ft user m anualsubm itted

subm it fina l userm anual

update userm anual

use

r m

anu

al

test plan

test plan

test scripts

CIF / Vendor / OrderingUser

prepare tra in ingof the testing

team

in tra in ing

reports end oftra in ing of testing

team

tra in testing team

m anage tra in ingof the testing

team

trai

nin

g m

ater

ial

Test Designer/Vendor

IT Project Office

subm it testscrip ts

test scripts (IT Tester / Vendor) &User Tester

test

test

scr

ipts

receive m anualsand tra in ing

m ateria l

use

r m

anu

alo

per

atio

nal

man

ual

trai

nin

g m

ater

ial

SoftwareC onfigurationM anagem ent

receive ongoingtest resu lts

preparere lease

contro lresolution of

d iscrepanciesin test discrepancies in test

a ll right

seriousdiscrepancies

before c losing testw orkshop

conduct c los ingtest workshop

official releaseversion

user m aual operationalm anual

Senior Management

be inform ed aboutpro ject c los ing

before user tra in ing

tra ins the tra iners

user m anual

prepare operationsupport (he lpdesks, ...)

report test results

in terpret testresults

Administrator

transfer applicationto productionenvironm ent

require sw itchof test

environm ents

receive ongoingtest resu lts

update testscrip ts

acceptvendorproduct

transfer applicationto other testenvironm ent

Programmer &Analyst &EnvironmentSpecialist &IT Architect &Expert User

in terpret testresults

test results

test results

Page 55 DRAFT

Pilot OperationUser Trainers/Vendor

confirm user readinessfor p ilo t

IT vs. Dept. Meeting/Project Office

receive in fo about p ilo toperation start

Senior Management

receive in fo about p ilo toperation results

PM User PM IT User End User Support (HelpDesk)

Support Team/Vendor

w ait fo r read iness

organize k ick -offm eeting of p ilo t

operation

receivereadiness in fo

ready fo r p ilo topera tion

partic ipate ink ick -off m eetingof p ilo t operation

confirmreadiness


receive p ilo toperation k ick -off

in fo

confirmreadiness



confirmreadiness



confirmreadiness

in p ilo t opera tion

m onitor p ilo toperation

resolve prob lem s

consult prob lem s

in p ilo t opera tion in p ilo t opera tion

pilot supportunder

progress

in p ilo t opera tionpilot

supportunder

progress

in p ilo t opera tion

pilot supportunder progress

report p ilo toperation

results

receiveinform ation about

p ilo t operationresults

has in form ationabout p ilo topera tion resu lts

report p ilo toperation

results

confirm ssuccessfu ll

p ilo t

recom m endproject

cancelation

recom m endreturn to


fin ish p ilo t andpro ject

cancel pro ject

re turn pro jectto


receive in fo about p ilo toperation results

receive in form ationabout p ilo t operation

results

decide aboutp ilo t extension

pilotsupportunder

progress

PM Vendor

receiveacceptance

Page 56 DRAFT

Support in Pilot OperationUser / Expert User(Supervisor)

report problem

afte r prob lem report

re fine problemdescription

subm itproblem

resolutionreport

be in form edon progressof problemresolution

w ait fo r p rob lemreso lu tion

cooperate onproblem

resolution

receive in form ationabout the way of

problem resolution

End User Support (HelpDesk)

receive problem report

rece ived prob lemreport

re fineproblem

description

subm itproblem

resolutionreport

requireproblem

resolutionon IT

resolveproblemwith own

power

doesn't need anyresolution cannot be

resolved

can be resolved w ithow n pow er


liase w ith user

receive in form ationabout the way of

problem resolution

IT Project Officeoffer in form ation

abou s im ilarproblem s

PM IT

receiveproblem

description

rece ived prob lemdescrip tion

decide on theway of problem

resolution

announcethe way ofproblem

resolution

in ita teC O N ST R U C T

process

coord inateproblem

resolution

standard w ay ofresolution

can beresolvedquick ly

notnecessaryto resolveim m ediate ly

Expert User (Supervisor)

consult the way ofproblem resolution

IT Trouble Shooting /Vendor


resolve anddocum ent problem

Senior Management

be inform ed about seriousproblem that needs to be

resolved

if necessary

problemdescription

if necessary

problemdescription

if necessary

acute

hastroub lereport

report aboutresolution

w ithout anyconsequences

report aboutresolution and

in itia teC O N ST R U C T

process

IT architect & IT Operations

assess im pact o f repairon whole IS

if necessary

reportedaboutreso lu tion

generalizeproblem and its

resolution

collect m etrics andfiles resolution

Trouble Report

Administrator

resolve problem

pass overthe

problem forresolutio

depends on scope

PM User

decide onprolongation of the

pilo t operationphase

problem doesn't deal w ithapplication

Page 57 DRAFT

AssessPM ITTechnical

Document W riter

subm it currentvers ion of

m anual

Userguide W riter

subm it currentvers ion of

m anual

CIF

in form abouttra in ing s tatus

PM User

receive a ll ex is tingpro ject outputs

beforeassessm entw orkshop

conductassessm ent

workshop

afte rassessm entw orkshop

in formabout

pro ject

Project Office / ITvs. Dept. meeting

receiveinform ation

about pro ject

operational m anual

use

r m

anu

al

tra

inin

g s

tatu

sre

po

rt

IT Project Office

evaluatem etrics

m etrics evaluation

Analyst &Programmer &Expert User &EnvironmentSpecialist

partic ipate inassessm ent

workshop

IT Meeting

update SWdevelopm ent

process

collectm etrics

subm it a ll pro jectoutputs

beforeassessm entw orkshop

partic ipate inassessm ent

workshop

afte rassessm entw orkshop

in formabout

pro ject

m etrics evaluation

update groupm em ory

PM Vendor

obta infeedback

Page 58 DRAFT

SupportUser / Expert User

report problem

afte r prob lem report

re fine problemdescription

receiveproblem

resolutionreport

be in form edon problemresolution


cooperate onproblem

resolution

receive in fo about theway of problem

resolution

End User Support (HelpDesk)

receive prob lem report

rece ived prob lemreport

re fineproblem

description

subm itproblem

resolutionreport

requireproblem

resolutionon IT

resolveproblemwith own

power

no resolutionneeded

cannot beresolved

can be resolved w ithow n pow er


liase w ith user

receive in fo about theway of problem

resolution

IT Project Officeoffer in form ation

about s im ilarproblem s

Problem Manager

receiveproblem

description

rece ived prob lemdescrip tion

decide on theway of problem

resolution

announcethe way ofproblem

resolution

in itia te"IN IT IAT E"

process,create in ternal

R FS

coord inateproblem

resolution

standard w ay ofresolution

can beresolvedquick ly

not necessary toresolve im m ediate ly

Expert User (Supervisor)

consult the way ofproblem reolution

IT Trouble Shooting


resolve anddocum ent problem

Senior Management

be inform ed about seriousproblem that needs

resolution

if necessary

problemdescription

if necessary

problemdescription

if necessary

acute

hastroub lereport

in form aboutresolution

w ithout anyother

consequencesreport about

resolution andin itia te

C O N ST R U C Tprocess

IT Architect & Administrator& IT Operations

assess im pact o f repairon the whole IS

if necessary

reportedreso lu tion

generalizeproblem and its

resolution

collect m etrics andfile reso lution

trouble report

Administrator

resolve prob lem

pass overthe

problem forresolution

depends on scope

problem doesn't deal w ithapplication

Table of Content

Documents

distributed environment

formal process

training process

distributed organization

process models

people evaluation process

formal measurement process

vendor managementthe