Framework Overview

The Project Delivery Framework consists of a high-level

understanding of how projects are organized in relation
to each other and specific approaches, practices, and
sub-frameworks that have been designed for particular
types of projects.

Introduction
Here is a high-level view of the Project Delivery Framework:

The diagram above shows a high-level example of a project scheduling plan with an initial implementation project split
into three releases, followed by an integration project and a migration project. The first release of the implementation
project is then expanded to show the phases.

The names of the phases shown here are based on the naming convention in DSDM’s Agile Project Management
Framework, however, they could easily be named differently. It’s the activities and deliverables within the phases that
are important.

The Project Delivery Framework makes a distinction between projects and application management, where:

Projects are blocks of distinct work with the aim of delivering a certain scope within a certain timeframe for a
certain cost (and an assumed level of quality).
Application management is the continuous support, operations, and maintenance of the live solution once it's
been deployed to a live production environment and is being used by end users.

Projects typically run sequentially delivering into the parallel application management stream. This starts with the initial
implementation project, often split into a set of sequential releases, followed by ad hoc or continuous projects in parallel
to application management activities, continuing on an on-going basis until the solution is eventually decommissioned.
Together this cycle of projects is called the application lifecycle.

There are also different types of projects, not just the initial implementation project. There may also be subsequent
functional development projects, system integration projects, internationalization projects, migration projects,
infrastructure projects, etc. and some projects that are a mixture of types if combined.

The Project Delivery Framework can be used as a reference for all of these projects and is adaptable to different
software development lifecycle (SDLC) methods such as Agile, Rational Unified Process (RUP), or waterfall, and it's
applicable to Project Management Institute (PMI) and Project Management Body of Knowledge (PMBOK) best
practices.

The framework is neither rocket science nor revolutionary. Its intention is to define a common and generic set of
practices and approaches that can be readily understood and used as the basis for a variety of more specific
frameworks and practices that can be selected based on the appropriate project context.

Many customers and partners will have their own methodologies or delivery frameworks, created and suited for their
own contexts and strengths. Some will be based on common SLDC methods, some will be hybrid approaches, or based
on less well-known SDLC methods. There's no right or wrong approach. It's all down to the specific context of a given
project and organization.

Therefore given the variety of contexts, it's important that the Project Delivery Framework is equally understandable to
someone from a waterfall background, or RUP background or someone using a hybrid approach with their own naming
conventions. So each phase within the Project Delivery Framework is within a generically named block:

Discovery & planning - the where/why/how/what of the project, including scoping, architecture, planning and
costs
Design/build/test – the building of the solution, whether iteratively (e.g. Sprints) or broken down into sequential
design/build/test sub-phases
Deploy – the preparation and delivery of the solution into the live production environment.

Releases
A large project is often broken down into slices or increments called a 'release'. The size of a release can vary
depending on the context. An example would be breaking down a 12-month project into 2-4 smaller releases of
relatively equal duration, with each release containing all the project phases as shown below:

The set of sequential phases would then start again with the next release, although the initial up-front Initiation phase
that assesses the project feasibility, business case, high-level scoping, etc. is often not required as the outputs of the
previous Initiation phase are still valid.

Smaller releases can help to reduce project risk, improve time-to-market and give more immediate visibility to the
business and end-users, however, they need to be balanced with the overheads involved starting/ending each release.

Alternatively, some organizations take this even further by utilizing Continuous Delivery methods to enable continuous
deployments to production on a weekly or even daily basis rather than releases spanning weeks or months. However
Continuous Delivery is not easy and ideally needs to be built into the project from day one. It requires significant
investment and the business drivers need to be properly assessed to match the frequency of releases. Not all
organizations can properly handle or need such regular deployments.

Initiation Phase (Discovery and Planning)

The primary objective of this phase is the alignment between the customer and the delivery team in terms of the
why/what/how/when of the project. The customer could be another organization or another department within the same
organization. The delivery team might be an in-house IT department or an external service provider. There might be a
commercial relationship, there might not. However, the high-level activities of this phase remain very similar and
include:

Alignment on the vision and business goals of the project

Alignment on project methodology
Identification of high-level functional and non-functional requirements
High-level requirements prioritization
Identification of key milestones, e.g. project start and go-live dates
Early identification of 3rd party and external system dependencies
Early identification of project and technical risk
Creation of a release roadmap
Understanding of the high-level scope & estimated effort of the project/releases
Creation of high-level project plans, with estimated timescales and costs

Ultimately the result of this phase is a go/no-go for the next phase to understand the project in more depth, called the
Foundation phase.

Foundation Phase (Discovery and Planning)

The primary objective of this phase is to establish firm foundations for a project from a business, technical and project
management perspective, and to enable all parties to have a solid understanding of the scope/time/costs/risks of the
project.

