Episode 41 Transcript

Banoo Behboodi: Welcome to the Professional Services Pursuit, a podcast featuring expert advice and insights on the professional services industry. I'm Banoo and today I'm back for part two of our conversation with Shane Anastasi. If you miss part one, I highly recommend you go back and listen to that one. Lots of great insights from Shane and a great framework for what we're gonna dive into today. Shane is an author, speaker, entrepreneur and professional services strategic advisor. He's also the CEO and founder of PS Principles, an organization focused on helping service providers and their customers achieve more successful outcomes from implementation projects. Shane, I'm really looking forward to this part two of our conversation to dive into project change management.

Shane Anastasi: Yeah, me too Banoo.

Banoo Behboodi: This time we'll be getting into an in-depth conversation on pitfalls and best practices related to managing change within a project. And what the listeners can use as steps and best practices to manage that change, the communication around that change and make sure that they come out of it unbruised hopefully, and uninjured. So let's jump in and talk a little bit about the biggest problems that you see arise from poor project management, and subsequent changes in how you coach your clients to properly manage them.

Shane Anastasi: Yeah, thanks Banoo, it's actually interesting. So the first book that I focused on, that I wrote was the Seven Principles of Professional Services that really just taught consultants the general kind of demeanor about how to get in and lead projects. My second book that I'm putting together now, which we're also developing a class on, is called Project Dynamics. And what we are looking at in that class and in that book is the true dynamics that are at play when you are trying to get a customer to change the project's constraints. It's about lots of different dynamics throughout the projects, but a very big focus of it is how do you change the customer's mind to accept the change that is occurring in the project? And so the first place to start with this is as a project team, to not be ashamed that changes occur. We generally have this kind of mindset that because we gave them a quote because we wrote an SOW, and because we learned something that wasn't in that SOW that we are at fault. And what we have to start to understand is that projects are a journey of discovery.The SOW was estimated and built off of our understanding of what the client told us that they wanted, and we interpreted that and made an estimate.

Now we know those estimates are gonna be wrong because they're never a hundred percent correct. And so just because we learn something new as the project progresses, we didn't make a mistake, that's what a project is. It's learning the true reality of what the customer wants in detail. And so the first step in change is actually embracing the fact that we didn't make a mistake because there's change. Now sometimes we do make mistakes and that causes change, and that's a little bit different. If we did something that was done incorrectly or we took a piece of information and we did something wrong with it, then we are at fault and we should fix it. But for the most part, because a customer comes back and tells us something that is different than what we knew at the beginning of the project, the fact that that changes the constraints is not something that we should hide from. In fact, it's something we should take back to the client and say, you have now changed our understanding of the project, and they'll say well you should have known from the beginning, you asked us these questions and we told you the answers. And so it's your fault because you didn't interpret it correctly. And I always find that an interesting argument because what's actually interesting in an estimate, is it more important what the customer thought they were getting from the estimate or is it more important what we thought the estimate represented? And so what we've gotta learn to argue is that what's actually most important about the estimate is what we, the service provider thought we were building with that estimate because that's where it comes from. That's the origin of it. The client took that and then had to interpret that to think, oh, here's what I'm getting for that estimate. And so it's learning to actually argue these nuances with customers that actually helps you build a better argument for change management and achieving change orders on a project.

Banoo Behboodi: I know in the past, in my career, I have been in a position where I have anxiety literally going and having to approach the client around having that change request process, feeling like a victim more so than the person who's in a position of power and understands and collaborates and cooperates with the client to get to really what their outcome is. And things are evolving and you're learning more and the client is learning more, and therefore the change. So I actually love that perspective and thought. But to that point, I know we talk about governance, right? All the three principles of your budget, your scope, your timing, of all the constraints around projects and the governance we put around based on PMBOK and all the best practices out there to manage a project effectively. And yet many times projects are not leading to the outcomes expected. There is scope creep, there is additional costs, whether that is born by the client or it's not, which then eats away at a margin if there was any margin at all. So where are things going wrong, is it the governance? Is it the communication as you were hinting towards?

