Episode 40 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 joined by Shane Anastasi. Shane is an author, speaker, entrepreneur, and professional services strategic advisor. He's worked for giants such as IBM, Singtel, and Salesforce, as well as play significant leadership roles in a few successful startups. He's currently 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, it's an honor to have you on the show.

Shane Anastasi: Thanks Banoo.

Banoo Behboodi: I can't wait to get into the conversation. It's obviously based on the background I just ran through, there's gonna be a lot of great insights and experiences that you can share with the audience. I'm excited to dive in. Now, there is a lot we have to talk about so we'll break this up into two parts. The first part, which is this session, we're going to jump in and really understand a little bit more about PS Principles and some best practices, overarching practices. And then in the second part we'll actually dive in and look at the whole change management process and what are some of the best practices around managing change. So let's just dive in and get started. Can you tell us a little bit about PS Principles and how you decided to set up that company and what it is that you do for the professional services industry?

Shane Anastasi: Yeah thanks Banoo. PS Principles is as a result, I guess, of my own experience in the industry and something that after 10 or so years in it, I realized. An area that wasn't being addressed. And to put it simply and blunt, it's the fact that we don't really have a degree for customer facing consultants. And every consultant that we would hire would be an expert in something other than customer facing consulting. And so I wanted to find a way to, if we could, accelerate the learning capabilities of these kids that we were bringing in to our software companies or our consulting organizations so that we could teach them what it means to deliver a service in front of a demanding, paying customer. And essentially, PS Principals focuses on doing that training in consultants on how they should be customer facing for project delivery, but also working with services organizations, whether it be embedded in a software company from a perspective of implementations or whether it be a pure play consulting company. We work with them on how to structure and get the most out of their professional services teams.

Banoo Behboodi: That's very interesting because very often when you look at skill sets and the teams are looking for capabilities, they're looking for project management, like are you PMI or are you a PMP certified and are you part of the PMI? But it's fascinating and extremely critical that we also have that consulting side of the skill set, right? How do you effectively consult, how do you effectively engage with a client? So what are some of the main elements that you consult and what are the key problem statements that you're trying to address with your client.

Shane Anastasi: That's a good observation and a great place to start Banoo. If you are, say, a project manager in this industry or you're in the services industry, one of the things that people will talk about is the certifications around becoming a PMI certified project manager. And I have nothing against these organizations that present or create these certifications because they’re valuable, but what they don't focus on, and because their market is so broad, they don't focus on customer facing project management. And if you take the idea of a project, which within PMI is just any endeavor to go and do something, and you go do that in front of a paying customer, it changes the dynamic of how that should be managed. It changes the dynamic of leadership. It changes the dynamic of customers wanting the greatest possible outcome for the least possible price. And they're entitled to want that, but now we've got teams in there that don't know how to deal with this pressure. And so what we teach them to do is to deal with the pressure. I mean, you can look at professional services from two levels. You can look at the stuff that we do, which is down at the project delivery level. How do you deal with the customer in this particular scenario when they're demanding that they want free hours or that you haven't delivered what they want? And then of course, we can look at it from the strategic level, which is, what is professional services to your organization and what role do they play?

One of the really important elements of professional services is that inside the software companies specifically, we are the last group that gets created. We create sales, we create product, we create engineering, we even create support. And then what happens is the first iteration of professional services is really just the development engineers going out into the field and making the product work for the customer. Getting it to work in the field so that we can at least claim that we have it live at certain places. And eventually that morphs or it matures into the idea of having a true professional services team. And so we stitch that together as the company grows. And we don't really care about making money, we just really care about trying to get the product implemented in a consistent manner so that we can continue to grow. And ideally, we kind of talk to software companies about this a lot. Ideally, we wouldn't need professional services in a software company, the software would just implement itself, but there's no such place, right? I mean Kantata anywhere, I mean if we could get this to just work for customers, that's the way that we would do it. But we become a necessary evil, which is just a really weird way to kind of look at your own industry. But if you weren’t needed, if it was possible to not need you, well then you wouldn't be needed and it would be okay. The software would just work, but it doesn't work that way. So we have to come in and help clients understand how to either implement, configure, set up, install, whatever it is, the solutions that they want.

