Many will agree that defining the PLM business case can be a daunting exercise due to complex (and sometimes conflicting) business requirements, implementation and transition challenges, legacy IT inertia, resistance to change, ongoing business imperatives and ROI justification challenges. So keep calm and read this…
Business Benefits
PRINCE2© and MSP© define business benefits in general terms as “the measurable improvement resulting from an outcome that is perceived as an advantage by one or more stakeholders”. Project and Program Management methodologies provide frameworks to ensure that business benefits are identified, defined, tracked and realised throughout the lifecycle of the business change and IT implementation initiatives.
Smaller initiatives are typically structured in short term single projects from which benefits are directly defined. Larger initiatives are usually structured in a portfolio of projects or medium/long term programs which are characterised by dynamic dependencies and complex interdisciplinary scope; they also carry higher risks associated with major changes. They typically have multiple sponsors and their benefits are harder to pin down due to series of parameters, such as:
- Complexity of the business case.
- Medium to long term strategic objectives.
- Business-as-usual and short term improvement priorities versus long term strategic objectives.
- People factors (engagement levels, contradicting perspectives and sometimes interests, cultural readiness, resistance to change, ability to train and learn, etc.).
Every project must have a business case to justify why the project is needed, what will be the deliverables, what the costs and benefits will be, and who will benefit from it, who the key stakeholders are, etc. The business case is reviewed throughout its life cycle to make sure that the project is still worth going, and is re-approved by the key stakeholders at each project gateway.
On large or complex or large strategic projects, the purpose of the business case is also to establish the mechanisms to judge whether the project is (and remains) desirable, viable and achievable as a means to support decision-making in its (continued) investment.
Defining the PLM Business Case
PLM initiatives typically involve engaging with a large number of stakeholders across the enterprise, from Product Development, Manufacturing Engineering and Service, Sales and Marketing, to IT organisations, internally and externally. They address significant interrelated business requirements and aim to provide integrated and scalable IT-enabled business improvements with ‘enabling’ technical solutions (tools and technologies). They need to align with long term strategies as they relate to the end-to-end backbone Product Creation and core Product / Process Management functions.
The PLM business case requires an agreed definition of the PLM scope ‘boundaries’ across various departments and functions, such as Engineering and Design, Product Programs, Manufacturing and Service, ERP, CRM, BI, etc. These boundaries are important as they inform where data is mastered and which systems drive certain aspect of the manufacturing and related supportive processes.
- Organisations are made of people, knowledge and skills.
- People define and use processes.
- Business processes require data to be mastered and shared between systems.
- Data is used across several processes and managed by various applications systems, databases and tools.
- Applications, systems and tools enable data segregation, control, access, management, integration and integrity.
Typical considerations relevant to defining the PLM business case include:
- Consistently and accurately mapping business capabilities and business processes across the organisation, using a framework that allows distinguishing between what is in and out of scope of the PLM initiative.
- Identifying and reaching to the business owners, data leads and their business champions (this is even more challenging in organisations where there are numerous process duplications, repetitions and overlaps, as there could be multiple business owners for similar processes across different functional department)
- Identifying common data related work streams which will later require integration, alignment or simplification; it is possible that the business structure will require changing when enabled by new PLM capabilities – implying that the business owners might change throughout the lifecycle of the PLM program.
- Defining, negotiating and agreeing with business champions a middle ground between ‘green field’ and ‘brown field’ solutions to support a credible deployment plan.
- Defining how to rollout out change (whether to implement in multiple large or small successive steps, across what timescale) and assessing the complexity of the transition rather than focusing solely on the end-state.
- Identifying the required integration levels and needed interfaces and considering future data migration requirements to enable transition from a current AS IS state to an expected TO BE state; this might include temporary interfaces to support a multistep deployment approach – while deployment approach and detailed steps are likely not be known at the time of the business case definition.
- Considering PLM and ERP integration is critical as external dependencies might require more time and effort to implement across the enterprise.
- Considering the people change elements, required organisational changes, and costing for training, business change projects to rearrange the departments in more effective teams.
- Considering the governance process to gather high level business requirements, engage with internal customers in detailed design of the PLM solution, identify and review between conflicting requirements, up to signing off the solution and implementing the change.
The inherent risks associated with any long term business benefit driven projects include the capability of the organisation to maintain a valid business case with a benefit realisation forecast that remains above the initial baseline. The more rework is required or if the program delivery slips, the more the business case gets eroded and the longer the payback period.
Tracking Business Benefits
Defining business benefits is an iterative and ongoing / continuous process – typically topdown driven first. Benefits are linked to high level business requirements which respond to business objectives to enable new capabilities and capacity or improve existing capabilities by eliminating “pain points” and reducing waste (non value-added or ‘administrative’ activities). The business case justification and business benefit baseline is drafted during the project preparation (or “startup”) phase, and then formally agreed with all stakeholders when the project is officially initiated.
Various project activities happen in parallel and benefits must be tracked throughout the lifecycle of the project. Benefit tracking needs to continue post deployment of a project as they might not be fully realised until all users are trained and transitioned to the new solution. PLM projects are no exception. Furthermore, as IT-enabled initiatives, new software introduction might imply increased cost of ownership in replacing amortised IT legacy solutions with more expensive technologies. Many argue that, when there is no alternative to changing a broken or unsupported IT solution, the change is imposed as a risk mitigation requirement. Therefore, PLM strategists and planners should consider the actual option (in the sense of “choice”) that a business may gain by undertaking a PLM project – perhaps in the form or a business transformation and/or tool replacement initiative..
What are your thoughts?
This post was originally published on LinkedIn on 27 January 2015.
About the Author
