Budgeting PLM Implementations: How to Get Business Transformation Projects Started

Budgeting in general, and budgeting for PLM implementations, is closer to science as there is no black magic despite the fuzziness of certain PLM roadmaps out there. It is a necessary assumption-driven exercise to understand what organizations are committing to, before approving and releasing the required budgets and resourcing. The budgeting process typically consists of business justification, including selecting technical solutions and vendors, choosing the relevant delivery model and assessing various dependencies based on both organizations’ cultural and technical readiness. It may follow early use cases and scope definitions, wider extension assessment of future roadmap phases to confirm viability, aligning strategies across enterprise platform interfaces and capabilities, selecting a trusted implementation partner, defining future maintenance and support models, etc. Based on the complexity and the business model, budgets typically include multiple elements, such as:

• A capital budget as part of long-term strategic investments
• An initial implementation budget
• An ongoing operations and support budget
• A budget for essential non-value-added related elements or related contingencies

In this article, I discuss how to budget for PLM and associated business transformation projects, including their subsequent maintenance requirements. I consider different implementation approaches, project types, CAPEX and OPEX considerations, and how cloud-based solutions are possibly changing the budgeting requirements.

Organizations deal with both projects and operations all the time. Budgeting projects differs from budgeting ongoing and recurring operations. Both have to secure many kinds of resources. Both need to be planned, delivered and controlled. Both must be sized using a given strategy and approach. Projects are performance and effectiveness-driven, whereas operations are efficiency-driven. PLM and business transformation projects are no exception. They require sizing, approving, monitoring and adjusting from steering committee members based on a given anticipated business case, performance and outcome expectations, ongoing growth and business change requirements.

PRINCE2 defines a project as “a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case”. Beyond the definition, PLM projects vary from one to another in several aspects, including scope, size and scale, expected business value and waste reduction, technology change and complexity, business change.

Implementing and managing PLM solutions (not just the IT platform, but everything else that comes with associated and subsequent “PLM operations” across processes, people and skills, data quality, etc.) can imply different types of projects and associated operations, hence different types of budgets. For example:

• New or major PLM implementation projects typically require value proposition budgeting or zero-based budgeting. One must consider value-added benefits with zero-based budgets, starting from scratch with new justification based on business imperatives, dependencies, anticipated discoveries and scope prioritization.This might include how to transition from “as is” to “to be” solution, hence how new operations could affect the exiting ways of working and associated budgets (and the transition from “as is” to “to be” budget).
• Upgrades or improvement PLM projects might be handled as part of incremental or activity-based budgeting. One must consider incremental budgets for minor upgrades, or as part of a managed services framework for maintenance and support as well as when it is possible to relate to work (and budget) previously executed. Also, one must think about activity-based budgets for bespoke changes, based on input and output, with associated activities required to the delivery of the expected outcome.

The above can vary based on project complexity, urgency, company culture, and many other factors, such as who owns the budget as well as how it spreads across multiple functions, across the business and IT, etc. This post is not an exhaustive review of all traditional and modern budgeting methods.

However, it is interesting to note that the budgeting approach might drive different assumptions, behaviors, implications, expectations and needs based on associated delivery and commercial models (fixed price outsourcing, on-demand sourcing, time and material implementation, etc.). As PLM solutions combine multiple dimensions across people, data, processes and IT platforms/tools, it is important to associate the relevant budget elements across the associated elements.

PLM implementations typically require focused delivery efforts based on a combination of minimum viable products (MVPs) to optimize learning and value realization for most stakeholders. This is while phasing deployment based on risk mitigation measures (across people, data, integration, etc.). This often assumes an initial implementation budget for the relevant MVP(s) with associated maintenance and subsequent budgets for future enhancements, extensions, upgrades, etc.

Each MVP (yes, there could be more than one when each solution elements have different deployment constraints) is driven by early value realization from a given scope, target function, through a given timeframe, or a combination of all of the above.

Also, budgeting for PLM investments includes considering current and future budget reallocation opportunities, as benefits get realized in one or the other business area, as operations become more productive and effective. PLM projects are multi-disciplinary andbudgeting for PLM projects are multi-faceted. It covers the following array of elements and disciplines:

• Platform product license budget: configured role-based or project-based licenses, aligned to a given licensing model (perpetual, rental/leasing, platform as a service, infrastructure as a service, combined and other models). It  includes hybrid scenarios when transitioning from legacy systems.
• Infrastructure budget: whether on-premises or cloud-hosted, fully managed or only partially, it is important to understand the sizing model and how the cost is likely to evolve in the future when scaling up or down capacity and capability. This includes possible re-mix once the business gets a better understanding of the solution. It is also important to compare short- vs long-term costs and balance with the need for flexibility.
• Implementation budget: from initial sunk cost to get the platform running to onboarding implementation suppliers, investing into specific implementation skills, getting the initial capabilities set up, tested, validated, rolled out, etc.
• Data migration, archiving and enterprise integration budget: transition and integration activities are often directly linked to implementation budget, though they also relate to legacy data quality, migration and archiving strategies, which might require specific budgets when handled as part of project or operations.
• Vendor management budget: engaging solution editors and other service providers requires strong leadership and a robust handle on deliverables and performance management. This comes with a necessary budget requirement, above and beyond the actual implementation budget.
• Maintenance and future upgrade budget: considering the total cost of ownership, current and future maintenance activities, from user on/off-boarding, administration, system and license monitoring, continuous improvement and other user support activities—part of application and infrastructure operational managed services.
• Training budget: from training the trainer to training the end-users, considering all knowledge management activities often requires a dedicated budget item, continuing beyond PLM implementations into maintenance and support or talent management budgets.
• Business engagement and change management budget: considering the amount of business model design changes, from initial readiness to organizational change management requires a dedicated budget, whether or not such budget is part of ongoing operations or the implementation budget itself.

Organizations with ambitious transformational change expectations should not underestimate how much end-users and business leaders will need to engage in the PLM implementation journey. This requires the relevant budget assumptions to assign, substitute, or augment the relevant business resources, covering existing and possibly new functional SMEs.

Unless an organization is a fairly young start-up, any mature OEM or engineering company is likely to have legacy PLM processes and platform(s). Modern enterprise operating models and associated SaaS licensing models might affect capitalization and hence impact how organizations manage product budget elements, either as CAPEX or OPEX:

• Capital expenditure (CAPEX) covers long-term investments to be amortized over time, over-current and future usage, typically across several financial years. Purchasing enterprise software was used to (and somehow still can) be a long-term investment with associated annual maintenance fees, which might not be deducted from income taxes in certain cases.
• Operating expenditure (OPEX) covers day-to-day operations and typically R&D activities, often with deductible taxation in the same financial year that they occur. While enterprise software license renting is also common with on-premises infrastructure, cloud-hosted solutions promote this model through a further transition of traditional infrastructure sunk costs to OPEX budgets.

Clearly, organizations might favor short-term cost savings over long-term ROI or cost efficiency, especially with the promise from SaaS and cloud-based offering to inclusively include combined application and infrastructure maintenance with up to ongoing platform upgrades. As Jay Gorajia, director of Global Lifecycle Management Services at Siemens Digital Industries Software put it, “OPEX through subscriptions removes the CAPEX lumpiness. The subscription is fixed, over time, and can be budgeted, and the cashflow more reliably managed.” Obviously, this does not mean that subscriptions are cheaper in the long-term, but they are hassle-free and offer more scalability and flexibility, also reducing barrier entries to PLM.

Most PLM platform vendors provide pre-configured industry templates to help OEMs embark on this strategy definition, budgeting and subsequent value realization implementations. Most existing frameworks focus on value definition and early justification processes to position software product offering. However, OEMs must first ask:

• What pre-configured industry-driven templates can be used?
• How prescriptive are these templates? How can the different building blocks be interconnected?
• What and how will they be adapted, i.e., tailored through configuration and customization?
• What are the existing industry and domain good practices?
• What accelerators can be deployed?
• What value is expected to be realized? How can it mitigate any risks of value erosion?

To help OEMs answer these questions, Dassault Systèmes have their Value Engagement Model and PTC has its Value Roadmap framework. Similarly, Siemens promotes the ability to accelerate the deployment of Teamcenter through either cloud start packages or on-premises pre-engineered offers with several industry/domain-specific playbooks. While there are a lot of investments from vendors on value assessment, assessing cost (and therefore budgets) is equally relevant when assessing possible ROI from PLM implementations.

What are your thoughts?

• CGMA (2013): Activity-Based Budgeting (ABB)
• Corporate Financial Institute: What is Incremental Budgeting?
• Investopedia (2021): Zero-Based Budgeting (author: Julia Kagan)
• PRINCE2 Wiki: What’s a Project? (and What’s a Business Case)