The Strategy of Divide & Conquer and its pitfalls

Have you used the strategy of “Divide and Conquer” in your PLM (product lifecycle management) project? I’m sure you have – it’s the commonly used “best practice” to solve a problem by “slicing the elephant”.  Or as the Romans would phrase it: to break another power into smaller, more manageable pieces, and then take control of those pieces one by one.

• It’s used in software implementation projects to slice processes into activities which are realized through features and functions which are again sliced into technical tasks
• It’s used in problem solving to get a grip of the challenge in front of you
• It’s used in change management and rollout strategies both in terms of scope and organization

Losing the Big Picture

Dividing the world into manageable chunks is powerful and has become a de-facto approach to take on challenging tasks. It’s a reasonable thought and it is a good strategy in many cases but it has its pitfalls. And looking at the other side of the coin: The “Divide and conquer” strategy is about keeping smaller powers and governments from uniting. This might have been a winning concept for Romans and the British Empire to conquer their enemies. But PLM and software implementation projects using this strategy require some mitigation actions to avoid falling into a trap of sub-optimization, lack of transparency and losing the sight of the actual goal. Because, even though you want to cut your elephant into digestible chunks, you still need to be able to see what you are eating. You become the victim of the strategy itself as its whole purpose is to separate, while both PLM initiatives and most software projects require a holistic approach throughout its implementation.

Conveying the Big Picture

If you don’t keep the bigger picture in mind while working on the details, you will deviate from the guiding vision and strategies, the architectural principles, the business goals and actual business needs, the overall processes, and the UX (user experiance) guidelines. Let’s look at the symptoms for each of the listed areas above:

• Vision and Strategies – Sub-optimized efforts which doesn’t contribute to the overall vision or strategy
• Architectural Principles – Platform, application, design decisions breaking the IT strategy will create silos, interconnectability issues, customized solutions, and a diverse spectrum of used technologies. This results in high TCO (total cost of ownership) and a situation where it becomes hard to support and maintain solutions (read: higher risk)
• Business Goals and Needs – Functions and features might be developed according to guidelines and conform with good architectural principles but that doesn’t make anyone happy if it doesn’t help in achieving business goals or addressing business needs
• Processes – If you don’t know how things are stitched together, the risk is pretty big that you will miss something along the way, resulting in a set of “disconnected” features
• UX – The perceived usability of an application will suffer if the look and behavior diverge across functions. This will result in more need for support, more user errors, more training and lower efficiency

The Right Decision at the Right Time

So one challenge we have identified with the strategy is that we need to find ways to convey the “big” picture, so that we can make the right decisions while working on the details, as we want the pieces to still work together to achieve the objective of the whole.

But, we need to find the right level of details describing this big picture. And the timing of setting these details (= make certain decisions) is also crucial. Finding this balance is important as we will lose important freedom too early in the process and thereby our agility.

I hope that it’s clear that it’s not a waterfall approach that I’m promoting. It’s just that I don’t believe that you can work effectively with enterprise software implementations, such as PLM systems,  if you don’t have some ground work done both in terms of processes/methods and involved technology. The output is as much an artifact to be used further down the lane as it should be used to anchor the stipulated way forward and keeping stakeholders involved.

Conclusion

The challenge lies in the way we slice the elephant, while maintaining the big picture and manage the balance between too much or too little of the ground work: taking the right decision at the right time. The next trick is to actually use that knowledge to communicate and anchor our way forward and give input to activities further down the lane. That is what will cater for success.

Do you agree? Have you found this balance and do you have an effective way of conveying guidelines, principles and decisions?

Robert Wallerblad

www.infuseit.com

PLM failures - how to address them?

In my previous blog, I talked about why PLM often fails to reach its potential. Now I will look at how to address this. Is it possible to re-vitalize PLM if it has been stagnant for years? It might. Just ask Henry Ford.

These were some of the typical situations I discussed:

• Our PLM is just PDM
• PLM is just for Design/Engineering
• Management is not interested in PLM
• We have had it (PLM) for years and very little happens
• Our PLM system is hard to change and hard to upgrade

The last one – cemented solutions and challenging upgrades – I’ll save as a topic for later.

Should you rethink your PLM strategy?

