Monday, September 29, 2014

Beware fake implementation timescales

Time - one right one wrong 

This is a brief message: if you have been asked to plan a new CRM or fundraising database implementation, and you have been told to create a timescale for the project, then beware of the 'fake timescales' syndrome.

For example, if someone in your organisation (usually a senior manager…) says it must be done by date x, if there is no solid business reason for that date then don't just accept it. If you have over-run your procurement by a couple of months, then don't simply reduce the implementation time by 2 months - why has it suddenly become quicker to do just because you're starting later?! Or if your timeline is based on the fact that someone once did a project somewhere else in that timescale...

Of course, if you have an absolute deadline for a good reason then that needs to be accounted for, although even those can sometimes not be definite. e.g. if you are moving office, then is there no way you can continue to access your old database in your new office - or is that just an excuse to get a deadline? If your current software supplier is stopping the support of your current database on date x, then maybe you can accept the risk of still using it for just a short-time after that rather than rush your new implementation?

What you should do is work with your supplier and your project team, your key staff and your organisation's whole calendar, and work out how many months the implementation should take regardless of when you are starting. (Then review it again and see if even that is realistic…) Then you can allow for any periods which might mean it could take longer (e.g. Christmas/New Year, your big annual event, August holidays) and extend if it necessary. And if that really, really is unacceptable to your project board then you will need to explain you will have to de-scope something and/or increase resources.

But don't accept fake timescales - they don't do anything except increase the risk of failure.

No comments: