Power Platform and the Definition of Done
One of the sessions at D365 Saturday Philadelphia this past weekend was “Managing a D365 CE Project” by Jennyfer Hogeland, it was a great session. On one of her slides she described “Definition of Done”, and that phrase stuck in my head.
I don’t know about you, but when I hear the word “Done”, I assume something has completed. When I am “done” with a meal at a restaurant, they take my plate away, bring me my check, and the wonderful relationship I developed with my server comes to an abrupt conclusion. When the service manager at the car dealership leaves a message on my voicemail that my car is “done”, I go down there and get it, and our relationship has concluded, hopefully forever, even though he seemed like a really nice guy. “Done” means something different in the software deployment world.
Done times 100
With Agile methodologies, big projects are broken down into smaller parts. Fellow MVP Neil Benson can fill in all the details around this for you, and will probably correct everything I write here. For this post I just want to say, that for each of these smaller parts, there is typically a concept of “Definition of Done”. Some people call this “Exit Criteria”, which sounds equally terminal. Regardless, if your project gets broken down into 100 parts, you will get to “Done” 100 times. Kind of like when you complete your appetizer, and they take that plate away and put another one in front of you, except it would be a 100 course meal.
Done as a Beginning
It is not uncommon for a development team to feel they have met the “Definition of Done”, only to find that the customer did not understand the definition in the first place. “What do you mean Done? What about xyz…?” It is not that hard to come up with a definition of done that your team understands, it is exponentially harder to come up with one that your customer understands. Their advance agreement is not a reliable signal that they actually understand what they are agreeing to. Why would a customer agree to something they don’t understand? Often, it is because they don’t want to appear like they don’t know what you are talking about. They are content to understand what you mean, after you get there, and then renegotiate if necessary.
Done as a Flag in the Ground
One of the key advantages to your development team is creating several points along the path where they can plant a flag and say “This thing is done“. It should protect both sides from misunderstandings, or at least limit the damage to either party when there are misunderstandings. If we waited until the end of a year-long implementation to say “Done”, all of those misunderstandings will be a wave that will wash over everyone involved. Another fellow MVP Gus Gonzales recently did a podcast outlining these very issues using a real world case… case as in law suit.
When engaging an implementation partner, it is quite common to have your discussions conclude with a “Statement of Work”. A typical statement of work will attempt to define the deliverables and the costs associated with delivering them. It may have been created pursuant to a list of requirements from the customer, or several pre-sales phone calls or meetings. The lazy SOW says, “We will deliver all of the requirements from your list, which is attached, for $X dollars.” A customer who signs off on that is an idiot, and the project is already doomed. A better SOW does not even reference the customer’s list, but rather replaces it and covers each aspect, broken into chunks with a “definition of done” for each chunk. But, I would never give a customer one of these either. In fact, we don’t give customers SOWs at all.
Why SOWs don’t work anymore
I think SOWs were always a shitty way to create a contractual relationship, but never more so than today. All SOWs are ultimately agreed to at a “point in time”. Back in the day, that point remained fairly static throughout the life of the engagement. Not so anymore, not even close. A month after that SOW was memorialized, new features were released that the SOW did not contemplate. Now what, do we continue down the path, or maybe look at whether any of these new features make more sense for one of more aspects of this SOW we are both bound by? If they do, do we both mutually agree to change the scope. Does that change in scope require a change in cost? Are we going to argue over that because you think I have you over a barrel? Am I going to be a dick about that because I actually do have you over a barrel? If we ultimately agree, what are we going to do next month when it happens again? It is little wonder that so many of these relationships turn out sour in the end, or worse, in litigation.
Several years ago, I got fed up with the broken SOW process. While I never put my foot on a customer’s neck, they frequently assumed I was, because I could. My Dad once told me that, “Leverage always exists, there is no such thing as neutral… who has it at the time, may not be clear“. I can certainly recall being on the phone back in the day with customer making all kinds of demands, assuming he had some leverage, when in fact he did not. It is not a good place for the customer to be, and I did not like it either as you may have gathered from my last post.
I decided that we were going to take a business risk, by no longer responding with SOWs… or fixed cost agreements. They create an antagonistic relationship from the jump. Our “risk” was whether customers would go along with the idea. We did not invent this idea, but at the time, it was pretty novel in our space, and still is. We developed a two-page agreement, where customers could pre-purchase blocks of time, the larger the block, the lower the rate. What could be done with this “time”? Anything the customer wanted. We also simplified the tiered rate structure into a single blended rate. The whole concept could be digested in about 3 minutes, without the legal department having to look for “gotchas”. Many other partners told me that no customer, particularly large ones, would ever move forward on this basis. They were wrong. Since we launched it, we have helped hundreds of customers, including multiple Fortune 500 customers, and the freaking United States Navy. In fact, there as been virtually no resistance at all.
Selling Time Blocks
I still had many partners not believing that customers would engage this way, being unable to imagine their customers going along. I have also talked to some who said they tried, and had limited success. Compared to our 100% success rate, I decided that this was a sales problem for these partners. I know their customers would go for it, if they presented it the right way. The key point is that every customer who ever did an SOW or “Fixed-price” agreement was not happy with that model either. That trend is getting worse, which can easily be seen by searching for example “Accenture Lawsuit“. Not to pick on Accenture, their current woes are just fresh in my mind, but SOWs and Fixed-price agreements are ending in litigation at an alarming rate today.
How about instead of going down a path with a high possibility of failure, you instead try something that minimizes the risk to everyone. In our case, the maximum size block a customer can buy at one time is 80 Hours. Why? This means that every week or two, we both get to reassess our relationship. While leverage may still exist, it is more equalized. If you are not happy with us, then you can go another direction, the block was consumed, and we owe each other nothing. On the other hand, if you are a raging asshole, once the block has been consumed, I can say adios. But another thing I have noticed in this arrangement is there is seldom a need for the customer to become a raging asshole. In fact, I don’t recall off-hand ever saying Adios to one.
This concept dovetails nicely into Agile frameworks also. You can’t get much more “Agile” than being able to redirect all energies in a new direction when new features are launched or other realizations are made by the customer along the way. No change-orders to argue over, no hard feelings, the river of effort just flows down whatever tributaries the customer wants it to.
Hey, wait a minute
“Steve, you seem to be glossing over a huge aspect for partners. Where we make the big money is when we come in way under cost, in your scenario this windfall would not exist!” First, I would say that you need to subtract from your windfalls on the winners, all of your losses on loser projects, and come back to me. If you ever chatted to a gambling addict, all they talk about are the times they won. But, if your winners do vastly outnumber your losers in dollars, then you would be right. This model assumes that your customer will actually get an hour for every hour they purchased. Which, by the way, is a other huge selling point! We obviously generate a margin on each hour sold, but there are no opportunities for a huge windfall with this model. Conversely, it is also impossible to end up upside-down on a project. Since customers pre-pay for the blocks, we also have no account receivable department and zero collection effort.
I think so, if the profitability of your business is dependent on windfalls from winners to offset losses from losers, then moving to this model will help you at least sleep. You can also move from having a few key customers who will sing your praises, to have every customer doing so. This certainly makes getting more customers a lot easier. When your prospect asks for a reference, it feels good to be able to respond with: “Sure, how about every customer we have?”.
I get that this approach is not for all partners, though I am not sure why. I also get that not all customers will go along, but I have yet to run into one. I am happy to discuss with any partner how we make this work, or any customer who wants to explore it as well.