Beyond On-Time, On-Budget with Deborah Kaminetzky

You know that expensive software system your company bought that everyone... stopped using? Deborah Kaminetzky sees this pattern constantly. Projects delivered on time and on budget that still fail because nobody wants to touch them.

Deb brings a unique lens to technology implementation. She's a former attorney turned project management consultant who specializes in what she calls the "messy middle" – the space between buying software and actually getting value from it. Her secret? Translation. Not just between tech teams and business teams, but between what's being sold and what people actually need to do their jobs.

In this episode, we dig into why user involvement isn't just a nice-to-have (spoiler: shadow IT is alive and well), the difference between being heard and influencing outcomes, and why your C-suite needs to stop treating technology teams like the organizational stepchild.

This Week's Takeaways:

1. Solve the problem before you buy the solution – Understanding what you're actually trying to fix has to come before you start shopping for software. This seems obvious, but most organizations skip this step entirely.
2. Mediation matters more than metrics – When users are involved in gathering information and partially in decision-making, adoption happens. When they're just told what to do, they find workarounds. The question is: how much of that involvement is just making people feel heard versus actually changing what gets built?
3. Outcomes over outputs – On-time, on-budget means nothing if the software gathers dust. Find ways to measure whether you're getting the value you expected, not just whether you hit the deadline.

Want to reach out? Email us at feedback@definitelymaybeagile.com or visit definitelymaybeagile.com.

Chapters

• 0:00 Meet Deb And The Real Problem
• 1:05 On Time, On Budget, Unused
• 2:39 Rescue Projects And Contract Pitfalls
• 4:39 Translating Needs Into Design
• 6:51 Experience Has Changed, Products Haven’t
• 9:26 Start With Users, Avoid Shadow IT
• 11:35 From Current State To Future State
• 14:05 Roadmaps, Tradeoffs, And Growth
• 16:20 Optionality Without Overspending
• 18:18 Reuse What You Own Wisely
• 20:05 Behavior, Adoption, And The Gym Analogy
• 22:12 Outcome Metrics Leaders Value
• 24:10 Bring Technology Into Strategy
• 26:00 Quick Fixes Versus Real Change
• 27:18 Final Takeaways And Closing

Transcript

Peter Maddison [0:04]: Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello everybody. So I'm here with Dave again, and today we have another guest. Deb, would you like to introduce yourself?

Deborah Kaminetzky [0:19]: Sure. Hi, Deb Kaminetzky with De facto PM. I do project management solutioning and consulting. Glad to be here today. Thanks for having me.

Peter [0:28]: Great to see you. We were chatting a bit before this, and you were describing your background and what led you to the work you do today. Why don't you give our audience a taste of what you'd like to talk about?

Deborah [0:43]: Oh, sure. So before I was officially in technology, I was actually in technology, just not officially. I did kind of a Pareto 80/20 pivot. I was a practicing attorney who handled all the tech for my company and did a lot of lecturing and continuing education for lawyers on it. Then I moved to Seattle, got a job with a Microsoft vendor, and started officially working in tech in 2019.

The reason I started my own company recently is because I'd seen so many times where the client would purchase a solution that was sold to them. They thought, okay great, this is going to really change the way we work or make things better. And then in the end, when the project was delivered on time and on budget, which are those magic words, they didn't like it. So they weren't using it. They went back to spreadsheets or whatever they were doing before.

And I thought, how sad that they're not actually using all the stuff we just stood up for them. What could we have done to prevent this? So now what I'm doing is, much like I was as an attorney, asking the right questions, making sure I understand what the issues and problems are, involving the client in how we're going to solve it, and making sure they have a solution they're actually going to want to use afterwards.

Peter [2:07]: Yeah, I can't say I'd ever run into that. You mean people buy things and then don't actually get the value out of it? Shocking. laughs

Deborah [2:15]: Or they perceive they're not getting the value. Or sometimes it's also possible they just don't understand how to use it. But training aside, often it just isn't what they thought it was going to be. Kind of like lottery winners.

Peter [2:29]: So how do you help organizations? Do you get involved before they make the purchase to help them decide if this is even the right direction? Or do you typically get involved after they've said, okay, we're going to shell out all this money, we've got it, and now what?

