Table of Content

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 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 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. 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 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. 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 Overview Process model structure for Initiate and Construct phases 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 approveBusiness model • Develop and approveConceptual 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, Tiny projects Small, Big “Extreme” projects Big standard projects

10. Process Overview Process model structure Deliver and Support phases Models Model content Tiny development projects Program, generalize, test and model - extr. projekt 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 Tiny projects Standard / “Extreme” 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 (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. 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 toassist 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. Flow of deliverables Phases Initiate and Construct for standard projects Deliverable type Phase Proj. mgmt. System Test Manuals RFS Define requirementsand justify RFS Project Definition Approved PD Initiate Define management documents Project Charter Approved PCH Model BusinessModel Updated PCH ConceptualModel Construct Program, generalizeand test Updated PCH ProgramCode

14. Flow of deliverables Phases Initiate and Construct for tiny projects Deliverable type Phase Proj. mgmt. System Test Manuals RFS Define requirementsand justify RFS Small Project Charter Initiate Define management documents UpdatedBusinessModel Model Updated ConceptualModel Construct Program, generalizeand test BusinessModel ProgramCode Conc.Model

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

16. Flow of deliverables Phase Deliver Deliverable type Phase Proj. mgmt. System Test Manuals Conc.Model Deliver and test ProgramCode Bus.Model Updated PCH User manual Operationalmanual Updated PCH Training manual Test scripts Deliver Test results Pilot Pilot results Updated PCH Assess Projectevaluation

17. Flow of deliverables Phase Support Deliverable type Phase Proj. mgmt. System Test Manuals Conc.Model User problem User manual Operationalmanual ProgramCode Bus.Model Support, Support in pilot User problem User problem Support Trouble report InternalRFS

18. Process descriptions

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

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

21. Process description Model 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). 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

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

23. Process description Program, generalize, test andmodel - Extreme projects • 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 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 (cont.)

24. Process description Program, generalize, test andmodel - 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. Process description Tiny development projects • 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. 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

26. Process description Deliver and test 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 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

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

28. Process description Support in pilot 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 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

29. Process description Assess 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 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

30. Process description Support 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 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

31. Deliverable description

32. Deliverables 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. 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 Supportis 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. 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 definitionis 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. • 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. Deliverables Project Charter (PCH) • 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. Deliverables Small 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 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. 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. Deliverables 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.

39. Deliverables Operational manual • 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. 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 • Purpose • Results of particular test runs and test cases. Documentation of any test discrepancies. • Content • 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. Deliverables 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.

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

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) • 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

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

46. Roles description 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. Process models Please print from attached file on A3 paper format

48. Define requirements and justify

49. Define management documents

50. Model