You should ask yourself that question. If you have a limited PLM solution it might still be right for you. Maybe CAD management is the most crucial area to your business? Is it sufficient to handle parts, BOM, documents and controlling changes (PDM)? Yes, PLM have bigger potential but it comes with extra complexity and cost – if there is no business justification for expanding the scope of PLM, don’t do it.

If you believe that your business would benefit from a renewed focus on PLM, however, there are some steps you could take. Which steps, how to take them and whether you need to take them all depend on the size of the company, the business culture and your own position.

You might be fortunate enough to possess the necessary power and money to change things yourself. More likely, you’ll have to maneuver through several levels of management and surrounding departments where some of them don´t even have a clue of what PLM is all about.

To help you get started, here are some steps you can take to get PLM on the management agenda:

Get inspired
To get new ideas and to get other people start thinking about possibilities with PLM you probably need inspiration and facts. In other words: education and awareness. There are several ways to do that. This inspiration should be spread both upwards to management and downwards to users. Just be careful not to create too high expectations. Failure to meet new expectations will be devastating.

What are other companies doing? Maybe there are new solutions and approaches today than when you started 5-10 years ago? Get inspiration from others. Talk to companies that have done interesting things with PLM. Not only in your own industry. There is a lot to learn about new ways of doing things from industries that at first glance seem completely different. There is a reason why apparel, food and beverage or service companies have started to embrace PLM. They have taken PLM from discreet manufacturing and put their own flavor in it, focusing on additional areas, processes and functionality, which again can be of interest for other industries. This will be a topic in a future blog.

One tip is to challenge your PLM vendor. They would probably be more than happy to arrange a PLM inspiration day where they talk about all the exiting possibilities and what fantastic solutions other customers have implemented. The effort from your vendor is typically for free as they see potential new license sales somewhere in the future. Visiting PLM conferences and seminars is also a good place to listen to other’s PLM stories and establish new contacts. Even better: convince your manager to attend the conference as well – it could be an eye opener. Resources on the internet, including blogs and focused LinkedIn groups, have also developed into quite viral arenas for knowledge sharing on PLM related matters.

What is your PLM vision?
What should PLM bring to your company? Why should you invest even more in PLM? Which parts of the enterprise strategy can PLM support or even be mandatory for? It could be global internal collaboration ("Design Anywhere - Build Anywhere" or "One Company»). It could be reduction of non-conformance costs (One version of the truth). It could be simplified IT landscape (Replace local isolated tools with integrated enterprise PLM). The key here is to understand what is important for management and see if and how PLM can support that. An alternative approach could be: Pick a part of PLM that you believe in and figure out which part of the enterprise strategy it supports ;-).

Establish a PLM strategy
If you start to get some traction with management and they start to see some potential in PLM, you are in a good position. Use that position to get acceptance for establishing (or re-establishing) a PLM strategy. How to achieve the PLM vision? Which steps to take? What are the short term and long term goals & objectives? What main functionality and processes should PLM cover? Which roles and business units should use PLM? What information should be handled? Which systems should be integrated or replaced?

Build a solid business case
Earlier it was enough to justify PLM by showing functional capabilities. To convince management you must speak their language. And the language they most certainly understand is money. Build a business case with justified costs, earnings, ROI and the plan for how to get there at minimum risk. This is also a good test of your PLM vision. Can you provide enough facts and considerations to build a proper case? Maybe it will show you that you should spend your money elsewhere where it gives a better ROI?

For the business case to be accepted you anyway must get management believe in PLM and take ownership. Show them that you know what you are talking about, how it supports the enterprise strategy and that you know how to get there. You will need management support not only to get started, but also to be successful in reaching the objectives.

Enterprise PLM architecture
If the business case is accepted, you can continue to enterprise IT architecture where you go more in detail than in the PLM strategy. You position PLM in the IT landscape, main information flows, processes and functional areas. Which IT systems to integrate, replace, change or leave as-is.

Finally
Now you can start thinking about implementation. Note that the above activities are quite independent of which PLM tool you have. And it might not be your existing PLM tool that is the problem. Replacing it with another PLM tool will not help unless you do some re-thinking.

Depending on your position and the complexity of your company, this whole process can take a couple of weeks and a level of documentation that you can do yourself or it can take months or even years and a big team. You might be able to skip some of the steps. What you definitely should have is a PLM vision as inspiration and guiding star. Or you might end up unsuccessful again.

Tore Brathaug
www.infuseit.com