So that's the first iteration and we're not really concerned about money, and a lot of investment firms will look at startups and they'll say, let's not make money on professional services because that's the easy thing. Let's not argue with the client about profit and paying for hours and all that kind of stuff. But then you accelerate that to a 70 person consulting company or implementation team, and suddenly you realize that your p and L is just drained of money because of all these people that you have in your organization. And it only takes services people to rack up a million dollars in cost per year. So it adds up really quickly and then they suddenly turn around and say this is no longer a strategy and we can't just run at cost or we can't be making a loss on services. They have to pay for themselves and they have to pay for their growth. And so then we move into this, I think, of course correct when we do that and we go down the avenue inside of a product company, and it becomes more important for services to bill ours than it is to get the product live and I think that's a mistake. And then eventually, as the software company matures, and hopefully as the services organization matures with it, we settle down to what services truly should be for a software company, and that is the primary avenue to secure recurring revenue. And that means getting the customer live. And we try to make sure that when we teach our organizations or we work with organizations, we get them to adopt the mindset that professional services is simply the gateway to turning on or securing revenue and that's the focus. One of the things that we talk about is that when sales closes a deal, especially in a SaaS environment, we don't really have a customer, we have half a customer. We have a customer that wants to use our software, we don't have a customer that's using our software, and it's not until they're using the software that they'll renew. And so services don't necessarily always step into that role of understanding they are the gateway to securing that revenue. And I think we don't help ourselves in this environment a lot either because if you make a comparison between what we do and celebrate when we close a sales deal, we ring the bell, we send out emails, and we all slap each other on the back and high five each other.

And then of course, when we actually get the client live, we might send out an email and that's about the best that we do. And I think one of the things that we need to do is to find a way inside services to celebrate our own victories within the organization so that we actually recognize what it is that services are doing. And I don't blame any other department for the persona that we create inside of software companies because I think it is primarily our fault for not stepping into our role as opposed to other people pushing us about. But when I've gone from company to company throughout my time, professional services do tend to kind of act like the ugly stepchild. And it's kind of a little bit demoralizing sometimes to walk into these organizations and see that professional services is kind of like the whipping boy, and it's just not a good situation for them to be in.

Banoo Behboodi: Yeah, I love the distinction you've made around embedded services versus consulting organizations because if it's fee for service, you're clearly have positioned your consultants. That's what you do, that's your product, selling your services. But as you said, in an embedded service software company, it's not intentional, it's a byproduct; services is a byproduct and therefore a great point. Successes are not celebrated in the same way necessarily and so I love that distinction. So it seems like you guys focus mostly with embedded service because they need more of that skill set around consulting for all the reasons you mentioned. And so how is it that you guide companies, embedded service organizations to start becoming more profit-centric, to start becoming more consulting oriented customer facing and impacting, type of an organization.

Shane Anastasi: Yeah, and it's funny, other than the original intention of the organizations, whether it's embedded or it's a pure play consulting, you can kind of adjust what your primary objective is, depending on which of those that you are. But once you get into the customer facing project, it all pretty much becomes the same. And the role that we try to get those teams to adopt is we would create a persona around it, but it's called the project Sherpa. And the general idea is that you are the paid guide leading the customer through a dangerous environment to achieve the best possible outcome that you and they can achieve given the environment around you. And there's a lot of qualifiers in there, but we have to really understand what a project is to be able to lead the journey successfully.

