For the past couple of months I have been involved in another large scale computer system implementation. I will probably be around this one till the end of the year, and then into support and maintenance. The client spent 2 years evaluating this system before finally committing to it. The (client) project manager was convinced that they had an 80% fit to their requirements. However, they grossly underestimated the size of the remaining 20%. This has caused a fair amount of concern around the executive about the project. The system was initially promised last June - which was pretty hopeful as the contract with the vendor wasn't signed till December. Then the system was promised by the (client) PM in June this year, but we know that that is an impossible target and have informed the client that November is a more likely first deployment date. So how did they get it so wrong? No surprises - requirements, or lack there of. In evaluating the system, the client brought on board key stakeholders from the business to look at what the system could do, and had lots of meetings with minutes and agendas to discuss the pros and cons of bringing in the new system. After 2 years, they all decided that it was a great idea and would provide a major positive change to the organisation. There is another key word - change. In all that time, no one actually sat down and looked at the current business processes and mapped them out to provide an as is business model. More importantly they didn't look at the system and map how the system carries out the business functions that they use to operate their business. A simple example of this - client needs an payroll function, the proposed system has a payroll function, so the client ticks it off as being provided. The catch is, the system is designed to provide EFT payments to bank accounts, 20% of the employees need to be paid in cash. The system doesn't handle cash at the moment, so there is a redesign effort required to retro fit the requirement. Simple example, but this lack of rigour in requirements definition has plagued the project. It just hasn't been done at all well and we are now trying to mop up the mess and get it back on track... Just a quick mention of change management. One main reason for IT systems failing to meet the expected benefits is lack of user acceptance. I asked the executive sponsor if I could see his change management plan and they didn't have one. Apparently they can't put a change management plan in place until they have a deployment date. We still have a long way to go with this client. Keep the faith John