Selling Agile to Small Businesses: A Challenge
I think anyone with experience of developing projects based on a Big Design Up-Front understands the problems that Agile development can solve. Clients seldom know what they want until they see something else and with fixed bid/fixed scope project the job of the developer is to develop what the client originally requested as quickly as possible while discouraging and charging for change requests. There is often "dark matter" that wasn't described within the scope, leading to arguments over what is reasonable, and most times projects either don't meet client needs, go way over budget, lose money for the developer - or possibly all three. BDUF projects are usually disheartening for the developer and positively bad for the client. The question is how to sell the alternative.
Imagine that you are CEO of a small chain of sporting goods stores, the office manager in a small to mid sized law firm or the sales manager for a die-cutting shop in Ohio. You have fought tooth and nail to get $15,000 out of the marketing budget this year to upgrade the website that your cousin developed using FrontPage in 2002 to freshen up the look and to add some more functionality. You want a website that'll do better in the organic search rankings, a new look and feel, a way to update the content on the site yourself and you'd also like just a little magic pixie dust - functionality to bring your website to life. You might be looking for online commerce with the ability to order online and/or pickup from the store, you might want a secure document exchange for client projects or for sales sheets for your reps on the road, or you might be looking for better content management so you can easily associate practice areas, professionals, and the articles they have written. You feel like you have enough budget to get just what you want rather than choosing an off the shelf package, and you're looking for a team of professionals to really move your business to the next level given that you're investing almost 20% of your annual budget in the upgrade - you could have exhibited at two local trade shows for this amount of cash, ad you've seen that you can get Yahoo! stores or a web based cms for $50 a month, so this better be good!!!
You're looking for a development team that "gets" the web. They should understand marketing, SEO, design, and be able to program a good quality, secure applications that meets your exact needs. You're even open to offshoring. You don't really care where the website is built (I mean - HTML is HTML) as long as someone trustworthy sits down in your office every week to explain how the process is going.
One developer comes in. He asks some questions, says he knows what you want, and gives you a nice 12 page proposal (11 pages are boilerplate) for a $15,000 project that echoes back all the things you asked for. He was presentable, well spoken, you got along well with him and he seemed to really understand your needs. You looked at some of the sites he has done, he had a decent website, he told you that he offshores the programming so he can build you a better website at a more affordable price and he told you he'd make sure you were top 20 in Google for some keywords.
And now we walk in. We know the benefits of Agile programming because we have over a decade of professional programming experience. We've developed web apps big and small. We know that ANYONE can get you in the first page of Google - just not for terms anyone will be searching on, and we know that as we talk more about your workflow requirements for the document exchange or for some of the custom features that your store needs, it's probably going to take a paid discovery phase just to capture your requirements with sufficient fidelity to provide an accurate quote. We also know that what you are asking for probably isn't what you actually need (you say you'd like a blog, but what you really want is more leads) and a little bit of business consulting would really help you to get the best value from your technology spend.
Where to start? We don't know what other proposals you're received (although it is a fair bet you're received a number of fixed bid quotes just echoing back your fairly vague requirements). How do we get the project and save you from the heartache you're otherwise very likely to experience?
We definitely believe that using pre-built models, code generation, CSS design frameworks and other productivity best practices that we could add real value in 150 man hours at $100 per (to keep the math simple). The bare truth is that if we are good at what we do, the best deal for the client is to engage us for 150 hours. We'll work with them with 3-5 hours of business consulting to refine their business objectives, we'll agree what pieces we can pick "off the shelf" and what needs some custom programming, and we'll work iteratively by wireframing, then generating and finally skinning a site that'll provide the absolute maximum value in the time available. So, the proposal that would be in the best interest of the client would be a "trust us, give us 150 hours, and see what we can do". Unfortunately, such an approach puts all of the risk on the client. Can you imagine what their boss (or husband/wife if they're CEO) would say if the project went wrong and the quote was just for time and not for results?! Also, how can they reasonably tell how good you are? In my experience, most decision makers simply don't have the knowledge to discern quality in software design.
So, your job is to craft a proposal, a value proposition, an approach that would be compelling to the vast majority of decision makers in this situation and that'd probably get you the job. What would you do? Where would you go? How would you sell the story? I have some ideas, but I'd love to hear what y'all can come up with first.
The only success I've ever had selling agile methodologies is by establishing trust first on a personal level. Usually, I sit down in an initial consultation, and try as much as possible to remove all formality or "professionalism" from the meeting - just asking them general questions about how they run their business and showing genuine interest, and resisting the urge to make any recommendations at this first meeting at all. Just taking this genuine interest in their company is the best way I've found to generate trust. After I have that, it's much easier to sell the agile methods, because basically what you've sold is - "I'm interested in making you succeed. Let me see what I can come up with"
The problem is, this only appeals to a certain, small subset of clients, and it can often be a very long sell. As such, I try to not spend too much effort pre-sale. I never chase Request For Proposal's, and if they're expecting an 11 page document before-hand, I just move on to the next prospect.
I should mention that these methods have Not brought me untold riches, so if anyone else has a more profitable idea, I'm likewise eager to hear it.
However I also find that many clients are "just looking for X". One approach would be to sell FUD> Ask if they have quotes, then ask a bunch of questions showing they don't know what they really want and ask them if they really believe that if the previous vendors didn't ask those questions they believe they are likely to get a app that meets their needs irrespective of what the proposal might say. However, I'm not generally a fan of the negative sell.
I certainly have some thoughts, but would love to see what other people are thinking/doing. Let's see what comments we get!
Our quotes are always based on an estimation of man hours, making it clear that we're quoting on a very specific set of functionality and that substantial scope creep will always incur additional development costs. This just seems like common sense and means we provide clients with a like-for-like comparison with others firms. We always stress that we work closely with clients and that our development process involves iterations and requires frequent client review.
In my experience most welcome the opportunity to see progress in the early stages of development. They also appreciate the frequent contact, rather than intense specifications gathering followed by long periods of non-contact while you attempt to realise their "Big Idea".
I'd love to hear a little more about your experience as I've always had problems selling an estimate as opposed to a fixed bid . . .
What kind of price point do you play at, and what kind of experience do you clients have in working with software development? Is it $15-$25k projects or a fair bit bigger than that?
Also, do you have a paid discovery phase? If not, how do you get the "very specific set of functionality" - how long does it take to elicit that on average and are you charging for the process?
Also, in my experience, with an agile approach it is quite plausible that you'll only hit half of the function points, but you'll end up deciding it is better to hit those properly (with many revisions) than to try to knock out all of the functions that seemed important when specifying the project. Don't your clients have an issue if you estimated X hours any 12 use cases and you only deliver 6 but expect payment in full?
To me, with agile you're selling the fact that they don't really know what they want,. but you'll help them to identify and deliver the best business value in the timeframe. With a fixed quote/spec (even if it is only an estimate), most clients feel like you are committing to an implementation of a given set of functionality for a given price (give or take a little if it is an estimate).
How do you sell against developers that offer a guaranteed fixed price against your estimated one (saying they're prepared to take the risk as they know how to price a job and to build it more consistently than you)?
I'd love to hear more!
It goes back to risk reversal. I don't know you from Adam - why would I pay for your time when I don't know whether you'll be able to solve my problem when someone else is promising me a fixed price for a desired outcome?!
My problem is I'm never actually asked this question to my face. It's just a question that's asked (and answered) within the client company, so I don't get to weigh in.
Maybe what I'm missing is a good analogy with positive associations which makes agile seem like the smart choice. With the "house" analogy, some guy saying he'll pour some concrete, start slapping down some bricks, and you'll see how many bedrooms you have before you run out of budget doesn't exactly inspire confidence :->
What would be a good analogy for agile development? Not something like lawyers or accountants as (at least to me) I HATE lawyers that don't work on a fixed bid basis. What would be a good analogous example to Agile development that would show it is stupid to try to commit to delivering something upfront?
I think one of the issues I have with Agile is that it is predicated on the client not knowing what they want. In my experience, the client never knows what they want (with sufficient detail to be buildable), but they almost never REALIZE that they don't know what they want. To them, there are just some details that need to be clarified in the build phase and they don't get why you're making such a fuss out of the details when everyone else just gave them a fixed bid based on their nebulous wishes and a short chat.
Thoughts?!
I'm talking about the entire process - start working with an architect, selecting the land, building the entirely custom home. What if I decide to build a basement after they've framed the house?
My guess would be you'd be hard-pressed to find a builder to do it fixed bid, because there are just too many unknowns. But, I've not been in that situation, so I can't say for sure.
You have two builders. Both seem equally capable. One will fixed bid, one will only estimate. Many people would feel safer with the fixed bid - no?
Let's say there is a project you're selling. You know you're going up against a fixed bidder who has similar qualifications, experience, rapport. All other things being equal, what is the pitch to show that estimate or agile is better for the client - something that ven a marketing manager could understand?!
You're right in your guess that most of my work has been on projects in the $15-25k region, and at anything below this threshold there's something of a feeding frenzy where developers quote ridiculously low prices for functionality that they can't possibly deliver. For this reason we don't try to compete on price, and if a prospective client starts trying to play us off against another developer we walk away. That hasn't always been true, but we've learned the hard way that there's a world of difference between a client who wants the cheapest solution and a client who wants the best value solution.
It's my understanding that an estimate is legally bound to be within 10% of the final fee (at least here in the UK). This is why it's so important to define limitations of scope in written form. In the past we've landed a couple of contracts where we've been the most expensive solution (by 30%!), yet the client still chose to work with us. I'd like to think that wasn't just down to writing a slick proposal but down to our interpersonal skills. Our clients are typically small companies with little or no experience of software development, who appreciate good communication and the ability to explain things in a non-technical way (training is also a part of our delivery process).
I have done paid discovery phases in the past for larger projects, especially when the client doesn't have a clear idea of their requirements, but each time I do this I get better at preempting requirements (as long as I'm not speaking to a "screen" - the sooner you can get to the specification maker the better). The timeframe for this sort of investigation varies greatly depending on budget and client experience, but it gets easier each time I do it. Because it's a process that could go on forever I try to gauge I've got enough information to provide a relatively accurate estimate and/or start development. That point will be different for each developer and client. I used to avoid direct client contact whenever possible, so I'm still pretty new to all this (but I *have* seen the error of my ways).
I have a feeling that even if you find a fixed bidder with similar qualifications as you, your high estimate will probably come in at around their estimate. Even if it is higher, as long as you are no worse than middle you still come out looking good. If clients can't understand that there is a certain element of risk and uncertainty involved, and demand that the estimate be exact, do you really want to work with them?
I think we're starting to hit on the "bad" type of clients here and some questions you can ask before hand. If they are uncomfortable with the way you want to work and you are uncomfortable with the way they want to work, perhaps you can each find someone you want to work with rather than forcing the situation. Of course, you might want to explain WHY you work the way you do before you make a split, and then if they are still not prepared for that, what else can you do?
As for the ridiculously low bids - you can't compete anyway, so why try? Perhaps when they fail the client will think of all those things you told them and come running back to you to rescue their project.
Going back to making potential clients feel more comfortable, have a few referrals ready, along with any demos of similar applications (or just good ones you've done)
The team will be constantly focused on the highest priority issues as determined by the product owners at the beginning of each sprint, and the product owners can determine when the app is 'done'
Doug S.
Makes sense. Couple of questions. Do you ever have to bid against companies that simply provide a fixed bid for a fixed scope and what kind of people purchase your services? Are they experienced IT managers? Marketing managers? Have they dealt with software projects before? What makes them choose Agile over a fixed bid? I understand why agile is a better way of producing software - I'm still having a problem with how it sounds like a better value proposition when SELLING software development - especially to buyers who haven't been previously burned by fixed bid projects.
If the client were a software architect and skilled programmer he would still have trouble completing his desired site in a predetermined amount of time. It's either the site he wants paying for the skills he lacks or just a site that fits his budget.
http://rssnewsdigest.com
http://realwebnews.com/