|A.||Business analysts replace project managers, so once you assign a BA to a project, your work is over. All you will need to do is help referee the conflicts between the BAs and the IT teams.|
|B.||If your business analysts are trained and certified, they’ll know their own roles or can adjust quickly to what you want them to do. The agile IT team should be fairly self-directed. All you need to understand is who does what, present the responsibility chart and stand back ready to support them if needed.|
|C.||Agile teams do not need any supervision or direction over and above their own ScrumMaster, who is 100% devoted to one project at a time. Ask your BAs if they will cross-train as ScrumMasters to maximize the number of projects you can run at any one time.|
|D.||Due to the new strategic and business requirements from PMI, project managers have now been renamed. Just have your newly christened business analysts do what project managers have always done.|
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.