IT Project: System Implementation Project Template Description

2929 Campus Drive Suite 250 IT Project: System Implementation Project Template Description Table of Contents Introduction... 2 Project Phases... 3 Initiation & Requirements Gathering Milestone... 3 Initiation kickoff Meeting... 3 Requirements gathering - data gathering, interviews, analysis of documentation... 3 Develop a requirements register... 4 Go / NO Go Gate Milestone... 4 PDR Preliminary Design Review Milestone... 5 SRR System Requirement Review... 5 SDR System Design Review... 6 Finalizing PDR... 6 CDR- Critical Design Review Milestone... 7 Development Freeze Milestone... 7 DTR- Delivery Tests Review... 8 FQR- Formal Qualification Review Milestone... 9 Deployment... 10 Appendix A Recommended Documents per Project Phase... 12 Appendix B Project Charter Template... 12 Appendix C Service Level Agreement Template... 13 Appendix D - Recommended Tests... 14

Introduction This document describes an IT Project template for System Implementation. The purpose of the template project is to develop & implement a new Information System within the company. Note: Presented here is a generic template. It is possible that one or more phases or tasks may not be relevant for the system implementation project in your organization or it may be necessary to add other essential activities. You can easily adjust the template to your organization business environment by deleting irrelevant activities or by adding new milestones and tasks. Project Main Milestones The project has been divided into phases and milestones, with the respective activities broken down in each phase. Using this Clarizen template will allow you to manage your IT project from the initial concept phase through requirement gathering and to a Go- No Go decision about deploying the new system in your company. Clarizen s roadmap view provides you with the clear view of the project s progress. Capturing Project Knowledge In the description of each phase you will find the lists of recommended documents that can be reviewed or prepared at that specific phase. You can combine recommended documents into one and adjust them to the needs of your organization. See also Appendix A for summary of all recommended documents per project phase. Keep in mind that documentation of all project concerns such as risks, system requirements, stakeholder s expectations, concerns and contact details, is strongly recommended. On the other

hand, creating and collecting documents is not the goal; documents are important for keeping the knowledge available for reference on future projects. Clarizen offers you several different means to document & trace the information related to a project: Standard documents that can be attached to the corresponding work items Notes written on the specific work items Discussions around the work items Emails sent directly from the application that are stored in Clarizen s repository and can be searched as any other data in the system. Risks to be directly logged into the risk assessment module Using the Collaboration View you will see an overview of all the collaborative data that was written for the specific project. You can also keep all or part of the collaborative data in the templates that will be used in the future projects. Project Phases Initiation & Requirements Gathering Milestone In this phase you will generate the ideas and concepts for the project and check its feasibility. The delivery of this phase will be an initial requirement definition document, sometimes called Requirement Register. This phase is usually followed by the Go / NO Go Gate milestone where the future of the project will be discussed and decided. Recommendation: Do not Activate the whole project at this stage. Activate only Initiation & Requirements Gathering and Go / NO Go Gate milestones. Activation or cancelation of the whole project will be decided at the Go / NO Go Gate phase. Initiation Kickoff Meeting The Initiation Kickoff meeting is an open discussion of the relevant stakeholders looking into the issue of a new Information system: concepts, needs, planned budget and other related issues. During this discussion you will look for answers to the following questions: Do we need a new information system or can we use available tools? What kind of a system is needed? What are the expectations? Who will be the owner of the system? Who will define the needs and what are the preliminary needs? When do we want the system up and running? Do we need suppliers or subcontractors involved? Note: Please pay specific attention on the recommendations embedded into this document related to communication with the subcontractors and vendors. Requirements Gathering - data gathering, interviews, analysis of documentation The purpose of this task is to understand the requirements for the new information system. You may want to interview various stakeholders, analyze relevant materials that could be previously documented in the form of the internal guidelines, meeting minutes, etc.

