The podcast by project managers for project managers. Are your projects truly delivering the promised benefits? Rasmus Rytter explains the often overlooked realm of Benefits Realization. He explains why so many projects miss the mark on delivering measurable benefits and shares strategies to implement to maximize value. Hear about the significance of engaging with sponsors, tracking progress, and analyzing outcomes for future improvements.

Table of Contents

02:37 … Why Benefits Management?
03:54 … What is Benefits Realization?
04:34 … Why Projects Fail to Deliver?
07:55 … Other Reasons for Failure
09:41 … How to Create Value
14:17 … Looking Beyond Deliverables
17:19 … Reassessing Throughout the Life of the Project
20:27 … How Benefits Change over Time
22:18 … Kevin and Kyle
23:35 … A Cause-and-Effect Relationship
25:42 … Project Sponsor Relationship
28:37 … Successful Project Closure
32:12 … Challenges to Change Implementation
35:19 … The Benefits Realization Book
36:50 … Contact Rasmus
37:36 … Closing

RASMUS RYTTER:  And you keep having those conversations up until a point where you say, okay, now we’ve done some analysis.  We have sort of a fair idea about, you know, what’s the IT part going to cost, and how expensive this change part is going to be, and then also what benefits can we realize?  And then the sponsor can say, yes, it’s still an excellent project.  Let’s go.  Or, no, it’s probably better that we spend some of our efforts on another project.  So we want to do some analysis to begin with, to have that conversation with the sponsors to make sure that we are not initiating projects that can’t really create the benefits that we dreamt of.

WENDY GROUNDS:  Welcome to Manage This, the podcast by project managers for project managers.  I’m Wendy Grounds, and with me in the studio is Bill Yates and Danny Brewer, our sound guy.

Our guest today is Rasmus Rytter.  He is a partner, a consultant, and advisor from Implement Consulting Group, and he is the author of the book “Benefits Realisation:  The Change-Driven Approach to Project Success.”  Rasmus is an author, a speaker, and a renowned expert within benefits realization and organizational change.  Before joining Implement, he worked for 10 years as a project manager, program manager, and people manager; and he is definitely well versed in benefits realization.  We’ve really enjoyed getting to meet Rasmus.

If you’re rethinking benefits in business projects, and you want to dive into why so many projects miss the mark on delivering expected benefits, we’re going to shift the focus from mere deliverables to real value creation in this podcast.  We want to explore the project manager’s perspective on benefits realization and discover strategies for maximizing project value. And Rasmus has excellent advice in all of that.

BILL YATES:  He does.  He’s so down to earth with this advice, too.  He started out as a project manager, and he has delivered, I’m using air quotes, “successful projects” where he looked back on it and went, “They never used the thing that we built.”  You know, I’ve experienced that, too; and that’s a very frustrating, it’s a deflating feeling.  And through that, I think it spurred his interest in looking at the long-term impact of a project, which is really what are the benefits after that project is done, the team has finished, the project manager has moved on to the next project.  What are they doing with the outcome?  So we’re going to focus on that.  He’s going to share great advice for us so that we can make sure that our projects have a lasting impact.

WENDY GROUNDS:  Rasmus, welcome to Manage This.  We’re so glad you’re with us today.

RASMUS RYTTER:  I’m so glad that you would have me.

Why Benefits Management?

WENDY GROUNDS:  The first thing is just tell us a bit about your passion for benefits management.  Tell us about your “why” behind this.

RASMUS RYTTER:  Well, I think we should start by, you know, at least looking back at my first 10 years of my career because, in those first 10 years of my career, I think I managed to do all the big mistakes that you can do when it comes to benefits realization.  And I mean, I made IT systems that no one ever used.  I built products that no one ever sold.  I designed processes that were certainly not used as we had hoped.  And despite of all that, I still got a lot of praise.  And I was sort of pulled into important people’s offices, and I was patted on the back and got a “Well done, Rasmus, and off you go to your next project.”

It took me some time to realize that something was wrong.  And it was just about the time when I joined Implement, a consulting company that I still work for.  That gave me sort of an opportunity to investigate, okay, something is wrong here.  And I was somewhat relieved to find out that I was not the only one who was not actually getting it right, but that there was a general problem about us not getting the benefits from the projects that we should do.  So that really made me think.  And that’s sort of the point where I really decided to look into that.

