Company
Project Transparency and Consistency: Our Recipe for Customer-Centric Development
Published on 23 Jan, 2025 by Jonathan
Rather than a blow-by-blow account of our agile development practices, how we organise revision control and our pipelines, and our testing and documentation practices, I want to share some of the processes we have implemented to keep our customers informed and support our development teams.
In the previous article we discussed the cone of uncertainty. We use the cone of uncertainty, to understand the inherent risk in a project, and use this as a discussion point with our customers. This leads to two distinct activities on projects, which can run sequentially or in parallel depending on the scale and scope of the project. These activities are Design and Development. From our perspective, Development includes test.
To ensure consistency from Sales, through Engineering, and onwards to ops and support, and most critically to support the bulk of the engineering effort in Design and Development we have developed a series of Gates which must be completed to progress to the next phase, for example, to progress past the Pre-Delivery Gate there are several requirements such as Acceptance Testing, Documentation and Risks Register Review.
The Gates allow us to review each project consistently, provide a common language in the business on where a project is, and serve as a record of decisions made. Associated with the Gates is a detailed project checklist that guides our teams in the best practices we have learned throughout the company’s history. This again helps drive consistent delivery. The Checklist is often updated as a result of an improvement to the process identified during the post-mortem.
Design and Development are organised into Sprints (most of our projects are Agile, but some by customer need or regulatory requirements are not). Sprints are often discussed, and work prioritised for a sprint, in conjunction with the Customer. Standard Agile ceremonies and practices apply, again often involving the Customer, which provides good buy-in to and support of the project.
We typically use Burn Up charts to track project progress. We typically operate two charts, one is used for Work, and a measure of the remaining and completed Work, and the other is for the Project Budget. This allows an at-a-glance understanding of project status for the Project Lead, team, and anyone else within the business.
Providing insight into project status within the business and to the Customer is an essential part of the Customer-Centric approach we take. We operate a fairly standard RAG score for projects, and it is our culture to place a project into Amber, or even Red at the earliest possible point, such that collectively, and often working with the customer, we rectify problems early. We use the following measures:
- Scope
- Schedule
- Budget
- Resources
- Communication
- Quality
- Customer Satisfaction
- Confidence
- Risk Management
- Payment
It is important to us that processes remain lightweight, but ensure that we uphold the quality for which we are known. It was an interesting observation to us when we applied for our first AWS Competency that AWS are looking for these sorts of processes and consistency of project approach as part of their Competency review processes.
In addition, we are an AWS Well-Architected Framework Review partner, and as such leverage this to ensure we deliver against these best practices.
I hope this has given you a final insight into how we work, and in the next post I will wrap up and summarise this post and the previous four.