Last time I looked at 4 soft benefits that go into project business cases and are a factor in project selection. They were:
Today I’ll look at another 4. You may be able to include these in your next project proposal alongside the financial measures and with any luck they will help get your project approved.
1. Increased user satisfaction
Customers are one thing, but it also pays to improve the experience for internal users. So if you are designing software for use in-house or for clients, improving their satisfaction with the product will be a significant project benefit.
Project selection should take this into account as (generally) happier users are more productive and are more likely to stick to the processes. If the products they are using are not easy to navigate, they will find ways around the processes in order to make their lives easier. This negates any benefits the software or process is designed to offer. In my experience, going outside the process means that data isn’t collected in a standard way so any measures are incorrect. Many user satisfaction improvements could be done to systems to improve data collection and make it less obtrusive for users – a better experience for them and a better standard of management information for others, so everyone benefits.
2. Improved corporate image
Improving brand awareness is one thing, but what if everyone thinks your brand doesn’t represent value for money? Or that it is not socially responsible? Some projects are designed to improve the image of your brand and while these won’t directly impact the bottom line they could result in more sales or a brand that is ‘worth’ more.
3. Increased safety
Safety measures at work normally cost money, so health and safety projects can find it difficult to justify the investment. But how do you put a price on the health and safety of workers? Projects that implement new measures or better processes that will help avoid accidents are essential in some cases.
And they do indirectly contribute financially: lower insurance premiums, fewer sick days so better staff productivity, better staff morale from knowing they are with a responsible employer and fewer court cases, one would hope. But putting a financial measure on this can be difficult: your finance department may have some models that will help, but otherwise it’s probably best to leave this as an intangible project benefit unless you can categorically link it to a financial figure.
4. Meeting regulation
As I mentioned in a footnote last time, sometimes projects are done for no financial benefit at all because change is required to meet new regulations. There isn’t much decision making involved in project selection when it comes to regulatory projects because you have to do them. You could make the link to financial benefits such as reduced risk of being fined by your industry watchdog, but in reality you are going to do the project anyway, so there isn’t any need to spend hours working out the financial figures – just get to work on the project!
Project selection processes differ from company to company depending on what your business considers important. For some it will be to make tactical changes, for others project choice will be limited by the resources available or by corporate strategy or by the technology available to support projects. All project selection should consider the chance that the project will be successful: there really is no point kicking off a piece of work that has very little chance to succeed as this is simply a waste of resources and time.
Selecting projects effectively, even if the business case is made up of ‘soft’ benefits, will ultimately benefit the firm financially as it means project teams will not be tied up working on initiatives that are wasteful, not a good fit for business strategy and that won’t contribute to the company. Pick your projects with care and use your project time wisely!
Project selection: more than just ROI
When we select what projects to do, return on investment is one of the major decision-making factors for many companies. Financial measures like cash flow and ROI are essential: after all, who wants to work on a project that isn’t going to contribute to the bottom line? What’s the point?*
The financial justification of a project is normally worked out by whether the financial benefits outweigh the project’s total lifecycle costs, by how much and when this happens. Your finance team or portfolio office will probably have a selection of measures that they use to calculate the important sums behind project selection.
However, financial benefits aren’t everything.
What else needs to be considered?
You’ll probably have worked on projects that don’t have huge financial benefits but contribute to the company strategically or tactically in other ways. Here are 4 additional ‘soft’ benefits that can (and should) be taken into account during project selection:
1. Increased customer satisfaction
Happy customers generate return business and it’s a commonly held belief that it costs less to keep a customer than it does to attract a new one. So it really does pay to get your customers on side and keep them happy. How do you measure customer satisfaction? Whether it is through surveys, an Exceed customer satisfaction review, focus groups or amount of ‘likes’ on social media sites, you’ll need to take a baseline first before your project implements anything so that you can do a comparison later on.
While customer satisfaction is often considered a soft benefit, customers do spend money so there are financial implications of keeping customers happy. Normally though, this is really hard to work out in terms of adding numbers into a business case, so unless you’ve got some complicated models it gets lumped under the ‘soft’ benefits category. Pair it with increased revenue as a hard financial measure.
2. Improved brand awareness
While brand management and PR agencies would probably say that there are tangible financial measures relating to brand awareness, it is hard to measure and in my experience isn’t worked out for project business cases. If you are opening a new store, for example, this will increase brand awareness of your business in the area where the store is, but how do you measure this? It’s tricky. And even if you can measure it reliably, can you link it to a financial measure? Just because people know about the company doesn’t mean they will spend money with you.
3. Better staff morale
Lots of internal projects are done to improve staff morale, whether that’s decorating the staff canteen or implementing a suggestion scheme. Staff morale is something that can be measured and many companies run internal staff surveys to track how employees feel about the company. Compare these results year on year and you’ll be able to see how morale changes, but there are many factors at play so tying these results to one particular project is difficult.
I’ve read research that shows happier staff are more productive, so if you equate productivity with revenue, you can see that there is a financial link. However, it’s one of those that is again tricky to prove or to calculate without some complex models. Still, go for it if you feel you can!
4. Improved processes
OK, some processes do link directly to cash. If it takes a couple of hours less to complete a process you can work out the salary savings of the people involved. But normally with this sort of project you don’t move those staff on to a contract that says they work fewer hours per week. They will fill the time with other things, so the gain is in productivity and the ability to complete more work rather than in direct salary savings.
Even so, improved processes are a good thing, so whether your tangibly calculate the saving or report it as a soft benefit, it’s definitely something to record in the business case for project selection.
Of course, not all business cases will include all these elements, and many will include other soft benefits as well as all the financial measures. Next time I’ll be looking at 4 more soft benefits that could be a deciding factor in project selection so stay tuned!
* The point might be to meet regulation or for other compliance reasons, so I am aware that there are some projects that have to be done, regardless of whether the company is going to make any money.
Earlier this month I looked at what Michel Thiry says is important for a preliminary program business case, according to his book, Program Management (Gower, 2010). Today I want to look at the things you would include in a full program business case.
Let’s say that your preliminary business case has been approved by the powers that be. Now you have to put together a full business case for the program. This may be subject to further approval. Here is what he says needs to be included in the document at this stage.
Carry out a full stakeholder analysis and include it in the document. You should also put in a stakeholder engagement plan – this shows how you will work with and communicate with all the different stakeholders that have been identified as part of the analysis. What’s different about a program business case is that this piece of stakeholder work should also include which benefits relate to which stakeholders. In other words, who is gaining what from the program. Your program marketing strategy can also go in here, although Thiry says that at this point it only needs to be a high level marketing plan.
Review the scope again and make sure that the final version is accurately reflected in this document.
Your preliminary business case would have included some costs, but this is the place to document the program’s baseline budget. You should also specify where the money is coming from. If you can’t plan the budget for the whole program, do it in stages and only include the detail for the first stage.
By this point you should have some idea of who you need on the team, so this is the place to put in an organisational chart. Thiry recommends showing the decision makers and communication channels here too. This is also a good place to list the roles and responsibilities of the people involved in the program. You can link this to show who is responsible for benefits and delivering to the critical success factors or key performance indicators.
Document all the links to other programs, projects within programs, other business activities, and (although Thiry doesn’t specify it) things happening outside the company such as regulatory changes.
This is specific to a program as you probably wouldn’t need one of these on a project. This specifies the work required to properly integrate the outcomes of the projects into the program and embed the new capabilities in the business.
This is a fancy word for timescales. This should show when the benefits are likely to be achieved and the key program milestones, taking into account when resources are available.
Write down the governance structures that the program will abide by. This could include reporting schedules, dates for audits, approach for peer reviews and what criteria will be used to assess whether the program is performing effectively. Change management also fits in here. I would have thought that you could simply reference existing company change management processes but if you have to put together something specific for this program, this is the section to spell it out.
Here is where you list the activities and projects that make up the work to do for the next stage. It doesn’t matter if you can’t predict all the projects and tasks required going forward, but you should at least know what’s coming up in the next stage. Thiry says this is the point where you identify (and, I suppose, seek approval for) the projects that make up that stage and prepare the relevant project charters.
That’s it. That still seems quite a lot, but if you don’t know all this information, then you can’t really move forward effectively with the program. It seems to me that this gives you more than just the business justification – in effect, it also covers a lot of what you would expect at charter stage, if we compare this to managing projects.
Have you ever worked on a program? What documentation was in place before it started or moved to the next stage?
In his book Program Management (Gower, 2010), Michel Thiry looks at the elements that make up a business case for a program. In the first instance, you start off with a preliminary business case. A full business case can come later, when you have worked out whether there is enough justification to pursue the work. Here are the elements that he says are essential for that early business case.
Why are you doing this program? This should include a statement of the problem.
As with a project business case, set out the objectives for the program. This should include the high level scope statement and something about the timescales for the program.
Depending on what system your Project Management office uses to classify programs of work, specify the classification or category of program. This could be something like ‘compliance’ or ‘continuous improvement’. I think that if you work in a small company you may not have enough programs running to bother to include this.
This is the section where Thiry says you should include the critical success factors. Specify how the program will contribute to strategy and deliver something to meet the critical success factors at a strategic level.
What a great section! Apparently, this is where you include a statement about whether the program can be achieved. He concludes that it is a subjective assessment at this point but that you can base whether or not it will be a success on some preset factors (which he does not specify). I think that if you have a belief that the program will not be a success there is not much point bothering to put together this business case at all. Who is going to report here that their program is never going to deliver anything and will be a total failure? Still, the concept is interesting, especially if this section is completed by someone independent.
This section is self-explanatory. Include key deliverables and the associated milestones. You can also link deliverables to critical success factors or key performance indicators.
Include a short statement about the major risks and opportunities. He doesn’t talk about including mitigation plans but you could do this too if you already know what the approach would be.
This is the section to list the types of resources you need. If there are any special skill sets required, note them here.
Impact on organisation
This is an interesting section – it should cover the impact of this program on any other organisational initiatives that are happening at the same time. I suppose you could call it ‘dependencies’. This is where you can note any resource conflicts too, but equally any advantages of running this program in parallel to other work.
Of course, every business case should include costs. If you put your document together in the order Thiry suggests, by the time your sponsor (or the group that decides on whether to approve your program) gets this far, they should be thoroughly convinced that this piece of work needs to happen.
Benefits realisation plan
How are you going to get any benefits from this program? Specify how any financial benefits will be achieved, when the company should expect to see them and who is responsible for them. (Ideally, they should know that they are going to be responsible for them prior to you submitting the document, in my opinion.) You should also specify any non-financial benefits and how they will be tracked.
All this adds up to just the preliminary business case – which implies that a full program business case would need a lot more detail. However, this should be enough to help senior managers make a decision about whether it is worth investigating this program further.
Have you ever prepared a business case for a program? What things did you include?
Business case basics (part 2)
Last time I looked at some of the basic features of the project business case – the key document that sets out what the project is going to achieve, how the work will be done, and most importantly, why this is a problem that needs to be solved right now. I covered the purpose of a business case, who is likely to be reading it, and the general format. Today I want to look at what different sections go into the document to make up the full business case.
These aren’t in any particular order, and you can arrange the segments as you like, perhaps according to whatever template is used as standard by your Project Management Office. However, if you are going to use an executive summary, that has to come at the beginning, so let’s look at that part first.
Normally, you write the executive summary last. It is a short statement, normally no longer than a page, that sets out a summary of the whole document. It is for people who don’t have time to read the whole thing, but it is also useful for everyone. You get a complete flavour for what the document will be about and how the project is likely to unfold, and then you can read the detail on the subsequent pages.
Because it is a summary of the detail of the document, that’s the reason we write it last. You need to know what goes in to the rest of the document before you can summarise it here!
Statement of need or problem
Early on in the business case you should set out what the problem is that this project will address. After all, readers will quickly want to know more about the issues faced by the company and how this project will fix them. Mention the current situation, if this project relates to improving a particular system or process. Figures and other types of data, such as customer surveys, can also be useful for making the point that there is a real issue that needs addressing. If you can, link the problem back to strategic objectives or key performance indicators for the company, maybe referring to elements of the balanced scorecard.
The important thing in this section is to remember that it will be business people who are reading it, not technical staff or project managers. Try to avoid jargon and make sure that you set out the problem and solution clearly.
A business case should look at all the potential ways to remedy this problem before making a recommendation on the best one, so include a section where you spell out the different options. By this point you’ll already have a view on which solution you will be recommending, so don’t spend too much time describing options that have been rejected and why they are no good. However, you should mention them, so that the readers know the thought process that you went through to identify the best way forward.
Remember that there is always an option to do nothing, so you should also include this as a comparison to the proactive options.
In this section, spend more time explaining your proposed solution. You do have more space to go into detail, but again remember to keep it all in business language avoiding jargon where you can and being really clear about how this particular solution will help solve the problem.
This section is something that you could refer to later when putting together your project initiation document or charter, so it can also include a summary of costs and benefits, key milestone dates and who will be required to work on the project. If you don’t know names at this point, make a note of the key skills or job titles required.
Every business case needs a section on costs as this is one of the main ways that people make decisions about what projects to do and how to prioritise them. Costs cover a number of different areas so consider these:
You can probably think of some others yourself.
The flip side of costs is benefits, and your business case should make it clear what benefits will be achieved by working on this project. Benefits could include things like increase in customers, revenue, staff morale, or avoiding costs, or ensuring the company remains compliant with current legislation.
This section covers positive and negative risk and you would want to include some detail about what mitigation plans would need to be put in place to manage the risk if the project was approved. You can group risks into categories if that makes it easier to present the information to the readers. Your Project Management Office may already have a standard set of categories, but if not you could consider things like technical risk, business risk, and any dependencies on other areas or projects, as these could also be risks.
Those are the main considerations to look into when producing your business case, although there are no hard and fast rules and it is best to include more information (as long as it is clear and concise) than less. This gives people the information they need to be able to make an informed decision about whether to progress with the project.