What is Benefits Realization?

BILL YATES:  Hmm.  I appreciate your authenticity.  This is going to be a good conversation, very helpful.  Let’s start it out the right way, too.  Give us a definition for benefits realization.

RASMUS RYTTER:  Well, if we just look at benefits, then we define benefits as the result of a change that is considered positive by one or more stakeholders.  And so that’s sort of the textbook and, you know, slightly boring definition; right?  But that’s how we define benefits.  And so benefits realization is the process of actually making sure that your projects are realizing the benefits that they should.

Why Projects Fail to Deliver?

WENDY GROUNDS:  Now, studies show us that there’s a high percentage of business improvement projects that fail to deliver the expected benefits.  Why do these projects fail to deliver their benefits so often?

RASMUS RYTTER:  I think the main reason is that we focus too much on the deliverables.  And I’m pretty sure that, you know, if we ask any of the listeners to this podcast, “Do you think that it’s important to work with benefits realization to get as much out of your projects that you can?” I’m sure they would all say yes.  I’m sure if you also ask them, “Okay, well, do you also think it’s important that we help our colleagues get through this change in a good and effective way?” I’m guessing that they would all say yes. 

But if we then look at where we really spend our time and money and energy, it’s on the technical deliverables.  So we still, you know, we know this, but we still just put all our efforts into the IT or the products or whatever deliverables we are doing.  And I think that is the key reason why we are not where we should be.

I would definitely recommend Bent Flyvbjerg’s new book, “How Big Things Get Done.”  That’s an excellent read.  And the thing I like about Bent is that he spent, well, 20-something years gathering a lot of data about projects and their performance.  And one of the interesting takeaways from his recent book is that four out of five projects cost more than expected and deliver less benefits than we had hoped. That’s sort of covering all types of projects.  And if you are just sort of zooming in or IT or business change projects, which are the ones that I mostly work with, then 73% of those exceed that cost.  I think that’s very interesting.

But if we then should look at what about the benefit part, then, well, the Danish state auditors published a very interesting report a couple of years back.  And the state auditors, those are the ones who are looking after the Danish taxpayers’ money.  What they did was they looked into 44 big IT projects.  And what they found was that, when they asked the government executives about, okay, how did it really go, how large part of the benefits did you actually realize, they answered less than 50% of the expected benefits.  They then looked into, okay, you know, how many of these benefits that you believe you realized have actually been adequately documented?  And the result was a measly 18%.  And as a Danish taxpayer, I certainly hope that we’re closer to the 50% than to the 18%.  But nevertheless, those are horrific numbers; right?

And so, again, I think the key reason for that is an extreme focus on that we need to build some deliverable and just get it out there and not being too much concerned that, you know, if you spent millions of dollars or hundreds of hours building some big IT system, then it’s quite likely that someone in your organization needs to actually use that in order for us to get any value out of it.  And so if you don’t have a focus that is directed as much to, you know, how do we make our organization actually use what we are building and not only building the thing itself, then we’re setting ourselves up to failure.

Other Reasons for Failure

BILL YATES:  What are other primary reasons for the failure of benefits realization in projects?

RASMUS RYTTER:  Well, I think we’re basically skipping half of the projects.  And so you can say we are not really taking into account everything that needs to be in place in order for us to be successful.  I think the focus on the deliverables is probably sort of the most important reason.  And so I think that the important thing is to have a conversation about, okay, what do we need to do then?  And I think the first thing we need to do is we need to change the way we look at these business change projects and make sure that we see the whole project because, when you do IT or business change projects, then obviously you still need to build the deliverables, and they are still important.

But from the beginning of the projects and to the end of the projects, there are also jobs to be done in terms of both benefits realization and change.  And if you forget that, then you’re setting yourself up for trouble.  And I think, you know, that’s probably easy for most people to not agree to.  But I think the difficult part is that we’ve been spending decades on becoming good at building IT or product or processes or whatever.  I mean, some say since the ‘60s; some say since the pyramids.

But, you know, for a long time we have been looking into that.  How do we do that in an effective manner?  And we haven’t spent that much time actually looking into how do we get practical when it comes to benefits realization and change?  And so we need to apply the same sort of structure and logic and common sense that we have built into the way we build IT or products.  We need to sort of take that and put that into the way we work with benefits realization and change.