Deborah [2:44]: I've gotten involved with both. I work both with clients on the client side when they already have a software company or an implementation partner they're working with. I also work with software companies and implementation partners on their projects. A lot of times we're doing rescues, like an ERP rescue, where they have an ERP they got a few years ago, it's not working well, and we're either changing the complete ERP or doing reconfiguration.

It's also happened with a staffing company where we're reworking something that was installed. It wasn't installed improperly according to them, it just wasn't installed to their liking. And there's a difference. Huge difference.

So I do like to get involved in the beginning before the contract is signed. Contracts really are very important. Having litigated and drafted contracts, I won a case on one word in a contract at one point. So you really do want to understand what your contract says in terms of what you're entitled to, but also what are you actually doing?

I find that my work, a lot of it is translation. Translating between the tech people and the industry people to make sure everyone understands what we're building together and why we're building it and how we're building it. I once had a client that didn't understand the whole field mapping exercise. And I explained the difference between radio buttons, dropdowns, conditional logic, free text fields, and not only why that matters going in, but why it matters later when you want to do dashboarding and reporting. And that was important to them.

It's very easy to put a free text field in, very easy to put the data in, but then you can't manipulate the data. So what did you do? You put it in a Word document, essentially. And that's not really what they want. So yeah, getting me involved early is best because as a former attorney, I know risk, I understand ten steps ahead in twenty different directions. What are the things that could happen? And it needs to be pointed out.

Dave [4:51]: I find it so interesting because the industry, like technology... and Peter and I have talked about this a number of times... has changed. Twenty years ago, we were much more accepting of the solutions that people gave to us, technical software providers, whatever it might be, because there was very little room. You know, everything was going to be... once the internet came along and you start using web screens, everything's on the internet and there's a form, or there's some dropdowns and things. But the format is pretty basic and not too surprising. And there were not too many options except some forms that you're doing manually, moving to the technical platforms.

But nowadays there's so many people who have grown up with devices and their experience is so different. And I find it interesting that so many companies that deliver products are still delivering products as in "just accept it and we'll move on" rather than recognizing that we have to develop for different experiences, different devices, different contexts, different expectations.

And I just spent the holidays in the UK with my mum and my youngest nieces and nephews who are running around and they have completely different needs. And I used to be, you know, the technical guru, and I'm now definitely nowhere close to a technical guru. There's a whole other generation who roll their eyes at anything that I think is the latest and greatest.

So I love the fact that organizations now are much more aware that there's a building adoption, traction building phase in delivery. But so many companies don't have that. They have the delivery on time, on budget. And this is that project versus product thinking piece. The on time, on budget doesn't mean you get the value, right? The value is can I get everybody to stop using the Excel spreadsheets or the server under the desk in the corner? Can I get them actually using and agreeing?

With what you're saying, can I ask, when you work with this sort of messy middle bit, what are the things you're looking for? Where do you start the conversation to make sure you're having the right conversations and people aren't just going to meet a deadline and show a contract that says we've delivered everything you asked? Where do you start?

Deborah [6:59]: Well, I think it's very important to have either workshops or interviews or whatever you want to call it with all the different people that will be using the software. So let's say it's a manufacturing company, and let's say the COO is the one who's bringing me in. They and the CEO are going to tell me all about the company strategy, what it is they're trying to achieve, et cetera.

They have people in a warehouse who are picking things out. They have salespeople who are in the field. They have people in various situations doing their work. Sometimes the C-suite does not even know what it's like to do that work. Sometimes they do.

Getting to talk to those people and understanding what they're doing currently and then trying to just make it better, as opposed to just telling them, we have this new system and this is what's going to happen. You're disrupting their work. It may actually not work better than what they're doing now. And the problem with that is that they will go around it because they have to get their work done.

So if you give them a new system that did not take them into consideration, they're going to find a way to get their work done. And it may not be the way you want, and it may not be using tools you want. I'm sure you've heard the term shadow IT. There are a lot of people in companies, and if the company doesn't have a policy or the person doesn't realize they have a policy, they'll just start using a software they found to do a workaround on what they're being asked to do. And the problem with that is that then that data isn't necessarily residing anywhere within the official channels and it's being missed.

