4. Hints and tips on Mountain Climbing, not a guide to Climbing Mountains…
5.
6.
7.
8. Four Questions 2. Are we doing them the right way? 3. Are we getting them done well? 4. Are we getting the benefits? 1. Are we doing the right thing? Alignment Integration Capability/Efficiency Benefits
9.
10.
11.
12.
13. Benefits Realisation Management Process Develop/update business case; time-phased cost, benefit flows;plans Perform to plans Benefits being realised? Assumptions still valid? Determine corrective actions Yes Yes No No
43. Exec Summary Name of project Responsible Board Member Project owner Project manager Objective Value Drivers Market launch Estimated cumulated investments Present Value
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55. How should the Business case and Benefits be measured and managed during the project’s delivery?
63. Relationship to Other Management Disciplines …… ..Is Benefits Management a core competence of a Project Manager? ……… Should the PM be involved? PMBOK Application Area Knowledge and Practice General Management Knowledge and Practice
Not a “how to climb a mountain” guide — more of a reminder on climbing security… i.e. not about what steps you should take, but how to avoid slipping off the ridge…
As research such as this indicates, high performing companies are more likely to use analytic information strategically. Companies that have a depth of analytic support, that use it across their entire organization, and value the insights they gain from their analytic solutions—these are companies far more likely to be high corporate performers. Finally, if you’re not measuring how can you be managing….
With limited investment available, we must be sure that we run projects that are likely to deliver the changes we need. So we must define that needed change and the benefits we expect from it. We must ensure that the benefits are as measurable as possible. The measures used will be as wide-ranging as the projects and will include performance indicators and financial benefits as appropriate.
Financial benefits are among the more measurable, but still require some judgement. Financial Services will use a standard method for calculating the value of benefits, so that we can compare figures across projects. We will calculate both Payback (best for shorter projects) and Net Present Value (NPV - best for longer projects). This is just one of the criteria when judging whether a project is worthwhile.
In addition, we will look for non-financial benefits. Any project must contribute to a corporate priority. We expect to be able to use existing measures in most cases, as new measures may be expensive to obtain and do not give us any historical information. We will then measure before and after to ensure the project delivers. Example: We measure the number of complaints received in the six months before and after a project designed to reduce complaints.
Finally, we want to change the way the organisation works, as described by the four pillars of the Organisation Development Vision. So each project in the Change Programme is expected to contribute to changing the way the organisation works, as described by the four pillars of Change. Example:
Some projects may deliver a capability, expecting later projects to exploit the capability. So benefits will only be realised by the later projects. There is the obvious danger that the later projects may not happen, meaning that the anticipated benefits are not realised. So we will ensure that the later projects are identified and funded when we commit to the capability project. Example: First project puts the technology in place to allow users to identify themselves on the internet, using a username and password. Later projects use this capability to provide services which require the user to be identified before providing access to personal information.
This is similar to the previous example, but in this case the benefits will only be measurable some time after the end of the project. So there is a need to link the achievement and measurement of the benefits to an ongoing process, with a named owner. Examples: A new project management system is introduced and staff trained. But the benefits are unlikely to show for at least 6-12 months, when the first projects to use the system are completed. So an evaluation of those projects needs to be scheduled in order to measure the benefits obtained from the new system. A new web service is introduced by a project. An evaluation of the benefits of that project would have to wait for several months in order to allow time for users to find out about and try the new service.
Any financial saving made by a project will be removed from the relevant budget(s) and made available for reallocation during the formal budget-setting process. If a project generates efficiencies that result in posts being lost, there will be a process, based on existing council policies, for finding new posts for the staff affected.
As the Change Programme progresses, we can expect to: Manage projects and their benefits so as to stay within the Council’s cost envelope Manage both headcount and budget, for example planning recruitment with a knowledge of what staff might become free as a result of Change projects When necessary, restructure so as to make best use of new technology and improved ways of working.
So, to the left we have the Business planning activities, and to the right we have the delivery side. The key here is that to develop a successful change programme (the right side), you need to understand the left side. So, lets put this theory to the test: Could we have a show of hands from the room on the number of organisations that use put Business case approvals in the context of an annual budgetting process? OK next do Business cases approvals/rejections for project take place within the context of a strategic framework (typically this is a three year development/investment plan…..Show of hand please…
Many of System Dynamics clients have central IT functions supporting Business Units, increasingly we are seeing IT moving toward operating in a shared service centre model. What does that mean? Some organisations operate this as an internal market with chargeback for IT resources Some have fully outsourced operations and projects to third parties Supporting competing, duplicated and sometimes contradictory Business unit goals as a central IT function is a key challenge. The common denominator in all this is cash… So, tough as it might seem - Benefits need to be measured on a like basis, this basis is the monetary value.
I think this quote is quite interesting at it appears to contradict the previous slide. On the one hand we’re saying that to prioritise between projects, that a quantified business case is an absolute necessity, on the other Gartners view appears to be that the evidence contradics this and that this could actually be creating the opposite effects on the ground. Perhaps this points at two possible causes: There is a skills/experience gap in IT and the Project management community in developing cohesive business cases Payback periods for investment decisions are too short. So again just to make sure everyone is still awake I’d like to ask for your opinion. A show of hands please, in your experience are Business case justifications in your organaistions presented over 1 year, 3 years, 5 years, more??
So – you’ve implemented your project and everyone has taken a well earned rest. At the post implementation review you review the performance of the project against the baseline (Scope, schedule, quality), document lessons learned, etc etc. Is that when you check whether the Business case has been realised…….. Is that part of the scope of the project……. Is that the PM’s responsibility or the Business owner of the Project…..
Looks quite similar to a table of contents for a project initiation document/project charter doesn’t it? Perhaps the key difference is that a project initiation/project charter document describes the what and the how of the project, but doesn’t necessarily describe the justification for why the project will be delivered and the anticipated return in enough detail. I’d like to test that point if I may via a show of hands: 1) How many project initiation documents/project charters in your organisation include a costed Business case? Looking at the Pyramid to the right – note that the supporting analysis and information is supporting the business case, without it it doesn’t mean much. The key point here is to do your homework on the costs and benefits as well as understanding the scope, objectives, alternatives, risks, schedule, resources etc.
So what does the PMBOK guide on initiation recommend? Actually it does cover Business case/business justification. – page 53 PMBOK 2000. “ Initiation is the process of formally authorising a new project should continue into its next phase. This authorisation links the project to the on-going work of the organistion and should business need, market demand, Project selection methods also describe the need to measure value, and uncertainty (risk), PMBOK describes it as the decision model and calculation method. In my opinion, the level of detail in PMBOK doesn’t support the importance of the task, this is an area for more work in the standard.
![Objectives ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)