Integrated Project Management and Solution Delivery Process

Project Management and Solution Delivery Process :

Project Management and Solution Delivery Process Alan McSweeney

Agenda:

January 9, 2011 2 Agenda Process Introduction Solution Delivery and Project Management Processes Solution Delivery Project Management Using the Process Using the Template Documents Feedback and Process Development

Objective:

January 9, 2011 3 Objective To provide you with an introduction to the proposed process and its operation and use in order to get feedback prior to its full implementation

Process Introduction:

January 9, 2011 4 Process Introduction

Project and Solution Delivery Process:

January 9, 2011 5 Project and Solution Delivery Process Benefits Consistency Speed Drives Delivery Ensures Acceptance Productivity Reuse Professionalism Customer Confidence Speed Accuracy Audit Trail Cost Saving Risk Management and Reduction Change Management and Additional Work Formal Project Closure Potential Disadvantages Time to Adopt Suitability Too Comprehensive Cost of Use Not Currently In Use Risk

Project:

January 9, 2011 6 Project Deliver defined objective/solution Must have a defined start and end Project management is concerned about delivering what has been committed

Why Use Processes:

January 9, 2011 7 Why Use Processes Increase credibility Increase visibility of the customer engagement Improving customer confidence and facilitating smoother engagements Improve profitability by customising pre-defined proven processes rather than developing new ones Reduce risk through improve planning competitors have them Eliminate surprises

Why Use Processes:

January 9, 2011 8 Why Use Processes Structure and mechanism for knowledge capture and reuse A means for the retention and application of company knowledge Reuse encouraged and will become the normal practice, with significant reduction in the development of non-reusable collateral Adaptive and creative Allowing personnel to follow a structure and focus on adding value New and developing resources are brought up to speed more quickly Resource Management Better understanding and definition of required skills Training based around methodologies, standard techniques, and tools

Why Use Processes:

January 9, 2011 9 Why Use Processes Initially painful Can seem to be longwinded They really do help Add value

Methodology and Processes:

January 9, 2011 10 Methodology and Processes Methodology without process is meaningless Process without usage is pointless Methodology (General Framework) Process (Actualises the Methodology) Use the Process (Achieve the Benefits)

Solution Delivery and Project Management Processes:

January 9, 2011 11 Solution Delivery and Project Management Processes

Project and Solution Delivery Process:

January 9, 2011 12 Project and Solution Delivery Process Two processes running in parallel Solution Delivery – delivery of the solution to the customer Project Management – management of the delivery of the solution Processes must work together Processes supported by document templates Templates used to capture and document information Templates provide a framework for management and control

Document Templates:

January 9, 2011 13 Document Templates Full set of project template documents Project Management - \PMO\PROJECT MANAGEMENT\ Solution Delivery \PMO\SOLUTION DELIVERY\

Slide 14:

January 9, 2011 14 Planning and Analysis Detailed Design Implementation and Installation Testing Training and Handover Support, Administration and Maintenance Initiation Scope Quality Communication Risks, Issues and Decisions Closure Project Management Solution Delivery

Use of Process:

January 9, 2011 15 Use of Process Tailor process to suit project Agree in advance how project is to be handled: Project management Solution delivery Use process appropriate for Project size Project complexity Number of participants role Customer

V Lifecycle Approach:

January 9, 2011 16 V Lifecycle Approach V Project Initiation Project Closure System Requirements System Testing High-Level Design Integration Testing Low-Level Design Component Testing Install and Implement Define Requirements and Solution Deliver Solution and Fulfil Requirements

V Lifecycle Approach:

January 9, 2011 17 V Lifecycle Approach Match project scope and solution design to what is delivered Ensure delivery matches what is committed Requirement drive delivery and closure Must identify and document requirements Must deliver on requirements Requirements may change during the life of the project Additional revenue

Solution Delivery Phases:

January 9, 2011 18 Solution Delivery Phases Planning and Analysis – customer requirements are captured and documented Detailed Design – the proposed solution is documented is detail Implementation and Installation – the solution is installed Testing – the solution is tested Training and Handover – the solution is handed over to the customer and training is provided Support, Administration and Maintenance – the solution is transferred to support

Solution Delivery Process:

January 9, 2011 19 Solution Delivery Process Document requirements Confirm requirements Design solution to meet requirements High level and detailed design Confirm solution design Implement solution Test solution and confirm requirements are met Handover solution and provide training

Project Management Phases:

January 9, 2011 20 Project Management Phases Initiation – the project is formally initiated Scope – project scope is managed and changes are captured Quality – project quality is managed Communication – project communications are managed and documented Risks, Issues and Decisions – project issues, risks and decisions are managed and documented Closure – the project is closed and moved to maintenance

Project Management:

January 9, 2011 21 Project Management Not sequential Controlling the project will lead to changes in project planning and execution Initiate Plan Execute Control Close P I E Cn Cl

Solution Delivery:

January 9, 2011 22 Solution Delivery

Solution Delivery - Planning and Analysis:

January 9, 2011 23 Solution Delivery - Planning and Analysis Final Requirements Checklist.doc This is a checklist to validate requirements. Functional Specification.doc This describes the functionality of the solution being delivered. Infrastructure Requirements Checklist.doc This is a checklist to infrastructure requirements. Non-Functional Requirements Checklist.doc This is a checklist to non-functional or operational requirements. Objectives and Requirements Specification.doc This documents the customer’s objectives and requirements. Requirements Traceability Log.doc This logs requirements to provide traceability to ensure they are delivered.

Solution Delivery - Detailed Design:

January 9, 2011 24 Solution Delivery - Detailed Design Detailed Design.doc This documents the actual solution design in detail. High Level Design.doc This documents the actual solution design at a high level. Proposed Solution.doc This defines the concept of the solution

Solution Delivery - Implementation and Installation:

January 9, 2011 25 Solution Delivery - Implementation and Installation Installation Plan.doc This documents how the solution will be installed.

Solution Delivery - Testing :

January 9, 2011 26 Solution Delivery - Testing Acceptance Test Package.doc This defines the approach to testing of the solution. Acceptance Test Specification.doc This details the set of tests to be performed to validate the solution. Fault Report Log.doc This is a log of any faults discovered during testing. Fault Report.doc This documents a fault discovered during testing. System Test Plan.doc This defines the plan for performing testing. Test Execution Log.doc This logs the testing performed.

Solution Delivery - Training and Handover:

January 9, 2011 27 Solution Delivery - Training and Handover User Documentation Manual.doc This documents the solution.

Solution Delivery - Support, Administration and Maintenance:

January 9, 2011 28 Solution Delivery - Support, Administration and Maintenance Operational Support Plan.doc This documents a plan to provide operational support. Service Level Agreement.doc This defines the service level to be provided. Solution Support Plan.doc This documents the level of support to be provided. Transfer to Support.doc This documents the transfer of the solution to support.

Project Management:

January 9, 2011 29 Project Management

Project Management - Initiation:

January 9, 2011 30 Project Management - Initiation Project Initiation Document (PID).doc This initiates the project. Statement of Work (SOW).doc This defines the scope of the work to be done. Project Organization Chart.ppt This describes the project organisation.

Project Management - Scope :

January 9, 2011 31 Project Management - Scope Issue Resolution Request.doc This documents an issue that has been raised that needs to be responded to. Change Request Log.doc This logs requests for changes. Change Request.doc This is used to document a request for a change. Solution Delivery Plan.mpp This is the project plan for delivering the solution.

Project Management - Quality:

January 9, 2011 32 Project Management - Quality Quality Log.doc This documents results of testing for quality logging. Quality Plan.doc This is a plan for managing project quality.

Project Management - Communication:

January 9, 2011 33 Project Management - Communication Communication Distribution Plan.doc This documents project communication. Communication Log.doc This logs communications. Customer Monthly Status Report.doc This is a sample monthly report. Customer Status Report Presentation.ppt This is a sample status report presentation Delay Notification Log.doc This is a log of delays that have occurred in the project. Delay Notification.doc This is a formal notification of a project delay. Information Request Log.doc This is a log of requests for information. Information Request.doc This is a request for information Meeting Agenda and Minutes.doc This is used to record meeting minutes. Project Monthly Report.doc This is an internal project report. Project Weekly Status Report.doc This is a sample weekly report. Steering Committee Meeting Agenda.doc This is a document for use with a project steering committee.

Project Management - Risks, Issues and Decisions:

January 9, 2011 34 Project Management - Risks, Issues and Decisions Actions-Issues-Decisions Log.doc This is a log of actions, issues and decisions. Decision Request.doc This documents a project decision. Issue Report.doc This documents a project issue.

Project Management - Closure:

January 9, 2011 35 Project Management - Closure Project Closeout Report.doc This documents project closure. Project Sign-off.doc This is used to record formal project signoff by the customer.

Using the Process:

January 9, 2011 36 Using the Process

Using the Process:

January 9, 2011 37 Using the Process Effective project and solution delivery steps 1 – Initiation 2 – Requirements 3 – Project Planning 4 – Solution Design 5 – Delivery and Testing 6 – Training and Handover 7 – Closure and Move to Maintenance

Project and Solution Process – 1 - Initiation:

January 9, 2011 38 Project and Solution Process – 1 - Initiation Copy folder structure into project location such as PROJECTS\<CUSTOMER>\<PROJECT> on shared folder Take project scope from previously submitted sales proposals Complete \Project Management\10 Initiation\Statement of Work (SOW).doc and send to customer for review and signoff Complete \Project Management\10 Initiation\Project Initiation Document (PID).doc if project justifies it (greater than 20 days effort) Rename the documents to include customer and project name <Customer> <Project> Project Initiation Document (PID).doc

Document Storage:

January 9, 2011 39 Document Storage Store template documents to shared location \PROJECTS\<CUSTOMER>\<PROJECT> Create separate folder in PROJECTS for each customer Create separate folder in PROJECTS \<CUSTOMER>\ for each project for the customer

Project and Solution Process – 2 - Requirements:

January 9, 2011 40 Project and Solution Process – 2 - Requirements Gather and define customer requirements using documents in \Solution Delivery\10 Planning and Analysis\: Objectives and Requirements Specification.doc Final Requirements Checklist.doc Infrastructure Requirements Checklist.doc Non-Functional Requirements Checklist.doc Manage requirements through life of project Requirements Traceability Log.doc Complete functional specification – defines what is to be done (not how) Functional Specification.doc See separate Requirements Management process to be used for larger projects

Requirements Definition and Documentation:

January 9, 2011 41 Requirements Definition and Documentation Requirements Definition Requirements Management Gather Analyse Review Assess Capture Change

Requirements Definition:

January 9, 2011 42 Requirements Definition Gather – Tasks relating to the initial gathering of requirements Analyse – Analysing and categorising requirements and specifying them Review – Agreeing (with the customer) exactly what the requirements are. Modify if necessary to reach agreement.

Requirements Classification:

January 9, 2011 43 Requirements Classification Business – objectives and goals to be delivered as a result of the solution Functional – what it does Technical – operational and procedural constraints Implementation – how the solution will be implemented Project – requirements of the project

Business Requirements:

January 9, 2011 44 Business Requirements Financial (Market share increase) Customer-related (On-time delivery) Business Processes (Business cycle times) Innovation and Learning Measures (Speed of completing transactions) Regulatory Requirements (Adherence to regulations)

Functional Requirements:

January 9, 2011 45 Functional Requirements Inputs Outputs Actions Responses Outcomes Usage

Technical Requirements:

January 9, 2011 46 Technical Requirements Performance (Response times, transaction throughput rates, batch job durations.) Volumes (Data capacity, network bandwidth, business units) Availability (Required uptime, daytime periods for which the system must be available) Resilience (No single point of failure, MTBF of components, switchover times) Recoverability (Backup times, tolerable data loss, offsite needs, recovery timescales) Scalability (How the solution will deal with more users/data, capability for predicted growth) Integrity (Degree of problems tolerated, problem detection needs) Interfaces (Internal and external, user, hardware, software, communications) IT Management (Event handling and classification, detection needs, management roles and processes)

Implementation Requirements:

January 9, 2011 47 Implementation Requirements Timescales (What are the desired target dates) Disruption and Impact (What levels of disruption can be tolerated) Data Conversion (What data needs to be migrated, how, and with what constraints) Supportability (What levels of support will be needed) Training (What staff require what new skills) Handover (Process of transfer of control, parallel run) Support Warranty (Coverage during warranty) Post-Warranty Operation

Project Requirements:

January 9, 2011 48 Project Requirements Implementation Testing Facilities

Requirements Management:

January 9, 2011 49 Requirements Management Capture – Ensure that the new requirements or change requests are captured Assess – Consider whether the changes will be actioned. Approve or reject Change – Undertake the changes

Project and Solution Process – 3 – Project Planning and Management:

January 9, 2011 50 Project and Solution Process – 3 – Project Planning and Management Complete first draft of project plan

Project Planning and Management:

January 9, 2011 51 Project Planning and Management Standard project plan structure Initiation Planning Executing Project Management Closing Customise detail for individual project

Managing Change:

January 9, 2011 52 Managing Change Changes during the course of a project are inevitable and can affect the scope, cost, delivery, and nature of the deliverables as well as the functioning of the project team Change Management is a systematic process that allows for changes and at the same time aims to minimise the negative consequences of these changes Change process must be included in the project initiation material and published to the customer

Change Process:

January 9, 2011 53 Change Process

Change Control Templates:

January 9, 2011 54 Change Control Templates \Project Management\20 Scope\ Issue Resolution Request.doc – document issues Change Request Log.doc – maintain log of change requests Change Request.doc – document change request and document outcome

Risk Management:

January 9, 2011 55 Risk Management Risk All projects have risks Need to identify and manage Action can be taken to mitigate/circumvent risks Minimise the negative risk impacts Risk management steps Risk Management Planning – determine the approach to risk management Risk identification - identify all known project risks Risk Analysis - perform an assessment of the probability of occurrence and potential impact Risk Response Planning - create action plans to manage the identified risks Risk Monitoring and Control – monitor, review and update risk status and plans Risk Closeout – document lessons learned Take appropriate approach to managing risk

Issue Management:

January 9, 2011 56 Issue Management Issue management Identifying, tracking, resolving, and communicating to project stakeholders the issues that arise out of day-to-day project execution ongoing process, from start to closure of any project and it is a critical component of project monitoring and control activities Steps Identify Project Issues Establish Issue Tracking Evaluate the Issue Determine Issue Resolution Implement Issue Resolution Close the Issue Take appropriate approach to managing risk

Risk and Issue Management Templates:

January 9, 2011 57 Risk and Issue Management Templates \Project Management\50 Risks, Issues and Decisions\ Actions-Issues-Decisions Log.doc Decision Request.doc Issue Report.doc

Project and Solution Process – 4 – Solution Design:

January 9, 2011 58 Project and Solution Process – 4 – Solution Design Complete solution design using documents contained in \Solution Delivery\20 Detailed Design\ High Level Design.doc Detailed Design.doc Proposed Solution.doc Not always necessary to use all documents Depends on project size and approach Could have single design document

Project Reporting:

January 9, 2011 59 Project Reporting Define communication structure during initiation Status reports Frequency - weekly, fortnightly, monthly Content/agenda Meetings Frequency - weekly, fortnightly, monthly Content/agenda Levels – project team, project steering group

Project Reporting:

January 9, 2011 60 Project Reporting Use documents in \Project Management\40 Communication\ Document how communication is handled - Communication Distribution Plan.doc Log communications - Communication Log.doc Meetings Meeting Agenda and Minutes.doc Steering Committee Meeting Agenda.doc Reports Customer Monthly Status Report.doc Customer Status Report Presentation.ppt Project Monthly Report.doc Project Weekly Status Report.doc Other communications Delay Notification Log.doc Delay Notification.doc Information Request Log.doc Information Request.doc

Project and Solution Process – 5 – Delivery and Testing:

January 9, 2011 61 Project and Solution Process – 5 – Delivery and Testing Deliver solution \Solution Delivery\30 Implementation and Installation\ Testing \Solution Delivery\40 Testing\ Acceptance Test Package.doc Acceptance Test Specification.doc Fault Report Log.doc Fault Report.doc System Test Plan.doc Test Execution Log.doc Test against requirements Log results of tests to establish audit trail

Project Quality:

January 9, 2011 62 Project Quality \Project Management\30 Quality\ Quality Log.doc Quality Plan.doc Ensures that quality is built into project from the start Delivers real benefits Reduced testing Reduced rework Increased customer satisfaction Increased project profitability

Project and Solution Process – 6 – Training and Handover:

January 9, 2011 63 Project and Solution Process – 6 – Training and Handover Handover \50 Training and Handover\

Project and Solution Process – 7 – Closure and Move to Maintenance:

January 9, 2011 64 Project and Solution Process – 7 – Closure and Move to Maintenance Closure and Move to Maintenance \Project Management\60 Closure\ Project Closeout Report.doc Project Sign-off.doc \Solution Delivery\60 Support, Administration and Maintenance\ Operational Support Plan.doc Service Level Agreement.doc Solution Support Plan.doc Transfer to Support.doc

More Information:

January 9, 2011 65 More Information Alan McSweeney alan@alanmcsweeney.com