How to Create Value

BILL YATES:  That is so true.  And Rasmus, it’s great to have you in this conversation because we want to switch to focus on the role and the responsibility of the project manager in this, how the PM views benefits realization, and how the project manager might improve in this area.  So the first question related to that is how can a project manager use benefits realization to create value in a project?

RASMUS RYTTER:  Well, I think the project manager needs to do several things.  But I think where to start is to make sure that you’re designing your project to create benefits.  And you do that by figuring out who in our organization are likely to be able to own the benefits and champion the change that is most often required to realize the benefits.  Then you invite them to a workshop, we call it the “Benefits Realization Workshop,” and then you together with them design the projects.  And you do that by asking them three questions.

And the first question is, what is the purpose of this project?  That might seem super trivial.  I also thought that going back a few years.  But it actually turns out that many of the companies that have implemented this come back to me and say, well, we thought we had that purpose thing sorted out, but actually we realized that having that initial conversation about purpose helps us a lot because now we don’t have those cases where we one year into the project or even one and a half or two years can still have a conversation in our steering committee or between our sponsors about what’s actually most important.  So getting the purpose in place is super important.

And once you do that, we can start looking into, okay, what benefits do we need to realize for us to fulfill the purpose?  And while the purpose can be a little bit big and fluffy and preferably sound great, then the benefits needs to be hard and tangible.

So the next question is, okay, what benefits do we actually need to realize to fulfill the purpose?  And if I must just give you sort of a super simple example, then most organizations, they do sort of efficiency or optimization projects.  So let’s imagine that your company is doing that.  A part of that project has to do with optimizing your procurement department.  And so maybe that’s the overall purpose, and maybe the benefit here is that we want to free up, let’s say, four people from procurement to do other stuff that we are not doing at the moment.  That could be a very tangible end benefit.

But then you need to ask them another question that is, that sounds great, but how is that going to happen?  And then the answer might be, well, our procurement process is very ineffective, so we’re going to optimize that.  So optimizing the procurement process will then help us free up some time.  Well, so far, so good.

The next question is, how will this impact our organization?  What will this mean to our good colleagues in procurement?  And sometimes when you answer that question, it is okay, it’s just another screen or a slight change in how they work.  And sometimes, you know, you are turning their world upside down or taking them through 25 years of digital time.  So you want to have that conversation right up there in the beginning, saying, okay, what do our organization need to do in order for us to realize the benefits?

And so after that, if you have time in that workshop, you know, you can still ask, okay, how much do we need to help our friends in procurement to actually change their ways of working?  What competencies do they need?  And then, of course, what IT systems or processes or technical tools do they need in order for them to change behavior?  But the key here is that we want the conversation about purpose and benefits with the managers that can own the benefits right away.  And then figuring out what the project needs to do, we need to start with how will this impact the organization. 

And it actually means that, from back then when I started as a project and program manager, everything was about the deliverable and doing that on time and on budget and with the agreed scope.  But now the important thing is has the project helped our good colleagues in procurement changed their ways of working, because that is what will trigger benefits.

Looking Beyond Deliverables

BILL YATES:  It’s like a broader view of the purpose of my project beyond just the deliverables, and it might be something in my contract or an SOW that has specific points and requirements that are spelled out.  I’m looking beyond that and looking at benefits realization, talking with people that are going to own this and saying, okay, these items in this contract, how does this tie to the end state that you really want?  Because you know how many times the contract doesn’t reflect what the sponsor or the ultimate customer really wants.  The lawyers have done their thing on it.  So now we have to make sense of it, and that we have to look beyond the deliverable to see what does the sponsor or the owner ultimately want, and are we going to deliver that benefit?

RASMUS RYTTER:  Actually, we just did a survey on our own, and I asked, “What was the purpose of your last project?”  And almost half of the respondents said that it was building that next IT system or product or whatever.  And if you ask me, that can never, never be the purpose of a project because that is just the means.  It’s not the end.  So in order to make sure you get the design right for the project, you need to make sure that there’s a common understanding of what’s the overall purpose, what tangible benefits do we need to realize, and then how will this impact the organization?  And then the project needs to deliver whatever needs to be done in order to make our friends in procurement able to work in another way.

