There are problems you are likely to encounter when writing a software business case. The correct term is more likely an IT project business case. Here are the common pitfalls that I see and what you might do to fix them.
Problems Writing a Software Business Case
IT system business cases tend to be off track before the project even starts. My experience has been that the ‘problems’ I list below, set the project up to fail. Why? Because they are key areas that should be approached differently when writing the business case.
The Sales Team Have Done a Great Job Selling a Solution
Sales team listen to vendors. And if vendors have great salespeople, they sell businesses on THEIR system as the only answer to any problem the business has.
Vendors will always make the software fit the believed problem. They will talk you into a customized solution, that most of the time does not meet the businesses needs. This strong statement comes from years of watching this happen both in Government and Corporate Australia.
Customizing a software package comes at a cost. Overall project cost must include ongoing software maintenance charges. You can’t simply talk about the project timeframe in isolation.
Thank the vendor for their time and conduct a thorough RFI (Request For Information). This will provide options from a number of vendors, not just one. Go back to the basics of developing Business Requirements independently of the vendor.
Brainstorm ALL possible options. That could include developing a system to meet business needs.
Business Owners Don’t Provide ALL Information To The PM
Projects often start when a Business Owner has money in a budget to spend. The Business Owner wants to spend the money this financial year, so will create a project to do just that.
The WRONGEST reason to start a project. This is why this project will fail, or completely waste a bucket of money.
Often this battle to spend the money is a battle between the Business Owner and Finance. Finance wants to keep control of the funding or take it back. Business Owners want to keep funding and control how they spend it.
Vendors love these situations because they see easy money on the table for them. A Business Owner who is desperate to spend the money in his budget. The vendor with the perfect solution of how to spend that money ‘purchase THEIR software.’
Write a strong business case that shows the vendor system is not the answer to the business’s problem. Provide lots of options. It might be the best thing to show that the ‘Do Nothing’ option is the best one.
You might not win this war with your business case and if you write it succinctly enough it will show other senior managers that purchasing a system is not necessarily the right answer.
Cost Estimates Aren’t Realistic
Estimating isn’t realistic. It never is when you have an outside source providing information i.e. a vendor. Often times it is the internal teams can’t and won’t provide realistic cost estimates that set a project up for failure.
Estimates are provided after high-level investigation. Not good enough. Not the right way to bring a project in on budget.
With all of this going on there are lots of unknowns and assumptions made that are incorrect. Each of these will cost time, money and resources.
It is also common with this way of going about the development of a software business cast that hidden costs are not identified. More cause for concern.
This also leads to problems with the contingency, where it is overestimated. All red flags when it comes to setting the project foundations strongly.
Take the time to do proper cost estimates. Check the assumptions that people have. I find the best way to do this is to get a group of people in a room.
Gather together those involved in the business who know the current process or way of operating. Talk to them about how things work and if it was to change what they would want. You will be surprised at the information you will be given using this process.
Make sure that each of your options is properly estimated. That is the only true way to know which option is the most viable.
What Is This Software Business Case Really About?
It is not about a problem statement. It’s a story crafted to fit a specific piece of software. Details often fit a budget and the characteristics of a vendors software.
It is obvious reading an RFQ who has written it. When there are specific terms and details only available in a vendors software solution that comes through. This type of RFQ has ‘Failed project’ is written all over it from the start.
The software solution is the focus. This has tipped project foundations completely upside down. No wonder the project fails.
Go back and define a true problem or opportunity statement. Any software business case should begin this way.
Incorrect Calculation of ROI For the Software Business Case
When Finance and the Business Owner fight over funding often the ROI is simply ‘meet the magic figure.’
Intangible benefits are often overlooked and not captured. For example, customer service agents feeling better about their jobs. Why does this happen? Because Finance are only concerned with ‘real figures.’
Project Managers aren’t taught to look at intangible benefits. This creates a problem when writing a software business case. Intangible benefits should be included in the software business case.
Benefits that aren’t directly related to ROI need to be looked at too. Include the ‘people related’ intangible benefits.
It may be true that benefits to the business might be higher than a calculated ROI. The benefits of making a change are often higher than a forecast financial ROI. Financial ROI is only one true factor in the overall ‘business benefits’ package.
Business Unwilling To Take Ownership of the Benefits
“Business Owners are scared to take ownership of benefits realisation.”
An interesting concept to consider. A topic for another podcast episode.
Finance doesn’t wear ‘fluffy’ benefits. The Finance Department wants to see the headcount disappear, for example. Their focus is always on dollars.
Your project becomes BAU for the business as soon as it is delivered. Benefits are related to a project for them. The business, therefore, doesn’t see the need to track the benefits.
In a series of podcast episodes, I’ve covered writing a standard business case, writing for an agile project, a business case for ERP and tips for writing a business case for a CRM implementation. I also looked at what is needed in an EDRMS business case.
Read the blog posts supporting the podcasts for additional information. They all have valuable and different tips on the business case for each specific purpose. You may find value in listening to each one of them.