Welcome to this week's TBT blog, originally published in 2012,
and continuing our Super Friends theme.
I apologize for the long hiatus of the Super Friends blogs. Between the SolidWorks World conference and a wayward web developer who messed up all our historical links my blogging has been disrupted. I am now settling in back at the office and will complete the Super Friends blog series with this article and one next week. When I first started this series, I drew parallels between the original Super Friends and their Product Lifecycle Management (PLM) team counterparts in my article titled "The PLM State: Super Friends Powers Activate: Building an Effective PLM Team". I really envisioned Application Man much like Superman as an all-powerful super capable resource and super hero. But upon reflection, I wonder if this is an accurate depiction. Often in PLM implementations, it is Application Man who gets the project off track and mired in the weeds. Obviously, it is critical to have someone on the team who is well versed in the functional aspects of the application. A resource who understands PLM use cases and product development and who can quickly configure the software for these use cases is absolutely essential. But, beware the power of Application Man. He can complicate your implementation significantly and extend time to value. This article will discuss the merits of Application Man and how to maximize his value and minimize the potential downside that can result from his abilities.
One of the nice things about Superman is that he can do anything. If there is any trouble in the world he can fly off and take care of it. He can stop wars, reverse natural disasters, and he can even turn back time. Having all this power and capability means that others can 
develop an unhealthy dependence on him. When he is not around, people no longer have the skill to help themselves. This can be true with Application Man as well. If he runs through a project unchecked, he can create all sorts of capabilities and customized solutions that only he knows about. These snippets of code can be very useful, and in certain situations, are essential for a successful PLM implementation. However, these super human efforts can merely create a reliance on Application Man and make it very difficult to do any type of system change or upgrade without his direct involvement. The general rule is that the more you depart from the basic functionality of PLM, the more challenging it becomes. We have seen numerous examples where talented individuals have created custom PLM vehicles that only they can drive. This is great for job security but bad for business.
The questions become, “How can you harness the power and capability of Application Man for good? How do you channel the ability to fully customize a user interface and to automate process via process extension or script?” The key is to make sure that your PLM team is functioning as a unit. When you combine the capabilities of Application Man with Process Man, then the functionality is created within a specific context to address a business need. If IT Man also participates he can ensure that configuration is created in a fairly standard way and fully documented. There are talented individuals that can reverse engineer database schemas and read and write information directly from tables. While this is impressive and sometimes useful, it is not a sustainable methodology for supporting applications that will be used on a regular basis. Typically, one upgrade or patch will break this type of software leaving a company in a severe lurch. By following best practices and planning out any customized functionality, companies can avoid the pitfalls of hyper customization. Thinking things through beyond the near term is needed and sometimes clients need to hold their partners accountable in this area. Most consulting organizations are staffed with highly capable resources that know the most expedient ways to create functionality. Sometimes the schedule and pricing demands from their clients can force them to make short term solutions. Other times, it is the consultant himself who fails to fully consider the implications of his methodology. Therefore, it is critical to make sure that your PLM deployment team is fully staffed with the needed roles to ensure a functional and sustainable deployment.
It is nice to have power and knowledge, and most companies benefit from working with the best and brightest. However, unrestrained intellect and capability can be a recipe for disaster when it comes to PLM, or for that matter, any enterprise software deployment. Understanding the full context of your business process improvement initiatives and the cost associated with 
enhancing PLM or over-configuring it is a crucial element to coming out on top. Make sure your version of Application Man is not a lone wolf in your deployment and that he is working cooperatively with process and IT focused resources as you develop the best approach to satisfy business requirements. Companies that have been through enterprise software deployments previously understand this because they have experienced the consequences. Current calls for simplifying PLM are just reactions to this issue. The problem is that simplification can leave you without the capabilities needed for success and the compromise might speed up deployment but end up costing significantly in lost productivity. Balancing capability with context and sustainability gives a company the best results. Application Man, much like Superman, needs his friends to succeed. And that, my friends, is why the show was called Super Friends instead of only Superman.
[Edit: repost from 2012]