And I’ve done this, and as I also said in the beginning, failed at this many, many times.  I remember one particular project, I needed to implement a new system for project managers to manage their projects in big infrastructure projects.  And we made some terrible decision in terms of system choice.  But in the end, you know, we got the system right.  And I forced everyone to take some training and do multiple choice tests so we were sure that they got it.  And then I was in there in that fancy office and got my pat on the back, and then I was off.

But these project managers, they were really seasoned.  They weren’t born yesterday.  So they’ve seen many of these systems come and go.  So they know that we just need to lay low four to six months.  Then this thing will blow over, and I can manage my projects in whatever way I want.  And so they just went back to doing what they have been doing for the last 25 years.  And so you can say that we managed to do the deliverables.  Yes, we did.  Did we build competencies?  Yes, we did.  Did they use it?  Absolutely not.  So did we get any benefits out of it?  Absolutely not.

And so in having this broader view on projects, we need to get to a point where you’re not a success.  Your project is not a success until you can see that the behavior in this case with our procurement friends have actually changed because that is what triggers benefits.  And so if you let go too fast, chances are that people will just go back to their old ways of working, and you won’t have achieved anything.

Reassessing Throughout the Life of the Project

BILL YATES:  Rasmus, I get the sense based on our conversation about the purpose of the project, benefits realization is not a one-and-done process that we go through.  I have a sense that, yeah, this needs to be done upfront very early in the project.  But looking at the model that you teach and preach and just having the conversation with you now, this feels like a conversation that needs to be readdressed with the team, with key stakeholders, sponsor throughout the life of the project.  You want to speak to that a bit?

RASMUS RYTTER:  Yeah, absolutely.  Absolutely.  And you’re totally right.  And I think you have taken that first step as we just discussed and make sure that you  got your projects designed right. You have a commitment from managers in your organization that could actually own the benefits and also champion the organizational change.  That’s an extremely important first step.  But after that, and after what is usually an amazing workshop, then comes a lot of hard work because there’s some analysis required for us to actually get some firm estimates on how many benefits can we actually realize.

So what you want to do after this initial workshop is that usually at that point in time, you don’t have any good estimates on what the benefits are.  You just get sort of an, okay, there’s probably some efficiency benefits, and there might also be some, you know, we want also to make some more money or create some stakeholder satisfaction or whatever.  And once you sort of have that outlined in that, the Benefits Realization Workshop, you need to go out and then figure out, okay, can we actually free up four people in procurement?  Or is it actually only two?  Or could it be six?  And what’s the effect on other parts of the organization?  Can we actually also sell this in Brazil, or is it only in the U.S. and Europe?  And what’s actually feasible?

So after you have spent some time with the managers who can own the benefits, then you need to go back in your projects and actually do some real work and figure out, okay, what is actually feasible?  And so in that process, you might get surprised, sometimes positively, which your sponsors or steering group will probably appreciate, and sometimes not.  And if you can’t get as many benefits out of this as you imagine, then of course it’s important to go back and touch base with your sponsor and say, okay, should we still do the project?  We can only sell this in Europe and the U.S., so the benefits will be 30% lower than we dreamed of.  But should we still go for it?

And so having those conversations are extremely important.  And you keep having those conversations up until a point where you say, okay, now we’ve done some analysis.  We have sort of a fair idea about, you know, what’s the IT part going to cost, and how expensive this change part is going to be, and then also what benefits can we realize?  And then the sponsor can say, yes, it’s still an excellent project.  Let’s go.  Or, no, it’s probably better that we spend some of our efforts on another project.  So we want to do some analysis to begin with, to have that conversation with the sponsors to make sure that we are not initiating projects that can’t really create the benefits that we dreamt of.

How Benefits Change over Time

But if you then say, okay, yes, this still looks good, then we have a rule of thumb saying that, if your project is longer than six months in duration, then at least every quarter you need to check in and say, can we actually still realize our benefits?  And that rule of thumb comes from a friend of mine, Per Svejvig, who’s a researcher at the University at Aarhus.  I did my first book with him and one of my colleagues.  And one of our big questions was, is it really necessary?  Then what is it actually that makes benefits change over time?

