Product Lifecycle Management (PLM) systems are software tools that are used by product manufacturing companies to support the entire lifecycle of ideation, business planning, requirements, design, manufacturing, launch, and eventual retirement of products.
They are interesting to me for two reasons: (1) they are relevant to the development of software products, and (2) they share some important characteristics with health care information technology. PLM systems, like electronic medical records (EMR), order entry, registries, care management and analytic systems used by Accountable Care Organizations (ACOs), are systems that are mission-critical to the company. They involve complex information. This complex information is created and maintained by business users with some technical capabilities. This complex information must be communicated in ways that support collaboration by many different people from different professional disciplines. They support processes that are constantly being changed and improved in ways that can create competitive advantage for the organization. They support design and analysis, rather than just execution.
So, what can we learn from product companies and the systems that they use that can be applied to Accountable Care Organizations?
I just read a report from the Aberdeen Group on the “CIO’s role in Product Lifecycle Management (PLM) System.”
http://www.ptc.com/WCMS/files/110940/en/Aberdeen_Report_PLM_CIO_english.PDF
The report starts by acknowledging the tendency for CIOs to view PLM system implementations initiated by product people to be “rogue” projects. The report explores whether such system implementations should be in the “realm” of IT, rather the product people.
This article seems to be written from the perspective of the CIO. It concludes that to be “best in class”, a company needs to:
- Have the PLM implementation project “under IT,” rather than have it under product area leaders who have “a day job,” asserting that, if the PLM system is supported by the product area, there will be a risk to “business continuity”.
- Have the PLM implementation project funded through the IT budget, including funding for some dedicated staff in the IT area, but justified based on a business case tied to a business initiative of the product area. In other words, the product people are responsible for helping argue the case to the C-suite for increasing the IT budget.
- Minimize customization to the PLM software, even if the product people argue that customization is required to maintain some aspect of the product lifecycle process that they consider to be a competitive advantage.
At the end of the article, the authors acknowledge that less than 50% of recent PLM implementations are taking this advice and formally assigning CIO responsibility for PLM system implementations. The companies that do so tend to be large companies that “focus on standardization.”
Of course, none of these turf issues matter if the people and departments involved are fundamentally collaborative and agile and if the right talents are represented in the collaborators. I theorize that the problem has, as its root cause, the culture of blame that sometimes develops in large organizations. In such organizations, IT leaders routinely experience blame when IT-related things inevitably go wrong, even in situations where the problem is largely out of the control of the IT leaders. After receiving routine beatings over a long period of time, IT leaders and IT department culture can take on a defensive posture. This defensiveness, in turn, does three things:
- It crowds out collaborativeness
- It fosters hiring and promotion processes that emphasizes management skills (“are you done yet?”) over design insight and creativity
- It encourages processes to be optimized for documentation and blame avoidance rather than agility
Then, after years of experiencing IT support that, in the opinion of product leaders, lacks design insight, creativity and agility, the product leaders insist on keeping the PLM systems under their own control. CIOs consider this to be “rogue” behavior that needs to be thwarted. As a result, a reinforcing loop (a vicious cycle) is created.
This general system of causes and effects seems to apply as well to other technologies that are used for mission-critical processes by non-IT people with some technical capabilities, including workflow automation, business process management (BPM), enterprise data warehouse (EDW), and electronic medical records (EMR). Specifically in the latter case, clinical leaders that are focused on using IT to transform their actual care processes sometimes tend to associate “EMR” with “big expensive project owned by IT people that don’t understand my clinic.” As a result, they prefer “registries,” which connotes “little project owned by the clinicians and focused on enabling the front-line process improvements we’re trying to make right now.”
The Aberdeen Group report attempts to address some practical issues regarding budgets and organizational roles. It does a nice job of linking survey data to recommendations. But, in my opinion, the solution to this problem — whether it be for PLM systems in product companies or care process management systems in ACOs — is not to decide who owns the turf. It is to address the root causes. IT and product/clinical leaders must work together in ways that avoid finger-pointing, builds trust, attracts and retains the best talent, and invites meaningful participation by all the team members with something to contribute and a stake in the outcome. And the information systems must be designed to enable such collaboration. Admittedly, easier said than done.