I know had previously written about Partner business models, but I can't find that post. I recall discussing our "Blocks of Hours" model, and how it was working well for both us and our customers. But I was seeing some cracks in it, and decided to create yet another business model, that we are starting to use now, that shows even better potential. What is a Business Model? At some point in talking with a customer about how awesome you and your team are, and hearing about what they are...
I know had previously written about Partner business models, but I can't find that post. I recall discussing our "Blocks of Hours" model, and how it was working well for both us and our customers. But I was seeing some cracks in it, and decided to create yet another business model, that we are starting to use now, that shows even better potential.
What is a Business Model?
At some point in talking with a customer about how awesome you and your team are, and hearing about what they are hoping to accomplish, they will ask "So how do we engage with you?" They will have to ask, because we all have our own ways of working with customers. I have tried them all, and don't like most of them. Each one that is in common use today has it's "fatal flaw", maybe for you, maybe for the customer, or sometimes both. Let's review a couple for fun.
Fixed Scope-Fixed Price
Most customers think that this is the model they want. How can they get budget approval without a fixed cost? This is particularly acute with Government or Large Enterprise customers. You could answer with a range... it could be as low as $x, or as high as 2 x $x. Which number do they go to management and ask for? In our business, the fixed-scope will not survive the first kick-off phone call anyway. Since the time you developed the requirements, Microsoft launched three more applicable features. Fixed Scope-Fixed Price is the most antagonistic model there ever was. It literally turns the engagement into a battleground from the jump. It does not work for either side, so we'll toss that one in the toilet.
Value Based Pricing
The idea here is to abstract away the actual effort required, and price things according to what their value is to the customer. This one is completely partner-centric, basically charging normal costs for normal things, but hammering the customer for the shit they really want. This model assumes that customers are morons... this one ends badly.
Time and Materials
This one seems pretty safe for the partner, although upside is limited. No scope, no price, we just put our heads down and start working. At some point we look up to a customer who is saying "What the fuck have you been doing?", "Oh, you know, just bopping along." No structure, goals, plan, or timeframe. This one usually comes to an abrupt end, with no finished work.
A Little Better Model
Several years ago we went to a "Blocks of Time" model. Customers could purchase blocks of time in increments of 10, 20, 40 or 80 hours. These were pre-paid, so it eliminated any chasing money on our part. It was a blended rate that covered anything they wanted to do, and unused time expired after six months. It was similar to a regular T&M model, but was promoted as more of a modified Agile approach. What I did not like about it was the lack of accountability, on both sides. 40 hours is basically one week of one person, but with six months to use the time, nobody was in any particular hurry. It would not be unusual for a customer to go quiet for weeks, and then come back all fired up to resume. In the meantime, we re-assigned people, forgot where we were on their project, and it was just not as efficient as it could be. The upside was the most the customer could buy was 80 hours at a time, which meant we both had the opportunity to end the engagement whenever a block was consumed. It was a pretty good model, but I saw room to improve it.
PowerSprints
I liked the idea of "blocks", but it was lacking the urgency and accountability on both sides to actually get shit built... quickly. Time is the killer... endless projects that meander around are not good for anybody. I originally started thinking about time-boxing the blocks, getting away from the six months and tightening that up... a lot. I ended up with this idea that I'm call "PowerSprints" (Neil Benson is shaking his head at this moment).
Basically, a PowerSprint is one week of effort by a team. I have small, medium and large PowerSprints, while each is one week in duration, their size will determine the velocity as they have progressively larger teams. An engagement starts with a required PowerSprint Zero (5 Man-days). I stopped providing free consulting, under the guise of "Pre-Sales", years ago. We use this week to perform any analysis, setup environments, pre-requisites, etc, and conclude with an initial backlog for the first PowerSprint. We will also create a high level schedule of time and sprint sizes, which can vary from week to week depending on what needs to be done. This schedule will be a range of "Best Case" with up to a 100% contingency, in case all hell breaks loose.
We will mutually agree with the client on which week a PowerSprint will begin. They need to be ready for continuous communication and daily deliverables, and we need to be ready to execute. The PowerSprint begins on a Monday morning, and is continuous effort and deliverables until Friday afternoon... and it's done. What got done? As much of the prioritized backlog as possible based on the team size. This is what you call "Not Fucking around".
A small project may only require one Small PowerSprint... but it's done in one week. A large project may require several successive sprints, and potentially some off weeks to all catch our breath.
What do I like about this model? Well, as long as everybody is on-board, focused and ready... this is a "Shit gets done fast" model. What are the possible drawbacks? There are a couple of risks. On our side we have to have a team in place, focused and ready. A Team typically consists of a B/A who can also do configuration, an Architect, an Account Manager, a Developer and a Q/A person. The make-up of the team is flexible depending on the sprint backlog, as long as it adds up to the same man-days. For the customer, the risk is that they think they are ready to hold up their end, and then are unable to for some reason. Once a PowerSprint starts, it does not wait for anybody, and ends on Friday, ready or not that PowerSprint was consumed. If the customer is unable to engage, they will get our interpretation of the backlog.
So we are starting to use this model, and having good results, I would love to hear others' opinions.
