Monday, March 21, 2005

Avoid frustration when implementing third party software

If you are a small to medium sized company trying to implement a software product supplied by small to medium sized independant sofware vendor (ISV), chances are, you've experienced the non-productive spiral such projects often seem to end up in. If you've never experienced this, prevention is better than cure, so read on.

Many small to medium sized Independent Software Vendor seem to feel it is not in their interests to have much visible project management performed on your behalf - it could possibly only highlight their woes. In many cases they are, in the short term at least, better off with projects drawing on and on. They probably have staff to support and keep busy and if you're really unlucky, they are working on a time and materials basis, so the longer it goes, the more they get paid! (Despite the fact that their licence costs are usually so high that this is actually
not the case at all.) Quite often, the mystery, or smoke and mirrors as I've heard even some of these guys describe it as, works entirely in their favour, bambooziling you, and making them seem somehow smarter, because they apparently understand what they are talking about. Anyway, if this sounds familiar, for the sake of your business – take control of the project yourself!

I have witnessed out of control, software development and/or implementation projects from both sides of the fence. I’ve worked for ISVs and companies implementing third party software systems.

(I am talking about implementing medium cost software solutions here – maybe $150K – $200K. I am sure the $500 accounting package vendors, or their sales/support channels are happy to help you implement their software and get you up and running effectively as quickly as they can. I would hope those vendors selling million dollar plus systems would have acknowledged the need for effective project management of customizations and implementations – I have no experience in this realm.)

Where a small to medium sized company spends, say, $300K to implement a piece of mission critical software, I‘ve seen, so many times, the customer sit back at wait for the vendor to customize and implement their product. Any progress updates or status meetings that do occur generally consist of a representative from the vendor (loosely termed a “Project Manager” - often as much for his/her own self esteem as anything - in many cases sitting at a board room table without even a pen and paper) listening to customers (who generally have no IT experience) rattle off ad hoc details about requirements they have for quite detailed features in the system. Some they maybe thought of on their way to the meeting.

This PM will rarely be basing any of the discussion around a requirements document or project plan. Such documents do possibly exists - they are probably gathering dust on a shelf in that manager's office, because they promised they'd write one back at the start.

It's interesting that all too often you are told, “you've changed the requirements, it's out of scope, the goal posts keep moving, that’s why things are running late". Interesting because I doubt anyone could put a finger on a documented version of those goal posts to show how far you moved them. If this sounds familiar to you, I would say – be prepared to take control, manage things yourself. (If it doesn’t then feel good about yourself, your company, and take your particular vendor out for and expensive dinner – things are good!).

If you don't have anyone experienced in this area, it doesn’t have to be elaborate. All you need is one document outlining the nature of the system and a point by point description of each of the features. These are your requirements. Ask the vendor for time estimates for each of these points, and ask for an understanding of which ones depend on which others and how many people will be allocated to the project for you. Build a time line for yourself! Then, by all means communicate this back to the vendor. Accept their input and review the plan accordingly, but don't handover control of it.

Review this plan every day if you have to. One thing is for sure – it will change! A plan is one representation of exactly what won’t happen. That’s not the point. By being prepared and knowing that changes are occurring, you can make informed decisions about priorities which will mean your project stays on the best possible track for you - not your supplier.

This project management need not add undue effort to your end of the process, as a
minimum you only need to follow these basic guidelines;

  1. From day one, produce a document outlining the project "big picture" and a point for list of each feature that is to be implemented in order to achieve it. (This is a Requirements Overview). Group all like functionality together and build an understanding of how all the features relate.
  2. Ask your vendor for estimates of how they intend to implement each of these features. Ask for time estimates and also ask for details of any "behind the scenes tasks" that they feel they must perform. (There will be some "technical stuff" that needs to be done such as "data modelling", "object model designing" etc. That's fair enough, but don't let it all remain a mystery.) Each of these tasks should be able to be linked to one of your features. It is the vendors right to supply these time estimates, just as it is your right to request features and set priorities. By making sure you fully understand each activity between the start and the end of the project, you can be fairly sure they aren't padding the tasks too much. (If you're happy with the price, and you are aware of all the tasks, padding is irrelevant).
  3. Build a time line based on these time estimates. This can be a sophisticated project plan (using a product like Microsoft Project) or a simple task list with start and end dates and names of those responsible against each task. Make lots of small iterations so that you are seeing incremental progress in your system all the time. This give you the flexibility to change things regularly.
  4. Monitor your two documents at the very least, weekly, if not daily. By monitoring, I mean update the document with any new or altered requirements. When you make changes update the version number and add a small comment to the revisions table in the document. Make sure all parties are aware of the document and that you are satisfied you understand their impact. Also, update your time line so you are always aware of changing dates. If you are not happy with the impact, change your priorities. Remember it is the vendor's right to estimate the time frame. You can't change how long it takes - this is a fact. You'll know if they're lying. As timings change through the course of the project you will start to get a feel for the magnitude of different tasks. (At this point, a sensible rule to remember is that if one tasks - particularly an early one - blows out by x%, it is not likely you'll make up that time, in fact it is more likely that all tasks will blow out by x%. Applying this rule can be very hard. It is so tempting to feel you'll make it up later, but really, why would you? Remember bad news gets worse, the longer you let it fester!)
  5. Monitor any bugs the same way. The sooner you can fix bugs the better. Don't leave them all to the end. It's harder for the developers to fix them and it's much harder to estimate time frames at the end. Include each issue in your plan and get them into the most immediate iteration you can. (The list of issues/bugs list will get large. Don't be discouraged - it happens all thge time and if you stay on top of the lists from the start, they won't take over. Include issue resolution in your project plan).
  6. Communicate, communicate, communicate. Communicate all requriement changes, the bug lists and schedule changes to your team at least weekly and maybe even every day or so. Include the vendor in this team. They'll soon respond if your expecting too much, and they'll be forced to keep up otherwise.

There you have it, you're managing your project and you'll know exactly what to expect, all the way. Don’t fall into the trap of allowing the vendor to do this for you especially if they don't seem to grasp how important this is. Many will dismiss a lot of this activity as too "bureacratic". Many would rather "get on with the real work". Beware! They will probably be charging you for that "real work" for a long time to come.

It’s your system so you should enjoy watching it grow. If you were building a house and if you’re like me, you would need tradesman and specialists every step of the way – but you wouldn’t just walk away and hope they called you when it was finished. You’d drive by, often. You’d want to see, touch and feel the results. Do that with your IT solutions too. Don’t let one little detail be dismissed. Make sure your plan includes everything that is added or changed. I must re-iterate – this won’t stop requirements changing or new ones being added. What it will do is make sure the things you want finished, get finished, in the best order for you – not for the vendor. It will make them think properly about estimates they give you. If you can get some penalty clauses in your contract for late delivery – all the better, but this makes it all the more important that you do the monitoring. I firmly believe this approach, while it seems like adding extra work and responsibility to your end of the deal, will stop your project winding up in the code, fix, change, code and fix again, change course, spiral that so many of these projects end up in.

As the customer, you define the reality. So while the vendor may (and should) still run all their own project plans – you do it anyway. You are the one that defines whether you’re happy. Most importantly, this approach should prevent the problems appearing in the first place. The irony is, you'll never even realise what trouble you saved.