1. 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

2. Summary

3. 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.

4. 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.

5. Summarized features of the new SW development processes
Summary
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.

6. 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.

7. SW development process overview

8. Principles for different types of the projects
Process Overview
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.

9. Process model structure for Initiate and Construct phases
Process Overview
Models
Model content
Gather initial requirements
Cathegorize requirements
Approve requirements
Define requirements and justify
Tiny development projects
Initiate
Develop detailed project charter
Approve projects
Define management documents
Develop and approve Business model
Develop and approve Conceptual model
Model
Program, generalize, test and model - extr. projekt
Construct
Develop program code
Generalize program code
Perform system test
Initiate documentation
Program, generalize and test
Small,
Small,
Tiny projects
Big standard projects
Big “Extreme” projects

10. Process model structure Deliver and Support phases
Process Overview
Models
Model content
Program, generalize, test and model - extr. projekt
Tiny development projects
Model
Develop all manuals
Provide training
Perform tests
Release SW
Deliver and test
Prove SW under real-life conditions
Manage SW problems during pilot
Close project
Program, generalize, test and model - extr. projekt
Pilot
Model
Deliver
Support in pilot
Evaluate project
Record “lessons learned”
Assess
Manage user problems
Fix SW defects and user problems
Support
Support
Standard /
“Extreme” projects
Tiny projects
(Small, Big)
(Small, Big)

11. 10 Features of Extreme Projects in Contrast with Standard Projects
In our approach, the concept of extreme project is inspired by the Kent Beck’s theory ( 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. 1
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. 2
In extreme project, software is produced earlier, but there are also generated all other deliverables as those of standard project. (manuals, models, metrics, ...) 3
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. 4
If the project is selected to be extreme, this information must be visible in PD (project definition) and PC (project charter) documents. 5
In extreme project, the user must be more involved in the development process. The user must be properly trained to be able to assist developers during construct phase. (Or IT must help users with this role) 6
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. 7
Extreme project has more risk than standard project. (Because of higher dependency on development and user experts and technologies, for example) 8
Extreme project is more expensive than standard project. (Shorter software development time is not for free) 9
Extreme project requires better quality management. Quality administrator needs strong assistance of programmer and analysis specialists, because each recognized problem must be immediately repaired. 10
The success of extreme project is dependent on well working technical infrastructure (shared repository, for example).

12. Flow of deliverables

13. Phases Initiate and Construct for standard projects
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
RFS
Define requirements and justify
RFS
Project Definition
Initiate
Approved PD
Define management documents
Project Charter
Approved PCH
Model
Business Model
Updated
PCH
Conceptual Model
Construct
Program, generalize and test
Updated
PCH
Program Code

14. Phases Initiate and Construct for tiny projects
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
RFS
Define requirements and justify
RFS
Small
Project Charter
Initiate
Define management documents
Updated Business Model
Model
Updated Conceptual Model
Construct
Program, generalize and test
Business Model
Program Code
Conc. Model

15. Phases Initiate and Construct for extreme projects
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
RFS
Define requirements and justify
RFS
Project Definition
Initiate
Approved PD
Program, generalize, test and model
Simple
Project Charter
Construct
Updated
PCH
Conceptual Model
Business Model
Program Code

16. Phase Deliver Deliverable type Phase Proj. mgmt. System Test Manuals
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
Conc. Model
Deliver and test
Updated
PCH
Bus. Model
Program Code
User manual
Operational manual
Updated
PCH
Training
manual
Test
scripts
Deliver
Test
results
Pilot
Pilot
results
Updated
PCH
Assess
Project evaluation

17. Phase Support Deliverable type Phase Proj. mgmt. System Test Manuals
Flow of deliverables
Deliverable type
Phase
Proj. mgmt.
System
Test
Manuals
User problem
Conc. Model
User manual
Operational manual
Bus. Model
Program Code
Support,
Support in pilot
User problem
User problem
Support
Trouble report
Internal RFS

18. Process descriptions

19. Define requirements and justify
Process description
Define requirements and justify
Entrance 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
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.

20. Define management documents
Process description
Define management documents
Entrance 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
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
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.

21. Model Entrance conditions checklist Exit conditions checklist
Process description
Model
Entrance 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
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).

22. Program, generalize and test
Process description
Program, generalize and test
Entrance 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
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.

23. Program, generalize, test and model - Extreme projects
Process description
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
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 memory
metrics have been collected
(cont.)

24. Program, generalize, test and model - Extreme projects (cont.)
Process description
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
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, 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.

25. Tiny development projects
Process description
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
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 memory
metrics have been collected
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
the application has been packaged for the delivery
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.

26. Deliver and test Entrance conditions checklist
Process description
Deliver and test
Entrance 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
metrics have been collected
train the trainer process was started
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

27. Pilot operation Entrance conditions checklist
Process description
Pilot operation
Entrance 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
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

28. Support in pilot Entrance conditions checklist
Process description
Support in pilot
Entrance conditions checklist
pilot operation successfully started
pilot supporting team established
helpdesk procedures defined and staff properly trained
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
Exit conditions checklist
system satisfies acceptance criteria (contracted)
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

29. Assess Entrance conditions checklist Exit conditions checklist
Process description
Assess
Entrance 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
decisions, both made and forgone, have been documented in group memory
metrics have been collected
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

30. Support Entrance conditions checklist Exit conditions checklist
Process description
Support
Entrance conditions checklist
pilot operation successfully started
supporting team established
helpdesk procedures defined and staff properly trained
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
decisions, both made and forgone, have been documented in group memory
metrics have been collected
Exit conditions checklist
system satisfies acceptance criteria (contracted)
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

31. Deliverable description

32. 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

33. Request For Support (RFS)
Deliverables
Request For Support (RFS)
6. PROJECT IMPACTS
6.1 Dependencies
7. PROJECT ORGANIZATION
Project Sponsor
Project Steering Committee
Project Manager User
Project Team (user side)
8. ASSUMPTIONS AND CONSTRAINS
9. ENCLOSURES
Purpose
Request For Support is document containing the definition of user request.
Content
1. COVER SHEET
1.1 General Information
Project name
Code name
Description
Categories
Project sponsor
Project manager User
Project manager IT
Start date
End date
1.2 Comments
1.3 Document history
1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION
3. PROJECT GOAL
4. PROJECT SCOPE
4.1 Project scope
4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES
5.1 Project Output/deliverables
Legend: Italic letters shows new items comparing to current PM documentation

34. Project Definition (PD)
Deliverables
Project Definition (PD)
6.TECHNICAL SOLUTION
6.1 Technical approach
6.2 Reusable artifacts that can be used
6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS
7.1 Dependencies
7.2 Organizational impacts
7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN
8.1 Work breakdown and time plan
8.2 Test plan
8.3 Summary of internal resources
8.4 Metrics plan
8.5 Quality plan
9. BUDGET
9.1 Summary
CAPEX: … ths. Kč
OPEX: … ths. Kč
Total: … ths. Kč
9.2 Timing
9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)
11. PROJECT ORGANIZATION
Project Sponsor
Project Steering Committee
Project Manager User
Project Manager IT
Project Team
Quality Assurance
12. FEASIBILITY STUDY
12.1 Technical feasibility
12.2 Economical feasibility
12.3 Operational feasibility
13. ASSUMPTIONS AND CONSTRAINS
14. ENCLOSURES
Purpose
Project 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 After PD is approved, more detailed definition will start.
Content
1. COVER SHEET
1.1 General Information
Project name
Code name
Description
Categories
Project sponsor:
Project manager User
Project manager IT
Start date
End date
Budget, SAP ID
Internal resource (MD)
1.2 Comments
1.3 Document history
1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION
3. PROJECT GOAL
4. PROJECT SCOPE
4.1 Project scope
4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES
5.1 Project Output/deliverables
5.2 Acceptance criteria
Legend: Italic letters shows new items comparing to current PM documentation

35. Project Charter (PCH) Deliverables Purpose
6.TECHNICAL SOLUTION
6.1 Technical approach
6.2 Reusable artifacts that can be used
6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS
7.1 Dependencies
7.2 Organizational impacts
7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN
8.1 Work breakdown and time plan
8.2 Test plan
8.3 Summary of internal resources
8.4 Metrics plan
8.5 Quality plan
9. BUDGET
9.1 Summary
CAPEX: … ths. Kč
OPEX: … ths. Kč
Total: … ths. Kč
9.2 Timing
9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)
11. PROJECT ORGANIZATION
Project Sponsor
Project Steering Committee
Project Manager User
Project Manager IT
Project Team
Quality Assurance
12. FEASIBILITY STUDY
12.1 Technical feasibility
12.2 Economical feasibility
12.3 Operational feasibility
13. ASSUMPTIONS AND CONSTRAINS
14. ENCLOSURES
14.1 vendor contract
14.2 vendor PCH (equal to vendor accepted proposal)
Purpose
Project 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.
Content
1. COVER SHEET
1.1 General Information
Project name
Code name
Description
Categories
Project sponsor:
Project manager User
Project manager IT
Start date
End date
Budget, SAP ID
Internal resource (MD)
1.2 Comments
1.3 Document history
1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION
3. PROJECT GOAL
4. PROJECT SCOPE
4.1 Project scope
4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES
5.1 Project Output/deliverables
5.2 Acceptance criteria
Legend: Italic letters shows new items comparing to current PM documentation

