You’ve just received a licence to a new piece of software, and you’re eager to show your business some results.
a) Write a complete requirements document and get it signed off by all parties before starting the implementation?
b) Outline high-level requirements, and start implementation with the scope to restructure along the way?
The truth is, both approaches can work, but in my experience, there are huge benefits to option b, and I’ll explain why it works so well for FlowForma® BPM.
High Level Requirements:
It makes good sense to have a clear picture of what you want to achieve when you start the implementation of a project. Whether it’s a process flow in FlowForma BPM, or a structure build from LEGO®. You’ve very likely already determined the pain-point you’re trying to solve, so now is the time to outline how. Imagine a big box of LEGO - lots of bricks in various shapes and colours. Lots of pretty pictures on the box to inspire you, but none of them necessarily match what you really have in mind. You may have a vision of the end-results. Try to draw it or write down what it is, so you can use that as a guide to ensure you stay on track.
Your drawing will be incomplete, and you can decide to spend a lot of time adding detail to it to make it complete. But it isn’t easy to imagine all the details on a piece of paper when you can’t see all the dimensions, is it?
Let’s forget about the “documentation” for a minute. Let’s just get some bricks. Let’s build!
If your building bricks are flexible enough, you can modify your prototype. You can remove those 4 red bricks without damaging the space ship, because nothing is glued together. In the same way, you can remove a step in a process without deleting the questions. The prototype is adjusted, not dismissed.
The benefit of a prototype is that you don’t just have to imagine what it looks like, you can actually see it, and the pile of bricks is starting to look more and more like that space ship you had in mind!
A good prototype helps you steer the build, and ultimately helps you achieve the right result. It’ll save you time (and money) in the long run!
Here’s the thing – when you go through build iterations, you have to know when to draw a line in the sand. You have no documented end-result, so when have you reached the end?
Well, here’s another benefit. Because you have a build that evolves all the time, you can test it along the way. If you have too many bricks on one side, your space ship won’t be able to balance, or if you have too many approval steps in your process, you won’t ever reach the end. You test, and by using what you’ve built, you eventually see a working prototype.
Based on this, you can now decide how far you want to go. Do you need the bells and whistles? Will the end-users even notice?
You know the end is nigh, and you’ve seen throughout the build process that you can make changes at any point, so it’s up to you to decide when the build is ready for production.
The team has accepted the solution, and they are ready to start using it.
Backwards, as it might seem, now is the time to document how we got there. Remember those little booklets from your LEGO sets? The ones that detail how you put the bricks together?
Now is a good time to write that little instruction manual!
This means you can take the bricks apart in years to come and still know how to put them back together, without going through all the build iterations again, if you realise the modification you added just wasn’t quite right.
Ready to Play?
I’ve been playing with FlowForma bricks for a number of years, and I’m sure you’d like to find out for yourself how easy it is. You can build small, simple processes – or big, complex ones. It’s all up to you, and we’re happy to guide you until you feel you’re ready to do this on your own.
Want to learn more about FlowForma BPM? Take a free 30 day trial, or speak to one of our BPM experts.