Adam Gonnerman

Six weeks before our product launch, the VP of Marketing walked into my office with what she called "a small request." She wanted to add a complete user onboarding flow to our mobile app. Small request. Right. I'd seen this movie before. In my early days as a project manager, I would have smiled, nodded, and quietly absorbed the extra work into our timeline. The team would have worked nights and weekends, quality would have suffered, and I would have spent the launch week putting out fires instead of celebrating a successful delivery. But I'd learned the hard way that scope changes, no matter how they're dressed up, follow the laws of physics. You can't create time and resources out of thin air. The first thing I did was assess the real impact. This wasn't just adding a few screens. The onboarding flow required new API endpoints, database changes, additional testing scenarios, and integration with our analytics platform. My rough estimate put it at three w...

I still cringe thinking about that executive briefing years ago. Our team was six months into rebuilding the customer portal, and I had prepared what I thought was a thorough status update. I walked into the conference room armed with architecture diagrams, database schemas, and a detailed explanation of our microservices approach. Twenty minutes in, our CTO held up his hand. "Adam, I need to stop you there. Are we on track to launch in Q3 or not?" The room went silent. I had spent the entire presentation talking about technical elegance while completely missing what he actually needed to know: timeline, budget, and business impact. That uncomfortable moment taught me everything about communicating tech status upward. I had fallen into the engineer's trap of leading with mechanics instead of impact. The CTO didn't care about our service mesh implementation. He cared about whether customers would have the new features before the holiday shopping season. Since then, I...

Ask someone outside the profession what a project manager does and you'll hear some version of the same answer: they run meetings, update Jira boards, track tasks, and produce status reports. Maybe they build a Gantt chart or two. It's not wrong, exactly. Those things happen. But describing project management that way is like describing an iceberg by what you can see from the deck of a ship. The visible tip is real. The work below the surface is where the job actually lives. Beneath every clean status update is someone who spent the previous 48 hours balancing three competing priorities against a resource pool that couldn't support all of them. Beneath every smooth stakeholder meeting is a PM who quietly diffused a conflict before it ever reached the conference room. The Gantt chart your executives see on Friday reflects decisions, trade-offs, and conversations that never make it into any report. That's not an accident. That's the job. What the profession actuall...

When I got promoted to associate project manager early in my career, I thought I knew what I was doing. I'd watched other project managers for years and had managed a few small projects myself. But nobody ever sat me down and walked me through the basics. On my first major project, I stared at a blank Excel template for what felt like hours, trying to figure out how to create an actual project plan. I knew the tools existed, I knew templates were available, but I had no idea where to start. That's when I learned the hard way that creating a project plan isn't about mastering software or filling in templates. It's about having the right conversations with the right people in the right order. I started with what seemed obvious at the time but wasn't: I sat down with the project sponsor and key stakeholders for a kickoff conversation. I asked three simple questions that would become my foundation for every project since. What are we trying to achieve? When does it need...

"Innovation is saying no to a thousand things."  -  Steve Jobs There is a meeting to align on a proposal. Turnout is good, including some fairly senior people. Opinions differ. Time runs out. A follow-up is scheduled, a revised deck will be produced, a pre-read will be distributed before the next alignment meeting. Nothing is blocked. No one has said no. Yet nothing moves. This is what organizational stall actually looks like. Not conflict. Not resistance. Diligence. Leaders often equate consensus with alignment, but they are not the same thing. Consensus means everyone agrees. Alignment means everyone understands the direction and their role in it, even if they would have chosen differently. One is a state of unanimous opinion. The other is a condition for coordinated action. When consensus becomes the goal, progress slows while risk quietly compounds. Consensus optimizes for harmony. It is a room full of nodding heads, objections softened or withdrawn, everyone heard and id...

There are moments in a program manager's career when following the established process is exactly the right call, and moments when following it blindly leads to serious problems. Knowing the difference is not something any methodology teaches you. It comes from experience, and sometimes from a project that goes sideways before it gets right. I was once tasked with leading an ADA compliance initiative for a company's primary application, covering web, mobile, and Smart TV platforms. Accessibility work is not optional. It is a legal and ethical obligation, and the stakes of getting it wrong extend well beyond a missed deadline. When I assumed the project it had already passed through the hands of two product managers, both of whom had moved on to other opportunities. I was inheriting something that had already lost momentum and institutional memory. I did what any program manager would do in that situation: gathered what information I could, held a structured kickoff meeting, al...

Nobody puts missionary experience on a project management resume. I did not either, at least not explicitly. But after fifteen years delivering complex technology programs, I am convinced that two years of mission service in Brazil shaped my professional instincts more than any methodology certification ever has. Let me explain why. After a mission internship in Brazil in 1997, I committed to returning as a full-time missionary. That meant getting the right education first. I enrolled in Harding University's School of Biblical Studies, an accelerated program that compressed nearly four years of education into two. The pace was relentless. I studied beginning through advanced biblical Greek in 24 weeks. Along the way I went deep not just into Scripture but into counseling, fundraising, cross-cultural communication, and the practical realities of sustaining a mission. I was trained to enter unfamiliar territory and figure it out. That turns out to be an extraordinarily useful profess...

Embarking on a technology project can be an exhilarating endeavor, filled with the promise of innovation and progress. However, the success of such projects hinges on more than just assembling a group of individuals in a room. To ensure that a project planning meeting yields productive outcomes, project managers must lay the groundwork, communicate requirements effectively, and align stakeholders before the collaboration begins. In this blog post, we will explore the crucial preliminary work required to prepare stakeholders for participation, highlighting the significance of proper preparation and alignment in achieving accurate project milestones and dates.Establishing the Foundation: Before diving headfirst into project planning, project managers must set the stage by undertaking preliminary work. This phase involves assessing the project's objectives, identifying key stakeholders, and defining their roles and responsibilities. It is essential to ensure that all individuals invol...