So I feel if you want to design the technology for people, and that is what we should always be doing because people are the ones using it. If God forbid there were no people on the earth, we really wouldn't need the technology, right? We're only using it to help people do their work better. So I really feel you need to speak to them. I don't feel I need to speak to every single employee at every single level, but at least a few. And I think that makes a huge difference because truly understanding is the only way that you can build it.

It's the same thing if you're building somebody a house. If somebody has children, you're going to build a different house than if they have none and never will. You just want to make sure you're giving them the ability to do their work the best way possible.

Peter [9:15]: So when you go in... and it's very similar to processes I do to start to understand like how do you get things done here? What are the different roles? What are the different functions? How do you actually execute and how do you interact? What does all of that look like? And then we start to look at things like, how do you fund it all? And what's the operating model of the organization?

And I think as you're explaining that, I have many examples in the back of my head of the perils of things like Excel and Access in the bad old days for people to go and just build something that's totally custom. "This does exactly what I need. It's absolutely fantastic." And then all the folks in IT are going, "Oh no, you didn't." Like, well, I can't integrate that, I can't back it up, that data's lost if your machine dies. I have all these big problems that come up because that data is now often isolated off in a silo and it's not easily accessible.

And we look to solve these days... there are good ways of solving that, but it doesn't mean people don't still go off and do things which don't necessarily follow the best practices we're looking for. So once you've captured all of that information from all the people, what do you do with it then?

Deborah [10:30]: Well, at that point, that's where you speak again with the C-suite and say this is what is. Is this what we want the future state to be? And that's where there might be some decisions about whether we want to continue doing things exactly the way we've done them before, whether we can find some efficiencies and then build that into the new system. But without knowing what's actually happening, I don't know that you can design a really good future state because you don't know, you know, apples to apples what you're doing.

And in terms of getting people to actually stick with it, that's where my mediation background comes in very well. I feel that when people are included in the gathering of the information and partially in the decision making, they are way more likely to stick with something than if they're just told "this is what we've decided and this is what you're going to do."

Everyone understands. The people who work for anybody understand that this is the job and that they're being told how to work, when to work, and with what tools to work. We all get that. But including them in that makes them feel like they own it to an extent and that you actually care whether... I'm not going to say they're happy at work, but whether they're able to do their work easily and that you understand what it is that they do all day. I think it breeds resentment when people feel "oh, they have no idea what we're going through."

Dave [11:48]: Yeah.

Deborah [11:48]: Going through an exercise like this, you have an idea what they're going through. And you may decide to change the process because you had no idea. "I didn't realize it was that difficult. I didn't realize we had so many unrelated things that didn't integrate and made your job so difficult. Let's change that."

Dave [12:04]: When you're talking about the mediation piece and that, you know, the value of being heard and of having people in a room and saying "this is the experience we have with these things to change" or "these are the headaches we're dealing with"... I'm wondering, because I almost feel like that's quite well understood today, but occasionally you see rollout plans that will have a, you know, "we're going to listen to everything that people are saying so they feel heard." And there's huge value.

But there is also an importance in adjusting the plans based on some of that feedback. And I wonder if you have experience or some kind of rule of thumb that allows you to figure out how much of it is just giving people a forum so they get heard, versus how much of it is having some very real headaches that they may have, and that changing the specifications of what's being developed.

And the reason I'm mentioning it, we do quite a lot of work, for example, in insurance and certain financial services firms, and there are a lot of systems which are the backbone of these services, which are effectively bought off the shelf and then configured. And there's this real need to be able to recognize the local headaches that parts of the organization, for whatever reason, may be experiencing.

And we see different things. We see organizations that kind of shrug their shoulders and go, "Well, you can make the change, it just costs you." Which isn't really about being heard, it's about kind of hitting back and saying, "By all means you can have what you want, it just costs more money." Not really fair. Versus the other side of how do we modify this to give an experience which is elevated for the change.

