I’ve had quite a few emails about my post on Agile and the Professional Services Sales Process. I recently ran across this podcast where Scott Ambler and Bob Payne talk about the consulting side of doing agile projects. The podcast isn’t focused on this topic, but you can find it at about the 20 minute mark (although the entire podcast is very good).
Check it out, it’s worth the time.
A question came up at the “Advances in Agile” session today (at the PDC) about how to structure the sales process from the standpoint of a consulting firm. Some thoughts were given by the panel members on this, but I’ve had to deal with this problem multiple times and thought that I’d offer some insights after contemplating and addressing this idea for a couple of years now in a handful of different consulting firms.
The problems…
#1: The typical SOWs and project proposals for the standard consulting engagement typically constrain us to a structured delivery approach. Sales guys sell what they know and the standard most are familiar with selling BDUF projects. Typically this is structured after a waterfall process simply because contracts have typically been structured this way. This is a big problem because it legally binds us to deliver a structured process and the standard SOWs limit us to doing what is in the contract (whether or not it is the “right” approach for the customer).
#2: The typical company that we work for has a BDUF mentality for their budgeting process. Usually an individual or team will need to get a budget (up front) approved for the entire duration of the project. This is a big problem because they purchase solutions like they are buying a block of cubicles. Building software usually doesn’t follow the same approach as buying cubicles because we don’t have a good idea of the effort required before the project starts (or we do, but it changes because the business dynamics change or new opportunities arise, etc.).
The bigger problems of these two items is that both assume that we are using a structured approach and not an empirical one. In my experience, empirical approaches (in software development) usually trump structured approaches and provide the highest satisfaction, ROI, and overall value to the customer. Many items in the day-to-day operation of a business follow structured approaches and both of these items have traditionally been handled like everything else.
Given these two problems there is one that is directly in our control and one that we can (at least attempt) to influence. Number 1 is up to our firm and is a fairly easy problem to tackle. As we move forward with our customer (and prove value) and achieve a high degree of trust and influence we can start to take a look at the client budgeting process.
A possible solution for #1…
Simply remove the structured approach. We can achieve this by not defining the deliverables before we know what they should be. We should be on the ground and learning to determine the artifacts that provide the most value to our customer. When we take a structured approach, we are forced to guess (which we historically do a very bad job at). We should never be forced to guess because we don’t have anywhere near the right amount and quality of information at this point to make a well-informed guess.
Even though we don’t admit it very often, we are really making a poorly-informed guess and then protecting ourselves by implementing verbiage and process (and insurance) around change control methods. Change control sucks and it’s a bad solution to a self-imposed problem. Change is good and we shouldn’t punish our clients for changing their minds.
The best way that I know of to follow an empirical approach in selling services is to provide optional scope. If you have optional scope, it doesn’t matter if you have a T&E or fixed bid project and the client can choose what fits best for them. The shift in the billing cycles typically moves toward a subscription-basis. For instance, you could provide 1 month iterative billing cycles so that the client can choose when they are paying more money that they are getting back in value. If we are implementing the items in order of priority, the customer should see a positive return ratio in a much faster time than if the approach was structured. If the customer is consistently losing money, there is no reason for them to continue the project. Of course, it’s not always about dollar-based ROI, but you get the idea.
Thoughts on #2…
Unfortunately, this is simply the way things usually are and this is not an easy process to change. As a technical consultant, it may not be your place to try and influence an agile budgeting process. My approach to this problem varies from client-to-client and depends on the level of trust that the client has in both myself and my firm. The net present value of agile approaches typically comes into play at this stage and is usually the best bet and the most likely to show value to the individuals and groups that control the budgeting process. Taking the stance of failing faster also helps out here because you can let the financial influentials know that mistakes can be cheaper (in my experience, usually 10x or 20x cheaper). I think the fail-fast value proposition is huge, but it is often strange to position because it’s often perceived as a pessimistic statement (although it is very true).
Typically, I would say that number 2 should start with a casual discussion and not as part of any sales process. The problem is very prevalent and I think it will probably be a while before we see this change. If you successfully deliver a couple of agile projects, this gives you a good basis to start the conversation and I would position it as something to think about — not necessarily something the client should do.
Some other frequent questions…
What if the customer demands fixed scope? If they demand it, give it to them — just keep in mind that you likely won’t be doing agile. Please don’t say it’s agile and please don’t ask me to come work on it with you. 
What if the customer demands a fixed price project? Offer them fixed price iterations with optional scope (with this approach fixed price and T&E are irrelevant).
How do I estimate the duration of an agile project? You don’t. The customer does. You can guess, but make sure it’s identified as a guess and not a commitment. I wouldn’t recommend guessing and think that you should only do it if you have enough information to guess and you’ve been in a very similar situation before.
Hopefully this helps someone out. I’m also interested in hearing other approaches that individuals or firms have taken to try and tackle this issue.
