Architecture
The primary risk for know-how projects is the commuication 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.
The journey starts with your ideas, insights, prototypes and knowledge about your domain.
Analysis captures and translates your know how into a common language we can all work with. Design then shows these concepts in terms of the User Experience, this is like the walk through of a houses interior. Modelling is equivalent to the architectural plans with all the expected parts laid out.
The result of this stage is a set of technical Parts (like screens, API and data storage) that form a bill of materials grouped into Work Plan batches.
Analysis
Understanding the users, stakeholders, their goals and their needs.
Collecting business analysis, workflows, diagrams, algorithms, use cases, expected reports and outputs.
Creating a map of the business domain in order to understand how the software can support it.
Deliverables
Business Process Map.
Detailing how people, processes and materials (forms, surveys, other elements) interact prior to the system existing.
This informs the design and modelling stages to ensure the scope is captured.
Redprint RAGDAR.
RAGDAR stands for Roles, Areas, Goals, Data, Abilities, Results. This is the key information needed to ensure subsequent steps have the information they require.
It provides a clear understanding of the types of people involved in the solution, the goals each person has, along with the data, abilities they require in order to get the results they need.
User Experience Design
Focus on the User Experience and how best to provide the competing needs of the customer identified in Analysis.
Validating that the planned User Experience is going to work for the various use cases.
Can each role actually achieve the objectives from the RAGDAR in the Analysis phase
Deliverables
Wireframes Walkthrough
Rapid screen mockups help validate ideas and get to consensus quickly.
These are used to validate concepts with a small cohort of early adopters.
UX Walkthrough
Providing clarity to stakeholders, investors and the development team about exactly what they will be getting.
These can be used in pitch decks and customer validation surveys prior to further investment.
Product Style Guide
The style details the look and feel for the product along with a component library to increase consistency across the application and guidelines on implementing new screens.
This reduces costs later on as the defaults for components like how to select dates have been setup in advance, the customer and development team do not need to revisit unless there is a clear need.
Modelling
Translating the screens from Design combined with the processing requirements from Analysis and produces a Redprint Map of the planned solution.
Modelling identifies the parts and interactions required to provide a clear map for the Development phase.
The modelling also outlines the key Project Risk Profile to define the areas of the system that require additional attention during the Development Phase.
Deliverables
Redprint Map
This is a software architectural plan for the solution.
It shows the layout and relationships between all the parts of the system.
Workplan and Budget
From the Redprint Map the Parts are then sized and organised into small Development batches. These batches form the Work Plan for the Development phase.
Redprint Adaptive Deliver Process.
Redgums adaptive framework applied to manage the varying risks of a broad range of projects.