So that was a long piece. The bit I'm interested in is what's the difference or how much do people need to be heard versus how much do those individuals need to impact the specification?

Deborah [13:45]: I'm going to give you a very lawyer-like answer. It depends.

So when you're gathering the information and speaking with people, you want to make it very clear, but you cannot guarantee that they're going to get every single thing they want because there's this little thing called cost. And when you're taking an out-of-the-box vanilla situation and you're doing customizations, you really have to strategize and say, okay, what do we need to do now? What can we wait until next year? And that's more of a roadmap.

But when you are doing any kind of design or planning, you don't want to say, "well, this is what we're doing this year, and we'll figure out next year next year," because you want to leave room to be able to build that other thing.

I did a project once for a company where the client had been sold a solution that was essentially not going to fit on their current environment. They didn't have enough room to grow. We needed to go in and do some structural work in order to even be able to deliver it. So this was a $120,000 software implementation. And I was left speaking with their SVP about the fact that we literally needed another $80,000 of foundational work in order for this to happen.

So, first of all, they asked, "well, why? Why was it done that way?" And I didn't even work for the company when it was originally done. Whoever designed it designed it for today with no room to grow. It's like literally moving into a one-bedroom apartment with somebody who's pregnant with twins. It's just not bright. But this is what they did.

So we ended up doing a change order and they were happy afterward. They got what they wanted, and we left them even more room to grow. So happy, in fact, that they gave us a very good CSAT and asked to work with us again. So you really just have to figure out overall your strategy, your budget, and that roadmap, because sometimes there's a nice to have that you can add on later, but we're not going to do it right now. And I think people understand that. Just because they're telling you all the things they would want or saying it would be nice if we could do it this way instead of that way, we have to really prioritize. And cost is a factor. Configuration and customization is a factor.

Dave [15:57]: Yeah, it is a great view, a great example as well.

Peter [16:00]: I've certainly seen many projects where we run into those types of issues. It's never quite easy. I mean, there's a piece of trying to predict where we're going. We also have to be careful to balance these two things so we don't end up overbuying in the first place, so our initial costs become too high, and we buy a bunch of capacity potentially that we don't need. That's the other balance that's often coming into that, right? We have to make sure we have options. And that's actually might be a good way of describing it.

In the agile space, we think about are we creating options here? Do we have optionality to be able to make the future changes we might need to make? And can we do that for the minimal amount of cost at this point? We don't want to spend a tremendous amount more money creating options that we may never use because that might put us in a situation where we overspend in the first place. But it's that balance of if we have some future aspirations that might drive up the cost, those should be taken... we think about where are we going, what are we trying to do, what's the organizational strategy and tying this together.

Deborah [17:04]: Absolutely. There was one client that was looking at some very expensive, sexy solutions for their database. And it was a nonprofit client, and we were discussing how much it was going to cost for those things, not just to implement it, but the cost... the dirty word in technology... that monthly recurring revenue where we have to pay the per seat subscription price. So it would be, let's say, $500,000 over the next five years for one of those, which was something they really hadn't taken into consideration when they were looking to see what to switch to.

We ended up using what they already had to make them something very similar to what they were looking at. We put everything into SharePoint with the Power Apps overlay, and they got a much better situation than they had before, but they didn't have to pay anything more than the implementation cost. They were already paying for that. So when you can take what someone already has and use it differently to still solve the problem, that's always appreciated.

Peter [18:05]: Yes, reusing the other capabilities of the systems you already have is always a good way to go. The only time where that sometimes isn't the case is where you want to use the change in system as an impetus for other types of changes in the organization. You want to change the system, you want to change how people are thinking about it. And even though the old system could have effectively done this, introducing something new because it has that new sticker on it gets people reinvigorated to think about the problems differently.

Dave [18:39]: If it's introduced in the right sort of way, because what you often see is the sales process is "look at all of these future states that you're going to be able to do, these future things" that you may or may not have value in. And yet at the same time there may not be a strategic imperative to go and make those changes. So then you end up with these systems where whatever the system is, you're using a tiny... there's a huge amount of potential there, and you're just effectively paying rent for a ton of space that you're not using, or a ton of functionality that you're not using.

