- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2023 02:40 AM - edited ‎10-30-2023 05:39 AM
We would like to include future running costs when calculating the business case for a project. As they form no part of the investment costs or project budget, we cannot add them as cost plans since they will mess up the financial follow-up of a project.
Currently we have applied a small modification in the code to allow for 'negative benefits'. The running costs for an assets life cycle are added as negative benefits so we see the whole picture for an investment before giving the Go-ahead.
Are there any plans to extend the standard business case calculation allowing to enter future running costs ?
Solved! Go to Solution.
- Labels:
-
business case
-
IRR
-
project financials
-
TCO
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-21-2023 02:42 AM
We have also seen a number of SPM customers who would like to consider future running costs when calculating the business case for a project, but want to keep these costs out of the cost plans since they will indeed mess up the financial follow-up of a project. The financial follow-up can be done via separate Operational Projects. Many SPM customers use these kind of operational projects for resource planning and cost tracking.
However, for the business case during the demand phase, it is vital to consider the operational costs since they have a major impact on NPV and ROI. These costs need to be separated from the cost plans since they are not part of the project budget. The demand manager / project manager does not want to see these costs in the Total Planned Cost fields.
Negative benefit plans can be used for this purpose, but this requires customizing and is not a very nice workaround. From my perspective, the best option would be adding an additional ootb table that can be used to plan operatinal costs (like benefits) for demands and projects. The operational costs should be considered in NPV and ROI calculations in the same way like benefits. This is a quite common use case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2023 08:58 AM
We added an "ongoing expense" Cost Type so we could see those post implementation costs over a 5-year period. While it rolls up into the total cost of the project, having the data in ServiceNow by year and cost type helps us plan our ongoing operating costs of any demands under consideration. It may require some more nuanced reporting, but having that data is a must to understand the full picture of projects under consideration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2023 09:33 AM - edited ‎10-30-2023 09:37 AM
Another option we have seen implemented is to launch a 3-5 year Operational Project that is associated to the Business Application or perhaps Product that was implemented, and represents those operational work and costs. Actually allows to to define resources as well as costs, track RIDAC. Make the Project execution to be Hybrid and you can associate Stories etc. Unfortunately, it does not work at the Demand stage and it is there that Brenda's solution has an advantage. Perhaps a combination of the two, in Demand add the future costs, upon completion of the Implementation Project, migrate future costs to the operational project.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-03-2023 05:04 AM
It really depends on how you want it to show up in which calculations and reports. We have a lot of different internal organizations that plan things differently, so we have a lot of options for them based on how they want to report it.
Some of our internal areas really care about total cost, NPV and ROI over the next 3 years, not just this year, so they include the future outflows as cost plans with a different cost type (as Brenda mentioned).
Some areas want to know about ongoing operational commitment but don't want it included in the project financials in any way. We added a table Operational Cost Plans so they can report on those, but since it's a totally separate table, it's not included in any built-in calculations on the financials tab.
Most areas also use Operational Projects (as mcastoe mentioned) to hold the ongoing expenses to keep the lights on after the period covered in their project financials. They're effectively placeholders for ongoing cost plans AND ongoing RESOURCE PLANS. (Some areas have tended to forget their people have less time to implement future projects because they have to support what's been added by past projects, so including the ongoing resource commitments has been eye-opening for those areas.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-21-2023 02:42 AM
We have also seen a number of SPM customers who would like to consider future running costs when calculating the business case for a project, but want to keep these costs out of the cost plans since they will indeed mess up the financial follow-up of a project. The financial follow-up can be done via separate Operational Projects. Many SPM customers use these kind of operational projects for resource planning and cost tracking.
However, for the business case during the demand phase, it is vital to consider the operational costs since they have a major impact on NPV and ROI. These costs need to be separated from the cost plans since they are not part of the project budget. The demand manager / project manager does not want to see these costs in the Total Planned Cost fields.
Negative benefit plans can be used for this purpose, but this requires customizing and is not a very nice workaround. From my perspective, the best option would be adding an additional ootb table that can be used to plan operatinal costs (like benefits) for demands and projects. The operational costs should be considered in NPV and ROI calculations in the same way like benefits. This is a quite common use case.