One of the things that we tend to focus on in the industry, which is an incorrect way to look at it, is that we focus on things like making sure that we're on time, on budget, and on scope. That's a distraction. We focus on things like customer satisfaction, and one of the real values of project consulting or project delivery is not getting the customer to love you during the journey, it's getting the customer to love you after the journey is over, and that's what the focus needs to be, and you don't get that outcome if what you're doing during the journey is trying to pamper them or to not tell them the truth or to make them happy because they want something and you know you're just gonna give it to them for free. You make them happy by leaving them with an outcome that they see as value for money. And so what we focus on is, we feel that in the industry, people are really in a passive mode when they execute projects. They go to the customer, they take the sow from sales, they go to the customer and they say, what do you want us to do?

Sales said we're gonna do this, so let's just start doing that. And so all of a sudden the customer comes back maybe towards the end of the project and we realize we're completely misaligned. Well these misalignments could easily have been identified earlier if we had hit the project running as leaders and said why do you want to do this, wouldn't it be better if you did that? Help me understand where this plays as a role in your business process and why it's important to you. Why do you think that this is a key to your competitive advantage? And maybe what we should be using is the out-of-the-box product functionality because it's going to be more stable and better for you in the long run. We just don't tend to want to challenge things as we go through projects, mainly because we feel like we're not supported. But like I said before, I don't think it's other departments not supporting us, it’s us not standing or being confident enough to say this is the way we recommend that you should do it.

Banoo Behboodi: Yeah and I think you emphasize outcomes repeatedly through what you just talked about, which is a critical part, right? Understanding the desired outcomes longer term during the implementation as you're executing your services is going to ensure that the output or the deliverables are in conjunction and on paths to getting to those outcomes. So how do you consult, if you have any specific examples of this, of your clients to actually do that effectively? Have that communication line to the clients, to the project, to clearly identify, document, and make sure everyone is aligned on the desire, long-term outcomes, and therefore then start tailoring the project delivery to get to that outcome.

Shane Anastasi: Yeah, down at the project level, it's very important that we do a couple of things. One is to not get blindsided by the concept of project management. And one of the things that we do as peers principals, is we train the entire organization and we do that because projects are made up of members. And there's only one project manager, and that person can only see so much of what's happening in the project. And the scope creep that we find in projects isn't always happening at the project manager level. Maybe it's happening with the architects, maybe it's happening with the testers, maybe it's happening with the business analyst. It happens all over the place. And if we don't have a common way of looking at projects to understand what it is that we're doing on projects, the importance of baseline control, the importance of making sure that we don't just say yes to things because the customer pulls us aside in the meeting and puts pressure on us all of a sudden to do things that we shouldn't. The general idea is that the team has to manage the project. You know, we say it takes a village to raise a child, it takes an entire project team to implement a project successfully. And so that's the view that we take to break that mindset that it's one single person's responsibility within our project team to make this project work. It's actually all of our responsibilities to do it. That's the first thing that we do to kind of broaden it out.

The second thing that we do, is that we focus on this concept of empowerment and disempowerment. And the general idea of that is that there's this kind of weird misunderstanding that we have about how project management works. And what I mean by that is that project managers seem to adopt the role of owning the project. And the problem that we've got is that project managers, as they work for customer facing projects, don't actually have the authority to change the project's constraints. They can't just change the constraints. What they have to do is escalate. But when they do escalate, what happens is people get annoyed. Oh, why am I dealing with another escalation? And so one of the things that happens is as they escalate and as people get annoyed with escalations, the project managers begin to think, well, why bother escalating? And so now what we have is a lack of communication. So what we work on is embracing the idea of escalation, we want to escalate proactively. One of the things that we teach our organizations at the manager and sponsor level is to ask for escalations. Why have I not received any escalations? Why are you not escalating anything to me? I'm sure there's something that we need to be talking about. And then that walks into the idea of really consistent and somewhat regimented sponsor management that doesn't occur enough on projects. And to me, if you had to change one thing today to make projects more successful, it's to elevate and become rigid in your sponsor management. And I mean really rigid down to the point that you understand that project managers don't own projects. Project sponsors own projects because they're the ones that signed the contracts. They're the ones that set the constraints.