And we had a lot of hypotheses about what could be at play, but it turns out that it’s actually just the duration of the project.  So if it’s longer than six months, then you should definitely make sure that your benefits are still feasible, and much will happen.  And so if you have projects with a duration of a year or two years, it’s most likely that you need to listen carefully to all the opportunities that will appear in that period of time because new opportunities will appear.  And if you don’t see some of them, it’s likely that over time your business case will be drained bit for bit.  So maybe you can, again, sell the product in China, or maybe some legislation made it impossible to sell it in Europe, or maybe some competitor came up with a similar project.  Much can happen.

So for projects that last for six months, a year, more than a year, you really need to be careful to continuously figure out, okay, this new IT system, can we also use that in another country or in another department?  Or how can we boost the benefits from our project?  Because otherwise you are likely to end up with a drained business case in the end.

BILL YATES:  That’s helpful.  That’s a helpful tip to know how frequently to take a fresh look at that and reanalyze.  It’s great. 

Kevin and Kyle

KEVIN RONEY: Accurate and effective project status reporting is a cornerstone of successful project management. It serves as a communication tool that keeps all relevant parties, from team members to executives, informed and aligned with the project’s goals.

KYLE CROWE: It is an important tool that needs to be leveraged as it promotes the sponsors understanding and support of your project. A good project status report includes key elements such as project milestones, timelines, budget updates, and potential issues or risks. Accurately presenting this information helps with informed decision-making, gaining support, and maintaining transparency throughout the project’s lifecycle.

KEVIN RONEY: Also, consistent reporting at regular intervals, such as weekly, bi-weekly, or monthly, establishes a rhythm that allows stakeholders to expect updates and take a proactive approach to addressing any emerging issues. In the end, successful project status reporting goes beyond conveying information; it involves fostering a collaborative environment that empowers stakeholders to contribute to the project’s success.

KYLE CROWE: At Velociteach we offer an excellent course: Effective Project and Program Status Reporting that helps project and program managers learn how to accurately report the status of their projects in a manner that makes the information clear, concise and actionable. If you take this course you will gain a wealth of knowledge, tools and templates that you can use on every project or program you lead.

A Cause-and-Effect Relationship

BILL YATES: Rasmus, talk a bit about cause-and-effect relationships.  What’s the significance of establishing a cause-and-effect relationship in the benefits realization process?

RASMUS RYTTER:  Well, I think that cause-and-effect relationship makes it possible for us to understand or to see, you know, is it likely for us to actually realize our benefits?  Because if you highlight, okay, we believe that these benefits will come out of this changed behavior and organization, and that relies on this competence building, and that we are able to build a new CRM system or new IT support processes that can facilitate that behavioral change, then it’s all of the assumptions about the project are made visible.  And so you can see if you can take off both doing the deliverables, making sure that your people have the needed competencies, the behavioral changes in place.  If you can take all of those three off, chances are that you will actually also realize the benefits.

Of course, if you miss one or two, it’s highly likely that you are not going to realize the benefits.  So just highlighting what are the assumptions about benefits realization so everyone can challenge them and see, okay, we’re actually not selling what we dreamt of or saving as much money as we hoped.  And then you can also backtrack and say, okay, did we actually optimize this process?  Did we succeed with that?

And then, if things still look right, you can backtrack and say, okay, are our people in procurement actually doing what we hoped they would do?  And then more often than not we actually find out that, if you are not getting the benefits that you want, you can backtrack to the behavioral part, in this case, with our procurement people and say, okay, well, maybe they’re still throwing PDFs at each other, or supplies; and maybe they’re not actually using the process and the system as intended.  So in many cases it helps us to sort of, if you’re not getting the benefits, then backtrack and figure out, okay, where in this cause-and-effect chain didn’t we manage to succeed?  And then in many cases you can actually go back and fix it.

Project Sponsor Relationship

WENDY GROUNDS:  The relationship with your project sponsors is always important.  Do you have some advice on how the project manager should interact with these project sponsors so that they can confirm completion and track the project to the project benefits?

RASMUS RYTTER:  Well, I think in most projects the relationship to the sponsor is key.  And I started out by saying, what you need to do is get that sponsor and maybe a couple of other sponsors in a workshop that usually takes three hours, and then you’re off to a great start.  But actually, the first time a sponsor is met with a three-hour invite, that person is maybe sort of not inclined to accept right away.

