PLM – Do The Right Thing?

PLM – Do The Right Thing?

I read two blog articles written by Mark Suster in his blog Both Sides of the TableThe Benefits Of Top Down Thinking and Doing the Right Things is More Important than Doing Things Right. Mark is entrepreneur, investor and general partner in GRP Partners.  Mark is not writing about Product Lifecycle Management, of course. His name came on my radar after his company Koral was acquired by Salesforce.com.

There are two concepts that caught my attention. One is about top down vs. bottom up thinking. I found this association very interesting in the context of thinking about different engineering problems. I had a chance to participate in many discussions about various ways to implement PLM and ways engineers and designers are using our system. Lots of these discussions are comparisons of top-down vs. bottom-up approaches.

I specially liked the following fragment:

The wisest mentor I ever had was Ameet Shah, my partner on several projects.  He taught me much that I know about critical thinking.  He coached me that I had to start with the answers.  WTF?  How can I START with the answers?  How can that be effective?  ”Well, we know the basic structure of the problem we’re trying to solve and we have hypotheses about what some of the answers will be based on our experience.  You need to put this all down into a structured diagram from the first week with the answers that tie to the logic of the problem we’re trying to solve.”  — Heresy. —  But he had more insight, “once we know the structure of the problem and our solution we can plan the data that proves or disproves our theories.  The key is not to be wedded to our original answer.  But by problem solving in a ‘top down’ manner we can be much more focused about what data we collect.  We can also begin to socialize our answers with people in the company to get their reactions.  That alone will help us solve the problems.”

It made me think about the following: how many of PLM projects started with the vague vision of results, such as “to organize documents” or “to decrease cost of product development” or “to streamline processes”. On the surface, they look like very valid goals. However, in most of the cases, PLM implementations are lack of definitions about how results will look like. So, starting from the “answers” seems to me a very appropriated approach in implementing PLM.

Now, let me move to the next topic. Do the right thing. It made me think how many things we are discussing how to implement PLM in the right way. How important is planning, project management, executive commitment, methodology, roadmap, resource planning? Don’t take me wrong, all these things are really key topics. However, many times, I hit myself thinking about products. This is what we are doing for the last 15 years. Maybe we need to think about it again and see if some fundamental shifts happened in the industry, technologies, product development.

My favorite quote from this post is about product features:

Similar with product features.  One of the most important movements in software design in the past few years has been a return to simplicity – a move away from the Microsoft era of every release adding a new 150 unused features.  One of my favorite sayings in this area comes from a portfolio company, RingRevenue, who like to say “ease of use = use and use = revenue.” I love that saying.  If you don’t know WHY you’re adding features don’t do it just because you have a development team.  Better that they work on new initiatives, performance improvements, operational features to help internal management or anything other than just cranking out features for the sake of it.

I found it very compelling to what I observe in software products for engineering and manufacturing. Bloody competition on features became a very typical norm. I can bring an endless list of the examples. If you will track product release announcements you can easy track and compare features, functions, marketing messages, etc. I had a chance to discuss the topic of complexity many times before. I think, we are going straight to the point when focusing on how to decrease the number of features and make things work simpler.

So, what is the conclusion? In my view, we are thinking about PLM in a bottom-up way. We are starting with terminology, lots of engineering details, opinions, thoughts, facts. If you have two engineers in the room, you may have three different opinions about how to make things happen. However, when it comes to PLM implementation, most of the vendors are making it in a very top-down way. PLM platforms, interoperability difficulties, long implementations, the absence of granularity. My feeling, this is a potential place for our problems. Maybe we need to start thinking top down and focus on what is important to achieve? However, when it comes to the implementation and products, let’s make it bottom up. It will allow us to have a solid foundation for everything we are doing. Just my thoughts…

Best, Oleg

Share

Share This Post

  • Sudarshan Shubakar

    Hi Oleg,
    Some very interesting points here. Some thoughts that come to my mind as I read this are, who/what are we building a PLM application/solution for? Thinking bottom up is likely to get one closer to achieving that end.
    I get a feeling very often that the PLM solution itself is considered as the end (resulting in Feature buildup), rather than as a means to achieve the end (solving End user issues, performance, etc.).
    Regards,
    Sudarshan.

  • Barath_s

    One meme I have encountered is “the voice of business” as distinct from the “voice of the user”
    i.e corporate targets for PLM are different from a business user’s goals. This goes back to “who are we building PLM for” ? On a short term basis, PLM tasks could take 10 minutes longer (as it is unfriendly) but the mandate is to still use it, and doing so, reap business benefits.
    I have never loved this (anti) meme, and therefore love the RingRevenue quote ease of use = use and use = revenue. In the long run, the voice of business and voice of user must be aligned. There’s more to be gained from working together.

  • beyondplm

    Sudarshan, thanks for your comment! I like you point about what PLM application/solution for? In my view, today we are building it in order “to manage a product lifecycle”. This is probably wrong… The right one, can be “to help people to accomplish their daily job”. Now, job is different, for some people is to find the right version of part, for somebody else is to figure out why ECO stacks in the approval process and for top managers is about how to decrease a product cost… However, taking it bottom up based on a granular set of tasks can help to improve software we have today. Best, Oleg

  • beyondplm

    Barath, The statement “In the long run, the voice of business and voice of user must be aligned” reflects the desired result. However, in reality, I’ve seen a lot of conflicts between these two voices. Usability, complexity, complicated upgrades- all these things prevented many enterprise systems to be adopted by users. On the other side, business needs to manage processes in an organization drove future software implementation despite voices of customer. Does it make sense? Have you experienced similar type of problems? Best, Oleg

  • Vladislav Skoupski

    Maybe I’m wrong but I think that ‘top-down style implementation of PLM’ is the only way to success. And most of attributable implementators do it such way.

  • beyondplm

    Vladislav, Thank you for this comment! I’d like to differentiate between planning and implementation. From the planning standpoint, top down approach is appropriated. So, if a company has PLM strategy, the plan needs to be done in a top-down way. Organizational business processes, resources, goals, etc. However, when it comes to the implementation, I see significant difficulties in implementing things in a top down way. It happens with many PLM implementations. It starts from trying to apply standards templates, schemes and business process. It takes a lot of time to have a customer to agree on the way they need to manage data. As opposite, having an ability to implement application that serves particular needs of customer (think about Excel based application) can be much more efficient. This is a very granular approach in building applications. What is your opinion on that? Best, Oleg

  • Vladislav Skoupski

    Heh you’re right 🙂 But implementator must have will to did implementation like he planned 🙂
    In other hand: maybe there’s a problem with plan?