Your Project is Delayed. Now What?
By Todd Boehm
There are plenty of statistics showing how many IT projects are not finished on time, go over the schedule, and are delayed. One recent study said as many as 97% of projects were not finished on time in 2008.
There are plenty of reasons why projects are delayed, and plenty of articles detailing what to look for, how to try to prevent the problems, and what are the biggest causes. Bad planning, poor estimations, scope creep, lack of cooperation, bad luck, lack of resources, changing resources, all of these can affect the timing of your project.
Computers make things seem simple, but when you get to the details, it may take you longer than you think to finish. An IT project going over its schedule is nothing out of the ordinary.
However, once you are there inside the delay, then what? Anybody working on the tasks within the critical path will obviously be pretty busy. They are the ones who are most likely behind and need to catch up. They are the ones who are probably most worried. They are probably promising only a short delay and working hard so as to not be blamed for a huge failure.
What about people on the project who are in a waiting mode? What are they supposed to do? The risk for these people is loss of momentum. They may see the gap ahead of them, put aside the project and work on other issues. They may forget all that they have learned with regards to the new software, processes, or training. They may find other important tasks that will take priority when the project finally gets back to them.
If it is a short delay, then finding tasks for these people to accomplish won’t be hard. Projects can always use more people checking on quality issues and trying to make things better. Documentation is usually a weak spot that can be strengthened during an unplanned delay. If possible, adding to the testing processes as well as better training for newly added or existing testers is a good time-filling task. Training and documentation for the training is usually one of those last minute issues that could be done by people with a little available time during a delay.
What if the delay is longer? An ERP project will usually involve the migration of an accounting system. They may not want to go-live until a month end. That means a delay of even a few days will result in a full month of downtime.
It could be even worse. If the public company is worried about SOX and auditors and getting their public numbers out the door, this may cause further delay. There are plenty of good reasons not to go-live in the fourth quarter of the year. The fourth quarter may be when all of the auditing happens and executives may not be comfortable making major changes right when they are signing off on the quality of their company.
The project may be further delayed simply because they can’t spare the time. The accountants are busy on their old system, or manually if they don’t have one, closing the books every month. They spend a lot of time every month, every quarter, and every year end balancing the books. They may need to wait for the ‘best’ time for a go-live.
If your project is delayed by months, then you’ll need to make sure you keep people up-to-date. You will need to make sure people get re-trained. You have to keep people involved.
Mini-Pilots are a great way to keep people involved. You don’t want them to lose sight of the final goal, and their responsibilities to get there.
Another way I get people to work on the project is ask for more testing. Being technical, I can load data, setup programs, and create data. I then ask the appropriate people to validate my work. They need to see if what I did is what we want to happen after go-live. They may need to test the programs I setup, or look at the data to make sure there are no complications.
- For an accounting system, I have plenty of options for processes to validate. I can load inventory, shipments, orders, invoices, etc. and then get accounting to see if the transactions are accurately reflected in the General Ledger. I can load trial balances and hand them over to accounting to make sure they balance with the right accounts.
In manufacturing, I can run MRP and then get people to make sure that the right reports have been generated. I need to make sure that after we go-live they will know how to fulfill their orders. After that, we can check the transactions to the G/L to make sure the costs rolled up correctly.
In a CRM system, I would make spreadsheets with sample data and have people try to use that data as if it came from a customer. I would also schedule meetings where people can pair up, with one person pretending to be the customer calling the other.
The sales people will need good reports. A delay is a great time to have them ask for more details. Unless the report writers are still on the critical path, they can be fixing reports. Usually the reports are one of the last things to be changed. No one really knows what they need until they need it, and that is usually after go-live. Now is the time to get people to really study the new reports and ask for the changes they will need.
The other important thing to do during a long delay is to ensure communication. People need to know that their deadlines have been extended. Some of them may be breathing a big sigh of relief. They need to be reminded when the time gets close again. During a long delay they easily could have forgotten about the project. It will be up to the project management to push people back on track when the time is right.
Even when the project is not at full steam, it’s a global world out there, and technology makes it happen.
Todd Boehm has been a technology consultant since 1997 – helping companies perform better, fixing/analyzing their technology problems, and improving their systems. Todd currently works at Tatum, and can be contacted through his blog, World Class Technology Discussions.