Imagine you are a senior business stakeholder and you’ve decided to change the way that insurance claims to knees are done. So you write a high level project description:
Project Alpha – To stop paying out as much on knee surgery
With that description it’d be hard to peak people’s interest or even worse if you weren’t there, how are people going to understand that value of it, or even what it is? So let’s look at a vision statement to tighten up this process. I’ll use Moore (1991) as the foundation for this. The component parts are:
1) Who is it for?
2) What needs will this fulfil (ideally your customer’s needs)?
3) What is the key functionality?
4) What are the key benefits?
5) What current competitor or current practice are we comparing this to?
6) In what way will our product be different?
Let’s do an example on our knee surgery project with the numbers mapped into the sentence we’re creating:
1) Our customers requiring knee surgery 2) are unnecessarily going for knee operations when they have twisted knees 3) so we need our main system to flag these for review rather than authorising them 4) so that they can avoid discomfort and we can save unnecessary costs 5) unlike company XYZ 6) we will ensure a full doctors review first.
So there you have it, a bit more descriptive than the original project title isn’t it! Now that it’s much clearer, when you ask your team to break down the stories and put some detail around what they need to do, this should focus them. You can then apply ROI to the project with the vision in mind.
Now don’t think this is limited to a business project. You can move the vision into many aspects of your business, let’s look at a few examples, I’ll keep the numbering so it’s clear what we’re doing:
1) Our staff 2) are often coming in ill and spreading their germs around 3) so we need to educate them about not coming in when feeling bad 4) so that they can avoid spreading their germs 5) unlike the current sickness process where we meet them first to check their health 6) their line manager will ensure they phone in first.
1) The support team 2) are not clearing their defects within SLA 3) so we need to set up a reporting system that flags when they have one day left 4) so that we can make sure these are prioritised 4) so that we can pick these up with sufficient time 5) unlike the current reporting mechanism that waits until they are late 6) we will ensure that the application services manager monitors these daily.