In a recent article by Speller International titled “When good SAP projects fail” they spoke about a number of things that make the project fail. These project pointers are relevant to not only SAP projects.
I’d like to look at each of these items in relation to setting the project up initially in the business case phase and how each of the items listed relate to preparing a good and strong business case.
- Poor Preparation – Yes, poor preparation comes about from not ‘solving the right problem’. Defining the problem statement by getting to the real heart of the problem that needs solving is critical to success. How often do businesses waste time and money on a project that doesn’t really solve the problem they have, because they don’t spend the time to get to the root cause. Spend the time getting to the real heart of the problem, in the business case phase and you’ll be sure to be building a system that really does meet the customer needs.
- The Untimely Timeline – Project timeline estimates are a critical part of business case development. Not only do the estimates feed into the financial area, and are critical to obtaining the actual funding required to fix the defined problem, but also in estimating the timeline. If the problem is not properly defined you will have difficulty developing a realistic timeline. Therefore start with properly defining the problem.
- The Blown Out Budget – I know that I’m sounding like a broken record, and it’s because defining the right problem is the key to all of these other areas working out. Your budget will blow out if you are unable to correctly estimate it. Why will you have difficulty correctly estimating it? Because you haven’t succinctly defined the real problem. Enough said.
- The Silent Type – Are you really listening to the business? Have you sat and asked them to tell you about their real problem? What I’ve seen is consultants who come in with a product that they are selling, who don’t really listen to the real needs of the clients. And yes, the comment on defining business requirements I totally agree with. If the business defines their requirements, and fully describes the core problem that they have, then this will go a long way to helping. Maybe it’s about vendors mirroring their client and being silent – so that they can listen.
- The ‘Not-So-Super’ Super Team – Building a strong team is key, and it must contain the right amount of specialist expertise AND business knowledge. This is about ensuring that your business case allows for the correct resourcing to be in place. You must have the right mix of both external and internal knowledge from the start in order to make the project work.
- The Cut Corner – The work here needs to be done at the time of developing the financial aspects of your business case. It is all about understanding the work that needs to be done to solve the problem (there’s that word again), and what resourcing is needed to deliver that, and how long that will take; then if any additional resources are required in order to shorten the timeline. It’s not about cutting corners. Any time that a project team start to consider cutting corners is time to revisit your business case. It’s the red flag that says your scope has not been defined properly. Scope in my mind equals proper problem definition and clearly defined requirements.
I hope that you see the value of developing the best and most complete business case and how it sets your project up for success.
Written by Karen Munro