Shane Anastasi: So the first thing that we want to actually blow up is the success measure that people like PMI wanna report against every time they release their pulse of the profession. And look, this is what I think is really interesting about what we do. Pick up any report, it doesn't have to be PMI, it could be the Standish Chaos Report, whatever it is that you want to pick up. Basically what it says is that we are crap at doing what we are meant to be experts at doing, which is getting projects on time, on budget, and on scope. It says 70% of projects don't make it, 50% are a total waste of time, whatever it is. None of the stats say we're awesome at what we do. Now, I find that to be incredibly demoralizing. If I was like an X-ray technician and I was this bad at doing my job, I'd get fired. We are professionals, but the definition of success that we are chasing is somewhat unachievable. Projects change, scope should change. We should add scope. We should cut scope out. We should double the price of projects if they're not correctly constrained enough at the beginning. A project's success is not defined by whether or not we hit its constraints. The constraints are going to change.

So what we need to do is to define for ourselves an achievable project success, which to us when we've done it because we've spent a lot of time doing this, and we did this when we started the CirrusOne company, where we were putting all of this stuff to the test as a pure play consulting company. We said we are going to be, and a lot of people do this when they start companies, they look at their big, hairy, audacious goal and we decided that ours was that we would be the greatest implementers of professional services projects in the history of the world. And of course that's an insane kind of stupid goal, but we said if it's gonna be big, hairy and audacious, that's what it's gonna be. And then we hit a roadblock: how do you prove it? There's no statistics, there's no objectives. Like let's pick on Kantata, Banoo, what is your project success metrics? Nobody knows what they are, they're not objective. And so we kind of realized that as big and hairy and audacious as that goal is, there's just no way to measure it. There's no way to measure our success against another consultant company's success.

So we decided to try and think about how you would do that. And we came up with something that's more objective than on time, on scope, on budget, but you could still argue there's some subjectivity in there. But basically it comes down to trying to achieve three things in every project, and that is to gain a customer reference, to hit your financial targets, whether that be profit or loss, to hit your financial targets and to not burn out any consultants in the process. And if you can achieve those three things, that's a successful project. Now you can say, well, did you get the customer's outcomes Well, here's the problem I have with outcome based kind of ideas around project success. We've implemented a lot of really good solutions for customers that just don't run very good businesses. And so you've gotta really start thinking, if in 2001, Sony had asked me to implement a sales system that would help them sell more, is there any system that I could have implemented that would've stopped them losing market share to the iPod? I can't look at outcomes, outcomes cannot be my determining factor.

What can be is that when the customer looks back and you say to the client, was our service of value and would you recommend us to other prospects? If that answer is yes, then we've done a good job and I'd love for it to be more objective. I would love for it to be did you get your 5% margin increase? Did you sell 5% more per quarter? I would love for that to be the measure, but nobody has those measurements, nobody keeps those measurements, nobody really delivers those measurements back to you as the service provider because the customer never talks to you six months down the track to tell you how their business is going. That stuff just doesn't happen. So to chase a realistic goal, get a customer reference, hit your financial targets for the project, and don't lose any consultants in the process, and then if that's your measure of success, now you can start managing change without worrying about whether or not it's going to affect your metrics for on time, on budget, on scope.

Banoo Behboodi: We both agree that you've gotta be intentional and understand the outcomes the client is after and have that guide your project delivery. I totally agree with you in that, should the project's success in itself be measured based on that outcome? It can't be because by the time the project is finished, the outcomes may take some time. There's other contributing impacts to that outcome achievement or not, but you would argue that based on what you guys came up as a success criteria, the referenceability of a client in itself, what else is more telling than that, right? Is the referenceability of the client. And I love the associate part that you've built into that, the fact that you're not gonna burn out anyone. You're going to make sure that the team delivering it is also coming out of the project delivery happy and healthy.

Shane Anastasi: Surefire way to ruin your organization, right? A surefire way to ruin your team is to have them burn out on projects. And what we find is the most difficult, largest projects are the ones that burn out consultants fastest. And so paying attention to that and wanting to either identify that it's happened and find a way to somehow maybe reel it in a little bit or give consultants a breather to try and make up for whatever burnout has occurred is really critical to the long-term success of a PS team. But to get back onto the idea of change management, we've set the general idea now of a project so now we can change it without upsetting our success measurements. And I think that's really, really important because that creates apprehension, right? And I don't want to go back and change the project because if I do, then I'm no longer hitting my original objectives. Take that away. That's a really bad mojo to be carrying around with you.