Which can be peculiar if... I mean, nowadays of course, if somebody's selling you the solution, they want to tell you all about this future benefit, but there also has to be follow-through of actually achieving it.

Deborah [19:24]: You just described a gym membership. So many people in January join a gym, and the gym has 20,000 machines and 5,000 classes.

Peter [19:35]: All those classes you can take part in, right? Yeah, all these wonderful things you're getting stuffed into this, and it's such a deal... 12 months up front, you know.

Deborah [19:44]: But you have to go.

Peter [19:45]: Yeah, yeah.

Deborah [19:45]: So if all you're going to do is walk on the treadmill, you should have just bought a treadmill.

Dave [19:49]: Well, and joking aside, that whole thing about the gym has all of the same problems. So, what is the objective? Why are you going? What are the benefits you're going to get? How can you see those benefits? That's one of the headaches, right? You go a few times and you don't see the benefits. So, what can you see so you understand that change is happening?

There's a lot of things we need to do when we introduce new systems, when we introduce new solutions into an organization that our brains need to be aware of and part of. And I'm always struck with the economists' view of how we make financial decisions versus the behavioral view, where they understand that there are lots of ways we make decisions. If we're using a credit card versus having to take cash out of the bank, that changes how we make decisions with various things.

And yet, if I look at project delivery, it's the economist's view. Once a new better system is given to us, we will obviously use the new better system. And the reality is we don't. We need a very real reason to make that change. We need to understand why it's there, to understand how it makes things better, see that happen piece by piece, exactly like the gym.

Deborah [20:58]: Right. And you asked me earlier about getting me involved early. I will say that having been, quote unquote, "just a project manager" in other organizations, sales will sell something to a client, and then we're left to make it happen, right? Whatever we sold them, you make it happen.

What I like about what I'm doing now is I'm not in sales. I mean, I'm in sales, obviously, you know, to hire me. But I don't sell anything. I don't sell a particular software, I don't sell any particular hardware. So any solutions that I'm investigating on behalf of a client are completely agnostic. And I feel that's better and helpful because I'm not steering them towards what I already sell and not telling them about the things that I don't, because I don't sell anything.

Dave [21:43]: One way I'm interpreting what I'm hearing you describe, Deb, is... if I rephrase it in a different way, a project manager is delivering on time, on budget. So it's a very numeric, quantitative way of interpreting delivery. And what we all do is much more about outcome, about the acceptance of a new solution by the individuals, the teams, the employees, or whoever may be using it.

So that one is a lot less clean to say. We can't walk in and say, "yay, 27% of your target employees are now using it." And we can describe it that way, but there's a feeling, "well, just email the other 63% of employees and tell them they'd better start using it by Monday." Well, that isn't going to work in the way we might expect it to in most cases.

So when you're reporting out to leadership and executives, the on time, on budget is really hard to displace. It's clean, it's crisp, they can see it. Everybody in the room can kind of nod their head. It's maths and so on. So how do you change that? Because they really have to move away from that as a... what experience do you see that helps with that?

Deborah [22:52]: I think what helps is understanding the difference between, like I said, getting the paperweight, if it is a paperweight, and actually having people use it. Because there are some metrics where you can show that the adoption helped.

For instance, if all of a sudden you no longer need to backfill a role. Let's say you have five salespeople or five recruiters, and one of them leaves, and now four people can do the same work because this software is making it so they can. So that's a number. You don't have to pay another person and you're still getting the work done.

Or if your customers are now happier because everything's going more smoothly on their end. Obviously, it depends what the software was, why we put it in place, etc. But some of those things can be measured. They can't be measured on a particular day and time. "Okay, we said we would deliver by September 5th, it's September 5th." That's a finite date, but you can tell a month, two months, three months later the percentage, either more revenue or fewer people working and therefore better costs.

Those are things that can be measured. And I do think people are starting to think about adoption and use of the technology in their whole strategy. It used to be that the C-suite pretty much strategized and turned to tech and said, "okay, these are the strategies. This is what we've laid out for the year. We want you to just make sure that whatever tech you give us is in line with that."

