Redprint Deliver Process
Redgum's R&D has focused on how to produce software better to make software better.
Over 2 decodes of learning has been crystalised into our Redprint Deliver Process. This process supports and uplifts our team and our clients through the complexities of the entire software lifecycle.
There are a lot of developers with a lot of very strong opinions about a specific methodology, this is a trap that you need to ensure you and your developers are clear on.
Each project has different requirements and risks, the process your developers use should reflect the needs of your project.
Eg.
Rapid delivery to users and lots of iteration is suitable when the risk is you don’t know if the users need or care.
Projects that already know their user or already know the user gets value, then the risk moves to ensuring the users expectations are fully met. A half complete product will turn the user base away.
When your working at scale a 1 in a million problem can happen every few hours. Projects that have a high financial or physical chance of harm, the risk is ensuring the software is incredibly robust.
Ensuring your developers understand your solutions risk profile and have chosen and adjusted their process to suit your situation is critical to the long term health of the solution.
Redgum’s Deliver Process is an adaptive set of elements that comprise the full lifecycle of the solutions development.
Based on the risk profile of your project Redgum adjusts the elements to ensure your key risks are covered.
Architecture
The primary risk for know-how projects is the communication between the domain expert and the software development team.
The architecture stage is designed to allow both sides to understand the big picture. This way there is context and understanding for where the detail needs to sit during the development phase.
Read more about the process and deliverables.
Analysis. Creating a map of the business domain in order to understand how the software can support it.
Design. Focus on the User Experience and how best to provide the competing needs of the customer identified in Analysis.
Modelling. Modelling identifies the parts and interactions required to provide a clear map for the Development phase.
Development
Development stage provides control around the high complexity and detail required to translate domain know-how into software.
Read more about the process and deliverables.
Engineering. Enables business analysts and customers to understand the specifics of what will be built and exactly how the solution will operate.
Construction. Writing code to meet the requirements set out in Engineering with QA to verify the expectations have been met.
QA. Extended scenario testing outside of constructions "proof".
Implementation
At an agreed point there has been enough developed that you are ready for a first release, this opens up a new dynamic, working with your users in a live operating environment.
Read more about the process and deliverables
Release. Release plan and automation is created to allow rapid updates and ensure that new updates can be “undone” if required.
Warranty. Redgum provide a 3 month, not to spec warranty meaning that if it doesn’t meet the agreed requirements set down in the Engineering step Redgum will fix it
Support
Redgum’s focus is on providing the best long term return on your solution investment. To achieve this,
Redgum tailor an adjustable support package to suit your solution, goals and budget.
The components that we offer include:
Continuous Improvement. A “not to be exceeded” monthly budget for refinement and improvement of the system.
Maintenance. Monitoring, reporting and upkeep of the environments and technologies surrounding your investment.
Service Level Agreement. Rapid response plan for dealing with critical issues in the live system.
Redprint Adaptive Deliver Process.
Redgums adaptive framework applied to manage the varying risks of a broad range of projects.