In this episode of the “Art of Value” Podcast, I talk about value pricing project management: managing scope, gauging effort and completing projects.
Please find a full audio transcript below:
Speaker 1: This is The Art of Value Podcast. Discover value, create options, and start pricing. Artofvalue.com.
Susan: A project cannot go on forever. It has to have a start and an end.
Kirk: Welcome to the Art of Value show. My name is Kirk Bowman, the Visionary of Value. This is the show where we discover value, create options and start pricing. On today’s show, I’m going to interview the project manager from MightyData, Susan Fennema.
The inspiration for this show came from listening to the Chris Cerrone Show. Chris Cerrone and Laci Urcioli have been doing a podcast together for the past six months. I actually got to be a guest on their show. It was episode 91 where we talked about value pricing. What I loved, both listening and being interviewed on their show, is the banter between Chris and Laci. You can tell they know each other well and it feels like you’re listening to a conversation between friends.
That’s what we’re going to do today. We’re going to listen to a conversation between myself and my friend, Susan Fennema. Susan and I have been working together now for five years. Susan knows me so well she can usually predict how I’m going to make a decision in a situation. During this episode, we’re going to talk about how do we define a scope and then how do we see it through to completion for a value based project. Let’s go to the interview.
Speaker 1: Discover value. Create options. Start pricing. Artofvalue.com.
Kirk: Welcome to the Art of Value Show my friend, Susan Fennema. Susan is the project manager at MightyData, my software company. She and I have been working together for almost five years. Susan is the best project manager on the planet. Welcome Susan.
Susan: Thank you very much. I’m glad to be here. Thanks for the compliment.
Kirk: You’re welcome. It’s true. I wouldn’t say it if it wasn’t true. Now not everything else I say is true. For example, you are a Longhorns fan.
Susan: No, I’m a Texas A&M Aggie graduate.
Kirk: Sorry we had to get that out there. Both of our football teams are losing this year. A&M is having a rough one and Arkansas is having a harder one. We’re just going to bypass football and get on to what we’re going to talk about today.
We got a comment on the blog. It was a comment/question in response to one of the shows. I thought what we would do is just read this out loud and then let’s talk about it. I think there’s a lot of good advice we can give in response to this question. Let me just start by reading this. Can you give an example of a set of value statements hat you’ve worked from and how you’ve managed the client’s expectations? My experience is that so much of this is so objective. We all know the end of the project never really ends when the results are subjective. Questions we are constantly asking: what is finished? What is success? When do we start considering the next set of work? I guess, when do we start considering the next set of values? What a great question. There’s so much in there.
Susan: It’s a fantastic question. I think we have to break it down piece by piece.
Kirk: I agree. Let’s start at the top because there are two things that jump out at me in this. Probably something else caught your attention. Number one, the word subjective. He uses that a couple of times. I think what he’s saying is as the provider, finality means one thing to me and it means another to the customer. He’s calling that into subjective.
Number two is when is it finished? The scope. I’m going to start with the subjective thing and clarify that. Then maybe have you comment on the scope part.
When we talk about subjectivity with value pricing, the part that is subjective is the value. Value is in the eye of the customer. Only the customer can determine what value is and so that’s subjective. The scope of the project is not subjective. What do you think about that?
Susan: I think that’s actually what the initial question was something to the effect of how do you know when the value has been met? That’s the difference. The value is not what we’re meeting. We’re meeting the defined scope that we’ve agreed on with the customer. That is very tangible. It’s very specific. Whereas the value might be more subjective, even though we’ve agreed to both with the customer.
Kirk: In other words, first we agree on the value, which is subjective. There has to be agreement on what is the value? For example, in our process we literally as part of our proposal say, “Look here’s the value you’re going to create through this project.” We read through the bullet points with the customer and get their agreement.
Susan: Right. Having them agree that that’s the value that they’re going to gain from it is the first step. You can’t even define the scope if you don’t know that part.
Kirk: Right. You don’t want to define a scope that has no value. You have to find value first. This question is really going to how do you have defined scope that’s not subjective?
Susan: Right. From that value you start then to break down the specific items, the specific tasks and the outcomes that you’re going to create to achieve that value.
Kirk: How do you keep that from being subjective? How do you keep the scope from being subjective?
Susan: Sometimes it can be. When you say you’re going to create a letter, it sounds pretty specific until you figure out later that it had to fit into a window envelope and it needed to look like this and all of these things needed to merge into it. If you’re not specific in your scope, you can get trapped into the this is what the customer expected so now we need to do it. You need to be more specific with that and ask more questions about those tangible items up front in order to prevent your project from going on forever.
Kirk: Basically what you’re saying is writing a good scope is partially from experience.
Susan: Absolutely. We all are going to make mistakes in that area. Every time you make one you learn how to do it better the next time.
Kirk: If you have experience, you just need to go back and look and go, “Okay, where did we write a scope that kept us within bounds? Where did we write a scope that kept us out of bounds? How do we get better or how would we revise a part that was out of bounds?”
Susan: Right. I think with MightyData we do it a lot more along the lines of we’re off track here, what happened? Then we’ll go back and look at this is how we set it. This is how the customer perceived it. Since we are in the business of serving our customers, we’re going to do everything we can do give the customer what they perceived to be the scope unless it’s going to break the bank or completely kill us. Then we’ll go back and talk to them about what was the intention behind the scope. That’s a big thing to define as well. As the service provider, we are defining the intention behind the scope, not the customer.
Kirk: I always say that if there is a question about scope, what we go back to is what did I, as the provider, intend when I wrote the scope? As the provider, I’m the one that said, “I’ll agree to this scope of work for this price.” Where the customer agreed to it was on the value that was created. Really it’s my professional judgment, to a degree, on the scope.
Susan: As part of giving the customer the best of your value is serving them. Always giving them the benefit of the doubt is a really important part of that.
Kirk: You alluded to that earlier. The example you had of the letter. This particular one was the letter was supposed to go in a windowed envelope, which it’s been so long since I’ve even seen one of those, it never crossed my mind. That’s what the customer expected. We did the extra effort. It took about five iterations back and forth to get it just lined up with the window, which is hard when you’re remote and you’re dealing with different printers and all of that. We did it.
Susan: We needed to do that. That’s what their expectation without question.
Kirk: To your case, that expectation is part of the value that they were expecting.
Susan: Right. That’s another thing. You have to define whether or not that value … Are they getting that value out of this? Or are they just asking for something that it really doesn’t matter? It’s not going to change the value. It’s not going to change their workflow.
Kirk: One of the things I noticed in our proposals, they tend to be on average three or four pages long. Usually probably a page or two pages of that is the scope. The challenge, I think, part of it is not biting off too big a chunk?
Susan: Yes. Absolutely. You want to make sure that you have a time frame that you can finish the project in and it is very defined as to when it will be completed or when testing will begin. Some part of that clearly defined so that you do have an end date. A project cannot go on forever. It has to have a start and an end.
Kirk: Our friend Ed Kless, part of his definition of a project is that it is basically bringing together a team to accomplish a specific purpose for a short period of time. He defines the maximum period of time for any project is about 18 months. For us, it’s less.
Susan: 18 months would be too long for our customers. Too many things change on their end during that time period.
Kirk: The idea that any project that goes past 18 months and possibly we would say even maybe even 12 months is really no longer a project. It’s probably something you can break down.
Susan: We would call that a failure.
Kirk: Or two projects?
Susan: Right.
Kirk: Doing things in phases. Another thing that Ed talks about is the distinction between effort and duration. I think what you were talking about meeting a deadline is the idea of duration. You’re not talking about how much effort is it going to take on us to actually do the scope of work. You’re talking about when do we tell the customer that they were going to get it.
Susan: That’s really the bottom line. When is the customer going to be able to start testing? We build milestones at the beginning of each project so that they know when are they going to see something for the first time. What input are we going to expect by it the next time? All of those dates are scheduled for them in order to meet the end date of when the testing starts. That testing also has a start and an end, which is important to finish the project.
Kirk: What you’re really alluding to is we’ve got a process?
Susan: Right, we do.
Kirk: Part of the process is explaining the process to the customer. Why don’t you talk about that first meeting that we have when a project gets kicked off?
Susan: Sure. In our first meeting, we spend not more than half an hour, but we walk through all of the milestones. At that point I’ve already built a schedule out for them. I make sure that they’re not going to be on vacation during one of the major testing times or something like that. We’ll adjust it if necessary for that.
We talk through all of the things that they’re required to do. We talk about what the project champion does, which is their counterpart, their project manager on their side that’s leading their team to communicate with us. We talk about what they’re supposed to do during a testing period. We talk about the difference between alpha and beta testing and what those things look like for them. We talk about bringing in power users to test in the alpha mode before it goes to all users in the beta mode.
We walk through our process with them very clearly in the kickoff. Then we have to continually remind them throughout the project as we go. That’s why we have status meetings weekly.
Kirk: At least three things that Susan just mentioned that I want to call your attention to. First of all, we have a formal kick-off meeting for the project with the customer. The whole purpose of that meeting is to explain our process to them. It’s not the first time the customer has heard about our process. We actually try to begin educating them on our process during the sales cycle.
We have a formal meeting where the purpose of the meeting is to say, “Here’s everybody involved. Here’s the team. Here’s our process.” We try to frame expectations from the beginning. Then, as you said, you remind as we go.
Susan: Often, things might have to be adjusted a little bit. Things do happen throughout a project that might require a change of a milestone. I don’t usually consider that a change request, something where we would write something formal, unless it’s going to affect that final end date. Or if there’s any real contention over you’re going to see this part this week instead of next week, is that okay? If there’s a contention over it or a problem then we need to address it a different way. Usually that conversation and that teamwork with your customer makes all of the difference.
Kirk: One of the things that is interesting is talking with you about our process, I’m learning more about our process. The thing I’m realizing is our process has a lot of communication built into it. That communication allows for, number one, mutually reviewing expectations on a regular basis and then monitoring to see do we need to adjust expectations or adjust something else because of reasonable things that come up?
Susan: Absolutely. We’ve had one project where somebody actually had a brain aneurism. Wow, dealing with that you have to give a little love to your customer in those situations, a little grace, and figure out how you’re going to move forward. For everybody out there, she’s okay. She did make it okay. It was obviously something that no one expected to happen. You have to get back in there and figure out, this is always my rule, what’s your hit by the bus rule? How are you going to resolve the problem and keep things moving? We were able to get back in, but did take a little bit of effort on our part to get over that hump of losing our project champion that way.
Kirk: You’ve used the term project champion a couple of times. Can you define what that is and why that’s so important?
Susan: Sure. A project champion is really the project manager for the customer’s internal team. Somebody who is going to be acquiring all of the information that we ask for them to get forms, documents, answers, coordinating internal departments as well so that if there are multiple internal departments that they’re making sure all of that information is being fed through one person so that that person can pick what is and isn’t the best direction to take. They’re also responsible for training their team once they get to that point. Making sure that they’re the person on their team that’s going to lead the charge and get everybody to adopt the program once they get it in-house as well.
Kirk: We believe that having a clear project champion is probably one of the most important aspects to project success, right?
Susan: Absolutely. If you do not have one person that can make decisions and make them quickly and be available to make them quickly, the project goes no where really fast. That’s another answer as one of the questions that we were talking about is how does a project end? You have to have a leader on both sides of the project to get through to the end of it.
Kirk: The idea of project manager as somebody who is on the provider side and does the play calling for the provider and the team, that doesn’t work.
Susan: No because I don’t go to these people’s offices. I can’t go sit and their desks and tell them you have to do this right now. I need this file. I can’t go to their final cabinet, get something and scan it in. I have to have somebody on their time that’s responsible for those things.
Kirk: It’s interesting. We had to have a couple of conversations recently where two different customers for different reasons, but situation was similar in that the original project champion was too busy. We had to go to both customers and say, “We need to redefine who the project champion is.”
Susan: In many cases, we are working with the owner of a small company. They just do not have the capacity to be able to answer questions quickly. We’ve handled that many different ways. Sometimes that will be somebody that they will trust. They’ll hand it off to the president of their company instead of them being the owner. Sometimes they’ll take a person that might not be a decision maker, but that they know can drive the decision making process. They can be responsible for coming after the owner of the business to make him answer the question in a timely fashion.
I think that’s one of the things. It needs to be someone that the owner or somebody that they’re working closely with that they trust, that they know is either going to make the decision they want them to make or be able to raise their hand when they know it’s a decision that somebody else needs to make.
Kirk: I think one of the things that we’ve been getting better at is not even waiting until the project kick-off meeting to go, “Hey are you the project champion?” We’re actually trying to, n the proposal, as part of our terms and conditions say the project champion will be and specify the name. Then we go on to say that if that project champion changes, it might be a change request.
Susan: Right. There are some situations where a project champion can change and the other person might have been in the loop enough that it’s not a big deal. There are some times where the new person comes in they just don’t have a clue of what we talked about, what the scope is, how far into this project are we. That can be a real challenge.
Kirk: That’s why we say it could be a change request is because if we’ve got to start over and essentially bring somebody else up to speed, that’s like opening a parachute on the project. It just dramatically slows it down.
Susan: Absolutely. As long as that person is well trusted by the people who are the ones that are going to be measuring the value from us in the end, that’s really what we’re looking for. That doesn’t mean they have to know every single answer to every single question right now. It means they need to be able to figure out how to go and get them.
Kirk: Let me summarize some of the key points that we’ve covered so far. Then there’s at least two or three others I think that we may want to get to. Number one we’ve said you’ve got to have a process. Number two, we’ve said you need to practice writing scope. You need to learn from experience, but that at some point the scope can’t go on for pages and pages. When you come down to having a question, what we go back to is what was the intent of myself as the professional when I wrote it?
Susan: To that point, we’re hoping to be entering into agreements with customers where there’s a mutual trust and there is some equal give and take on both sides.
Kirk: Exactly. Then also we have a project champion. Getting back to our process, we use an online project management tool called Basecamp. There’s other products out there. That happens to be the one we chose. How does having that tool help keep a project on track and help you know when it’s finished?
Susan: When I first started at MightyData, Basecamp was not as robust as it is right now. You weren’t as able to schedule different things, move things around as easily. They’ve done some major upgrades that have made a big difference. Being able to put dates to things, being able to build different to-do lists so that you can follow along and be able to check things off.
We put our scope straight into Basecamp. The customer can see it there every single time they look at it. That’s what we’re building off of. The developer has all of those scope items assigned to him upfront. We can go back and forth. If we have questions, Basecamp pulls things into your email so that you can answer it from your email client if you don’t have time to pop in and look at everything that’s assigned to you. It has a whole bunch of tools and it’s very user friendly.
Kirk: It’s interesting, again, I’m learning more about our process as we go. We ought to have these conversations more often. I write the proposals for our software company. When I write the scope, I’m writing it in a way that I think the customer will understand. You’re right. You literally copy and paste the scope, which I write as bullet points, into Basecamp. Each one becomes a separate item on a to-do list, essentially a milestone.
Susan: Sometimes the milestones are broken out differently depending on the phase of the project that we’re in. We might group things differently in the milestones than we would in the actual items. We make different lists for those things. The milestones are different from the actual defined scope items. That gives us the benefit of being able to go back to the exact verbiage that was there from the beginning and say, “Have we met this? Have we done what that verbiage said we were going to do?”
Kirk: At some point you literally have to go back and go, “What did we agree to and write?” Whether you’re doing that in the scope document, a proposal or you’re doing that on what somebody might call a master services agreement, at some point nobody remembers every word that was written. That’s why you write them down so that you can go back and review it.
Susan: Exactly. Because value pricing comes with a fixed price, the scope is fixed as well. We do tweaks, no problem. We fix bugs. If something is going to come in and they want what they think is a little tweak, but it is a whole different ballgame than they’re expecting, now we’re going back to the original scope and defining is this within the scope? Is this within the value that we talked about earlier?
Kirk: I love the fact that you connected scope to value. What I was going through my brain is one of the questions we’re asking is this going to deliver more value than we agreed to deliver for the price?
Susan: Right. That is another thing we’re thinking about too.
Kirk: What do you think is still one of the things that we’re learning? We haven’t arrived. What do you thing is still one of the areas where we’re evolving?
Susan: That’s a good question. I think our discovery process, our initial process upfront, is still evolving quite a bit. We’re learning how to bring new people in earlier into the process, which is helping the transition from discovery to development. It’s also helping speed things up a little bit as we divide and conquer. I think defining that project champion as we have been more and more earlier in the discovery phase of the project, rather than waiting until the development phase is important.
That discovery is telling us right off the bat who has time and who doesn’t. That is really the key. If you don’t have time to come to a status meeting for a discovery session and you don’t have time to send a document that we’re requesting for a discovery phase, you do not have time to be doing a development project with us.
Kirk: I can almost hear somebody, a listener, saying, “Wait a minute, you’re talking about availability of the customer? We’re talking about defining the scope.” What we’re saying is it doesn’t matter how well defined the scope is, if the customer is not showing up to do their part and if as a professional we’re not in a professional way holding them accountable to do that, the scope doesn’t matter. You can’t keep a scope on track when both parties are not collaborating.
Susan: We cannot possibly meet a deadline with a partnership, a true partnership, with our customer. That means they have to be able to be available to answer questions. They have to be responsive. They have to be definitive and they have to be clear. Even when we get to a tweak or a bug stage at the end, just telling us it’s broken, that doesn’t solve it. We have to know exactly what’s broken.
Kirk: That’s why we’re so formal about the bug-testing phase. Obviously we’re talking about software development. These concepts can apply to other things, for example design. Maybe you’re doing some type of branding or logo. You still have revisions, iterations as part of that process. Think about how you can define that. You can’t define that so narrow that there’s no flexibility.
You don’t want to leave it open ended either. For example, for us, we typically say we’re going to have two bug fix periods and a project alpha testing, which happens during development, and then we have beta testing, which occurs after the formal development is complete. We generally define that time period is going to be this long.
Susan: There’s usually a break between it so that things can be cleaned up, servers can be moved, all of the kind of things. It’s defined as to how long each period lasts and that’s important. I’m even reminding them usually at the end of a bug period, listen up until midnight tonight you send in your bugs, they’re in scope. After that, we’ll have to say. I usually don’t say that part. I usually say up until midnight they’re included.
Kirk: I think part of this is there are always going to be questions about scope. You’ve got to have some courage to be willing to say, “No that is not in scope.”
Susan: Absolutely. To the point to of the person that was actually asking the questions, how do you end things? It’s custom software development. You can go with tweaks and bug fixes until the end of time. You have to define when is it over? You have to use that as pressure on your customer for them to spend some very valuable time of theirs with it and put forth some effort to test it.
Kirk: The word force sounds forceful. I might just rephrase it and say we’re actually helping the customer by helping hold them accountable.
Susan: Right. That pressure is necessary or else it will go on forever. That doesn’t help them either. Now they don’t have a solution that they can use. It’s buggy.
Kirk: One of the things that you taught me, it’s amazing I’ve been in this business 15 years before we met, and one of the things you taught me is if there’s not a deadline, it won’t happen.
Susan: That’s right.
Kirk: We apply that to our projects. We scope out the milestones. One of the things that I’ll mention is that when we write the scope, generally we’ll put an expiration date on the proposal and we’ll say, “As long as you give us an answer by that date, we can get this completed in X and Y weeks.” We’re use a range of 8 to 10 or 10 to 12, something like that.
Susan: Sometimes we put a specific date on it, especially as we near the holidays and we want to make sure that testing and all of that doesn’t start to interfere with that. That’s why that expiration date is on that proposal.
Kirk: Getting back to what I was mentioning about we use a range. The reason we use a range, and I’ll explain a minute why sometimes we don’t, but the reason we usually use a range is there’s another phrase in the proposal that says, in fact usually right after that, it says our project manager will determine the exact schedule and milestones once we’ve received a signed proposal and payment. We’re basically saying we can get it done in this general timeframe, but we’re not going to nail down a schedule until we know it’s going to happen.
Susan: There are a lot of reasons for that.
Kirk: Somebody else could sign a proposal ahead of us.
Susan: The developer could go on vacation. All sorts of things could throw wrenches in the original plan if you’re not being very specific. Very specific in some cases, giving yourself flexibility in others.
Kirk: Exactly. The case you mentioned where we do put a specific date on it, usually it’s either because we know we can meet that date, the customer has already told us that that’s the date that we need to meet or in some cases, like the holidays, in some cases we’re actually providing incentive for the customer to do the project on our time table, on the one that we would prefer.
Susan: Right. Something so that we can finish it before the break and everybody forgets everything that we were working on.
Kirk: For this example, we were actually trying to get the core development done before Thanksgiving so that we could do the testing between Thanksgiving and Christmas and be done before the New Year. Part of the scope is the duration that you set. Also I think project management, I may be oversimplifying it, but you need to have an end deadline. Then you need to break it down into smaller pieces in between and you just need to have constant communication. That sounds easy. You make it look easy.
Susan: Thank you. I try. Constant communication is the important part. There has to be something that’s going off in the back of your mind every now and then that’s like, “Wait a minute, why haven’t we heard back? What’s going on?”
I actually have tools to help me remember, to spark that thing in the back of mind of should I be worried yet? I will put a reminder in Basecamp. I have my own list and my own project in Basecamp of things that I need to remember to ask or times I need to check in with somebody. That’s important because if I’m not doing my part to keep them on track, then I feel like it’s partly MightyData’s fault that we haven’t gotten there. That’s part of what’s included in my proposal is my skill set so I best bring it.
Kirk: What I tell every one of our customers is we don’t believe that software can be successful without a project manager. That’s why we have a dedicated project manager. That’s why it’s included with every project. In fact, don’t ask us to take it out because we won’t.
Susan: I remember when I first started back when we were actually billing by the hour. We had a problem with that. That’s something to consider. We had a problem with customers who did not want a project management included because they knew that they would be being billed for more hours of work.
Kirk: I won’t turn this into a debate about hourly pricing versus value pricing. Maybe that would be another show that we could do later.
Susan: Let’s just say I’m glad I don’t have to do time sheets anymore.
Kirk: You are grateful and me too. They were always accurate. It’s interesting as we talk about this I hear the frustration in this question of just never knowing when it ends. I would say you’ve got to be willing to stand up and say, “No. That’s not in scope.” What do we do when somebody asks for something that’s not in scope? What are a couple tools we use to, what’s the phrase, say yes while saying no?
Susan: There are several. One is we actually create a wish list to-do list in Basecamp. It goes at the bottom of every single project. When somebody comes up with that brilliant idea of, “Can’t we just?” It always starts with can’t we just do this one little thing? We say, “Let’s move this to your wish list. Let’s address it after we complete the defined scope of work. We don’t want to get ourselves off track. We have it. We’re going to store it down here so that we’re not going to forget it.”
It’s amazing to me the number of times you come back to it and find there was no real value in that. We’re not going to proceed with it. That’s usually decided on by the customer. In the spur of the moment, it seems like it will be good.
The other thing that I just will flat out say, “This is not in the scope of the project.” Just that straight forward. There’s no emotion in it. There’s no disdain or anymore back and forth. I’m just stating a fact. It’s not in the scope. We can address it later. I always make sure that they know that just because we’re not doing it today doesn’t mean we would never do it.
The other thing is that if they bring up something that changes the project in the middle of it. That’s where your red flags need to be going off. Then you’re talking about writing a change request that might change the whole rest of the project. You need to stop at that point and regroup.
We don’t have that that often because we aim to make sure that we are doing things in a short enough time frame that things aren’t going to change that dramatically. Yet sometimes they do. That’s one way too. Then the other is we can tell them, especially on bugs that are late, we will say your bug period ended this day. This is a late bug. We can collect several and give you a price to do all of them at once or we can give you on off prices. There’s some ways to manage that too with change buckets and other things that we’ve put in place in the past to address the little things that come up along the way.
The main goal is to make sure that you finish the scope that was defined initially because that’s what everybody agreed the value was coming from. You want to get that out to the users. If it’s not to the users, there’s no value in it.
Kirk: Yeah until they actually begin to use whatever it is, whether it’s software or a website or some type of branding or collateral. Until they begin to use it there is no value.
Susan: Right. It’s just something cool.
Kirk: One of the things I love is we explain the concept of a wish list to our customers very early on. I think you may even go over that in the kick-off call.
Susan: I think so. If we don’t, they certainly learn about it pretty early in the process.
Kirk: In other words, we already know how to answer the question of hey what about this? What about that? You’re exactly right. Number one, it will take you off track. Number two, a lot of times you’ll go ahead and pursue the original scope, the original value you defined, you’ll find out that what they’re asking for maybe was not that valuable. Or if it survives on the list then it probably was. Then you can address it after the first phase is done. You’ll actually be able to address it better because now you’ve completed the first project.
Susan: You’re not in the heat of the moment. You’re not in the spark of brilliance, this is the best idea I’ve ever had moment. You’re in the is this actually going to bring value to your team, to your project, to your solution?
Kirk: Everything that’s brought up needs to be held up against that. You need to look at it from the viewpoint of value.
Susan: Absolutely. Some things are harder to identify value, too. If you have a whole long list of bugs that weren’t gotten to because the testing wasn’t completed by the customer, that’s going to be a lot harder to define. This is the all of the new value you’re going to be getting out of this. There is value in fixing in fixing what should have been fixed in the first place.
When you get to that, it’s going to enhance usability for your user. Those things you can address in that way. If you don’t put that end date on it, you will never finish. The person asking the question is correct, you will never finish.
Kirk: It’s interesting. Even bug fixes have value. The value there I think is quality. We struggled with a long time with how do we get customers to test? How do we deal with this? We finally were able to frame it in a way of look, the value of bug testing is quality of software. Bugs happen. Bugs happen in all software development. If you don’t want to deal with bugs, don’t develop custom software.
At the same time, we offer our customer options, different degrees or levels of dealing with that. We basically allow the customer to take more or less ownership of the quality based on an exchange for a price. We feel like if we’re going to take on more responsibility for the quality, then that’s valuable. There’s a premium price on that.
Susan: That’s something we’ve called user assurance where I, as a non-developer, will get in from the user’s perspective and actually test it from that perspective as well. I’m still not testing it the way that their process works, the customer’s process works. They have to test that. They have to provide that input. There are going to be bugs.
There are a lot of things that I find that I can look at and I’m like, “I see why the developer did that, but no, it’s not right. Make it more clear. Make it a different color. Make it stand out more, something to that effect just to make it more user friendly.” There’s great value in that because if your users don’t buy in to this solution you’re not going to get the value that you wanted in the first place.
Kirk: I’m looking at the question here. One of the things that he asks is what is finished? Then he asks, what is success? In my mind, those two things go hand in hand. In other words, you can’t be successful if you don’t finish.
Susan: That is absolutely correct.
Kirk: You can’t finish if you haven’t defined what success looks like.
Susan: We do that in our proposal. The value stated. The scope is defined. We even tell them on the bugs if we report them on time, we get them fixed. It’s probably going to go beyond the period that we set. If they report them in time, we’re going to address them.
The success is really in the end are your users using this? Are you getting the value you wanted? We make sure at the end of the project I send an email out that says, “Listen, everything is wrapped up. You guys should be using this. I need you to let us know if there are nay concerns or anything that we didn’t address that you feel like we should have.” It gives an opportunity for a customer to say, “Wait yeah you didn’t do this at all.” Then we have the opportunity to serve them and solve that problem or come back and say, “We didn’t ever say we were going to do that. That’s not in the scope. We can talk about doing that in the next phase.”
In that email when I close out the project as well I also make sure that they know that I’m going to reach out to you in not more than a month and check in on how things are going. Make sure that if it’s time to address the items that we put on your wish list. We always recommend that they use the software for a while before we come back and add more things to it. Then I reach back out to them in a month if I haven’t heard from them sooner and we go from there.
Kirk: It’s interesting the second episode that I did with the Art of Value Show was with Ed Kless. It was called the value of project management. The interesting thing, the theme of that show that’s coming back in this one, is what Ed said. In fact, Ed said something that at the time surprised me because I hadn’t heard him say it before because Ed is just a book of wisdom. There’s always something new. He said, “You can get so good at having the value conversation that you don’t need project.”
Susan Fennema: Right because your customer knows what to expect. Our favorite customer today came in and said, “Hey I know I’m past the bug period but I’ve just found this one thing.” I was able to say, “You are actually our favorite customer. We actually do know what’s wrong with it. We will do it for you.”
Not everybody gets that benefit. They’re right on the edge of their bugs, they just found out. We know we’re going to do more business with them. They’re clear on what the problem is. That is making sure that things give customers the value that was intended.
Kirk Bowman: This particular customer I think there’s other reasons why we give them benefit of the doubt. In this particular situation, I think I remember this customer something along the lines of going around the building bragging about how she was able to do something so much faster than she was able to before. They share the joy of the value. We now the value is there because they’re so excited about it.
Susan: They are so excited. She also said something to the effect of she was crying tears of joy after one of the projects was over because it changed her life. That’s what we want to do.
Kirk: That’s why we focus on value. You can’t change somebody’s life by focusing on hours.
Susan: Nope. You can’t change it really by focusing on scope. The scope has to come from the value.
Kirk: Does the scope contribute to the value?
Susan: Of course it does. It has to. If you don’t have a defined scope, you can’t ever get the value because you don’t ever finish your project.
Kirk: It’s interesting I said that comment one way and you read it another. Both are correct. My point was along the lines of the value drives it, not the scope. You then flipped it around the other way and said, “You’re not going to achieve the value if you don’t define the scope.”
They’re hand in hand. They’re related, right? Value comes first. Scope comes second. The reason you have to have a defined scope is so you can get to the value.
Susan: Yes I know in your initial conversations the customer seems to know what they want. You don’t even talk about that. You talk about really why they want it instead of what they want. That first conversation doesn’t even talk about scope.
Kirk: No. To some degree, I have to get some idea of what they want. I have to talk about it a little bit. You’re right, I will try to pivot the conversation fairly early on towards why do you need this?
Susan: It’s a big picture conversation about what they need as opposed to the details.
Kirk: The devil is in the weeds. That’s what discovery is for. What else would we add on this question how do you know when it’s finished? Anything else you would add just to wrap this up? Is there anything we missed?
Susan: You want the customer to agree it’s finished as well. You want the customer to want it to be finished. Darren, our senior developer, often says, “Custom software development is like having a baby. You have to go through all of the pregnancy pains. You have to go through the labor. At the end you get the baby and that’s what everybody wanted was this beautiful, perfect baby.” We want the customer to want that baby too and to get over all of these pains and problems that go along with it and get to where they get to make an adult now.
Kirk: I think that’s an important expectation that you have to set with the customer regardless of what you’re doing. I think this applies to accounting, legal, design, development, consulting, any professional service. The greatest joy comes after the project is over. It is hard work to go through the project. What I typically say to our customers is it’s going to get messier before it gets better. You’ve got to go through the Red Sea to get the problems fixed.
Susan: With our custom software development often times that mean that a customer is having to do things two ways. Sometimes simultaneously but definitely having to merge that process over in their world. People fear change for a reason.
Kirk: Would you agree that customers are more willing to go through the difficulty of any project because the value at the end is great enough that they can keep their eye on it?
Susan: Right. It definitely is something that you can bring them back to if they start to get off track. We want to create these things for you. Tell them all of the time. We can’t help you unless you help us kind of thing.
Kirk: Susan, this has been fun. We could probably keep going. At some point people need to stop their workout and go on to other things. If you have a question that you’d like for us to answer, let us know. Shoot us an email. Go to the website. Leave a comment. Go to iTunes and leave us a review, leave your question there. We read all of those.
We’d love to know what would you like for us to tackle? Is there something that we said on this show that you’re going man that makes no sense? I need you to go further. Let us know. I’ll have Susan come back in and we’ll do another listener question episode in the future. For now, Susan, thanks for joining me.
Susan: It was great to see you.
Kirk: Two points that I want to summarize from this episode. Number one, you cannot define the scope if you do not first define the value. Second, the customer will not begin to realize the value if you do not finish the project.
I’d love to hear what you think about this episode. Would you like to have more shows where Susan and I take a question and go in-depth on the answer? If so, be sure to leave a comment for us on the show notes page. You can find that at Artofvalue.com/33. As always, we’d love for you to leave us a waiting or a review in iTunes. You can do that by going to Artofvalue.com/iTunes.
My guest on the next show will be Verasage senior fellow Tim Williams. I’m really looking forward to this interview as we dive into Tim’s expertise on positioning. Until then, go create more value.