We educate and train staff using a set of key conceptual models, covering key principles as we move through the design cycle. This ensures consistency and a common understanding of the make up and structure of all end-to-end processes across the organisation, as well as compiling a common business vocabulary.

Getting everyone on the same page can be difficult. At the centre of our business process design is a single-page overview (process on a page). As we move forward with process design, we refine it and document the rest of the details in a comprehensive document, in such a way that is easy to digest for the organisation.

The single-page overview is easy to educate with and maintain, and becomes a reference point for on-going operation of the process well into the future.

We have developed a process design cycle that contains a series of workshops that we have executed time and time again. We refer back to the key conceptual models during the workshops to cement 'ground-up understanding' of key principles for the team, and we work with staff to complete the design by gathering and documenting their knowledge around these key principles to complete the process according to the process framework.

By taking a workshop approach to process development, we are able to gain agreement on the main elements of the end-to-end process design, and ensure that it fits with the maturity of the organisation.

We understand that for many organisations IT is a crucial part of the process. However we realise that IT supports the business, and the business should not just be driven by technology; rather, technology enables business processes to achieve business outcomes, whether directly or indirectly.

In our approach, we make a distinction between what happens in the business process flow and the application. This allows us to agree all the activities and applications encompassed by the business process (for example, putting parts on the truck could well be an activity in the business process, but will never be done by the application). By taking this approach, we are able to: define and agree areas of ownership, roles and responsibilities, an understanding of what needs to be measured and why, etc.

By focusing on the logical business process first, the focus changes from what the application can do, to how the team needs to work together to achieve the business outcomes. People understand why they do things in a certain way and what their role is - they no longer blame the application, and all elements of the business process becomes visible. Finally, accountability no longer becomes a dirty word, and the business process can then survive any application changes or upgrades.

The basis of our design consists of the following elements:

Using an internationally-recognised process framework for design provides consistency and professional equity, ensuring alignment with standards and facilitates improved understanding and agreement across the organisation. In addition, having a best practice process framework ensures that new staff joining the team are on-boarded relatively effectively and efficiently.

No-one knows your business like you do, and we understand that the devil is in the detail – once we have agreed and documented the logical end-to-end business process, we can work with your team to understand the actual AS-IS, and devise a roadmap to final implementation (the TO-BE).

By working with your teams to analyse the detail, we prove the design on paper, then gain agreement on what needs to change and what the final TO-BE should look like. Ultimately in our experience, scenario work becomes key to business change activities and application implementation.

We ensure that all changes are catalogued and reviewed with both business and IT staff to tease out as many design issues as possible before we plan the release.

Ultimately testing cycles can be expensive and time consuming – however we understand that identifying and resolving issues during the design phase will cost less than if they were identified and resolved during testing, and a lot less if they were not found until operation - something often referred to as the 'reverse cone effect'.

Robotic project management becomes stale and ineffective over time. We pride ourselves in using proven PRINCE2® product-based planning techniques to develop release cycles (based on product flow diagrams) that integrate all elements of the required change (business process, IT operations, application, and technical elements).

Taking a repeatable, reusable, and holistic approach to project management ensures that all costs are out in the open, and improvements can be sought without compromising the integrity of the release. By using common frameworks, the techniques we introduce often survive long after we leave.

Organisations are often impatient to begin the release, but we understand that the key to any project execution is good planning. We assess the organisation's capability, and integrate our planning techniques with the maturity of the organisation without compromising the integrity of the project management method.

By applying the appropriate focus on planning, we reduce stress on the organisation during execution, as well as reduce risk and the advent of unforseen cost. Ultimately, appropriate planning improves our ability to assist the organisation in successful transition.

We work to ensure that the environments are appropriate for the changes being implemented and the environment management strategy is agreed and understood by all teams involved in the release.

By ensuring the environments are adequate for the release and completely understood by all teams we reduce the cost of failed changes and the risk of re-work due to uncoordinated environment refreshes.

We work to ensure that developers and support staff agree on the use of and interface between different case management systems. This includes approaches to testing and defect resolution processes. By gaining agreement on processes and procedures and embedding them into the organisation's existing support tools, we ensure that the right information is retained and appropriate configuration knowledge is transferred to the support teams.

