PLM & OCM Ch. 7: "Change is a Painful and Inefficient Threat"
Patrick Hillberg Ph.D.
Adjunct Professor @ Oakland University | Product Lifecycle Management (PLM) | Speaker, Consultant, Expert Witness | Advocate for Workforce Development | Ex-Siemens PLM
“Hi, Prof.”
“Happy Monday, Sarah. How was your weekend?”
“Good, thanks, but I need to get right to it. I need a refresher on predictive project management methods, like Waterfall, and Vee, versus adaptive methods, like Agile, and Scrum. We discussed it in the course, can you take me through it again?”
“What? WHAT?!? You don’t remember every aspect of a course that you took three years ago? I’m shocked, shocked I tell you to hear that there is gambling in Casablanca!”
“Huh?”
“Oh, it’s from a classic movie with Humphrey Bogart and Ingrid Bergman. Claud Raines is a local cop who… Oh, wait. You need to keep moving. Professors learn to speak in 90-minute increments. How can I help you?”
“Um, sorry.”
Prof, said laughing, “Of course. By the way, I’m having fun with this, but you owe me a guest lecture next semester. ‘See one, do one, teach one…’ It’s time for you to teach!”
“I’d be happy to.”
“Why this topic?”
“When the project kicked off, it was slated to be Acme’s first Agile project, and at Spacely I am a known proponent of Agile. But in practice, Henry at HQ created a series of heavily defined predictive processes instead of truly embracing Agility; it can be a little terrifying for a traditional project manager. The predictions at the front end of a Waterfall or Vee seem so comforting when people still believe in them. It is later, when the predictions fall apart, that things go bad. Suddenly there is recrimination and blame-shifting, with everyone pointing fingers at everyone else.”
“Everyone who has ever been blamed for missing their deadlines inflates their future predictions to protect themselves. Then project managers are upset that estimates are so high, so the predictors must justify why they are protecting themselves, etc., etc. Before a project even starts, morale falls apart. With all that in mind, do you really need to make a case inside Acme for a switch to something truly adaptive?”
“Yes. It’s not something that everyone is familiar with, and I need to kick it off. I am preparing for another big meeting, in this case with Acme’s Leaders.”
“Who are the ‘Leaders’?”
“On this project, Acme employees fall into three groups: Execs, Leaders, and Users. The Execs are at the top of the organization and want to enable digital transformation using PLM and ERP. The Users are the many workers at Acme who will use the new technology, and the Leaders are in the middle. They are the people responsible for each dot in the Arrow Diagram; they respect the Exec vision while also thinking about the impact on Users. Leaders may or may not be managers but are visionaries within their groups. That said, there are strong personalities involved.”
“I’ll bet! Okay, looking at your arrow, Simulation provides info to Design, who provides info to Supply Chain.”
“Right. Fortunately, the Simulation group is mature in their existing use of Spacely’s virtual manufacturing software, and we’re getting a lot of support from the manager of this group. He is motivated to better integrate his team’s simulations into the other groups. Gary and I feel lucky here; he is passionate about moving US Acme forward, and his vision is aligned with both the Execs and Spacely.”
“Then the Design group takes information from the Simulation group, designs the necessary machines, and feeds procurement orders to the Supply Chain group?”
“Yes, and again we have a passionate advocate from Design. He previously worked at another company which used PLM, and he would like to see Acme do the same. He is frustrated by the overall CAD management process and would like to improve it.”
“And Supply Chain?”
“Robin is the Lead. Specifically, her team checks design data, which is tedious, error prone, and the cause of lots of frustration. Initially, I was concerned about Robin, her role is like someone at a different company who caused us problems. That person had a tightly controlled process for managing procurement, and people were afraid to challenge her. Even the COO was afraid to challenge her. She was the only person who really understood how designs turned into manufactured products and had lots of informal power. But at Acme, Robin is happy about reducing her team’s frustrations.”
Prof paused, “Hmm… well, good. I’m happy it’s working. So how can I help you?”
“US Acme follows a traditional waterfall project management approach in building the assembly lines that they sell, but the Leaders and Execs are willing to try Agile on this project. And I’m falling back on the conversation in Dirk’s office which said ‘Let Spacely lead’. So, dammit! Agile is what we’re going to do!”
What is Said, vs. What is Heard
Prof smiled. “Why don’t you like the Waterfall or Vee?”?
“Predictive projects always seem to end up as a nightmare. Something doesn’t get done, or the developer does what she thinks the user wanted, and the user says, ‘it’s not what I want, now’ and then there’s an argument over ‘does the functionality we delivered match what was agreed upon months or years ago?’ This leads to arguments and animosity, and if the developer wins the argument, it means that the customer is unhappy. If the customer wins, the developer is up late trying to fix the problem with some patch which will likely need to be fixed again. I know Architects who write long and detailed statements of work (SOW) to protect themselves in future arguments, but that’s a lot of upfront work with little added value. Architects are expected to become accountants and lawyers.”
“Are you worried about protecting yourself at Acme?”
“No, I believe that an adaptive process where we embrace change is lower risk, for me and the project. I don’t think the customer can possibly know now what they will want from us in the future, so it’s counterproductive to force Acme into an agreement up front.”
“I happen to have a slide in this.”
“Of course, you do.”
Prof shared the slide on the screen. “Yeah, yeah, yeah. You called me, remember?”
Prof continued, “in our last meeting we discussed how change is painful, the status quo is easier than learning something new, and that power centers within the organization are centered around control over existing processes. So, when an architect asks, ‘what are your requirements?’ The question will be seen by some within Acme as creating a painful and inefficient threat to their value system. The two people in the diagram have conflicting mental models. The provider thinks that they are just providing technology, but the client worries that ‘it’s not how we do things here.’ After ‘Change is Pain’, this is my favorite slide.”
“What is Fight or Flight?”
“All animals face this when stressed; should I flee, or do I need to fight? Your points of contact will ‘flee’ by not answering your emails, not attending meetings, or being noncommittal when you do talk to them. But then the ‘fight’ response will occur when, late some Thursday afternoon, you’ll be called into a meeting with your contact’s boss to explain why you haven’t made progress, despite your contact’s unwillingness to engage with you. The whole thing devolves into recriminations and arguments.”
“The meeting set up by Henry a couple of weeks ago looked like it would be a fight.”
“Yes, but you and Dennis built the Arrow Diagram, and were fortunate to have some time to educate Gary, Mitch, and by extension Dirk, before the fight could really get started.”
“We were lucky on that. A January meeting was put on our calendars in December, and the US took a shorter holiday break than HQ. When Dirk started making our points for us, Henry chose to flee Dirk, rather than fight Spacely.”
“Right. And the timing was fortunate. You could have had a much different outcome otherwise. Maybe a lesson learned is to establish your insights as early as possible. I won’t go into it now, but the Challenger books are big on this.”
Predictive Management Inhibits Transformation
“Can you bring up a Vee model slide?”
“How do you know that I have one?”
“Yeah, right.”
“Were you this sarcastic to me when you were in my class? What grade did I give you? I can take it back, you know…. “
Prof continued, “This is one of the slides I use; it originated with the book A Practical Guide to SysML, but then I added the two questions in orange, ‘what if stakeholders change their minds about what they’ll need?’ And the other question is particularly relevant in the case of Digital Transformation, ‘what if the organization needs to change?’ You can find a lecture discussing this here.”
Prof continued, “but a key point is that if your purpose is to enable Digital Transformation, you must also enable organizational change. It means that the ‘Stakeholder Needs’ on the left cannot lead to a ‘System Solution’ on the right.
Sarah paused. “Wait. Say that again?”
Prof laughed. “In broad strokes, digital transformation requires organizational change, and transformation is outside the ability of predictive models, like the Waterfall or Vee, to manage.”
“This is just what I was looking for, Prof! Calendar time from left to right can take years for some projects, meaning that you need to make accurate long-term predictions. As the project continues, the supplier becomes focused on fulfilling a contractual agreement from the left which is becoming less and less relevant as transformation moves to the right. I don’t have confidence that Acme knows now what they will want even a few months from now.”
“Exactly. Think about it… if the organization wants to digitally transform, but you keep enforcing an agreement made months or eventually years ago... you are not allowing your client to change.”
“Wow! By enforcing an upfront agreement, rather than adapting to changing perceptions of value, I am violating the entire purpose of PLM at Acme.”
“Right. And then there is the decomposition problem. This slide originated from DARPA, which is the advanced research arm of the US Military. This may be my third favorite slide.”
“Yes! On a big project we break the work into teams and give each team a set of tasks. But how do we ensure communication between the teams throughout the project? I see these projects like jigsaw puzzles, where each piece is some small amount of the overall work, and individuals work diligently on the center of their own pieces. But they don’t pay attention to how their edges fit with the pieces developed by the other teams.”
“Then the means to build the puzzle is not through over-specifying upfront agreements, but through recurrent collective learning over the course of the project. You can find a lecture discussing this here.
Prof continued, “I want to come back to decomposition and learning the next time we talk, but aren’t project scope changes handled through change orders? An agreement to change the statement of work?”
“Oh, and SOW changes are LOTS of fun.”
“You have really developed your sarcastic streak; do you know that?”
“And I’ve never heard THAT before”, Sarah said, rolling her eyes comically. “Sorry, I couldn’t resist.” She smiled. “But changing an SOW is painful, because there is usually money involved, and someone will be blamed for not seeing the problem sooner.”
“And we’re back to assigning blame again, not providing a System Solution.”
“The Exec goal is digital transformation, but I think that there are many within the Acme User community which will see it as a ‘painful and inefficient threat’.”
“Change is painful, and you should assume that people may be feeling pain when they see you.” Prof laughed, “you’re not an accountant or lawyer so much as a dentist!”
“Gee, thanks. But transformation means change. The Exec vision cannot be successful unless the Leaders below them embrace it, and the better approach to managing this project is an SOW which encourages and embraces change.”
Agile Learning
“And what you’re saying is aligned with the Agile Manifesto, which emphasizes:
And you are adding a fifth point, which is:
Sarah replied, “Right. I want everyone to embrace change, and also provide a learning environment so that Acme asks for the changes that I want to give them.”
“Right. As the Lead, you need to have a strong vision on PLM strategy, and I think you have one. The next step is to provide learning environments so that Acme requests functionality which is consistent with your vision. There will be some give-and-take on this, and no small amount of negotiation, but if you are confident in your vision, and in Spacely’s ability to support that vision, I think that your implementation will end up in a better place than if you force your team to deliver on a contractual agreement based on a tenuous prediction.”
“I think so too, but how can I prove to Acme Execs that progress is being made?”
“Have confidence. I think that you’ve started well. You have committed the team to an aggressive goal, but you haven’t handcuffed them with detailed sub-tasks. This gives them the opportunity to learn new things, and people love to learn if they’re not forced to change. Once they start, they will progress faster than you can imagine, and you can use your weekly project meetings to help the Leaders learn from each other, and from this you can judge their progress.”
“I hope so.”
“Have faith! Talk next week? I want to cover some decomposition stuff.”
“Thanks. See you then.”
Learning Goals