36. Small Project Charter Deliverables Purpose
6.TECHNICAL SOLUTION
6.1 Technical approach
6.2 Reusable artifacts that can be used
6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS
7.1 Dependencies
7.2 Organizational impacts
7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN
8.1 Work breakdown and time plan
8.2 Test plan
8.3 Summary of internal resources
8.4 Metrics plan
8.5 Quality plan
9. BUDGET
9.1 Summary
CAPEX: … ths. Kč
OPEX: … ths. Kč
Total: … ths. Kč
9.2 Timing
9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)
11. PROJECT ORGANIZATION
Project Sponsor
Project Manager IT
Project Team
Quality Assurance
12. ASSUMPTIONS AND CONSTRAINS
13. ENCLOSURES
Purpose
Small 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.
Content
1. COVER SHEET
1.1 General Information
Project name
Code name
Description
Categories
Project sponsor:
Project manager User
Project manager IT
Start date
End date
Budget, SAP ID
Internal resource (MD)
1.2 Comments
1.3 Document history
1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION
3. PROJECT GOAL
4. PROJECT SCOPE
4.1 Project scope
4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES
5.1 Project Output/deliverables
5.2 Acceptance criteria
Legend: Italic letters shows new items comparing to current PM documentation

37. Simple Project Charter
Deliverables
Simple Project Charter
6.TECHNICAL SOLUTION
6.1 Technical approach
6.2 Reusable artifacts that can be used
6.3 Reusable artifacts that will be developed
7. PROJECT IMPACTS
7.1 Dependencies
7.2 Organizational impacts
7.3 Risks
8. WORK BREAKDOWN, LABOURISNESS & TIME PLAN
8.1 Work breakdown and time plan
8.2 Test plan
8.3 Summary of internal resources
8.4 Metrics plan
8.5 Quality plan
9. BUDGET
9.1 Summary
CAPEX: … ths. Kč
OPEX: … ths. Kč
Total: … ths. Kč
9.2 Timing
9.3 Major deliveries (suppliers)
10. ECONOMIC STATEMENT (cost benefit analysis)
11. PROJECT ORGANIZATION
Project Sponsor
Project Steering Committee
Project Manager User
Project Manager IT
Project Team
Quality Assurance
12. FEASIBILITY STUDY
12.1 Technical feasibility
12.2 Economical feasibility
12.3 Operational feasibility
13. ASSUMPTIONS AND CONSTRAINS
14. ENCLOSURES
14.1 vendor contract
14.2 vendor PCH (equal to vendor accepted proposal)
Purpose
Simple 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.
Content
1. COVER SHEET
1.1 General Information
Project name
Code name
Description
Categories
Project sponsor:
Project manager User
Project manager IT
Start date
End date
Budget, SAP ID
Internal resource (MD)
1.2 Comments
1.3 Document history
1.4 Checked / approved by
2. CURRENT STATUS DESCRIPTION
3. PROJECT GOAL
4. PROJECT SCOPE
4.1 Project scope
4.2 Out of project scope
5. PROJECT OUTPUT/DELIVERABLES
5.1 Project Output/deliverables
5.2 Acceptance criteria
Legend: Italic letters shows new items comparing to current PM documentation

38. User manual Deliverables 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.

39. Operational manual Deliverables Purpose
Operational manual is part of system documentation. It explains how to administer and operate the system.
Content
Administration 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.

40. Test scripts and Test results
Deliverables
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.
Content
Test 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
Results of particular test runs and test cases. Documentation of any test discrepancies.
Run 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.

41. Project evaluation Deliverables 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.

42. Pilot Result Deliverables 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

43. Roles descriptions

44. Roles description 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-points
This 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)
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
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

45. 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
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

46. 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

47. Please print from attached file on A3 paper format
Process models
Please print from attached file on A3 paper format

48. Define requirements and justify

49. Define management documents

50. Model

51. Program, generalize and test

52. Program, generalize, test and model - extreme project

53. Tiny Development Projects

54. Deliver & Test

55. Pilot Operation

56. Support in Pilot Operation

57. Assess

58. Support