Projects; It’s now or later… and later will hurt more
So it’s Friday here in New Zealand which always feels a bit like cheating when dealing with the rest of the world who are struggling through yesterday. One thing that strikes me on a Friday is that so often we try to wrap things up as it feels good to complete things before the weekend. Makes sense, but there’s one thing I’ve found for sure over a multitude of projects and jobs is that stashing away tasks or skipping on a bit of forward thinking always seems to come back on you one way or another.
Anyone who knows me is well aware that I’m the dreamer more than the step-by-step process guy. I’m agile not Prince2. I’m Trello over Gantt. I’m always people over process. But that doesn’t mean I’m someone to put off what needs doing or avoid those difficult parts. It actually means if anything we make them more obvious, we raise risks, we address issues and, yes, we have a process to minimise those risks.
A great example is in the learning technologies world where we frequently get asked to do ‘more’ with a learning system than it was originally intended to do. These are usually a ‘customisation’ (when you’re working open source customisation isn’t a dirty word you know) and often we get asked to do them ‘quick and dirty’ (okay, now it sounds dirty) to achieve an immediate need. I’ve got a couple of issues with this; firstly customising isn’t the heartache with open source systems that it is with a proprietary style system, but it still shouldn’t form your first resort. Secondly, if you go with the quick fix without putting the structure around it, you’ll still get that hurt at some point and that hurt is going to be big.
Perhaps the most obvious stage of work that gets cut down (or even cut out altogether) is scoping. If you don’t scope a project properly as a contractor prepared to pay for it later, quite literally. If you don’t scope a project properly as a client then be prepared to pay for it later; you may not pay financially, but you’ll likely pay in pain, grief, timeline and future issues. Whenever you change a system it has effects and some of those are not quite as immediately obvious to you at the time. Any project that runs without a proper scoping has a huge risk attached. Even when you include scoping you’re asking for trouble if you don’t include time for testing and re-working too. Even if you’re the provider allow time for UAT (user acceptance testing) too. Yes the consumer does that part, but likely they want help and it often throws up questions that someone has to answer.
The time spent sorting the issues, unpicking stuff that was done quickly, sorting out learning records, re-working code, emailing backwards and forwards (if you’re not on board with the disruptive technologies), the internal discussions, the management of miscommunication and the planning that should have been done initially. That all adds up to a heck of a lot more than a bit of prep work before you hit the work. Somebody pays for it and usually it’s not one person or organisation but all sides.
So sure, 2 hours work by a developer sounds quick and easy, but don’t be surprised to pay several times more for it by putting in proper scoping, testing, training, UAT and project management. In fact you should actually want this; it’s there as much to protect customers as is it is to protect providers. When I pay for a service I want them to have properly understood what there is to do, how they’re going to quality assure what’s done and have someone who can answer my questions through the process.
So my final thought for our Friday here is that looking ahead to the weekend I want to look forward to skiing down the slope, but I also want to know that Monday won’t be a tree in my path that I could have avoided!