So one of the things we did at CirrusOne is we actually told all of our consultants from day one that, on time, on budget, on scope does not exist here. Do not go to a project thinking that. And then that gets back to what you were saying before, the apprehension and the anxiety that you felt and I felt, talking to clients about change in the middle of a project, that starts to ease a little, but that never goes away. Telling a customer they have to pay more than they had budgeted, that hurts. Whether you are you, me, or anybody else in this industry, you get anxious before doing that. All that this does is it kind of helps you understand why it occurs. It occurs because this is a journey discovery. Now, how and when do you implement change? Here is something that we decided to address.

One of the things that I've been looking at for a long time is this idea of what we call project dynamics. Why do projects follow the process that they tend to follow? And one of the examples that we can look at is why do projects tend to kind of go all the way through design, why do they spill design in the build, and then why does nothing happen until the end of testing when everybody realizes that the customer didn't get what they want? And then the project really escalates and fixes all the things it needs to it the 11th hour, and of course now we've lost a ton of margin. The customer's kind of annoyed because there's been a lot of rework at the end and a lot of missed expectations. Why do projects follow that patent 13:30? One of the things that we looked at was this dynamic within projects, which kind of helps us realize who has the power in different stages of a project. So let's look at it this way. When you start a project, there is the design phase, and what's happening in the design phase is you are actually receiving information from the customer so that you can build the design. And you receive that information, and in most projects what happens is the customer isn't actually ready to give it to you. In fact, they either give it to you poorly or they give it to you slowly, and that has a massive impact on the budget that gets consumed for the design phase. But of course, we gave the project manager the whole budget, and so the design phase kind of spills into build while we're still receiving information from the customer, but consuming the budget we were going to use to build the solution.

Now, at that point in time, there is a shift in dynamics. I'm now giving the customer the solution and they are the one receiving the solution from me. You can see that dynamic has switched. I was receiving information from the customer, but now they are receiving the solution from me. We worked out that there's a very simple piece of leverage that gets used in these two different situations, and we call it receiver's advantage. So the easiest way for me to create leverage with somebody is if they give me something and all I have to do is look at it and say that's not what I was expecting, and the minute I say that, I create leverage with that person. Now, it might be completely false leverage, it might not really exist, but I can easily create the perception of it simply by uttering those words.

And so what tends to happen in a project is we don't use receiver's advantage throughout the entire design phase, we actually just let it ride. And so we don't get what we want from the customer, we don't get the requirements that we needed on time. We don't get the participation that we needed. And then of course, the design runs long. What we decided to do at Cyrus was to not give project managers the entire budget, we just gave them the design budget, and that meant that the project would run out of budget and if it ran out of budget before a design was actually achieved, then it would automatically escalate to the sponsors because we had no budget left in the project. And we forced what we started to call stage budget control, which meant that now we were having the conversation with the customer about what changed. But guess what, we had the receiver's advantage. The reason we haven't finished design customer is because we didn't get the list of users that we needed. We didn't get the list of logic for the business process that we need to implement. We didn't get you to participate . We don't have people on your team that know what they're talking about or whatever the issue might be.

Now, when we started to go through this the first few times, of course the customer's general response is, well you're the service provider, you need to absorb it. But because we shorted the project of the budget for the build stage, and we have that placed somewhere else in the system, we don't really have a choice here, we have to fund it. And so now we start having the conversation about where is that funding going to come from and why do we have to fund it? It's not because we made a mistake as a service, it's because we couldn't get the information from the customer. Now, did we win every one of those and did we get a change order that the customer funded? Of course not, not every time, but I would say we were probably in the high seventies or even maybe in the 80% where we would get a fully funded finish to the design phase funded by the customer. Now, we did all sorts of things to kind of make that happen. So there's lots of other kind of techniques that we can go into there, but the general idea is by forcing that, we then went into the next phase of the project with two things.

