You think you have a handle on how to deliver your projects. Then a mandate comes down that your development team is “going agile”. This is an understandably scary proposition for some people. Here we look at general patterns, models, values and practices that lead to success when thoughtfully practiced by motivated individuals.
The Spin Cycle
It’s that time of year when business cases are being prepared for next year’s projects, and it seems as though every year I am asked for tips on how to best “sell” a proposal. While I understand what’s being asked, it really concerns me to hear it put in those terms. A business case should clearly set out the benefits of what is being proposed along with the expected costs, and a number of supporting elements. It should then be judged alongside other business cases on its merits, and either gets approved or not. If the business case demonstrates clear benefit, then it shouldn’t need selling; and if it doesn’t, then it shouldn’t be positioned (or sold) as if it does!
The purpose of project justification
The fundamental issue with many project justification processes is that they aren’t completely based on what is good for the organization, but have decisions clouded by force of personality and political influences. This isn’t an article on how to improve the process, so we’ll save that for another day. But it’s easy to understand why projects are positioned to try and appeal to those stakeholders whose views and preferences seem to carry more weight.
Let’s try to put that to one side and focus on what the project justification process should be about. The project proposal or business case needs to address just a few basic elements, most importantly the following three:
- What benefits will the project deliver to the organization? That might be revenue growth or cost savings, but should be expressed in financial terms wherever possible. It should also address when the benefit will occur to allow for accurate calculation of the return on investment.
- What costs will the project incur? The obvious cost piece is the project itself, but this should also consider ongoing support and maintenance costs. Again, an indication of when the various costs will occur should also be included.
- How does the project align with organizational strategy? The organization will have established a number of strategic priorities and an explanation of how the proposed initiative aligns with those should be provided.
It’s clear to see how these elements contribute to the project selection and approval process--the projects that align with the corporate priorities and deliver the best net return are most likely to be approved. There will be exceptions, of course--regulatory projects, maintenance initiatives, etc. But the “game changers” will be approved based on the elements above.
Project proposals will all have their supporters--the people and groups that came up with the ideas and developed the business cases. The champions of these proposals have a personal stake in the project being approved--not just ego and reputation, but also more tangible factors like department budgets, resource levels, personal position, etc. So it’s very tempting to overstate the benefits, understate the costs and make the project sound as though it is more closely aligned with the organization’s goals and objectives than might really be the case--to “sell” the proposal rather than simply present it and allow it to live or die on its own merits.
Controlling the spin
To try to reduce the potential for abuse in the project justification stage, organizations should consider a number of different steps. One of the simplest--but also one of the most effective--is to provide standard templates for proposals that focus on numbers and how those numbers were developed rather than allowing for a lot of free text descriptions and discussion that may not add value. This also helps to make the review and comparison of proposals simpler because there is more consistency between business cases. The downside of this approach is that it makes a proposal rather “sterile” and removes the opportunity to explain what may be new and complex ideas.
The next step that organizations should consider is an independent review of numbers prior to submission to the decision-making process. An informal audit by the finance team of the cost and benefit claims can help to identify any errors or unrealistic assumptions and will also ensure that there is consistency in the numbers used for the different financial calculations (things like exchange rates, cost of capital, etc.).
The final step that can be taken is the simplest, but is rarely done. That is simply to measure the actual benefits and costs against the business case. In many organizations, the business case seems to be ignored as soon as a project is approved. By holding sponsors accountable for the numbers that they claimed in their proposals, a lot of the more blatant salesmanship can be eliminated.
Project justification is a competitive business--there will always be more proposals than there is money available for investment, and it’s easy to understand why people try to gain an advantage over competing proposals. It’s the organization’s responsibility to ensure that this “noise” is eliminated and that all proposals compete equally for the available funding.
Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at email@example.com. Andy is also on Twitter at RoffensianPM.
Thanks Andy for your article. Andy explains some of usually overlooked items in his article. Specially the baselining of business case. I have a question. Doesnt the program management practice address this? Especially through Benefit realization?
This article touches a rather sensitive and painful area, especially in nowadays rush-time for the next year budget. I agree with Andy's standpoints.
The only point is what Malcolm claimed as well, measuring the benefits promised in the Business Case is a very complex and rather difficult task.
According to my experiencehere are some reasons why:
Usually this is not included in the bonus pack at C-level
When the project has delivered the outputs, only some quick wins can be measured
There are no validated plans how to measure the benefits
Quite a few company think of baselining the Business Case (let's say by project phases), especially when a very poor one was approved
Who prepares the measures and reports for the future, and persuades the IT to put it on the S.O.S. list to do so?
Finally the most important reason: usually not the best people are involved in the preparation ot the BC ( neither controller, nor Business Analyst, nor Project Sponsor)
It is facisnating how the 'sell' becomes so important when someone has skin in the game. A business case (BC) not approved is seen as a failure. I totally agree it is important to measure the benefits against the Business Case. But I wouldnt agree this is the simplest step. Ideally the BC should specify not only the benefits, but a baseline and how the benefits are to be measured. This is often not done, leaving a somewhat subjective postiion for measuring benefits. In addition such things as an increase in revenue by 5% is difficult to attribute, what other factors were at play outside the project? Having clear benefits and measurement criteria in the BC makes this cleaer, but still not easy.