It’s not rocket science (fortunately for me; the recent work on quantum mechanics and theory of relativity have left me mentally exhausted!). If you have a difficult task to do the best way to approach it is to break it into smaller tasks that seem that much more achievable. The same theory applies here, we’ve got ten thousand users to get up on a system that we want talking to numerous other systems (some yet to be deployed), we’ve got warring factions, some budgetary restraints and past records to import from our terrible old system, 5 Excel spreadsheets and some ‘paper’, we also have to migrate these 50 courses we think and maybe we need to customise the system to do x, y and z although we want an out-the-box solution too. Sigh… welcome to my world.
Given this type of complex solution we need to start by breaking it right down. Firstly, do you really want us to set timeframes and set costs day one? If so, you can expect your partner to err on the side of caution - that means that they’re going to go with a higher price tag than you may have thought of. It’s the only way they can do it without accepting enormous business risk and even then we’ve been burnt on these types of projects as they tend to drift rather than focus on the deliverables and milestones that make us more comfortable.
There’s a simple first stage that’s a must - and this is what we try to advise our customers as the best way ahead. Don’t go with give me a price for everything (even though I’m not sure what that is) straight away. Let’s start by a scoping or initiation phase. In this phase I want to look in detail at what you’re asking for - if you want to do this properly it costs but it’s more than worth it in the long run. I’m always happy to give early price indications, it’s not about us trying to hide what things cost, it’s about trying to accurately work out the time and efforts involved to meet your needs. We’d also be looking to work out the roles and the sort of configuration work we’re going to need to do for you to get your solution where you need it to be. We would have this as part of a solution anyway, the advantage of phasing this and starting out is that your commitment is only to that first phase. The problem some organisations have is that they realise there’s a risk they could pay for phase 1 and then not want or be able to afford for further stages - that means they’ve invested in something that hasn’t been able to get them a solution. Let’s spin this around though. Had you been given a price of say $50,000 for an LMS implementation and started in a similar vein before finding out that there were some ‘issues’ that would mean you would need to either solve things internally that couldn’t be solved (like a data access or security issue that you hadn’t scoped out) or you had to pay a lot of money to the vendor for a different type solution. Then you’re caught in a contract that probably won’t allow you to go backwards and suddenly that $50,000 project is a $150,000 project that you can’t really get out of but don’t have budget for. You end up with a solution which doesn’t meet the organisational needs and has potentially massive flaws because the scoping has turned up things that the vendor couldn’t have known. Compare that with a $10k scoping exercise that found the same issues. From an informed position you could embark on a longer scale project or change direction or hold at that stage while you progressed another solution. The worst case scenario it would be $10k with little out, but likely you’re in a much more informed state however you move ahead.
Out of the deliverables for phase 1 we’ll get some form of accuracy around the rest of the phases. I’m involved in a project now that will likely have three or four similar scoping phases along the way it’s that big, but by making each of the steps scope the next it’s far more achievable overall. The other thing I really like about a phased approach is that we can still make a big project ‘pact’. What I mean by that is that we can set deadlines and expectations within a phase to keep the process moving along and avoid project drift. It always seems easier to meet those smaller milestones than one big one. The hardest milestone of all is ‘Go Live’ - but even this doesn’t need to be one. If you’re running a staged approach or pilot you may have several mini-Go Lives along the way and again that’s far easier to control.
Of course you may have a need for small and rapid implementation - in those cases here’s the price and away we go! Yes, but the danger with these is that what may appear small is really just a dressing for a much bigger project. Again, if you want to run a pilot as a project, keep it at that phase rather than letting it morph into a huge beast along the way. Keep it small, keep it simple and achievable and the chances of success are much higher.
The final beauty of a phased approach is that it’s ‘saveable’. What I mean by that is that each phase once delivered is effectively a save point in the game, you don’t have to keep going back to the beginning or reliving old preconceptions over and over again as you progress - it’s a series of non-return valves if you like. You don’t have to ignore learnings or redo things unnecessarily, but make decisions from the vantage point of having already completed certain parts and have the ticks and learnings ‘saved’ for those parts.
I could probably go on and tell you about our approach or argue over the best from here, but I really don’t want. The ‘how to’ is of less importance to me than the concept of breaking it down, removing unknowns and working in achievable size targets. Hopefully you’ll agree! If not, be sure to let me know as I’m always keen to work out better ways of doing things :)
No comments:
Post a Comment