What I Know Now That I Didn’t Know Then.
A follow-up to “What Project Management Taught Me About Change”
A year ago, I wrote about earning my PMP and what that process revealed about my work in change management.
I wrote about seeing the connections: how a Work Breakdown Structure could help identify resistance points, and how stakeholder registers mapped beautifully onto influence and engagement planning. I wrote about the potential of bridging those two worlds.
What I didn’t know yet was how that bridge would actually get tested. This past September, I got my answer.
I had one portal, two hats.
Our team supported the rollout of an enterprise employee portal, a large-scale initiative that touched nearly every corner of the organization.
My role covered both sides of the house: change management (OCM) and knowledge work from the technology perspective, and project management for the AI chatbot that would live on the portal. Two very different lenses. Same deadline.
I had anticipated how PM and OCM would complement each other. What I didn’t anticipate was just how naturally they’d pull in the same direction.
When I was tracking chatbot UAT timelines, I was also thinking about user readiness. When I was drafting knowledge articles, I was watching dependencies. The two disciplines weren’t competing for my attention. They were reinforcing each other.
I hadn’t fully expected that. And honestly? It was one of the most energizing professional experiences I’ve had.
When it’s go time, you go.
As the launch approached, the lead PM developed the test scripts. My job was to execute them — running through every scenario, documenting defects, and tracking what passed and what didn’t.
There was a lot of it. And it all needed to get done. So I got it done.
Looking back, that instinct to just pick it up and get it done? That was the PMP talking. One of the quieter lessons from earning my PMP is that project success isn’t about protecting your lane, it’s about protecting the outcome. When the work is in front of you and the deadline isn’t moving, the question stops being “Is this exactly my job?” and starts being “What needs to happen and how do I help make it happen?”
Change managers talk a lot about helping others navigate uncertainty. That September, I had to practice what I preached.
The chatbot went rogue.
I’d be telling an incomplete story if I left this part out.
Right before launch, the chatbot started behaving in ways we had not configured it to behave. It wasn’t doing what it was supposed to do. In the most technical terms I can offer, it was acting stupid.
After all the planning, the test scripts, the knowledge work, the coordination, we had a chatbot that wasn’t ready to meet users.
We made a call to delay the launch by a week.
In that moment, everyone owned a piece of the communication. The OCM lead handled the broader stakeholder outreach. My job was more targeted, reaching out directly to the specific group impacted from a technology and knowledge standpoint. It was a focused responsibility, but an important one.
And it reinforced something I’ve come to appreciate about large initiatives: everyone holds a thread. When the threads are pulled together, the message lands.
A delayed launch is not a failed launch. It reveals a team that cared enough about the user experience to get it right.
I wish I’d known this one thing.
If I could go back and tell myself one thing before stepping into this role, it would be this: No launch goes perfectly, and that’s okay.
There will always be something. A vendor behaving unexpectedly. A stakeholder who needs more runway. A chatbot that briefly forgets everything it learned.
The goal isn’t a flawless go-live. The goal is a team that knows how to adapt when things don’t go to plan, and users who feel supported on the other side of it.
That’s what change management is really about. Not controlling the outcome but being prepared to lead through whatever the outcome turns out to be.
A year later, I’m comfortable wearing two hats.
My PMP gave me a framework. My Change Management Manager role gave me a proving ground.
One year in, I’m still using both, sometimes within the same hour. The skills don’t compete. They compound.
And on the days when a chatbot goes rogue, and a launch gets pushed, and the whole team is sprinting toward a new deadline, I’m grateful to have both in my toolkit.
Because when it counts, you don’t get to pick just one hat. You just figure out how to wear them both.