- Because each success experience has required a unique approach this model primarily illustrates the categories of activity and what they entail rather than their order or separation. The model is always tailored to suit each unique project and any formal or informal established models within the customer’s Enterprise.
- For example on some Enterprise Delivery projects it has been prudent for the customer’s IT Department to have a view of the ‘Technical Architecture Preparation’ challenge much early on and as part of the ‘Business Requirements Focus’.
BUSINESS REQUIREMENTS FOCUS
Initial analysis is carried out in order to fully understand the brief. This is essentially a capture of high-level business requirements. It includes gaining an understanding of the opportunities, the background, the issues, the processes, the existing business model (the business architecture).
BUSINESS CASE
An outline of the features to be realised in the future state. The proposal of costs and the effort required. A statement of the benefits, ideally monetised in order to gain strong business sponsorship.
SCOPING
A more detailed analysis and definition of what is included in the project Delivery and highlighting of any aspects to be more firmly defined during the life of the project.
Some Customers have required a significant investment of time and effort with this aspect, which has been essential given some organisation wide projects and established Enterprise cultures require extensive, and weighty project mobilisation activity for momentum to be gained. Also project activity exposure and sense checking of the project artefacts at this early stage can save huge amounts of time later on by building confidence, strengthening stakeholder engagement, insuring sponsorship, agreeing funding and attracting focus. This is achieved by educating and involving all concerned parties on progress.
HIGH LEVEL PLANNING AND ESTIMATION
Regardless of whether the project is Agile, Waterfall or something in between, this aspect involves estimating resources required either from external sources or from within the organisation to inform an initial planning exercise.
Timelines established at this stage help give an early view of sprint and/or work package planning and indicative Delivery dates.
Depending on the type of project, this aspect is often extended to include the resources required to maintain and support the future state so the Enterprise can understand the future state operating costs.
SOLUTION DEFINITION
A specification of the ‘As-Is’ and the ‘To-Be’ systems architecture. This focuses primarily on the applications, software, data, and any data migration challenges and systems integration.
TECHNICAL ARCHITECTURE PREPARATION
Specification and preparation of the hardware, networks and security. This is often progressed closely with customer technical teams to ensure the solution is not only consistent with the customer’s technical stack but to permit sensible checkpoints being followed to enable efficient transition to technical sign off and a supportable, continuous and sustainable future state.
CONTINUOUS ITERATIVE DELIVERY TO THE ENTERPRISE
This principle is applied by Enterprise Delivery to both Agile and Waterfall project methods. Whether project Delivery is divided into Agile Sprints formed from a Product Backlog or individual Work Packages that may be programmed into a Waterfall Plan, Enterprise Delivery prescribes management of these packages of effort as consecutive cycles in order to give continuous transparency to Stakeholders and Customer teams.
Again as with the overall process, these cycles and the quantity of them are tailored to suit localised and individual projects and also in alignment with how the Enterprise likes to get things done. For example, it has often been necessary to commence Business Change activity earlier in the cycle and even from the outset of the entire project.
ITERATION PLANNING AND PRIORITISATION
Detailed planning of what will be accomplished in the next work package or iteration of work. How it will be achieved, by whom and what exactly is the behaviour of the solution being sought. This is another opportunity for all involved to challenge and understand the interdependencies between deliverable chunks of work.
TECHNICAL OPERATIONAL SUPPORT AND REVIEW
Evaluation and communication with Technical operational and support teams to ensure all that is needed is appropriate and is in at a state of readiness to support, test and release what is about the be developed.
DEVELOPMENT
This primarily includes the writing of the software and often encapsulates the testing activity. Enterprise Delivery seeks this activity to happen as iteratively as possible with features divided into small deliverables for frequent inspection, customer team inclusion and strong daily communication to support the requirements definition and decision-making that guides development.
TESTING
Testing of the Development to ensure system behaviour is as expected and is appropriate to requirements.
ACCEPTANCE
User acceptance that the solution has been appropriately tested and is appropriate for deployment.
BUSINESS CHANGE
Ensuring the Enterprise is at a state of readiness to adopt the change and to realise the benefits. This can include training, communication and process change to insure business continuity and improvement.
DEPLOYMENT
The release of the solution or solution packages. This could be the live business ready environment ready for immediate benefit realisation or perhaps firstly to an environment prior to live if there is a dependency on later activities or solution elements.
BENEFITS REALISATION
An evaluation on how successful the Business Change and Deployment has been. Identification of key learnings and changes to feed into the next cycle.
Measurement of benefits being realised during the project and sharing this data with stakeholders to ensure continued investment in any additional iterations.
POST PROJECT REVIEW
The measurement of benefits realisation for the whole project. Identification of knowledge and learnings to feed into the customer’s PMO (Project Management Office) in order to benefit related and future projects.
CORE PRINCIPLES
Central to the diagram describing the Enterprise Delivery model are the foundations upon which the successful cycles of development and change are dependant.
Experienced Project Governance that maximises input from all stakeholders and in particular product owners and customer teams.
Strong focus on evolving the architecture of the Enterprise and the aspects within that include:
a) Business Architecture: Business processes and models.
b) Solutions Architecture: Applications, software, data and systems integration.
c) Technical Architecture: the hardware, networks and security.