In life and business alike, things change – needs, priorities, cash flow – and usually when you least expect it.
That’s why Plume runs any sizeable project using an Agile approach, which allows for changes of scope and priorities, even after the budget and delivery dates (milestones) have been agreed, and the design and build process has kicked off…
The Agile approach breaks the project down into phases:
This is where we bring in our consultants, developers and designers to help you build your project’s requirements. Here they will decide on the technical approach and produce wireframes, and the output is a Project Blueprint which informs the rest of design and development phases. As part of the Discovery, we’ll help you to prioritise all your requirements so we can deliver as much as possible within your budget.
Our design team produces high-fidelity, interactive designs which bring your project to life. This is another collaborative phase, where we’ll work in line with your branding and make any revisions to design and functionality, making any adjustments so this can still be delivered within your budget.
This phase consists of several two-week Sprints, each of which sees a ‘package’ of your requirements tackled, to get the most ‘bang for your buck’ when it comes to devs’ concentration and skills. But working in Sprints also allows you to change scope, re-prioritise or introduce new requirements at any time, for discussion at each fortnightly Sprint debrief / planning meeting. The testing of deliverables after each Sprint may also bring new ideas to light, which can improve the overall impact of the end product.
At the end of the last Sprint, the MVP (Minimum Viable Product) version of your project will be provided, and we’ll enter the ‘Testing & bug-fixing’ phase. You can also make changes during this phase – if they can be accommodated.
In the lead up to launch, we’ll work with you to create a launch plan and schedule in any additional training you and your team might need ahead of Handover. If there are any additional requests, these are usually shared with us at Handover and post-launch so we can start to create a vision for Phase 2 and 3.
As you can see from the above, working in Agile allows you to change your requirements and priorities at regular intervals right up to the delivery of the MVP version of your project. Even then, the Testing & bug-fixing phase is a great opportunity for you to think about any post-Handover tweaks or even a ‘Phase 2’.
Any changes to the project’s scope will mean that the dev team needs to use the project’s development hours to investigate and estimate against new requests.
For example, if there are a set number of development hours allotted for a Sprint, then any new requests made during that Sprint will mean less time to deliver agreed functionality – i.e. investigating and estimating takes time out of the original budget, meaning fewer of the original requirements will be delivered.
If you choose to proceed with the design and development of new scope, you typically have three options:
1) De-scope an old requirement: Lower the priority of other requirements, to make up for the time needed to deliver the new requests instead
2) Increase the budget: Increase the project budget to allow for the extra requests, subject to the availability of extra developer resource
3) Save until later phase: Do not action the new requests until the initial build has been handed over
Of course, Plume will advise you on re-prioritising, de-scoping or estimate how much extra the budget needs to be increased by, to accommodate any changes or additional requests. But the bottom line is that any changes to the original scope and budget have a knock-on effect, and even getting us to investigate/estimate any changes takes time and money away from the development budget.