So actually, you know, the first piece of good advice is that you need that workshop, and so you probably need to do some stakeholder management in order to get your sponsor in there.  And so investing in that is a good idea.  Fortunately, it turns out that if you have that workshop, and you ask that person all these questions, and your sponsors have a good conversation about purpose and benefits and what this will actually do to their organization, chances are that they will come out happy and probably also a bit surprised about how much they learned, not only about the projects, but the other perspectives on what could this project also deliver.  So I think that’s my first piece of good advice.

And then interact with them frequently.  I think when you are interacting with them in terms of, these are the benefits that I will deliver to your organization, and this is the change that will happen in your organization, and if you use the procurement example again, the head of procurement is likely to be interested to figure out, okay, am I actually going to free up four people in my department for the work that I need to get done, and get a firm idea about what will it actually take for his or her employees to actually go through this change?  And what will the project do to help them?

So I also think that, if you’re only having conversations about bits and bytes, then I’m sure some sponsors will think that that is probably a bit less relevant.  But if you’re talking about, you know, we’re going to help you save this amount of money, or we will help you achieve your sales budget next year, and we can also help you change the organization so they will work in a more standardized way, or they will sell differently and hopefully more effectively, then they are more likely to listen.

So if you broaden your perspective on the project, and so it’s not just, okay, we will throw this IT system at you at some point in the distant future, then I can understand that they don’t have time for that.  But if you’re having a value-based dialogue – this is what we’re going to deliver to you, this is how we’re going to make you a success, this is how we’re going to help you transform your organization – then they are more inclined to listen.

Successful Project Closure

BILL YATES:  One of the questions I want to ask you has to do with the end of the project.  We’ve checked off our deliverables.  Hopefully we’ve tied our deliverables to benefits.  We began with the end in mind.  Now we’re at the end.  And now we’re trying to have that meeting that says, okay, here are the benefits that we’ve realized.  Here are the outcomes.  We think we have project success.  But it doesn’t matter if I, the project leader, believes it.  I need the sponsor.  I need the owner to believe it.  When you look back at successful meetings, successful closure meetings like that, what were the elements that you saw?  What was a part of that meeting that made it more fruitful, more successful than others?

RASMUS RYTTER:  Well, I think the conversation in those type of meetings when they’re successful is not about bits and bytes and whether that sort of blue lens is on or off.  It’s about, is the organization working in a different way?  And can we see sort of leading indicators that, for example, that we are now serving our customers in a different way?  Can we see that already now?  And can we perhaps also see that we’re starting to see more customers coming in or having worked in a more efficient way with processes that we implemented some time ago?  So I think switching again the conversation from is it on or not to is the organization working in a different way, and can we see sort of the first indicators that the benefits are on the way?  That’s a good meeting.

But I also think that it’s important to realize that at some point, you know, we need to let the project manager go home.  I mean, he or she can’t stay on the project forever until all the benefits are realized.  So once we have seen that the ways of working have changed, and they’ve managed that, then they deserve the big pat on the back and say, you know, “Well done.  You have really done your job.”  And then we need to have the project sponsor report, for example, to PMO after the project is done saying, “Did we actually, did we come through?  Did we realize the benefits?”

And I also think that that could be a little bit scary for many sponsors.  That’s also why it sometimes takes a while for them to lean in in the beginning of the projects to actually commit to benefits because they soon figure out that if you commit to benefits, then someone will be there at some point in time checking whether you actually realize them or not.  And especially when we start working in a structured manner with benefits, then in many cases, even though we do as good a job as we can in estimating the benefits, sometimes we are not exactly spot on, and sometimes things also just happen.

So we need to be a little gentle with the sponsor that has actually leaned in.  And so if they’re not exactly sort of on par, then instead of just shooting them at dawn, we should investigate why are we in this situation, and then learn from that.  Because a lot of companies, they do a lot of optimization projects, and they do a lot of projects that has to do with, you know, increasing revenue.  And so if you start to actually figure out how well did it go, then sometimes there’s an opportunity to praise the sponsor when we actually realize the benefits. 

But there is always an opportunity to learn something and put that learning into new projects so we can have even better conversations in the beginning about, okay, are we really sure that we are going to save four FTEs?  Because the last time we tried to do something similar, it didn’t quite work out that way.  So we can have much, much better conversations if we actually start learning from our projects and how many benefits we realize.

Challenges to Change Implementation

