There are two common ways that software can be developed and configured – Waterfall or Agile.
In Waterfall, a software company typically spends large amounts of upfront time detailing and scoping the clients needs before providing a client with a complete design for sign off. Once approved by the client the software company then goes away and builds and configures the application, and once completed it is then provided to the client for use.
Waterfall creates software that you think you want sometime later – however on starting to use the delivered software the theory clashes with the reality. Users are notoriously bad at describing what they need, ensuring that all the required features are included and avoiding bloat. Also building software takes time and business changes rapidly. Changes after significant development can involve significant rework.
At Saasplications we utilise Agile Methodology to develop and configure bespoke applications for our clients. This is not a new way of working – it is well known in software development. Our experience shows that clients must be involved in the development process as the system evolves to minimise rework, capture unconsidered requirements and refine as early as possible. We aim to have our customers testing key flows within weeks and edge cases in the following weeks.
This means we do not know at the start of a project what will be delivered. We do know that the solution will be customer led all the way using our experience to provide a broad, efficient and focussed solution and we aim to have raving fans empowered and excited about what they can now achieve.
Importantly the test / refine / test process continues after go live for 3 months. It can take time for a business to encounter some of the edge cases. It is also common that a new system opens up new opportunities that were not previously considered. So our implementation process is not considered complete until after a 3 month sign off.
The Agile Development Methodology works because the client has the opportunity to review and test the configuration and suggest changes and additions whilst the application is being built – so the client will receive a solution that accommodate their current and future requirements as close as they can imagine
Agile also minimises the overall project length and design time, because the client is frequently reviewing and providing ideas and only what is required and useful is configured with unnecessary items removed. With Agile the initial prototypes are rough, but they quickly get refined and are quickly functional enough to start using.
The advantage of Agile Development is that clients are able to access and even use/test portions of their solution whilst being configured. Components get provided earlier for assessment reducing risk and cost. Features of no interest are never configured and the solution can go live while still being refined reducing the time to benefit. The configuration team works closely with end users ensuring that the configuration fits the need.
A workshop is conducted to understand the businesses processes and customer / supplier / enabler touch points. The intention of this phase is as a high level overview to determine focus and timings.
The result is a shared understanding of key processes, community and high level flows.
80% of the business will be managed with 20% of the flows. It is important that these flows are as efficient as possible and tested by the business. These flows are completed first.
Each flow we will start at the beginning
1. The flow initiation steps and the required information
2. Configure the system
3. Users to check and identify improvements of Configuration
4. Back to 2…
While refinements are continuing on the beginning stage – we move to the next stages of:
1. Flow next steps detailed
2. Configure the system
3. Pass configuration to users to check and identify improvements
4. Back to 2…
We continue until the end points of the flow have been reached.
Some of these flows will be variants on the core flows. Some will be completely different – for example after sales service.
The required flows will be listed and prioritised then each approached as above. From the beginning until the end.
Key users in the business will do scenario testing checking the flows are capable and complete.
Key users will assist with training rollout across the business.
Go live is a cutover weekend. Normally multiple practice cutovers are done to ensure any imported data (example open invoices) creates correctly.
For 3 months after go live we expect that users using the system will want minor changes to improve usability. There is often items that were not considered by the users prior – or good ideas that come up because of a new way of doing things. We expect this and work with you to implement changes that are needed. This ensures that the system is actually working well in the business instead.