Note: This phase may involve issuing an RFP (Request for Proposal) for outsourced work if you decided to work with subcontractors. Develop a Requirements Register The purpose of this task will be to document the requirements gathered during the previous project activities in an orderly fashion. You may want to present the requirements in table form. It is recommended to include the reason each requirement originated, along with the contact details of the stakeholder who brought it up. It can be very helpful to prioritize the requirements. No. Description Catego ry Priority (*) Requestor / Stakeholder Requestor / Stakeholder Contact Details 1 We need a system to contain the cost & budget information of each & every project, according to project codes & work packages Cost 1 Dan Kevin Email: danb@clarizen.com Phone: 123456 (*) Priority: 1 highest; 3 the lowest Recommendation: If your project deals with hardware and technical performance - you can see the QFD (Quality Function Deployment) technique. This technique can help you to better prioritize system requirements. Take into consideration that there is also software available for requirement documentation and management. You can read about QFD in Wikipedia: http://en.wikipedia.org/wiki/quality_function_deployment Go / NO Go Gate Milestone This is a Go / NO Go decision gate milestone. Here you analyze the technical and functional requirements, budget requirements as well as time frame requirements and decide whether the project should be continued or canceled. If the decision is negative, Cancel the whole project. If the decision is positive and the project is considered to be beneficial, determine if you need to fine tune the planning of the future stages and then Activate the project. Recommendation: If you are a subcontractor that will perform a project, this is a good time for you to receive Receipt Order (RO). If you are the customer and do not have the ability or desire to execute this system design and implementation project in house - you may need to issue a Purchase Order (PO) to your chosen subcontractor, after you have examined the RFP responses. At this point, you generally put together an initial management plan, which may be called a Project Charter. The Project Charter is a high level view of what the system design and implementation project is about and may include: The project s business needs and justification

The project s objectives- both technical, as well as relating to the main requirements, budget, quality, target time frame and other relevant issues How success will be measured (also referred to as success criteria ) Who is the project manager and what is his\ her authority? Assumptions and constraints You can find the template for the Project Charter in Appendix B. PDR Preliminary Design Review Milestone In this phase we examine and elaborate on the chosen preliminary design or architecture of the system in aspects of applicability, compatibility (or suitability) and its ability to meet the main criteria and requirements, which were defined earlier. We also perform necessary changes to the design and write an initial test plan. At the end of this phase we have a preliminary technical design and an initial test plan. This phase may also contain three initial stages: SRR System Requirement Review, which usually produces an SRS System/Software Requirements Specification and SDR System Design Review, which usually produces an SDD System/Software Design Descriptions STP- System/Software Test Plan, in this phase you may write a first draft of the STP, a plan for conducting qualification testing which will be finalized in the next phase- CDR (Critical Design Review) These three deliverables (SRS, SDD, STP) are also part of the standard for MIL-STD-498 often used as the United States military standard whose purpose is to "establish uniform requirements for software development and documentation These stages are optional. Most projects combine activities required at these stages into the overall preliminary design activities. SRR System Requirement Review At this phase you will elaborate and refine the requirements, analyze the data, as well as create a common language with the customers and\or users of the systems. Your purpose at this stage will be to finalize the requirements for the future information system. At this stage you will analyze & define: Customers constraints Required design System characteristics External interfaces Analysis of the potential for additions or growth of the system or, on the contrary, the analysis of the possibility that the system may become obsolete Competition information or details regarding similar systems Cost targets, including LCC analysis: Life Cycle Cost analysis RAMS requirements - Reliability, Availability, Maintainability and Safety Analysis should be summed up in formal documentation and shared with all the stakeholders of the project. Following are recommended documents: Contract Technical design Detailed requirement document