First of all, understanding that now the customer has receivers advantage. They are going to use it. So there is a way to nullify receiver's advantage, and that is by proactive leadership. So by proactively leading, the client doesn't feel compelled to use their receiver's advantage, they basically take your prescription because you've been leading all the way up until this point and you keep leading and they will follow. But we also have to recognize that now we have a build budget that was not cannibalized by the overflow of design. And now we actually have a better chance of delivering what the client wants during that phase. Now, of course, you could still discover things that create change, but what we found is that once you got to that point, we had a plus minus 5% variance on all of our post-design budget estimates. And to me, I find that to be incredible. What that tells me is not that we are great at executing, our engineer are brilliant that if you give them a stable design, they will execute it in the time that they estimate it. And I find that to be something incredibly interesting to me. Where we blow projects up is in our inability to manage the change control during the design process. When funnily enough, we actually have the receiver's advantage.

Banoo Behboodi: That's very insightful. I totally agree with you. So tell me Shane, Cyrus obviously was a business practice of yours, but it was also a hypothesis being proven out. What did you find out in terms of the company, the success it had, putting into practice a lot of what you discuss in your book.

Shane Anastasi: Yeah, I think the first thing that really hit me was I couldn't believe how much I was learning. I remember having a conversation with Godard Abel who was the head of Steel Brick at the time before Salesforce bought it, and he asked me, he said, what's it like to be trying to live out the hypothesis? And I just said, with all honesty, I've learned more in the last 12 months than I think I probably have learned in the last five years. We deliberately went out to do these things and in deliberately going out to do them, kind of learned how they worked. I had no idea how they worked up until that point in time. And one of the great things about the two partners that I had at CirrusOne with John Pora and Eric Rusch was they were 100% supportive. And so we just decided that wherever the mold needed to be broken, we would break the mold and maybe it would work, or maybe it would be a spectacular disaster. But either way, we were gonna take the chance to find out. And so what we learned was, first of all, that proactive leadership works. The customer wants you to lead them, but we also worked out that in about one of 75 customers goes at it, you're going to get a customer that doesn't want to be proactively let, you're going to get a customer that just wants to vendor manage you. And there's some tactics for that that we had to create, but it's about a 74 out of 75 times the customer wants to be proactively led. We learned that you could push the receiver's advantage, you can delay it, you can move into the build phase, and if you move into the build phase with this proactive leadership mentality, the customer will follow up until the point at which they say “enough is enough, I want my pound of flesh.”

Now the beauty of understanding that is that if what you've done up until that point is preserved a truckload of margin, you now have a truckload of margin to spend on that customer to give them what they want and not blow the constraints of the project. So what we learned, which is just a fascinating piece of learning, was that if we proactively led projects, we would conserve enough money to buy our way out of projects at the end when the customer finally decides enough is enough, I've taken your prescription, I've taken your leadership, you've given me a system that now looks completely different than what I thought. And I understand why and I'm not mad about that, but now my bells and whistles. Okay, well let's give you a couple of those, we have the budget to do it. And what we learned, this was a fascinating discussion when we finally acquired a discussion with our acquirer. We had the senior implementation managers sitting around a table, and I don’t know why this came up, but they said to us what part of the project to you is the most difficult. And they said, for us it's testing, just can't get outta testing.

And we said that's really funny because for us it was design and I just explained why, but testing for us was a breeze. I mean out of 174 projects, I can think of one that had testing problems because for the most part, by the time we got to testing, the customer was on board with what we were doing. And I think that's an important dynamic that we don't pay attention to. Rating the customer for testing, making sure that they have their admins, making sure that they're executing their own test cases. One of the things that we look at at Project Dynamics is customers have a tendency in testing to try and play a three card trick. Now that three card trick is that when you give them the solution, which you have now developed the specification that they helped you build, what they tend to do is to actually look into production and say what does this system need to look like so that I'm comfortable putting it into production. But that's not what they're testing, what they're meant to be testing is did you build what they agreed that you should build? And if they didn't give you a good specification of what will work in production, well then there is gonna be a disconnect, but it's not your fault. And again, that comes down to understanding what the customer is actually telling you when they start bringing up issues during a testing phase so that you can actually negotiate change management better.

