Creating new SPM budget types

[KhoendibG]

Hi all, 

Does anyone have experience with customising and introducing new budget types to the project_funding table?

We have received a new financial requirement to add two new types of OPEX Budget to the project_funding table. 

• BAU Opex - ongoing post-project costs (licenses, application maintenance, etc.) 
• SaaS Opex - New category of Opex to be spent during the project. 

Our finance team is having a hard time distinguishing between the different budgets allocated to a project from the fields we currently have available in SPM. So, I have been asked to created this distinction between the different types of Opex Budget a project can be allocated (note: A project can have SaaS and BAU Opex). 

Adding the fields and manipulating the existing UI Actions is straightforward, but I am concerned 

about the wider implications of modifying budget types, particularly regarding Strategic Planning, Portfolio Planning, and any downstream reporting or allocations that may assume only CAPEX/OPEX. Or are there any future upgrade issues I should be thinking about? 

If anyone has gone through a similar customisation, could you share any recommendations or pitfalls to watch out for when extending the available budget types on the Project Funding table?

Thanks in advance!

[Mark Manders]

A lot of logic is handled on that specific 'capex/opex' distinction. Adding the new options will exclude that logic on the new options. Rollups can go wrong, future updates will have to be checked every single time.

Wouldn't it be more useful to just update the record by adding a new option (if OPEX, select SaaS/BAU)? That way reporting can be done by dot walking to that distinction, without completely customizing everything behind it.

[phil_bool_unifi]

Hi @KhoendibG.  In short, I think you're absolutely right to be hesitant about this kind of customisation, but it might help to be a little clearer about what is and isn't possible. 

Adding extra options to the Cost Type list that work the same way as existing options (by that I mean, different types of OPEX cost) is absolutely possible.  This seems to be what you're describing.  Adding options that behave differently (such as a Cost type that could be either CAPEX or OPEX) is unlikely to be successful.  

If your plan is to change the relationship between costs and projects (such as the ability to track operating costs beyond the project completion date) then this is unlikely to be successful, and may cause impacts further down the road.  If that is your intention, you may want to consider looking at contract records to track that cost instead, or extend your project end dates so the cost can be tracked within the project lifecycle.

It definitely sounds like you're thinking about this the right way, and are asking questions in the right places.  I once had a customer that was adamant that alongside CAPEX and OPEX costs there should be other types of cost (eg Transformation).  That was a disaster.  I don't feel like you've fallen into a trap like that yet.

[KhoendibG]

Hi @phil_bool_unifi , @Mark Manders 

Thank you for confirming my thinking! 

At the moment, we will definitely add a choice field to identify if the Opex on a project is SaaS or BAU. 

Can I ask you both, what are your thoughts on adding two sub-categories of opex that will roll up into the Opex Budget field (i.e total opex = SaaS Opex + BAU Opex). 

Would this approach impact the defulat system logic at all? 

Thanks 

Kay 

[Mark Manders]

I think that field is normally not calculated in that way (maybe through child projects/tasks) but as long as you add it and don't overwrite it, you're good (it depends a bit on how you are using it), although I expect no issues, because you are just adding an OPEX to it, just with a custom field for reporting purposes).