Inside of the customer environment, the project sponsor is the only person who truly knows what done is going to look like. They're the only one that has the vision of this project in its completed state because that's the person that made the promise to the organization about what this project would do. Inside your own organization, the service provider's organization, you are the person that owns the P&L that this project reports into. And so you have to own and understand where this project is going to finish. And you have to help the project management team discuss with the client the issues required to change the constraints on the project. And one of the things that we really focus on is this idea of proactive sponsor management, which means that if for any reason on a project your sponsors don't turn up or don't go to a sponsor review meeting, that's an automatic escalation. I mean that should be a red flag status for a project. We went to have a stakeholder meeting and the sponsors didn't turn up, whether that be the customer sponsor or the service provider sponsor because right now, as soon as that happens, you don't know if you have permission to keep continuing with the project as it stands.

Banoo Behboodi: Talking about project leadership and success, I know you talked about the importance project sponsorship and having them in place. How do you measure, what are the key KPIs that you suggest be managed and monitored through the project, and how do they get tied to the intended outcomes for that implementation project?

Shane Anastasi: So there's kind of a couple aspects there. One, on the sponsor management side, it's really simple. Are you having sponsor meetings, like are you meeting and doing reviews with the sponsors, and if you are, is everybody present? And are you actually able to discuss with the sponsors where the project is at, whether or not the budget is sufficient and whether or not the project is moving in the right direction. When you focus on that and you have those conversations with the sponsors, you're doing everything that you can, you over metro size. You can kind of look for metrics in there that don't exist, but for the most part, it's are you doing this? And we have a way of measuring that in most of the kind of solutions that we've implemented, either myself personally with inside my own teams. But we usually will have some kind of a tracking mechanism that will immediately escalate a project that stops or isn't having sponsored meetings.

The second thing to look at is how do you measure success for a project? And this is really important and I kind of touched on a very important element that we think success means for a customer facing project in this industry. And that is on time, on budget, on scope. Well, the problem that we have with this general idea is that everywhere you go that this is the measure we want to use, if you actually look up what that measurement is, nobody has a definition for it. Nobody tells you what you should do if the customer agrees that they should add more time. Or agrees that they should add more scope or agrees that they should remove the scope because it's too dangerous to try and execute all of this at once. So nobody really has any way of measuring the idea of on time, on scope, on budget anyway. You know, we sign a $300,000 project for nine months, the customer comes back midway, says this is way too complicated for us, let's just cut this down and spend 260,000 and do less. Is that a bad service? It's not a bad services, if what we did was give them good advice to not try and bite too much of the apple off in one go.

I think the idea is trying to think that our job is to give the customer the outcome that they wanted at the start of the project. I think that's the distraction. Neither the customer nor the service provider truly know what the project is going to achieve as an outcome until they take the journey together, and it's the journey itself that actually defines what we both collectively agree are the best outcomes for us to try to achieve, given the constraints and the budget we were given for this project. And we might decide to change those constraints if they are compelling enough to achieve other outcomes. And I think that that's a big mistake that we make. We make the general idea that when we close a project, while the constraints are set and so you guys aren't allowed to change the constraints. You just have to now move and not come back and tell us anything. And I think what that does is it actually ostracizes projects. It creates a whole portfolio of projects that don't want to communicate back to the sponsors and that's a bad idea. It takes sponsors to do this and guide the project successfully.

Banoo Behboodi: So when you say that, to wrap this up, what is the number one or the key reason that your clients come to you? I think you've hinted throughout in terms of some of the effectiveness in project delivery and sort of traditional assumptions that don't hold true. But what would you say are the symptoms they're sensing or feeling, that they come to you and go, okay, we clearly need help, help us. Is it that they're now turning over their professional services organization to become a profitable team? Or what's the trigger?

