This pillar of the maturity model covers ....
You don’t need to make software that is not necessary. You can avoid waste by questioning the requirements and making sure you really need a new feature before you start developing it. You should test your needs quickly, using evidence from user feedback and data to prove the value of your products, services, or features.
Measure | Description | Score: 1 | Score: 3 | Score: 5 |
---|---|---|---|---|
Ideation | Ideally you'll want open forums where anyone on your team or beyond can suggest ideas for improvement. | Tends to come from architects/product owners or the client; the involvement of our team is minimal. | Comes from all team members through open design decisions. | Comes from all our team members through open design decisions and from the user community. |
User-Centric | How do you gather user needs when undertaking new work to avoid building something on based on assumptions? | Feedback on new features is only sought after our team has built them. | We are able to quickly qualify the need for new features rapidly through qualitative and quantitative user research. | Structured process and integrated into refinement. Comes from all our team members and with external stakeholders support to challenge business assumptions around NFRs and SLAs. |
Challenge | Do you question the need for the changes you are asked to make? Do you have a good reason to build the feature or to meet the SLAs/NFRs? Do you feel comfortable to challenge something that someone higher up has told you is needed? | Tends to come from the more senior members of our team, if at all. | Structured process and integrated into refinement. | All our team members challenge assumptions around NFRs and SLAs. |
Iteration | How quickly can you go from an idea to working software that you can show to user to get feedback? | We can go from new requirements to working software and getting feedback in months. | We can go from new requirement to working software and getting feedback in weeks. | We can go from new requirements to working software and getting feedback in days. |
You can save energy and resources by making user journeys simpler and faster. Conway’s law says that organisations create systems that reflect how they communicate. For example, a digital application might still need a paper form to be printed so someone in the back office can sign and approve it. You can use design thinking to rethink your digital products and services and avoid Conway’s law and the trap of ‘we've always done it this way’.
Measure | Description | Score: 1 | Score: 3 | Score: 5 |
---|---|---|---|---|
Process automation | Optimising processes once they start to cause you pain makes sense, but do you continuously review/optimise how things work to reduce waste/increase efficiency? | Once we observe bottlenecks in a process, we use automation to minimise those manual parts of the process to make it more efficient. | We have implemented a process of continuous optimisation where we systematically identify and mitigate process friction. | We have implemented a process of continuous optimisation where we systematically identify and mitigate process friction. We actively garner feedback from service users to build our view from multiple perspectives. |
Design thinking | Improving your current methods has its limits; what if you could redesign the service to achieve the same goals but with more efficiency and user satisfaction? | We tend to optimise the existing process to make it more efficient than redesigning the whole process. | We attempt to go back to the drawing board and rethink how we can better satisfy user needs without being tied to the existing software solution, but we tend to stick to the existing digital channels of the process. | We adopt a whole service multi-channel view to how we optimise user journeys and make them more efficient e.g. digital, online and offline processes. |
Accessibility | The better you are able to accommodate people's needs within the service, the more likely they are to stay within it e.g. if a user needs to contact a support centre to understand how the service works or validate what something means then you've incurred waste. Aligning with standards including WCAG can help alleviate this. | We don't require our teams to apply WCAG and we target the lowest (A) rating when we do. | It is compulsary for our teams to apply WCAG to an intermediate (AA) rating. | It is compulsary for our teams to apply WCAG to the highest (AAA) rating. |
Design services for circularity can reduce software's environmental impact through re-use. For example, designing for future extensibility and ease of integration means more people are likely to consider adopting your common solution than creating their own version.
Measure | Description | Score: 1 | Score: 3 | Score: 5 |
---|---|---|---|---|
Backwards compatibility | By making your solutions compatible with older versions and avoiding changes that break the functionality of existing systems, you can prolong the lifespan of current capabilities, hardware, and software. This is a key way to prevent unintended obsolescence. | We align with current standards, software and devices available at the time of building software. We don't tend to undertake end-user device testing beyond using emulators to prove it works with with most common user configurations. | We align with current standards, software and devices available at time of software creation and within the last 3 years. We undertake a limited amount of end-user device testing with the most common user configurations to prove compatibility. Where an incompatibility becomes known it is treated as a bug and prioritised as high. | We align with current standards, software and devices available at time of software creation and within the last 5 years. We undertake end-user device testing with the most common user configurations to prove compatibility. Where an incompatibility becomes known it is treated as a bug and prioritised as high. |
Communities of Practice | A community of practice has a common goal and make your technologies compatible across projects, even those that are not related to a common cause. | Sharing of approaches, solutions and patterns tends to be informal and organic. There is no concentrated effort to encourage re-use and sharing within the organisation. | There is organisational support to facilitate the sharing of approaches, solutions and patterns; forums and mechanisms exist for teams to share with one another with possible examples of this happening. | There is organisational support to facilitate the sharing of approaches, solutions and patterns; forums and mechanisms exist for teams to share with one another. This happens consistently with communities formed to support these mechanisms and drive forward common themes. |
Working in the Open | You open up access to source code, use Open Data, Standards and Interfaces, and maintain documentation and getting started guides to make code re-use easier. | Our source code is available within the organisation though the documentation tends to be written to be consumed within our team. We try to align with open standards/data when we can. | Our source code is available within the organisation, documentation is written from the perspective that it will be used throughout the organisation with at least a getting started guide. We align with open standards and data. | Our source code is available within the organisation. We align with open standards/data with services designed for ease of integration and extensibility. Documentation is written from the perspective that it will be used throughout the organisation with clear getting started, contribution and issue-raising guidelines. |
Create a sustainable business model to promote eco-friendly practices and help guard against greenwashing. For example, if your product operates a subscription-based model, you might encourage energy-efficient usage through tiered pricing by carbon impact.
Measure | Description | Score: 1 | Score: 3 | Score: 5 |
---|---|---|---|---|
Business Model | A sustainable business model extends the standard Business Model Canvas to include End of Life plans as well as a list of possible negative effects and plans to minimise or mitigate them. | In defining the business model, little or no consideration has been given to the potential negative effects of the solution, as well as what happens at the end of the product lifecycle and whether the product can be profitably reused or sunset (End of Life). | The potential negative effects of the product have been documented and incorporated in the service definition. There is a plan for how you can profitably reused or sunset the solution. | The potential negative effects of the product have been documented and incorporated in the service definition. There is a plan for how you can profitably reused or sunset the solution. |
Charging Model | Many industries have adapted charging models which prioritise responsible use of their services e.g. charging more when demand is higher or less when demand is low, could the same apply to carbon intensity for electricity? How are you using this to influence your thinking? | We equalise our costs across customers/consumers to offer a one-size fits all approach. We can offer volume based discounts. | We offer a dynamic pricing model where we vary our pricing and incentives based on prevailing circumstances at the time. For example, we can increase/reduce spot pricing for our service based on the availability of low-carbon energy. | We offer a dynamic pricing model where we vary our pricing and incentives based on prevailing circumstances at the time. For example, we can increase/reduce spot pricing for our service based on the availability of low-carbon energy. |
Reporting Transparency | How openly do you track and report on the environmental impact of your service, and the impact of the resources you consume in delivering and operating the service? | We do not track or make known the environmental impact of our software or the impacts users incur through using our software. | We track and report environmental impact at a service level e.g. we can reason about the impact of each software service we offer and relate this to end users activities e.g. using the Software Carbon Intensity methodology. | We track and report environmental impact at a service level e.g. we can reason about the impact of each software service we offer and relate this to end users activities e.g. using the Software Carbon Intensity methodology. |