Many failed ERP (or other package software implementations) fails due to some combination of these three factors:

1. Companies mistake a unique back-office process for a competitive advantage. Usually a process evolved organically over a long period of time, and after several years is left with an “evolutionary hangover” of inefficiencies and steps whose justification has long since been forgotten. Rather than spending months trying to cobble these processes into packaged software, focus your creative energies and innovative efforts on your products, services and R&D and settle for simplified, generic and ruthlessly efficient back office processes.
2. In a “design” phase, spend some time trying to simplify your organizational structure, and examine if you are making your business more complicated than it needs to be. Follow the rules above.
3. Build a cadre of “outside the project” advisors, either external or internal people not closely tied to the project, and in the case of outside resources, consultants who do not provide implementation services or have a financial interest that might bias them. Review the objectives of the project with them before you start, and let them serve as an unbiased sounding board should things go awry or should you need to make a critical scoping decision.

First, I would NOT skimp on performance evaluations. As a manager it may be personally hard to tell someone they are a low performer, but especially when there is little/no pay to go around, you need to honestly evaluate your top people, recognize your high performers, and provide a detailed career map for everyone that tells them how to advance. Rather than splitting what little monetary pot may be available among everyone, allocate it to your key players. This is not the time to attempt some schoolyard notion of fairness.

In terms of staff development, let employees explore new technologies, or build small prototypes then present their findings, essentially letting them do “independent research” in an area that interests them, that vaguely ties into the goals of the corporation. It’s free, would likely have been time lost to web browsing anyway, and improves morale, develops staff presentation skills and just might produce useful prototypes that can be leveraged into an enterprise project.

I recently wrote about this on my Tech Republic column which has some additional ideas: http://blogs.techrepublic.com.com/tech-manager/?p=1153

1. Certification Surfing. Many in IT use certification or “guru” organizations as a shortcut to hiring key project staff. While a PMP or other certification may be nice, the person sporting a raft of letters after their name may be an exceptionally poor project manager. If you have a critical project with significant money and time at stake, take the time to vet candidates for key positions in person. The cost and time required far outweigh even a few days lost to poor management once the project is in full swing.
2. Focusing on Deliverables. Many of the project management methodologies focus on the wrong thing, so-called “deliverables” that are generally supporting documentation or ancillary tasks that do not directly relate to the business objectives of the project. When deliverables become disconnected from business objectives, you can easily get into a situation where the project is 99% complete from a deliverables perspective, but 0% complete in actually meeting the core business goals of the project. Ensure that projects are measured and tracked on objectives that are “MAD:” Measurable, Actionable and Dollar-based. While a functional spec or technical document may move you towards a business objective, it should not be used in reporting the project’s completion until the underlying business goal (getting sign-off on a prototype, resolving a process question, hiring appropriate staff, etc.) is complete.
3. Postponing Decisions. While postponing decisions is often done in the name of “keeping our options open,” the longer you postpone a critical decision, the fewer options you actually end up with. To make a project effective, ensure that decisions are made in a timely manner, and that the actual decision making process is transparent and limited to key parties. While anyone can have an opinion, the actual decision should be made by a group that is specified in advance, otherwise you will spend weeks soliciting opinions and building consensus. With high-dollar burn rates, a good decision today is often cheaper and equally effective in the long run than a great decision a month from now.