Every project, no matter the size, has a certain level of risk - the bigger the project the bigger the risk.
The best way to manage project risk is to understand the causes of project failure.
In the 1990's I read an article that resulted from a study commissioned by APICS. The article spoke about how often manufacturing software projects fail and the top 10 reasons these projects fail. This study interviewed manufacturing companies that had recently implemented a new manufacturing information system and attempted to quantify success or failure. The results were worse than the author expected.
That study indicated that 1 in 8 projects was deemed a success by management – 7 in 8 were deemed a failure.
That is a very low number and seems a bit worse than I would believe. The article did go on to provide some insight that I really agree with and would like to share with you. The author followed up with the 7 in 8 companies that deemed their project as a failure and identified the common themes across these companies.
Below is a list of these common characteristics:
- Lack of management commitment
- Part-time or no internal project leader
- Limited input from various departments in the organization
- Lack of project focus or goal of the new system
- Project seen as an IT project and not a business project
- Lack of training on new system
- Limited feedback on project status
- Selected the wrong software to address the business issues
- Inadequate outside resources
- Financial resources inadequate to achieve results
To reduce the risks in manufacturing software projects here are some items to consider.
- Is this the most important project on your company's agenda for the next 6-12 months and can management articulate that fact?
- Do you have a near full time project leader that understands most parts of your business? How long has this person worked for your company?
- Do you have a cross-functional team that can support the project leader?
- Does this team universally know the purpose and focus of this project? If you ask each member why we are doing this project, do you get the exact same answer from every team member?
- Is the focus something other than IT? Is there real business benefit that everyone can rally around?
- Have you considered how different people learn? Some require one-on-one, other require manuals and others repetition – does the plan account for each learning style?
- How organized is the project leader and can that person report the status of the project in a clear and concise manner? If so, can the organization change course if needed?
- Have you talked to other users that are using the exact system you are implementing? Did these companies have similar business issues before they started and have the issues been addressed by adding the new system?
- Does the outside firm supplying training, support and programming have a clear understanding and experience in your industry?
- Can you really afford the upfront costs to achieve your desired results?
Aside from that - keeping an open dialogue before, during and after the project with your team (including outside consultants) will take you a long way to reducing risks.
Best of luck on your project and I hope these insights provide a certain level of clarity.
No comments:
Post a Comment