The phase consists of a series of onsite workshops with the customer and delivery teams, plus key stakeholders and
3rd parties. The specific activities and deliverables of this phase can vary depending on the methodology however they
generally remain very similar (although granularity will vary greatly between different methods, so waterfall will have
much more detailed requirements definition than Agile):

Appropriately detailed definition of functional requirements (prioritized if Agile)

Appropriately detailed definition of non-functional requirements
Architecture design (logical, physical, data, security, etc.)
Appropriately detailed system integration architecture & design
Definition of quality management (testing) strategy
Risk identification and mitigation
Communications planning
Change management
Resource planning
Definition of project governance, organization, and structure
Refined project plans, timescales, and costs

Usually, the result of this phase is a go/no-go for the build phase of the project, called the Engineering phase. However,
sometimes there is still too much uncertainty (technical or otherwise) which prevents the teams from having enough
understanding of the risks to give the go-ahead for the full Engineering phase, which is essentially the go-ahead for the
whole project due to the very significant commitment of resources and people. In this case, teams may want to proceed
with a smaller, optional, Exploration phase.

Exploration Phase (Discovery and Planning)

This is an optional phase. It's only required if there remains a high degree of uncertainty or risk following the Foundation
phase. The primary objective is to explore those risks and uncertainties in enough depth to provide the teams with the
confidence to proceed with the larger Engineering phase and essentially commit to the project.

Given that risks and uncertainties are project specific, they can vary widely, so the activities of this phase will also vary.
However, typically they are technology related, and often involve the development of prototypes or proof-of-concepts.
These can be throw-away or designed to be reused if the project goes ahead.
These types of phases are more common on greenfield or build-from-scratch projects, especially when using new or
leading-edge technology stacks with challenging non-functional requirements such as very high numbers of requests or
data volumes. They are less common when building a solution from a mature platform such as Hybris Commerce,
however, an Exploration phase can still be valid where needed, e.g. if using Hybris Commerce to build a mission critical
solution with non-functional requirements that exceed the boundaries of the design criteria for the Hybris Commerce
platform.

Typically the Exploration phase is relatively short in duration, just enough to provide appropriate certainty to make a
go/no-go decision for the project, starting with the Engineering phase.

Engineering Phase (Design / Build / Test)

The primary objective of this phase is to design, build and test the solution to meet the functional and non-functional
requirements and the high-level architectural design defined in the Foundation/Exploration phase.

The approach taken to develop the solution will vary significantly depending on the SDLC method. Some methods will
break this phase into small 2-3 week iterations called sprints each with smaller design/build/test cycles (e.g. Scrum),
others will have larger, more well-defined design/build/test cycles maybe even with their own sequential gates and
sign-offs. For example, a waterfall approach would split this into three separate design, build and test phases.

This phase will also include some form of acceptance testing, often planned as a block of time at the end of this
phase, however, sometimes acceptance testing is managed iteratively throughout this phase. System
integration, performance, and other non-functional testing are also key activities of this phase.

Ultimately the end result should be a high-quality solution that meets the functional and non-functional requirements and
is ready for deployment to the production environment within the Deployment phase.

Deployment Phase (Deploy)

The primary objective of this phase is to prepare and deploy the software produced in the Engineering phase to the
production environment, ready for use by end users.

The activities of this phase can vary significantly depending on the project context, however, typically they will include:
 Readiness of the production environment & data
Deployment of the final release candidate to the production environment
Support during go-live & immediate post-live support

Teams may plan not to take the solution live in the current release for business or technical reasons (perhaps the
customer is replacing an existing platform and there is only a subset of the current, live functionality in this release), so
this phase is not mandatory. However, there are strong technical and business advantages to deploying early to test the
solution in the real “live” environment, even if it's a 'soft' launch (e.g. friends-and-family) with a subset of users. Early
feedback at this early stage can significantly reduce the risks inherent with a big-bang deployment later.

Application Management

Application management is not a phase or even a project. It's a continuous workstream providing support and live
operations management, and often also providing maintenance and on-going smaller development work that can be
delivered outside of a project context.

This workstream starts with the first deployment to production from the initial implementation project, however, it needs
to be planned from the start of the project to ensure responsibilities are clearly defined and people are appropriately
trained and enabled. The project team can sometimes manage some of this workstreams responsibilities. However, it's
often managed by a separate specialized team.

Regardless, just as much thought and planning should be dedicated to application management as projects. There's no
point having the best solution in the world if you can't run it. Poorly managed live solutions can have a significant impact
on end users and ultimately a customer's brand and reputation.

Typical application management activities can include:

1st, 2nd, 3rd line support

Development of a knowledge base
Investigating and resolving break-fix incidents, e.g. fixing/working around technical issues
Managing and resolving service requests, e.g. supporting business users
Prioritization and management of incidents/requests
Production environment tuning, monitoring & reporting
Development of change requests
Creation of maintenance and hotfix packages for production deployment
Coordination with hosting/managed services teams and other operational/system integration teams
Release and deployment management
Coordination with project development streams