Project Delivery Methodology on a page with activities, deliverables
•
0 likes•75 views
I've not found a 1 pager like this anywhere so I created it based on my experiences. This 1 pager details a waterfall style project methodology with defined phases, activities, deliverables, assumptions. There's nothing in here that conflicts with commonsense.
Report
Share
More Related Content
Similar to Project Delivery Methodology on a page with activities, deliverables
Similar to Project Delivery Methodology on a page with activities, deliverables (20)
Recently uploaded
Recently uploaded (20)
Project Delivery Methodology on a page with activities, deliverables
- 1. A - Analysis D- Design E - Development T – Testing & Operational Readiness P - Deployment O - Operations B - Business Case • Define business owner • Define drivers, pain points, shortcomings, opportunities • Define scope • Define funding source • Identify BC approval path • Define business benefits • Define expected outcomes • Define cost/benefits • Engage subject matter experts • Identify conceptual architecture • Identify technology solutions • Identify potential market solutions • Identify business impacts • Identify to-be business operating model (processes, roles, capabilities) • Identify customer impacts • Identify schedule for delivery of project and go live • Build stakeholder plan • Communicate to stakeholders • Develop and approve deliverables • Manage risks, issues • Produce status reports • Develop business change management plan Activities Deliverables Stage Gate Assumptions • D1 – business case • D2 – conceptual solution architecture • D3 – market scan • D4- conceptual target operating model • D5 – x-ref solution components, expected outcomes, business benefits, pain points etc • D5 – Project management plan (PMP) • D6 – project plan • D7 – Change Management Plan • D8 - status reports • S1 – business case approval • A1 – detail in business case depends on spend • A2 – acceptable financials for business case will depend on the organisation e.g. IRR, NPV • A3 – to complete the business case indicative costs for solutions will be needed • A4 – potentially the business case needs to cover multiple solution options, if an RFI/RFP is to be undertaken in the Analysis Phase • A5 – vendor evaluation occurs in analysis phase • A6 – business case would typically cover the entire project with refinements to occur post analysis and design phases • Gather and document business requirements within defined scope • Conduct business workshops • Conduct vendor solution assessment e.g. RFI, RFP • Develop solution architecture (all tech. domains) • Communicate to stakeholders • Develop and approve deliverables • Manage risks, issues • Produce status reports • Revise business change impacts • Validate business case, revise if needed • Develop change request • D1 – solution architecture • D2 – RFI/RFP (optional) • D3 – vendor selection report • D4 – solution architecture • D5 – revised business case • D6 – business requirements • D7 – x-ref of business requirements to solution components, expected outcomes, business benefits, pain points etc • D8 – Change request(s) • D9 – status reports • S1 – signed off business requirements • S2 -revised, approved business case • S3 – approved change requests • A1 – business requirements are captured at a level of detail that enables solution definition and design • A2 – vendor RFI/RFP is optional depending on the project scope but if a new solution needs to be picked it needs to be selected before design can commence • A3 – sometimes vendor solutions inform business requirements • Develop target business processes (L0-2) • Develop staff role changes • Revise solution architecture • Develop technical design documents (for development phase) in line with solution architecture covering integrations, UI, reports, security, infrastructure • Procure licences for target solution (if needed) • Define target solution configuration and customisation requirements to meet design • Manage risks, issues • Produce status reports • Revise business change impacts • Validate business case, revise if needed • Develop environment strategy • Develop testing strategy • Develop rollout strategy • Develop migration strategy • Develop information strategy • Revise business change management plan incl. training • Communicate to stakeholders • Develop and approve deliverables • Manage risks, issues • Produce status reports • Design target operating model • Validate business case, revise if needed • Develop change request • Complete vendor commercial agreement • D1 – solution architecture • D2 – business change mgmt plan • D3 – solution architecture • D4 – revised business case • D5 – business requirements • D6 – x-ref of business requirements to solution components, expected outcomes, business benefits, pain points etc • D7 – vendor commercial agreement • D8 - Change request(s) • D9 – env. strategy • D10 – rollout strategy • D11 – testing strategy • D12 – information strategy • D13 migration strategy • D14 – status reports • D15 – target op. model including business processes (L0-2) • S1 – revised solution architecture • S2 – approved change requests • S3 – revised, approved business case • A1 – additional deliverables may be needed if a vendor solution is being acquired, and these may be developed by the vendor or system integrator.. • A2 – assumes vendor commercial agreement occurs here post RFP completion (if this was in scope of the project) • A3 – various strategies listed as deliverables are specific to this project • A4 – D15 is the primary definition of the congruent business changes needed alongside the new system Phase • Setup environments • Setup code version control and build solution • Develop code and unit test for system • Develop integrations • Configure system • Configure security • Configure infrastructure • Setup master data in system, golden copy • Conduct showcase • Resolve unclear business requirements • Develop change request • Manage risks, issues • Produce status reports • Define training material and online help • Communicate to stakeholders • Create test data, test plans • Develop data migration scripts and test • Conduct functional testing • Conduct system integration testing • Conduct user acceptance testing • Conduct performance testing • Conduct security testing • Record defect • Resolve defect • Develop workaround • Build release and migrate to environment • Develop operational processes, policies, work instructions to production ready standard for business users • Prepare helpdesk to support new solution • Conduct end user training • Setup cutover triage and hypercare team • Develop operational processes for the system support team, and setup system tasks e.g. backups • Develop change request • Manage risks, issues • Produce status reports • Communicate to stakeholders • Conduct data migration • Conduct dry run cutovers • Cutover to production • Tune system • Triage defects • Triage unplanned issues during cutover • Cancel cutover if needed and restore legacy system • Provide hypercare • Develop defect fix or emergency fix • Deploy fix to production • Issue communications to staff or customers as needed • Develop change request • Manage risks, issues • Produce status reports • Conduct DR test • Communicate to stakeholders • Design, develop defect fix • Design, develop functional enhancement • Test defect fix • Test functional enhancement • Schedule release to production • Package release • Put release into production • Rollback production release • Plan releases for defined period and allocate changes to releases • Ensure backups are operational • Conduct DR test • Mitigate system performance issues • Plan for vendor software upgrade • Implement vendor software upgrade • Issue comms on planned outage • Triage unplanned outage • Rectify unplanned outage • Respond to helpdesk ticket • Produce system status report e.g availability, defects, performance • Update online help • Update training material • Communicate to stakeholders • D1 – user communications • D2 – release notes • D3 – defect report • D4 – code and configuration • D5 – online help • D5 – training material • D6 – DR test report • D7 – test data • D8 – test plans • D9 – test results • D10 – UAT testing report • D11 – SIT testing report • D1 – defect report • D2 – release notes and cutover report • D3 – User communications • D4 – code and configuration • D5 – DR test report • D1- test results • D2 – training material • D3 – release notes • D5 – security testing report • D6 – performance testing report • D7 – UAT testing report • D8 – SIT testing report • D9 – Operational processes, policies, work instructions for business • D10 – IT operational process for system • D11 – helpdesk readiness report • D1 – test data • D2 – test plans • D3 – code and configuration • D4 – Change request • D5 – training material • S1 – functional requirements for go live are delivered in a working solution (subject to post-unit testing) • A1 – environments such as QA, SIT, UAT may be needed for the new system as well as systems that will be integrated to • A2 – development could occur iteratively e.g. sprints • S1 – system passing testing, security, performance criteria and thresholds • S2 – business endorse system readiness and confirm operational readiness • A1 – multiple cycles of testing are likely to be needed • A2 – frequency of deploying defect fixes from dev to test depends on the project • A3 – end user training should be contextualised for the specific business and reflect the target operating model also i.e. not be solely focussed on IT • S1 – system goes live • S2 – system operational for 48 hours • S3 – business operating as intended • A1 – dry run cutovers simulate the production cutover and typically span the full end to end cutover activities including data migration • S1 – periodic system status report • A1 – assumes that a vendor solution is involved but this may not be the case • A2 – this is post go live and post hypercare BAU for the new system Notes: • Deliverable # are unique to the phase • Activities in each phase not listed in a particular order • Depending on the scope of the project certain activities and deliverables may not be relevant • Structure and content of each deliverable needs to be defined and tailored for the scale and complexity of the project • Though this is a waterfall approach most of the activities and deliverables would still be needed in an project applying an agile/iterative approach • Author: Clive Minchin 25-07-2024 • Budget control • Ensuring quality in terms of activities and deliverables • Accurate project status reporting • Effective scope management • Strong business engagement and consultation • Effective risk and issue management • Team engagement, consultation and alignment Key Success Factors (all phases)