SOW- Statement Of Work (also called Scope Of Work sometimes) The SRS, SDD and the preliminary STP documents (if written) may be elaborated at this phase to include further details. SDR System Design Review At this phase you will examine the chosen concept and compare it to the main requirements and the main criteria. You will start preparing the preliminary design of the system, focusing on: External interfaces (which were defined in the SRR phase) Main components or modules. We would recommend you to Examine alternatives for the chosen solutions Summarizing constraints of customer and contractor Make risk analysis, including mapping of knowledge gaps, noted in a risk register Documenting chosen solution and reasons for choosing it Start system and preliminary technical design o Defining external interfaces o Defining critical components or modules Start initial planning of the project and create o Initial schedule o Initial resource plan o Initial cost andbudget plan Recommendation: Use the Risk Management module in Clarizen to define and manage your risks. If you need to purchase different software or hardware, this can be good timing to select vendors and suppliers. At the end of this phase we have a high level system design and may also have a preliminary technical design draft. This phase usually happens after signing a contract (in case of outsourcing the project, or parts of it). Finalizing PDR In addition to the analysis and definition described above, you need to create: Module, components, screen descriptions and drawings External and internal Interfaces definitions Summary of preliminary tests results (if there are any) or technical data regarding similar or earlier systems Defining external interfaces, in details Feasibility check of relevant technologies Calculations regarding systems tolerance and endurance Updates to the risk register and/or constraints register for risk management purposes Examination of the maintenance requirements of the system Examination of the ILS (Integrated Logistic Support) aspects You will need to finalize the preliminary planning of the project: Putting together an initial test plan (STP- System Test Plan) Schedule planning

Resource planning Vendors and suppliers selection (if needed) and management activities. Recommendation: See Clarizen Vendor page for vendor selection. Using this page you can overview rich list of vendors from different industries without leaving the application. Procurement plan Cost and budget planning, relating to all of the systems life cycle phases It is extremely important at this stage to revisit the project Success Criteria. In this phase we may present results or initial data to the users or customers of the system. Recommendation: See corresponding articles in the Clarizen Community Knowledge Base to learn how to schedule projects, plan project budgets, manage resources and more. CDR- Critical Design Review Milestone In this phase you will examine the design, elaborate to a mature design and\or develop it more if needed, define what needs to be developed, and check the system versus requirements and\or specs and\or standards and\or success criteria, including performing necessary changes. We also update and refine the initial test plan (from the previous PDR phase) as we go, to create a test plan. At the end of this phase we have finalized the Technical Design & Development Documentation, STP- System Test Plan, we will also have an SLA- Service Level Agreement, if required. At this phase you will need to refine and finalize the analysis and definitions that you started in the previous stages. Following is a list of the issues that may require your attention: Performance- checking and executing modifications according to the requirements and design Reliability - checking and executing modifications according to the requirements, standards and design Standards in the market and/or success criteria Change and configuration management, including impact analysis (relating to technological and technical impacts, schedule & cost impacts, risks impact, etc), including change log Verification and checks of the modules and components of the system Verification and checks of the internal & external interfaces of the system Definition of maintenance principles and/or SLA (service level agreement) principles. See example of the SLA document in Appendix C. At this stage you can finalize the project plan by: Checking and, if required, adjusting the costs and budgets related to all of the systems life cycle phases Performing Risk Management Performing Schedule Management Examining, modifying and elaborating the test plan created earlier in the PDR phase Important: Project planning should involve the whole Project Team including customers and sponsors of the project. Use a Top-Down or Bottom-Up approach to the planning. Delegate detailed planning to the functional managers that are responsible for specific activities. If your project is a long scale project, don t try to build detailed plan for the whole project term. Make estimations and define major milestones and tasks. Then plan as you go. Development Freeze Milestone

