Product Value Management

In part one of this blog series, we discussed roles of PLM business process architects and PLM enterprise architects as custodians of the process definition, process modeling and analysis techniques and tools. Having creative architects that can design better processes and specify blueprint for transformation is a required but not sufficient condition for success. Navigating through organizational dynamics that intensifies with every transformation requires firm stewardship, self reinforcing motivation and relentless focus on ultimate objectives.

Let me start with an analogy.

At some point in time, many people have a need to remodel the house they live in. Various reasons come to mind: new additions to the family, school age transitions, health needs, parents moving in, … They canvass the needs from the family members, discuss extensively the needs (with few heated arguments) to eventually approach good architect who figures out the current house layout and comes with an improved layout that meets all sorts of objectives, with few compromises. Looks good? There starts the trouble.

Several bids and negotiations later and already at least one of the family members fails to cooperate. Lets’ say, a promised piano purchase got postponed, or worse yet - bathroom or kitchen fixtures got downgraded - and of course, many hidden requirements only surface when the concept is done.

Eventually, after several painful compromises, best bid is selected, budget secured and preparations need to start. Looks good? There starts the trouble squared…. I hope you get where this is going. Let me cut this story here because it may get very ugly, let’s be optimistic that it ends with a truce and just one year of relationships mending extending the budget by mere 30% on Miscellaneous Items.

Similar issues follow in PLM transformation, since organizational dynamics is based on human nature. So, what would be a meaningful approach to govern PLM transformation beyond the blueprint design? I intentionally say meaningful, because there is simply not best practice in this aspect. What works for one company may not at all work for another, due to multiple reasons all ultimately buried deep within the organization’s DNA.

It actually starts before the architects are called to help define the blueprint. Several roles get engaged in goal setting and qualification of high level business requirements. Let me introduce a role of product development analyst.

Product development analyst is responsible for:

- Gathering and analysis of product development metrics across multiple development programs;
- Definition of development program estimation techniques;
- Benchmarking and comparative study of performance differences between internal and competitive development programs;
- Establishment of relationship between metrics and practices;
- Improvement of estimation techniques based on correlations between various measurable program parameters (innovation index, variance, key indicators of change, etc.)
- Development of proposals for process changes and communication to the PLM business process architect about the changes required in the process management framework.

It is often series of reports by product development analyst that triggers discussion of the needs for change. Another usual trigger is the change in company’s strategy. One way or another, product development steering committee is the body that evaluates if changes in the current practices and processes are needed or not. Who are members of the steering committee? How often do they meet? What do they discuss? What decisions they make?

Product development steering committee (SC) is a body that comprises three to five core members. One of the core members is always the company’s most senior leader, CEO or president. Other usual member is most senior leader in charge of product development organization, and usually when the company’s development function is decentralized, that membership is offered to multiple equivalent representatives from various divisions. The extended committee usually involves other senior leaders, such as most senior financial manager, operation leader and sales and marketing leader. However, the extended committee is usually only called upon the need to make a significant decision and when the usual members decide it is needed to communicate the issues at hand.

Steering committee meets on a quarterly basis. Since many of the members are already deeply involved in the product development decisions either as members of product direction team, or through portfolio planning sessions, they are usually well versed in the programs statuses and product planning trade-offs. The purpose of the product development steering committee is to discuss if the product development process requires deeper attention or not. Occasionally, steering committee members may require analysts to dig deeper into specific issue that they are curious about, either externally or internally.

When the SC deems the need for investigation into the possibility for change, they are aware that it may be a start of a transformation initiative. At that moment, the SC selects the sponsor of the initiative to act on their behalf throughout the initiative representing the objectives of the SC. Sponsor can be anyone that the SC chooses, whether on the SC or not. The role of the sponsor is to be a proxy for the stakeholders objectives and to preside over all key decisions that the initiative may undergo. There may be several initiatives at different stages of progress and the sponsors can be same or more people. Thus, the SC usually juggles several initiatives at different stages of progress and can decide to cut them short or change their scope and objectives depending at what point of progress they are. Just like in any other portfolio management.