WENDY GROUNDS:  You’ve talked a lot about the importance of behavioral change and implementing this behavioral change within your projects, but it can be difficult.  What are some of the challenges that organizations face when they want to implement changes?

RASMUS RYTTER:  I think most organizations don’t really know how to go about it, and don’t have a structured approach to do organizational change.  So in many cases we’re in the same situation as with benefits.  We don’t really have a good idea about what should we do.  I think many also have an idea that you need to have something special in order to actually go and do organizational change, and it’s almost magical when it works out right.  So only a few people can do it, and that’s just not true.

And I think what we found out was that, especially in the beginning of the project, we ask the same questions to understand what behavioral change lies ahead in all projects.  So since it’s the same list of questions that we ask every time, everybody can do it, and everybody can then, in the beginning of the project, get a good understanding about what is really at stake here, and what should we do to have our friends in procurement or wherever they are, those who are affected about this change, what should we do to get them through that change in the best possible way?

And I think while we can be extremely structured in the analysis part of a project when it comes to organizational change, and get a very, very good understanding about what should we do, then the change itself is obviously different because the people are different. And the thing that needs to happen is different.  But then there’s still a few steps that we almost always have to go through.  And we can sort of look at those and say, okay, what’s relevant in this case?  And in most cases it’s a really, really good idea to find people in the organization, first line managers, and people among the employees who can help us make this change happen. Change agents, champions, whatever you want to call them.  So starting out by identifying them and involving them very early on is super important.

And then what we’ve also found is that involving people before the change actually happens, or before we release the IT system, or before we change the way we work with sales, involving people in before the change actually occurs helps them to both understand what’s actually going on, but also to provide input.  And that involvement, even though they can’t maybe change much about the process of the IT system, then maybe they can sort of change when do we actually need to do this task, or how would we like you to help us go through this change project or this change process?  So getting that input early on is super, super important because it allows people to understand what’s actually going to happen. And it helps us understand what is it they actually need in order to get through this change process in the best possible way.

The Benefits Realization Book

WENDY GROUNDS:  Rasmus, can you quickly just tell us about your book, “Benefits Realisation”?

RASMUS RYTTER:  What I hope to achieve with this book is to answer some of these questions that we discussed.  And that is, you know, how can we be more practical about our approach to both benefits realization and change?  I think when I started to look at benefits realization as a topic, there was a lot of theory about, you know, how should we go about it?  And the theory was super good, and it made a lot of sense, but it was just not very, very practical.

So I think my sort of modest contribution to benefits realization as a topic is that me and a lot of colleagues spent a lot of time figuring out how do we actually make this work in projects.  The book “Benefits Realisation” is our suggestion to how do you actually approach benefits realization and change in projects.  So it’s a handbook, with examples and workshops and so on and so forth, to be sort of as practical as possible to actually help people succeed in realizing more benefits.

BILL YATES:  It’s a great contribution, Rasmus.  We need this in the project management community to focus on the big picture, to think and ask those questions at the beginning and throughout the project.  Are we addressing the purpose of the project?  Are we just going down our deliverables list that happens to be on a contract and not even thinking about who’s going to own this when we’re done?  So this is great advice.  We appreciate it.

RASMUS RYTTER:  You’re most welcome.

Contact Rasmus

WENDY GROUNDS:  If our listeners want to get in touch with you, what’s the best way they can do that?

RASMUS RYTTER:  Well, people are always welcome to either follow me or connect on LinkedIn.  We publish a lot of articles and events and new ideas about how to get more value out of your projects.  And you could also visit our website.  It’s Implement.dk/benefits.  And there we also have tools and templates and cases and articles that we previously published that might be interesting.  We actually also have videos and so on, if you want to explore more.  So that’s also a possibility.  And then, of course, you can always get the book.  That’s also a good option.

BILL YATES:  Thank you so much for this conversation.  This has been really beneficial.

RASMUS RYTTER:  Thank you.  I appreciate it.

Closing

WENDY GROUNDS:  That’s it for us here on Manage This.  Thank you for joining us today.  You can visit us at Velociteach.com, where you can subscribe to this podcast and see a complete transcript of the show.

To earn your free PDUs, you can claim them by going to Velociteach.com.  Choose Manage This Podcast from the top of the page.  Click the button that says Claim PDUs, and click through the steps.  Until next time, keep calm and Manage This.