#1) No Plan: Projects need a comprehensive plan including (but not limited to) solid requirement definitions, valid timelines, resource allocations, communication, risk assessment and quality control. These are basic to all plans.

#2) No Metrics: You must define, (upfront) how you will gauge a successful project.  Examples may include "20% reduction in inventory carrying costs", "15% reduction in international long-distance" or "reduced system administration and ongoing associated costs" etc.

#3) No Buy-In: Over the years major corporations have spent billions of dollars in project implementations (usually at the request of the IT Manager (or CIO) only to find, halfway through implementation, the "IT Budget" has been cut and the project is either put on hold or cancelled.  It is important to understand that there are no "IT Projects...only Business Projects" which require the full support of the Executive Board or Senior Management.  Remember that when the CEO commits the project manager needs to provide constant communications and status information.  Inversely, the executive team should advise ALL direct reports that this is a strategic business project and as such, their full support is expected.  This goes a long way in neutralizing political boundaries and establishes open lines of communications.  Also keep in mind that if these regional/area VP's and managers "sign-on" they want to ensure interruptions to their agendas are kept to a minimum.  This can be achieved by pursuing the next issue, #4) Training.

#4) No Training:  OK...the "system" is ready for production.  Now what?  Make sure you follow through with a comprehensive training plan "prior to going LIVE".  Not only will this provide feedback to your project and development teams regarding usability but it usually uncovers process-related issues previously not considered.  The project budget should include funding for initial training in all aspects of the "system" at the required levels of details.  Make sure you include 'discretionary funds' to cover the costs of those in need of additional instruction or assistance.  If your internal resources are bogged down in technical issues engage an outside training organization to assist in development and deployment of the training curriculum as well as provide feedback to confirm everyone in 'on the same page'.

#5) No Closure:  "Scope Creep" (allowing additional work to be performed after the project has begun) is a recipe for disaster.  This almost guarantees the project will never finish on time or (worse) continues forever.  Projects must start and end.  Any additional changes / enhancements should be considered carefully and (if required) may require adjustments to the plan.  If it is decided these requests can be put on hold it is important to have those documented change requests ready for review "immediately" after the initial projects closure.  These could be hidden gems just waiting to be discovered and can bring about additional benefits not initially realized.  Finally, you should bring together all members of the project team (including senior management involved in project planning) and create a document outlining "LESSONS LEARNED".  This document should detail specifics relating to DIFFERENCES between the initial scope, timelines and cost estimates and actual outcomes.  The "LESSONS LEARNED" document is extremely useful for future endeavors as it highlights areas where the projects' outcome did not meet expectations.  This allows you to fine-tune your methodology going forward.

 

(dlm)