But having the technology be part of that strategy is very important. I feel leaving out the CIO, CTO, et cetera... that should not happen. Not that I'm saying they should drive the entire thing, but they should definitely not be the stepchild of the C-suite. They should be included because there are lots of different ways to do it.

Back to the gym analogy. If somebody comes to you and says, "I want to get into shape, I want to be stronger, I want to lose weight," then you start thinking about what things they can do. A gym might be one of those things, but it might not. There's food, there's exercise without a gym. There are lots of different ways to solve that problem.

When you go to a gym, their solution is to sell you a gym membership, but you may have other issues. You may have nutrition issues. So I don't do a gym membership. I'm not selling what I think you should have. I'm getting an idea of what you actually need to solve and then discussing various ways to go about doing that that people will adopt and use so that you actually achieve solution of that problem.

Peter [25:20]: Yeah, for gyms, it's the cross-sell, upsell into nutrition. "Would you like to meet with our nutritionists? They'll help build you a customized diet plan that will give you all the things you need."

Of course, the other problem you often run into there when you're thinking about other options is like, if your goal for going to the gym is to lose weight, well, over here we have this instant gratification solution. You just take some pharmaceuticals and that perhaps solves it, and it's much easier than going to the gym. Do you run into that sort of problem with the work you're doing where people just don't want to do the work because they can see it's much easier to just buy it and throw it in and it's instantly going to all work?

Deborah [26:04]: What I see a lot of actually is people who did do that simple, easy way first. They just bought the thing and threw it in and then realize they're not happy with it, or they may have bought several things and then thrown them in and they're not happy.

I do a lot of, you know, like I said, rescue missions where they're using or not using a software. They purchased it, it's kind of gathering dust, they've gone back to spreadsheets and they're willing to try again, right? To do something similar or the same.

So yeah, I agree with you. It is that quick fix. But I think people understand, especially if they've already had a quick fix that didn't work, that you really need to think these things through. It's not just a simple, "oh, let's go buy the software, it's going to magically solve all our problems." I don't feel any software, any one, even some of these ones that claim to be, you know, your one software for everything... there are still areas where you're going to want things to be slightly different, or it's not going to do every single thing that you need done.

Peter [26:58]: Yep, I would agree with that. There is no ubiquitous piece of software that does everything that everybody needs in the way that everybody is going to want it done. Maybe we'll miraculously get that someday.

So I think we're getting to a point in our conversation where we sort of want to wrap this up, put a little bow on it for our audience. And at this point in the conversation, we ask each of us to come up with a point that they'd like the audience to take away from the conversation. So as our guest, Deb, would you like to go first?

Deborah [27:26]: Sure. So I think for me, the most important point is that you need to consider what you're trying to solve for before you immediately put a solution in place. And that's an area I can be helpful in.

Dave [27:38]: Dave? Right. So this is the messy middle that Peter and I have talked about many times. And I really, Deb, appreciated the insights you brought in, especially from that sort of legal perspective as well. That's a different background, certainly to what I've experienced.

What's floating around in my head is the conversation around mediation and that buy-in and exploring how much of that discussion is buy-in and how much is influence over the final product or service that might be being built. And that one is something I'm going to take away and just keep thinking about because I think there's a lot more to uncover there as well.

Peter [28:11]: I think for mine it's the... there are a lot of analogy pieces you're describing there. I'm often looking systemically at how some of these things are done in organizations, even the process of procuring these products and what that looks like and how that flows through the organization.

I thought it was... remembering that focus on the outcomes and ensuring you have a way of measuring them so we're not getting stuck. I think that's a good point to take away from that. So we're not just looking at cost and time, but we're looking at hey, is this actually going to do what we want? Are we going to get the value we want from this? I think that's a very good takeaway.

Well, I'd like to thank both of you. As always, it was a fascinating conversation. Thank you so much, Deb, for joining us today. And thank you, Dave, as always. And with that, we'll wrap up. Until next time.

Deborah [28:59]: Thanks so much for having me.

Dave [29:00]: Thanks a lot, Deb, for the conversation. Peter, as always, a pleasure.

Peter [29:03]: You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.

Claude es IA y pu