When you implement a new fundraising database or CRM system, you will always have requirements and wishes which you will want to implement after your initial go-live – often, many such wishes!
Traditionally, this has been managed by breaking down a project into “Phases”. Phase 1 is the initial implementation, i.e. the build-up to your “go-live” with the new database, and then you plan to implement Phase 2, Phase 3 and so on.
But I think this is a bad idea and we should look at alternative approaches.
The problem with Phase 2, 3 etc
Why? Because the problem with this is that, so often, Phase 2 and other subsequent phases just don’t happen. Or if they do, then they are either nothing like they were originally envisaged, they don't achieve the benefits that were planned or they are cut right back so much that they are barely recognisable as a "Phase" at all.
And why does that happen? Because during the initial implementation, there is all the drive, adrenalin and organisation about the lead-up to go-live and all the impetus which goes with that - and then (understandably) after that has happened, there is a huge sigh of relief and people just get on with what are/were doing. And what was for that first part of the project, quite possibly, a significant project team with senior management support and understanding, is no longer a recognised unit - but whoever is left is still, somehow expected to get on with Phase 2.
And then there is the minor inconvenience of a budget. Whereas most (well ... some) organisations recognise the need to get the database up and running and therefore allocate an appropriate budget for that project, once that has happened, the concept of allocating yet more, possibly still quite significant money towards a Phase 2 (and maybe Phase 3, 4…) is harder to swallow.
It is also quite feasible that, once you have gone live with your new database, that the things you originally thought were important for Phase 2, are now no longer the priority. But you have designed and planned (and budgeted) for the implementation in that way.
Breaking down a Project is Good
One thing I should clarify is that I am not suggesting that the concept of breaking down a project into smaller bite-sized chunks is a bad idea – it isn’t. It’s a good idea. You can’t and shouldn’t implement everything you want on day one in "Phase 1", for so many reasons (e.g. manageability, cost flow, learning what the software can really do, dependencies, timescales, future changes etc).
And therefore we should be planning to go-live with a defined scope; and other functionality and benefits should of course be left for after that.
The Alternative: On-Going Development
A better idea than Phase 2 etc is to create a “road-map” for “On-going Development”. This means creating a list of all the additional benefits and functions which you already knew about before you started the initial implementation but which were not included in it, and adding to that any requirements which are de-scoped during the initial phase for whatever reason, and any new requirements and wishes which are discovered during that phase.
Thus, you will have a list which you can then prioritise into a road-map and plan to start to develop and implement from now on.
The beauty of this is that you can allocate priorities of desire, benefits, costs, timescales, resource requirements, complexity, risk etc and thus agree which things should be developed first and which should be left til later.
And if another new requirement comes along after a few weeks/months, then you can slot that into the road-map depending on its benefit, urgency, resource requirements etc – and in comparison to all the other things on your list. If it is more important then something else will have to give way. But you won't have to "wait for the end of Phase 2" or stop and then re-start Phase 2 later. (Phase 2a, 2b anyone?) You can also adjust the road-map if, say, your software supplier brings out new features or modules which can replace or complement your planned developments.
Some readers may recognise this as form of Agile Development, and whilst it has similarities, I’m not suggesting that you need to follow an Agile format (i.e. sprints, scrums etc). But the basis of the benefits of this approach and Agile are indeed similar.
The need for Enlightened and Involved Senior Management
Of course, you’ll still need a budget and you will still need x people to do this. And you will be asking for a budget for which you can't necessarily say up-front will bring Specific Benefit A or Function B. So it needs the support of an SMT who are willing to trust whoever is in charge of this (see below). But the good thing is that you will be using your budget and resources in the best, most appropriate and most efficient way for your organisation as it stands at any one moment – rather than keeping to some Phased plan which you came up with ages ago and which you feel bound to keep to because that was someone’s plan.
One way in which you can manage all this is to create a Database Development Team which can meet, say, quarterly and discuss the road-map and determine the priorities for the next quarter/year as appropriate. And if you include in this team the Business and the IT team (i.e. fundraising/finance staff etc and database/IT staff) then everyone will be able to make their point about what is needed, what the benefits are, the time and resources which will be needed and so on.
No comments:
Post a Comment