How to Hit the Right IT Project Balance
What dooms IT projects are too much customization, lack of focused training, lack of management involvement, poor consultant management, and finishing a project too soon, according to a recent report from Nucleus Research, "Avoiding the Top Five IT Mistakes." The firm reviewed results from thousands of IT projects in areas including collaboration, CRM, e-commerce, ERP, integration, and supply chain and found that technology is rarely to blame for project failure.
"Striking the right balance between business requirements, technology capabilities, and realistic employee adoption rates goes a long way toward ensuring the success of any IT project," says Kathy Quirk, research manager at Nucleus Research. The report warns of the following negative markers:
Too much customization rarely increases usability, but will increase both initial and ongoing costs. Although we all want applications that are easy to adopt that users love, companies that customize applications too much get an ROI double-punch. Initially, they spend more on consulting and take more time to deploy than a vanilla application, and on an ongoing basis, they require more consulting and personnel to support and evolve.
Skimping on training
Even if an application is intuitive enough to be usable without instruction, any related process or culture changes should be driven home with at least a quick tutorial. Nucleus found a number of Salesforce.com customers, for example, that deployed the technology without user training but were challenged to get people to enter information. As a result, they ended up abandoning the tool or investing more in changing bad behavior later because they hadn't trained in the beginning. Train on context as well as content. If users have to significantly alter the way the work, change management should be a key goal of the training process. Be prepared to explain why the changes are happening and what's in it for the end users.
Companies also should follow a vendor's estimates. For example, if a vendor suggests 40 hours of training are necessary, but a company only wants to spend 20, perhaps they should reconsider purchasing that application. Secondly, only train the employees who need to know certain processes instead of making the entire company sit through it.
Executive involvement can be critical if the project requires new collaboration between different groups within an organization or if users are hesitant about process change. A C-level person that's willing to lead by example, by making the new application the only channel by which they receive information or by incenting use in other ways, can drive effective adoption. Building a business case that includes expected and worse-case returns, milestones for business results, and a clear list of expected benefits can help you open the dialogue.
Organizations must speak up if they are concerned about project management, negotiate pricing and payment terms, and agree on any expected time and cost for customization, integration, or development. It may take another day of whiteboarding to get there, but before you begin a project you should be sure both you and your partner understand clearly what work needs to be done and who will do it.
The beginning or the end?
The project ends not when it's deployed, but rather when it's effectively used, which can be months or years later. If a company has invested in ERP or CRM, there's likely analytics or additional integration projects that can help leverage more value.
The best way to avoid these pitfalls is to have a structured project strategy based on the expected timing of costs and benefits, not just a project plan. Building a clear business case is in the beginning and using it as a budgeting and planning tool to structure your expected costs can help give you the roadmap to continue to maximize value from your IT portfolio.
Self-Marketing--IT's Better Business Value
Data Quality: Is It Up to IT Alone?