So we talked about how you negotiate change management up until the end of design because you have the receiver's advantage. After that, you actually have to start paying attention to the dynamics that are occurring inside of the post-design phase because there are different pieces of leverage that you have to identify and use. And if you don't identify them, the customers already identified the leverages they're going to use. Customers are actually very good at doing this, and that's because we want the greatest possible outcome for the least possible price as a customer, and we're entitled to do it. None of this is, unfriendly, everybody uses these bits of leverage as a buyer, as a user, as a consumer, we just haven't learned how to use them as service providers or how to push against them when they are used on us, and that's really what the new class is focused on teaching. The fact that when you are in testing and the customer is now saying to you, this won't work for me in production, it's actually irrelevant. Testing is about testing did the service provider build what was agreed in the design document, but yet teams get very easily confused by the client to thinking oh, I've gotta now go fix it for free because it's not what they want in production.

Banoo Behboodi: I know you mentioned that you're working on a new book, I don't know how much you can speak to the new book and what it's about, but is a lot of the concepts you were just reviewing covered in the book with more details?

Shane Anastasi: Yeah, for sure. So the book is called Project Dynamics, the subtitle is probably going to be something along the lines of the invisible forces that push projects forward, because they push projects forward maybe in a successful way, maybe in an unsuccessful way. It's actually a project management focus book, and it's up to us as project managers to work out how those forces are either positively or negatively impacting the progress of our project. And if we can reel them in when they're negatively impacting the project, that's a win. And if we can use them to redirect the project, that's a win as well. But to do that, we actually have to work out a very difficult area for projects and project management to understand, which is how do projects decide what direction to go in and they decide what direction to go in based on leverage and consequences and understanding what the consequences are for actions. And making sure that the parties, or parties, the customer, the service provider, even the prime, if there's a prime in there as well, understanding what the consequences are of every decision we make and do we accept those consequences as we move forward. That's really the focus of the book, teaching project managers how to really look at what's happening in a project despite or beyond what they might already have been taught through project management certification.

Banoo Behboodi: When are you expecting it to be out?

Shane Anastasi: Oh, the book will be out in second half of this year, probably July, August timeframe. The training should be ready in a few weeks.

Banoo Behboodi: If the audience wants to reach out and get access to the book, where can they find you?

Shane Anastasi: You can find us at psprinciples.com, you can just send me an email at info@psprinciples.com and we'll always get back to you. You can get me on LinkedIn, anywhere like that, we can get moving.

Banoo Behboodi: Shane, I wanted to give you this last chance before we call it a podcast end, there was one hint, one very tangible tool in negotiating change orders, what would that be from your perspective?

Shane Anastasi: Yeah Banoo, that's a great question. What we would probably recommend is a technique that we've developed, and I'm sure maybe there's other places where you could find something similar, but we call it the self-imposed ultimatum, and the general idea with getting a change order from a customer, is to get them on board with the fact that they are the one causing the change or that the change order is required as a result of their actions. And so what we've created is this sequence of events that as project managers you need to manage. So the first one is that something gets missed, the event occurs that creates unexpected change or unexpected cost, unexpected effort that needs to be expended by the project. Now a lot of project managers, even if it's small, we'll say, well I won't mention it. And they'll absorb it, but they also won't tell the customer that they're absorbing it and so what happens is they lose the leverage. Me absorbing something is for you is leverage, right? Hey, don't worry about it Banoo, I've got it. I'll absorb it, I'll take that cost. Now you now know you owe me one. That's a piece of leverage. Now, project managers don't use it that way, but we recommend that they should. We recommend also that they should say to the customer, a consequence was created by you missing this date.

Now, let's say I needed information from the client by Wednesday, right? The customer doesn't give it to me, so I go back to the customer and I say look, you not giving me this information in the right period of time has created a consequence. That consequence is that I now have people here doing other work and we are going to keep doing work, but I'm gonna have to absorb the impact of getting this information late. It's gonna create some rework that we're gonna have to go back to do whatever it might be. I'm okay with that. I want to invest in your success. And to be honest, it's just a few hours, days, whatever it might be. But here's what I need to know, when will you get me the information that I need and I can make a decision on how much of this I can absorb based on that information?

