AI-Era Project Planning: Stop Drift Before It Starts
Tempo Software CEO Vic Chynoweth joins Techstrong TV to tackle one of software development’s most persistent problems: project drift and the collapse of traditional planning cycles in an AI-driven world. Chynoweth argues that annual and even quarterly planning rhythms are now obsolete — replaced by continuous, data-connected orchestration that links team-level execution to strategy in near real time. From AI agent negotiation to the politics of change management, this conversation covers what engineering leaders and product organizations actually need to do differently today.
Transcript
Hey guys, thanks for the throw. We're here with Vic Chenoweth, who's the CEO at Tempo Software, and we're having a little chat about how to keep software development projects and teams on track because, well, there's this thing called drift, and it happens to the best of us. Vic, welcome to the show.
Thanks, Mike, for having me. How does this problem kind of manifest itself from your experience? " And then over time things happen, but how do we kind of prevent that drift from kicking in?
Great question. I think people have been trying to solve for this for a long time, and progress improves it along the way, and then other things happen that impede it. The latest being AI, and what's probably the biggest impedance we've seen just because of the pace that innovation can occur, both inside of a company, inside of a team, as well as with competitors.
I think that's the core of the issue is that people, businesses, teams, individuals have to respond to signals and changes in the market much faster than they have in the past, as well as changes inside of the company because of the progress and speed they're able to achieve, even with just copilot constructs, let alone agentic AI. Sometimes I feel like maybe we're overly wedded to our project management applications, and we decide that this is the outcome that we're aiming for, and so no matter what happens in the rest of the world, we kind of just keep coming back to that, even though the project we may have launched four months ago is no longer relevant. I think that's absolutely true.
One of the things that I would suggest is true of any plan is it's wrong. Just depends how wrong it is and if it's a time wrong, if it's a sequence wrong, if it's an amount wrong, whatever the case may be. And so, I think you're exactly right.
I think what we've gotten to is much more a continuous planning construct where the most effective organizations, or at least that's what the most effective organizations are adopting. So what's your best advice to folks about how to have these conversations? Because I think part of it too is everybody kind of has their weekly meeting and they do the check-in, but it's not clear to me that the check-in is actually anything that's coordinated with a meaningful KPI for the business.
So I think where we've gotten to today is that you need data to support those check-ins. Those check-ins are pretty oriented towards a team or a set of teams. You might even get to a program level with those check-ins.
" So on and so forth. And so it's really a data element, and it's a real-time data element. So basically planning an orchestration at the speed of AI.
And another thing there is just dropping, probably knocking down the historical walls that occurred and the processes associated with this historical walls. And what I mean by that is product organization relative to the engineering organization. They work closely together throughout time, I would suggest, at least the most effective have.
They're just more in real-time synchronicity relative to what they've done historically. I feel like there's a lot of dependencies that exist between different projects, but not all those dependencies are maybe obvious or even well explained, and it's not uncommon to see folks working on some project only to discover that some dependency that they were counting on isn't ever going to show up. So, how do we kind of have this conversation in a way where we understand if a team decides to abandon a particular project, the downstream implications of that decision?
Great question. So first off, making dependencies visible and discussing them openly is paramount. The second piece there is really, again, a construct of what you have to do, and at the speed of innovation and development today, that we maybe didn't have to do historically.
So if I go up a legacy planning approach, hey, let's look at our strategy, reassess things, think about a strategic roadmap annually. Let's go execute that, keep working things quarterly, more like at the team and function level, and then step back at a strategic perspective annually. That cycle doesn't work anymore.
So I think companies, the most effective, in near real time, are able to connect planning and execution, including dependencies at the execution level up to strategy level in near real time. It's not quite real time. Certainly, the project level is.
But if it was an annual planning cycle, it's at least that it looks at strategy and the connectivity. It's at least quarterly and some are probably monthly. " So how do we get to that ability where maybe the information and the insights we're looking for just kind of get automatically generated by the tools we're already using?
Great question. And that is what we're trying to do at Tempo, as you probably know. And so what we do there is we want to connect all of the signals, which includes all the delivery capacity, time, dollars, you name it, and then systematically connect that so that everybody can see it in real time as well as when they want to step back for a planning process and orchestration.
It requires aCommonality really in data. So one of the things we don't want to do, because it's really hard to do, is enforce how people are going to work and in what tools they're going to work. What we have to be able to do is uniform that or standardize that data and bring it together so that program management can see it, you can see it at a portfolio level, and teams can see it.
Because let's say, Mike, you're on one team, I'm on another team, and you have a dependency on me, you need to know how am I doing that or on that, and is that going to be ready in time for you or do you need to redirect? It has to be done at that data level. It can't be done kind of word of mouth, which probably worked effectively with some teams and some organizations in the past.
That just doesn't apply anymore. How smart will all this get? And I'm asking this question from this perspective.
" Great question. You probably asked that question today. It'll give you an answer.
How accurate it is, I can't tell you, but it'll probably certainly get you thinking. I mean, AI has advanced materially, and it keeps advancing daily, if not hourly, to some degree. And so, leveraging it just to ask some of those what ifs is something we can do today.
What we're trying to do, I think what's really important for engineers and product organizations, really delivering any product or service as we're innovating, is accelerating the planning and orchestration of the work, because that hasn't naturally or been the first thing out of the gate to apply AI to. It's really been, how do we develop faster? How do we innovate faster?
But now that we've done that, how do we orchestrate and plan work more effectively so we can actually get the outcomes and optimize the deployment of whether it's the combination of human engineering and agentic engineering. So what do you see organizations doing these days still that makes you shake your head a little bit and go, "Geez, folks, I think we need to be a little bit smarter than that"? I think the most common thing that I see, and I've seen this at Tempo, and I had to go, "Hey, we've got to think about this differently," is, hey, I have a mindset of I'm going to keep doing it the way I've always done it.
I'm going to try to leverage AI in that construct of how I've always done it. And the folks who are making the most progress, doing things, kind of getting the most value of AI at the speed of AI, so to speak, step back and re-engineer those processes. They go, look, I need to have an AI centric view of the world versus my legacy centric view of the world and go with AI.
Give you an example. Strategic roadmaps is a functionality that exists in a SPM umbrella. " Well, we should be able to just ask an application to go, here's all the things we know.
You understand what a strategic roadmap is because here's my last one. Synthesize this for me, and then let me respond to it, and then adjust from there. It's a different way of looking at the world, including how you even build that strategic roadmaps functionality, just using that as an example.
Do you think that teams, each of which is likely to have their own AI agents at some point, will enable those AI agents to kind of negotiate with each other? Because that's what we humans do, right, when we have projects and things change, we discuss, and we come up with some sort of optimal plan, or sometimes also known as a compromise. How will these AI agents kind of articulate that conversation on our behalf?
Great question. I think folks already have AI agents working with each other, therefore, they're having to negotiate with each other. I think the big question is going to be is how much, I don't know, decision making authority do we give to the AI agents versus the humans that inform those AI agents and guide them?
I don't know the answer to where that ultimately ends up. It's probably the multimillion dollar question that folks have, one of many, but it is something that we're already at. We already have AI agents talking to each other and negotiating with each other.
And it's really going to be the question of how do we leverage that, but in such a way that we don't lose the control and ultimately the ownership of what we want to get at the end of that day. I don't think it's much of a dirty secret, but very few projects in corporate America actually show up on time and under budget. So do we have any hope of actually achieving that goal someday?
I guess the question is what is the goal? To be over 50%, over 30%? I don't know.
What is that goal? I think the way we look at it is for every individual customer we work with, we want to go, how do we improve upon what you're doing today? And I think that's what every customer wants to do, or every enterprise out there wants to do.
With AI, the opportunity's going to be to accelerate all those things. Question's going to be whether our expectations align with that new speed or not. I don't know what the right answer is.
I think at the end of the day, we shouldn't deliver every project on budget, on time, so on and so forth, because if we do, we may have aimed a little bit too low on average. What are the right balances there? I can't tell you.
It's probably certainly over 50%, but again, if you don't aim high enough, you're going to hit your budget and your time every time. So it's a balance there, quite frankly. Ultimately then, this is an exercise in change management.
So what's your best advice to folks about how to navigate that? Because it's not just a technology issue, it's a matter of often humans and political capital and will. Great question.
I'd go back to something you mentioned earlier, which is visibility to dependencies. To me, it's like let's provide visibility and transparency to what we're trying to accomplish and why. So a lot of folks have been afraid, and they continue to be a little bit fearful of, oh, AI is going to displace me.
I'm not going to have anything to do, so on and so forth. And if you come at it from a fear of your approaches to kind of be protectionist of jobs, that's going to be a hard way to win at the end of the day. However, if you go, hey, this technology is here.
It's going to move forward. How do I leverage it to do what we want to accomplish faster, better, less cost, so on and so forth? The way I always think about it is I want to automate myself out of a job anyway because there's always something more important to do.
And so I think people just have to have alignment on why and what we're trying to accomplish so that you can actually get everybody participating in it. Because without everyone participating or the majority, it's really hard to move it forward. And in my experience, if people understand the why and have had a chance to contemplate it, internalize it, discuss it, they'll own the what, the when, the how.
And so I think that it's really a transparency, and I would suggest that's probably the most important part of any sort of change management initiative is making sure that folks understand visibility to why we're doing this change. All right, folks. You heard it here.
Hey, even in the age of AI, it's still true that if you want to shoot for the moon, maybe aim for the stars. Hey, Vic, thanks for being on the show. Thanks, Mike.
Appreciate it. All right. And back to you guys in the studio.