At this phase we develop components and modules that were defined at the previous stages. Keep your customer involved into the process. Do your best to organize the presentations of the intermediate results to the users and/or customers of the system. Remember you never can be 100% sure that your definition and design are perfect. Life is complicated and we all know that requirements have tendency to change during the project life cycle. Such an approach will help you to be sure that the system is being defined and implemented according to what the customer expects. In this phase we usually write a SUM- System User Manual - Instructions for hands-on use of the system to be elaborated, if needed, later on. At the end of this phase we have a SUM, as well as a developed system and its documentation. This phase may also contain three sub stages: Development in Development Environment- This is the working environment for individual developers or small teams. Development is done in isolation from the rest of the system modules or the rest of the tiers. The developer(s) can try radical changes to the system or code without adversely affecting the rest of system or the rest the development team. Development in Integration Environment - A common environment where all developers commit changes to the system or code changes. The goal of this environment is to combine and validate the work of the entire project team so it can be tested before being promoted to the Staging Environment. It is possible for Development and Integration to be the same environment. Development in Staging Environment as identical to the live environment as possible. The purpose of the staging environment is to simulate as much of the live environment as possible. The Staging environment can also double as a Demonstration/Training environment. DTR- Delivery Tests Review Note: This phase is sometimes called: TRR: Test Readiness Review or PRR: Production Readiness Review In this phase we test the system itself according to the predefined test plan. Testing may be performed against the requirements and\or specs and\or standards and\or success criteria and\or acceptance criteria. Results should be reviewed. It is highly recommended to document results of the tests, draw conclusions and perform necessary changes. This is also a good time for you to prepare an Deployment Plan & Training Plan for the next phase. At the end of this phase we have: Test results and a list of necessary changes or required improvements Executed changes or improvements that were considered a MUST for the release of the system Deployment Plan This phase usually happens after system design and implementation completion and before hand over or release of the system, prior to customers or users acceptance tests (if defined). This phase may also called FQR- Formal Qualification review. See Appendix D for the variety of tests that can be run at this phase. You should be sure that testing equipment will be ready prior to the beginning of this phase, specifically pay attention to the readiness of the auto test equipment. At this phase you will intensively use and update documents that were prepared at the previous stages of the implementation:

System design Technical design Test plan and test plan updates Flow chart of the test process Standards and specifications, success criteria Vendor and suppliers contractual obligations You will also deal with the creation of the new materials, such as: Summarized analysis of the test results, analysis tools Problem evaluations of the test process Change log or configuration change log (related also to change management) versus initial or original designs (system design and technical design) Implementation plan Training plan FQR- Formal Qualification Review Milestone Note: This phase may also be called ATR: Acceptance Test Review & release In this phase we make sure (through additional tests) that the system, in its final configuration, performs according to the defined requirements and standards and/or specifications and/or acceptance criteria. Quality assessment can relate to software, hardware, interfaces, physical characteristics, functionality, performance and other relevant aspects. Usually this phase also contains training sessions for the customers or users, or for the trainers of the customers or users (to train the trainers). This phase may contain the handover of the SUM System User Manual, if written. - If the system development was not done on the live environment than go live or perform the deployment of the system at this phase, after the testing the above elements. At the end of this phase we obtain a final approval from the user or customer regarding the completion of the system development, through a set of sign offs. This generally happens after System Tests and Delivery Tests Review phase. This is a final phase that results with the system up and running and operational, with proper sign-off from the necessary stakeholders. See Appendix D for the variety of tests that can be run at this point. At this phase you will intensively use and update documents that were prepared at the previous stages of the implementation, such as: System design Technical design Test plan & test plan updates Flow chart of the test process Standards and specifications, success criteria Contracts, SLA (Service Level Agreement) Summarized analysis of the test results, analysis tools Problem evaluations of the test process

Change log or configuration change log (related also to change management) versus initial or original designs (system design and technical design) Deployment plan Training plan Deployment At this phase you will deploy the system, according to the predefined deployment plan, as well as run tests on the live environment according to the System Test Plan (STP), and fix what need to be fixed. Project Closure & Start Maintenance Phase At this phase you will formally close the project. You will analyze the results of the project, drawbacks in the process and failures in communications between project stakeholders. You need to verify: Commissioning and final payments Vendor and suppliers contractual obligations Procurement documentation Sign offs of relevant documentation, such as delivery acceptance. This is also a good time for final closure of all relevant documentation, for example: Contracts User manuals to be handed over Technical design and system design Tests results documentation Performance documentation etc It s important for future projects success to arrange Lessoned Learned sessions with your project team. Be sure you document things in the notes related to specific milestones / project or attached documents. Working with Subcontractor in Clarizen It is highly recommended to add Subcontractors as a Resource, Manager or Reviewer of specific work items directly in your project. This will make a Subcontractor part of your team and thus will create much more productive communication between your employees and subcontractors. Add Subcontractors as External users to your organization and assign them to the relevant Subprojects, Milestones or Tasks. The application will take care of corresponding permissions; external user see only the work items that they are assigned to. Another option is to separate the work fulfilled by the subcontractor into a sub-project where the subcontractor will be defined as a project manager or a manager. In this case we still recommend having the key milestones of the subproject at the level of the master project. You can create a shortcut between the corresponding milestones in the subproject and master project to track the progress of the corresponding activities. Recommendation: Learn more about Shortcuts in the articles in Clarizen Community.