Now what that does is it really hands the reins over to the customer to draw the piece of reason. The reason this comes back to bite us later on is because we don't know how long the piece of string is, how long is it going to be until the customer gives us what we want? So we say to the client, at what point can you give me this information? And let's say the customer comes back and they say well, by Friday I will give you the information you need. And we say in return, oh, by Friday that's great. I can absorb Wednesday, Thursday, and Friday, but beyond that, I'm going to have to charge you for it. Now what you've got is something that the customer is now self-imposed. And moving forward, they know that if they don't get you the information by Friday, you will give them a change order. And once you give them that change order, there really isn't much argument from their perspective. They would say well, I don't owe it to you because this is your fault. They have to accept it's their fault. You've walked them into a self-imposed ultimatum, right? By Friday, I will give you this so that you can stop absorbing the cost of me not giving it to you on Wednesday. And by the time you get to Monday, if they haven't given you what you want, you are going to get a change order. There's a very high likelihood that you'll get it.

And why we teach this is because this, I think, is the most customer-centric way to actually go about achieving that result. Be willing to invest, absorb the customer's mishaps when you can, but absorb them with a limit. Where we go wrong in projects is absorbing the impact that customers create without a limit, and we call it turning off the spigot. You've gotta make sure that if you give free hours, they're limited, they're numbered, they're never copious, right? They're never unlimited. If you are going to absorb their impact, it's because projects are constrained budgets, and so the self-imposed ultimatum just basically gives you a method of doing all of this inside of a constrained environment so that it doesn't get taken advantage of and that it doesn't run away outside of your control.

Banoo Behboodi: You've touched the surface, but given us a lot of great ideas on managing change, and so I do appreciate your time, but I'm not gonna let you go until I ask my second personal question, I guess third in your case. And really, what I wanted to know is if you can tell us about someone who's been very influential in your life, and has helped formulate who you are, where you are in your career today, and what made them effective as a mentor?

Shane Anastasi: Yeah, it's really interesting. I would have to go way back to two managers that I would probably say were the largest impact on my career. And this is one of those things that we try to get through to PS managers too, which is that never underestimate the impact that you're gonna have on somebody's career because whenever I get asked this question, it's always a direct manager that I had. And I think that that should explain to other managers, there's a big chance that the people that are in your team, you are gonna have either a wonderful impact on them or potentially a negative impact on them, and we want it to be positive. But the two that I would point out is my first boss at IBM, Jeff Wells, who was just incredible at taking in a bullheaded student from college and telling him to calm down and to look at the big picture instead of getting distracted by the detail. I just cannot emphasize enough how important that's been in everything that we do.

I think the second would be a woman that was my manager in England, Julie Fisher, who really taught me what a sponsor should do on a project. And she was a bank employee, so I was a contractor helping the bank do an implementation. She was kind of my boss as the contractor, but she was the overhead, the program director for this big massive change that the bank was going through. My goodness man, she was like a rock, she made decisions, she was sturdy, she was stable. She did everything that program sponsors should do, which was kept a massive, I think we had 130 people in the project across three different streams. She just kept everybody aligned, everybody focused in the right direction. And I think that just taught me the importance of control, you can be flexible, you can do it when you're implementing change in an organization. When you're implementing something as large as a 30 million project, you've got to have some element of control that keeps everybody singing from the same hymn sheet, walking in the same direction, and integrating together as a unified team. And I think that she showed me how to actually build a high performance team the way that she did it. She was actually incredible. So those two people, that's what they taught me. One was about, stand back, look at the big picture, but the second was that if you don't have a method for keeping the team together, it just disintegrates right in front of your eyes. Keep everybody aligned and keep everybody moving in the same direction.

Banoo Behboodi: Love it. It's been fun, I appreciate your time, hope we can do this again, have you as a guest on our podcast. As always, we'd love to hear from you, from our listeners. If you have any follow up questions for myself or Shane, reach out at podcast@kantata.com. Thanks again Shane, really enjoyed our conversation.

Shane Anastasi: So much for having me again Banoo, really appreciate it.