Shane Anastasi: Yeah, there's a couple and that's definitely one. We get a lot of software companies that come to us and say look, we have not been profitable, we've not focused on profit, but now we're about to, can you help us out? The other group that comes to us is the one that recognizes that what they're getting is something that we call reactive escalation. So what we help organizations do is focus on the fact that there's two kinds of escalation. There is reactive and there is proactive. And clients who are getting drowned in reactive escalation are finding that they're constantly getting escalations, but all the damage has already been done. The team has not told them that there is a danger ahead. They're telling them that a danger has caused damage and now that damage needs to be fixed. And so what happens is they encounter a lot of rework. So organizations that come to us are suffering from reactive escalations and an uncontrolled amount of rework. And they come to us and they kinda say, how can I get this back under control? It might be a P&L issue, but it might just be an efficiency issue. What we typically find with a lot of project portfolios is that the individual consultants have far more projects than they were ever intended to have, and that's because we don't finish projects because we are reactively having to go back and fix them because we make mistakes. And what we work on is trying to help to get that list of projects per consultant down in a very fast way because the more projects you add to a consultant, the less effective they are at focusing on and delivering that specific project.

Now the problem we have there is if you said to me, Banoo, what is the right number of projects per consultant, the answer is it depends on how larger projects are. It depends on how complicated they are. It depends on how much interaction you need with the customer, but at the end of the day, every organization should have a number of projects per consultant that they have worked out that allows them to maximize the quality provided by that consultant to that customer on that project. Now when we did this at big machines, they have very large projects. We did this at Salesforce CPQ, big projects that we do with large enterprise clients. There is a limit to how many of those you want one consultant working on at a time. And if you can stick to that, if you can actually build your organization around that, you get much better project quality and you get projects that progress much faster. And then you get on top of your business and you get to work on the business rather than working in the business as an executive. And that's really the tipping point that a lot of clients come to us and say hey look, it's starting to get outta control, maybe it's already outta control, I want you to help me fix it. I want you to help us get involved with getting projects back on track, but getting a mindset and an identity for professional services that everybody can believe in.

Banoo Behboodi: Shane, I really appreciate the conversation, it's been very insightful. I typically like to finish with a personal note. I'm gonna have two questions for you. First, I'm sure our listeners are dying to know where you're from with your accent, let's start with that.

Shane Anastasi: Yes, I'm from Australia. I grew up in Australia. I've worked in many different places. I lived for a short time in the UK and now I live here in the United States, in Chicago. But yeah, the accent is very well rooted in Melbourne, Australia.

Banoo Behboodi: Fantastic. And then just generally, I'm a reader, love to hear what people are reading. What is on your list or what is the recommendation of a good read? It doesn't have to be business, it can be nonfiction. It can be fiction for non-fiction, whatever works/

Shane Anastasi: Well, I spent a little bit of time this year trying to do a book and class on Anna Karenina and I gotta say that was a treat. So it was led by a professor who talked to us about the way that the book is structured and the way that it was written, and it was absolutely enlightening. And to be honest, what I got out of the book was just the writing is just beyond anything that I've read before from a perspective of fictional literature. It's just incredible. But from a business perspective, I'm probably most interested in anything that's kind of around cognitive learning and brain hacking. That's probably a series of topics that I'm constantly looking at given that we are a training organization, and one of the things we do is move beyond the idea of just content. We actually look at how you develop the brain to learn a new skill and getting into that. But the business book that I would recommend would have to be Ray Dalio's Principles. I would say that it's an incredible book for the range of what it covers, both work and life. It's a book that you can go back to time and time and time again to keep picking out nuggets that are of great value.

Banoo Behboodi: Fantastic. Well, it's been amazing. Really appreciate your time and looking forward to our part two of this. As always, we love to hear from our listeners. If you have any follow up questions for myself or Shane, reach out to podcast@Kantata.com. Thanks again Shane, really appreciate your time.

Shane Anastasi: My pleasure, Banoo. Thank you so much for having me.