I electrocuted myself the other day.
It didn’t half hurt – left a couple of lovely little entry and exit burn marks on my right palm as well as causing my wife and son to run up the stairs to my blood curdling screams.
It shouldn’t have happened of course.
But we’ve got a bit of decorating going on at the moment, I fancy myself as a bit of a DIY-er, I’ve swapped plug sockets out before, what could possibly go wrong?
Well, our fuse box has 2 switches marked “sockets”. One for the first floor and one for the ground floor.
The sockets I wanted to change were upstairs, so I switched the first floor switch off and got to it.
Turns out, whoever wired the fuse box got confused about theirs upstairs and their downstairs and created a random selection of sockets for the house. NOT exactly compliant I’m sure but that’s how it was.
And what I’d done is make a big, fat A-S-S-U-M-P-T-I-O-N leading to … the unfortunate electrocution.
No, not the 240 volts. The assumption.
I should have known better.
Because my little electrical project is just like the big game changing project in your business.
There are lots of assumptions flying around – and the more people or complexity you have on a project, the worse it can get.
“But how can I stop this on my project, Mark?” I hear you ask.
Well here’s how:
- First, you’ve got to have a look at the key “moments” or deliverables you are planning on for your project. You might know these as “milestones” in project management lingo
- Additionally (ideally you already have these in your plan), also have a look at the tasks that lead up to the “moment” or deliverable
- Now ask yourself … who is doing this? Can they do it? Are they available? Do they have everything they need? What might change? What else needs to be true to ensure this happens? There are lots of other questions like this you could ask yourself, but these are a good start
- If the answer to your question isn’t documented in your plan in some way then you have yourself an assumption. Most project methodologies or books would now have you write these down somewhere and attempt to validate them. But here’s the way I do it
- Turn them into RISKS. How? Let’s say you have an assumption like this:
“Our developer will be available during the month of November to work on the project”
I would turn this into a risk as follows
“There is a risk that our developer may not be available during November because of a number of competing priorities or other unforeseen circumstances which could result in a delay to the project of up to 4 weeks”
- I’d then manage it through my Risk log, coming up with mitigating actions and monitoring the risk until it reduces to an acceptable level or goes away altogether.
Take a minute to ask yourself … what assumptions are we currently missing on our projects?
Could your metaphoric fuse boxes be incorrectly wired?
The answers might shock you!
We all know to never A-S-S-U-M-E – because you may end up making an A-S-S out of U and M-E.
But sometimes even the best of us forget…