Appendix A Recommended Documents per Project Phase Project Phase Initiation & Requirements Gathering Go/ No Go Gate Document Requirement register, RFP Project Charter, RO or PO PDR Preliminary Design Review SRS, SDD, Preliminary technical design, Preliminary STP, SOW, Project plans (**) CDR- Critical Design Review Development Freeze DTR- Delivery Test Review FQR- Formal Qualification Review Deployment Closure Finalized technical design, SLA, STP Development documentation, SUM Tests documentation, Deployment plan, Training plan Tests documentation Tests & performance documentation Closure & procurement documentation (**) Project plans may relate to schedule, budget, resources and procurement Appendix B Project Charter Template 1. Project Title & Description------What? 2. Project manager & his\her authority -----Who? Can PM approve changes to scope (CR), budget, staffing? Schedule? 3. Business need\justification---- Project is being done in order to 4. Pre assigned resources----what\how many resources will be provided? 5. Stakeholders\Stakeholders requirements----example: system requirements related to system 6. Product deliverables\description----specific system deliverables\results at the end of the project 7. Summary budget 8. Constraints & Assumptions 9. Success criteria 10. Project Sponsor approval

Appendix C Service Level Agreement Template 1. General This document describes the service to be given and may contain details such as: Company AAAA will provide a point of contact for dealing with trouble shooting (if you already know who it will be, you can specify name, job title and contact details), relating to the following subjects: o A o B o C Addressing the point of contact can only be through three predefined representatives (if you already know who they will be, you can specify names, job titles and contact details) Material regarding the trouble shooting may be transferred through the following email: ****, or Fax number: **** Times of service: o Monday to Friday, 09:00-17:00, not including holidays o For problems defined as work stopping the support will be 24*7, including holidays Response time: o Problems defined as work stopping will start the trouble shooting process within 4 hours from the time the call was registered and will be dealt with until the problem is solved. o Problems relating to applicative modules of the production environment will start the problem shooting process within 12 hours from the time the call was registered and will be dealt with until the problem is solved. o Problems relating to the development environment or to the test environment will start the problem shooting process within 36 hours from the time the call was registered and will be dealt with until the problem is solved. 2. Term and termination Relevant details 3. Financial provisions Relevant details 4. Warranty and liability Relevant details 5. Access terms to customer or service provider location (security, data security, etc) Relevant details 6. Cancellation or termination terms Relevant details 7. Non completion by client and \ or by service provider 8. Relevant details 9. Governing law Relevant details- such as noting the relevant laws 10. Signatures Service provider company name & company details Service provider job title AAA BBB Client Company name & company details Client job title BBB AAA

Service provider authorized signature Client authorized signature CCC CCC Appendix D - Recommended Tests Performance tests Functional tests Activation tests Load tests Human machine interface tests (HMI tests) Integration tests (to make sure all systems\ subsystems\ components\ modules are working together) Inter system tests and\or internal + external interface tests Unit test (of a single module, component or unit) Survival and recovery tests Installation tests Conversion tests (in case data needs to be converted from one format to another) Compatibility tests (to make sure that the system is compatible for working in the required environments) Usability tests Regression tests (to make sure that former functionality still works) Sanity tests Security tests