The sponsor creates initiative team. In the first phase - investigation, it only requires the analyst and PLM business process architect. These two propose to the sponsor who they believe should be the best champion from the organization to help them define the scope and objectives of the investigation. Here we depart from the typical situation, where IT gets involved prematurely. Also, IT is not represented even on the product development steering committee. IT is a means to an end, not the purpose of the transformation. Enterprise architect gets involved when the sponsor, analyst and business process architect recognize that investigation points to the need for change in how the organization utilizes information and other assets.

If investigation points out to the need for further detailed assessment, depending on the scope that has been already determined by the champion and business architect, the sponsor may decide to start next phase - root cause analysis and blueprint design. The purpose of the root cause analysis is to determine if the current process design can be changed and how to eliminate the problem that the steering committee has deemed significant enough to start an initiative. This is where the two roles defined in the part one come to play in earnest.

The sponsor will make sure that an appropriate champion is assigned to this phase as well, and it may be a different champion than in the previous phase. Additional people may get involved in either defining as is or designing should be process. Sponsor is empowered by the steering committee to ask for help from anyone he/she deems required to get to the bottom of the root cause and to come out with the blueprint for transformation. This phase may take longer, but it is the critical phase where through series of iterations architects try to come out with an improved design and a blueprint for its implementation.

To eliminate most risks while still in planning mode, the sponsor may lengthen this phase in order to do prototypes of the solutions, talk to external vendors, assess readiness and maturity, determine ROI of different blueprints… It is discretion and responsibility of the sponsor to make sure that everyone is on the same page if he/she is about to propose transformation execution phase. Sponsor may require return on investment to be evaluated, detailed roadmap for change established, etc. Acting just like a chief engineer in Toyota, the sponsor is in charge of the success of the initiative. It is very unlikely that the steering committee will reject a request from the sponsor to get company engaged in the transition execution. In return, the sponsor may require all checks and balances from the PLM process and enterprise architects and analysts before asking for the budget to be approved.

When the budget is approved, negotiated contracts are put in place and the execution can start. Whether the sponsor selected a completely outsourced, or internally managed execution it is less relevant. The sponsor is in charge of decisions and trade-offs. Usually, the transformation may take several steps and each step may have goals and objectives that are measured. The sponsor reports back to the SC on the progress and trade-offs.

Since the responsibility of the sponsors is very significant, what is the most important enabler for them? It is methodology. Sponsors need to be goal driven, not willing to come to compromise with reduced goals. They have to drive architects to be very creative to come out with good blueprint. They need to relentlessly pursue changes once the changes are clearly defined and assigned to the people. Above all, just like Toyota chief engineers, they need to front-load the initiative, keep multiple options open, work-off risks early, drive the decisions and push hard on the implementers to stick to their agreed upon integrating events and milestones.

Centralizing the driving force, taking it away from IT, and giving it to the accountable professionals, gives to the steering committee latitude to pick the most adequate sponsors from the internal staff. It also eliminates the communication and motivation burden from champions, architects and analysts. It is not uncommon that the sponsor is selected from one of the members of the SC. After all, it is their ship to navigate, their battles to pick, win or loose.

This governance approach grooms champions into future sponsors, promotes organizational learning and reuse of process knowledge through captured business process and enterprise architecture. It also leaves IT to become experts in enterprise architecture and not to dwell on the business direction. Their input into blueprint design can literally point the company to the right direction.

Today, much discussion ensues about the tools and techniques for process modeling, analysis, execution and other “cool BPM stuff”. Significant time is spent debating applicability of different tools to development process modeling and analysis, process execution and monitoring. Albeit an important issue, that should not be the main focus in PLM transformation. As we have seen in this part, the issue is much broader and it is the methodology that the sponsors need to rely on. Having a sound methodology and organizational alignment around objectives is by far more important factor of success. In the next - last part, we will discuss the methods and tools that can be put together into a meaningful transformation framework.