Taking this approach not only ensures efficient and effective issue resolution during the release (reducing transition costs), it also reduces the total cost of ownership once the solution is deployed, since records on changes and issues are easier to access if there are problems during operation.

We catalogue and structure changes into release packages, then gain agreement on staff involvement for each release package. We then use these catalogues to baseline and control the scope of the release during execution.

Changes occur as part of a normal release cycle - we ensure that they are documented, communicated, and tested efficiently and effectively to reduce risk and the cost of rework, both during the release and after the deployment.

Integrated solutions require a range of test models and test strategies. We understand this and know the difference between defect types and where to apply common resolution strategies.

Knowing the difference between defect resolution at all stages of deployment, and knowing when to use common resolution strategies improves the overall effectiveness and efficiency of the release, and ultimately reduces costs and risks during execution.

Cutover is a crucial part of the release cycle. We give it attention from the very beginning, and focus on planning for an appropriate business window, looking to minimise the impact on the business (often leading to 24x7 cutover schedules). We then work with technical and business teams to identify critical steps and communication points. All in all, we develop a single cutover schedule and identify in the release where it can be rehearsed both physically and in the conference room.

By spending time on cutover early, we can integrate rehearsal activities in with the overall release – thereby reducing the cost of cutover planning and rehearsal, and reducing the risk of roll back, time blow outs, or cutover failure during the point of go-live.

We integrate support teams early in the release cycle and work to ensure they have the right information to support the solution before it goes live. We also pay particular attention to early life support (ELS) to ensure that the appropriate support mechanisms are in place for individual teams - this often results in a mix of on-the-ground staff and centrally placed resources to handle escalations from the Service Desk. We always try to ensure that all go-live incidents are logged and categorised.

With a well prepared ELS, the adoption of the new business process becomes smoother, business teams return to productivity much more quickly, and the project team can be disbanded earlier. Overall, holistic costs for the adoption of the new business system can be reduced.

We conduct review sessions with staff that were involved to validate release performance and identify any areas of improvement. Overall, our aim is to ensure that reviews are conducted objectively, and that lessons feed into the right areas of the organisation so lessons can be acted on for future releases.

One of the key benefits of adopting an end-to-end process approach (including release management itself) is the ability to layout the process and see what went well and what did not go so well – we help with what to review as well as conducting the review itself.

We are experienced in providing reports in a variety of formats and to a variety of management levels. At the beginning of any assurance engagement, we review the different types best practice reports and checklists of what is to be assured, then we tailor communications to suit client needs.

By being flexible in the way we adopt assurance reporting we can fit in with the maturity of the organisation and ensure that the parameters that stakeholders need assurance on are covered adequately.

Once we have established what is to be assured we can apply both best practice and our business process experience in recommendations made.

We can help you avoid costly mistakes by assuring that: the right staff are involved, risks are controlled, communications are effective, staff are properly trained, quality methods are being followed, the scope of the project is not changing unnoticed, etc.

Depending on the size of the programme and knowing what needs to be assured, we can look at providing part-time assurance roles.

Once we have established what needs to be assured, the engagement can be tailored to suit the organisation's budget.

Before we execute the assessment we consult with key staff to ensure the scope of the assessment is suitable for customer requirements. We use PRINCE2 as the primary source of project health check. We can add our own understanding as required, and provide actionable recommendations based on our experience.

By understanding what you need before we conduct the health check, we can ensure that you get the right outcome from the health check.

Based on the PRINCE2 health check, we can work with our client to agree the scope of the health at the beginning.

The PRINCE2 health check typically looks to ensure that:

• Project management team roles have been allocated and understood.
• Board members are appropriate for the project and understand their respective roles.
• There is appropriate stakeholder representation on the project board.
• Appropriate project records are in place (logs and registers).
• Lessons are actively being learnt throughout the project lifecycle.
• Appropriate quality documents are in place, and the right quality procedures are being followed.
• The project approach has been agreed upon and is appropriate for project acceptance.
• All necessary project plans are in place.
• The project board is actively directing the project.
• The project is communicating appropriately to all stakeholders.
• The business case is viable, desirable, and achievable, given the scope of the project.
• The necessary strategies have been documented and agreed, and are actively adhered to.
• There is a benefits realisation plan, and it is being managed accordingly.
• Project controls are in place and adequate for the nature of the project.
• All appropriate project tolerances have been set and are agreed.
• Stage gate controls are being applied appropriately.
• Risks and issues are identified and managed appropriately.
• Progress is monitored and managed appropriately.
• Configuration items are identified and managed appropriately.

Using the industry standard health check as a basis ensures that you get an objective assessment of the health of your project according to industry best practice and helping you avoid costly mistakes.

With a skilled facilitator it only takes a couple of hours to put together a draft logical model, this is enough to enable the management team to look at their business from a lifecycle control perspective, showing all the major processes in their management system relative to the vital business lifecycle and other key portfolios.

To develop a draft model isn't costly or time consuming.

The model draws on the management principle of lifecycle control and on the knowledge of the existing management team to map out the relationship between the organisation's business processes in their management system and relevant services/lifecycles.

Although the model is often new to many management teams, it soon becomes a platform for business system decision making.

Once the management team has had chance to absorb the draft model, then it can be modified to include strategic intent of the organisation. Once the strategic model is completed, the management team can confirm the AS-IS a practical TO-BE (target operating model) and what resources are required to achieve the strategic objectives.

In strategy it is sometimes as important to know 'what not to do', as much as 'what to do', and also 'when'; by visualising the management system lifecycles against the vital business lifecycle a clearer understanding a practical process strategy emerges saving time, effort and ultimately money.

The vital business lifecycle model can act as a point of reference as processes are built and implemented. As each process is designed, the model can be updated and used to ensure that senior management maintain the scope and control of process design activities, while practitioner teams add the detail. Each layer of the model adds value in its own way, and provides the organisation with new perspectives on end-to-end processes.

All in all, having a simple model is an essential tool for overseeing and managing end-to-end process design activities.

In order to complement the vital business lifecycle model, we can work with the management team to develop a process reference model. This is another simple model that agrees on the outcomes for each process and (if required) how they relate back to the international standard for their industry sector (e.g. ISO 55000 for Asset Management, ISO 20000 for IT Service Management).

In an organisation that is focused on the outcome – agreeing what they are against each management system process enables the organisation to improve risk management, benefits management, service management, process management and teamwork.

Adding the process reference model to the vital business lifecycle model, adds the detail required to evaluate the construction and operation of each of the processes, it also assists all staff at all levels in defining and understanding the benefits of end to end process thinking while developing a certain amount of professional equity. "Once you know, you can't un-know!"

In accordance with best practice, we can perform assessments at three levels:

• Process only: Assessment only of process attributes based on the general principles and guidelines of the process framework*.
• People, process and technology: The assessment is extended to include the organisational structure, skills, roles and talents of the managers and practitioners of the process as well as the ability of the currently deployed applications to support process objectives.
• Full assessment: The assessment is extended further to include: an assessment of the culture of acceptance within the organisation, the ability of the organisation to articulate a process strategy, the ability of process governance structure to assure that process objectives and outcomes are met, the business/IT alignment via a process framework, the effectiveness of process reporting/metrics, and the ability of the decision-making practices to improve processes over time.

Being able to choose the level of assessment allows you to control the depth and scope of each assessment inline with your requirements.

Our process assessments can be used to provide management teams with an objective understanding of the maturity and performance of the process under assessment. Process assessments can also be used as part of a programme of work to identify the current maturity of the process as a baseline for process improvement.

An objective assessment provides an understanding of operational performance to validate past decisions or justify future initiatives.

Our process assessments can be used to benchmark process maturity, structure, and performance against best practice. When assessing IT processes we can benchmark process activities against ITIL and ISO 20000. When working with business processes, we use the relevant international standards. Benchmarking against best practice/international standards can be a way to open an organisation to new methods, ideas, and tools to improve the way they operate.

We do the detailed assessment – you know where you stand against best practice.