In this blog series, I provide insights as to why PLM has true potential to be so transformational for life sciences companies, but many aren’t getting there. We have come such a long way with our journey. If you haven’t had a chance to read the previous entries, you have some catching up to do.
We have moved into the part of our story where we are executing on the strategy and doing actual implementation projects. Maybe we are on our first phase where we likely will establish a Device Master Record (DMR), a strong change control process, and we’ll bring control and automation to the bill of materials (BOM) and documents. In this entry I pay homage to the importance of what makes a good PLM team.
Everyone knows that having a highly functional team is paramount to success. But what does that really mean, especially in the context of PLM? Any team must have at least these ten traits to be successful.
- Trust: The team must trust each other and be comfortable being vulnerable with each other. They should be comfortable explaining where they have blind spots and areas for improvement. Without trust, the team is not a team; it’s a collection of individuals doing work and probably hating life. Trust will build over time when people act with integrity, especially in more difficult situations (all PLM journeys will likely present many of those).
- Fun: One of the most successful PLM Program managers and architects I have ever had the privilege of working with is Jon Nelson, a PLM veteran of 15+ years. Years ago, I asked Jon the secret to his leadership success. His reply was simple, “If your team is having fun together, they’re setup for success.” This sounds easy, but it doesn’t come for free. It takes discipline and planning to ensure that fun things happen, especially during the course of a demanding PLM program.
- Decision Empowerment: I can’t tell you how many times I see PLM programs suffer slow deaths because the team is not empowered to make decisions. I believe that PLM programs are especially sensitive to this. The team must be carefully selected so they can represent the organization and understand the impact of their decisions, especially if existing processes are being redesigned. I had the privilege to be a part of a PLM program very recently where the decision authority was given to a very small handful of extremely skilled individuals, which helped the program move at lightning speed. The first real test came on the day of the conference room pilot; a time when the broader enterprise would get a peek at what had been designed. The team had done their job admirably, and it was clear that the appointed team had the right skills both politically and technically to make good decisions for the organization (these items are covered in subsequent points in more detail). I have also seen just the opposite, where perfectly great PLM programs were killed by committees.
- Access to the Right Tools: The team must be armed with the right tools. Programs suffer tremendously if this is skipped, and sadly, it often is. Give the team the time to set those tools up in a way that helps them be most productive. For example, a developer might decide they want an integrated development environment (that’s their programming environment) and they want this directly linked into the PLM platform. This way when they tailor the system they can quickly test if their changes are effective. Without this link, the process can be really slow and burn through a lot of time and money. Not all developers work this way, but those that want to should be allowed to. It might take a day or two to set this up, but it can save masses of time and frustration later on. Project managers should not deny these kinds of requests due to time pressures, and project leadership should constantly ask and re-ask the team if they have what they need to do their job. So often, people feel their requests are ignored and they hobble along unnecessarily. If leadership isn’t listening to the troops, then you have a problem.
- The Right Mix of Skills: PLM programs are not just technology projects, especially if the program is going to be transformational. We must not only have good technical experts (many PLM platforms can take years to learn well), but we must have individuals that can lead process redesign, those that know how to drive organizational change, those that can articulate business benefits, and those that can lead a team. This takes a variety of backgrounds and experiences and it’s truly hard at times to find the right blend, especially when time is short. The most successful programs I have lead or been a part of have at minimum: a program manager, a program architect, a business process analyst team (one BPA for each major workstream), an organizational change team, and of course engineering and testing staff.
- Leading Practices from Deep PLM Knowledge and Experience: Team members in any role must be armed with PLM leading practice-knowledge. PLM is really hard. When team members don’t know what works best in what circumstance, or don’t have real-life experiences to pull from, it gets really tricky. PLM is flexible, so one common mistake occurs when people make up answers and then tailor the solution to fit those answers. It’s easy to do this if you have good technical talent. But it’s hard to know if those made-up answers are going to ultimately box you into a corner or lead you to a place that isn’t right. I have seen many examples of companies that spent a lot on a PLM implementation, but their programs are led by individuals that lack real insights into the platform. This inevitably leads to lack of adoption, inability to maintain the solution over time, and underwhelming results at a business level.
- Discipline and Experience in PLM Solution Methodology: With PLM implementations, it’s very important to follow a proven methodology. Technical proficiency in the solution is not enough. Those that want to work really hard at playing and hacking will ultimately fail to deliver. An established implementation methodology (even ones that enable an agile methodology) helps avoid common post-launch issues like frequent bugs, poor documentation and uncoordinated roll out. Team members must first understand the PLM implementation methodology being used (some experience helps, as does a well-defined and documented methodology containing templates and examples). Next, they must respect it enough to follow it and take the time to do the stuff that might not seem natural to them (developers often hate to write documents). If team members are committed to quality outcomes, they will respect the methodology and use it, and the program architect and manager will enforce it.
- Involvement and Accountability: The entire team must be involved in planning (my colleagues and I refer to this as integrated planning). The plan cannot be built by the program leadership in a conference room away from everyone else. During execution, team members must be held accountable for earned value on a daily or weekly basis. When people fall short of their commitments, we need to understand why and help them overcome and possibly reset. We also need tools that help the team manage project execution, calculate dependencies, and critical path.
- Sense of Purpose: It’s very important that each member understand the magnitude of what we are trying to accomplish and know they are part of something big and exciting. Each team member must feel it on an individual level, communicate it constantly to stakeholders and be motivated by the notion that we are doing something special. If your goal is to really leverage PLM to the max, and if you want to go big and get to the true opportunity by integrating the 50 to 100 to 150 processes that comprise the product lifecycle, it should be easier to attain a sense of purpose. The team is doing something special, something really transformational. If they don’t understand this, take time out to educate them on why this program is special, how it will transform your business and drive their careers to new heights.
- Belief: The best team in the world can only be as effective as their belief in the program governance model and trust in the commitment of the executive committee and sponsors. If the team lacks trust in the governance model, motivation will surely wane and if they sense the executive sponsors are less committed than they are, this will become a problem. See my last entry for more about program and project governance.
In the next entry we will think about deployment methodology in much more detail (building on point 7 above).
More In This Series
The Missed Opportunity and How We Can Overcome It
The Business Benefits
The Basics of Technology and Strategy
Solving Coming PLM Strategy Problems
Making it Real – People, Governance and Methodology