The economics of MDD for Consulting Organizations

During the final session of Code Generation 2010 last week in Cambridge, England, Eelco Visser raised an interesting point. Consulting firms often don’t have a financial incentive to adopt MDD. I also made some remarks that I wanted to flesh out. One of the main benefits that MDD provides is the ability to build and maintain applications more quickly and cost effectively. For in-house development this is a no-brainer. The lack of adoption of MDD for in-house projects points to the presence of additional reasons for not adopting MDD, but I want to concentrate in this post on the additional issues facing consulting firms that want to adopt MDD. In my experience, adopting MDD raises a range of sales, marketing and operational issues for consulting businesses.

Negative Return on Investment

For most consulting firms, they charge by the person hour/day. As such, any time not billed must add value in some other way to the firm. By developing MDD expertise in house, most consulting firms will get a negative ROI. They will be investing un-billed time in creating solutions that will allow them to make *less* money as they will be able to deliver the same functionality in less time! Without some other change to the business model, that just doesn’t make economic sense.

Price isn’t Everything

Of course, one of the benefits of MDD is that you can provide solutions more cost effectively for your clients, however, that isn’t necessarily a key differentiator. If I have a $50,000 budget for a project, three firms come in at $45-$65,000 and one firm bids $5,000, unless I know a lot about that firm, I’m very unlikely to hire them. I have the $50k, I’ve been told to find a supplier for $50k. Selecting a $5k supplier has a high probability of getting me fired if anything goes wrong – and with software projects, something always goes wrong. So, the thought that one MDD firm is suddenly going to blow away all the other consulting businesses by successfully winning the business at a substantially lower price seems to me to be unrealistic.

Breaking the Sales Process

There is another issue with consultants changing their price point substantially. They’d have to completely change their sales organization/process. For example, in the US, you have to be selling solutions that run at least $15k to have traditional sales reps. To successfully retain and compensate experienced software sales engineers, the number comes closer to $50k+. Just imagine the average sales person taking eight meetings a week. Assuming they do three first meetings, two second meetings and one third meeting to close the average deal, that means a deal costs 0.75 of a week from a sales rep. With a base of $40k, commissions of $30k and another $30k to cover expenses and overheard, with a rep working 50 weeks a year, that’s 0.75 * $2,000 or $1,500 per deal just for direct sales costs. I’d say those numbers are conservative. A safer loaded sales and marketing cost would be $2,000 per project which makes it difficult to sell $5,000 projects this way. Also, generally the cost of the sales process is related to the project size. I tend not to bid on $200k projects. I’m just not willing to put six people into meetings and to do the kind of speculative upfront work to pitch those deals. I also remember back in the early 2000′s when some interactive agencies tried to go from $200,000 projects to selling $20,000 solutions. They found out pretty quickly that their sales process was fundamentally inconsistent with profitably selling (let alone servicing) such projects.

Keeping the Money

Ahh, you say. But what if we just bid at $40,000 anyway? Well, we could do that, but then what do we charge for? If our regular hourly rate is (say) $125/hr and we can build the project for $5,000 (in 40 hours), what do we label the other $35,000 on in the invoice?

Changing the Rate

We could just put our rates up to $1,250/hr! Unfortunately in my experience, one of the metrics proposals are judged on is a comparable hourly rate. It’s another “goldilocks” problem where if the rate is too low, the client will be concerned about the quality of your staff and if it’s too high they’ll look for a more cost effective supplier. Also, rates of $1,250/hr aren’t sustainable as some of the things you do aren’t worth that. An hour in a meeting is an hour in a meeting. You might be smart and add twice the value that the next consultant would, but it’s unlikely you’ll consistently be provably ten times as valuable per meeting hour as another equally experienced consultant.

Selling the Secret Sauce

Another approach is to sell your framework or MDD tool as part of the project. Then it’s $5k for the site and $45k for use of the tooling to be able to built it so fast. The problem with this approach is that now you are selling three things. Firstly you’re selling MDD concepts, secondly you’re selling your particular software and thirdly you’re selling your company. All your competitors are only selling the capabilities of their businesses so it’s much easier and appears much safer to buy from them. Whenever I try to sell MDD to clients I have found that it has raised a bunch of concerns/red flags. It’s not that I can’t answer the concerns, but when you’re building trust with a new prospect there is simply only so much you can sell them on. Also, in my experience, when I was selling a solution as “software” everyone wanted to know who was using it, whether the source was in escrow, they wanted to see the user docs, tech docs, support materials, FAQs and testimonials from satisfied clients. When I moved to *using* the software but just selling custom development, all they wanted to know was whether I seemed to be credible, what the project would cost, and when I could start!

The Return of Fixed Bids

So, if it is difficult to raise your rates or sell the software as a line item, what’s left? Well, if you know what the client wants and can deliver it, the obvious answer is to consider fixed bid projects. They write down what they want, you charge $40,000 for it, you guarantee to deliver it well architected and with maintainable code quicker than your competitors and MDD and code gen doesn’t even have to be mentioned. Now you’re in more or less the same business, but with a competitive benefit in terms of quality of solution and time to market, and you’re about ten times as profitable as your competitors.

There’s only one problem with this – making fixed bid work.

Fixed Bid What?

At SystemsForge we build a lot of projects with substantial commonality. As such we have developed a process for specifying and quoting fixed bid projects within our domain. For small sites, we’ll do it for free. For larger projects we recommend a fixed effort design phase to look at the business problem and help the client to come up with a list of sketched essential stories. We can then often provide a fixed bid for those stories. The challenge is that I don’t believe this process scales. I can spec a $25k project in 3-5 hours. In a 20-30 hour design phase I can spec a sub-$100k project, but as project size grows it becomes ever less plausible to capture the scope upfront. I believe pay per iteration is one of the best ways of implementing green field development projects, but it we’re back to paying by the hour, how do we recoup our investments in MDD and our loss of hours now that we can build the same application in a fraction of the time?

SPL vs MDD

In a Software Product Line (SPL), it’s a little easier. If you’re creating lots of smaller applications, there is no reason why you can’t just add a pricing component into your variability management tooling, allowing different variants of the SPL to be sold for different base price points. But for large scale MDD projects it isn’t clear to me how a consulting firm can introduce them unless the RFP specifically requests the development of a project using MDD in which case all of the firms are on a level playing field.

Managing Expectations

For our projects, I have also spent a lot of time working on managing expectations. One of the things you have to consider as you engineer the costs out of application development in a fixed bid world in the cost of client changes/refinements. Generally what we’ll do now is give a number for delivering “anything that meets the written spec”. I have been unable to find a way to guarantee I will satisfy clients or definitively solve a particular business problem for the kind of low fixed bids we provide. What I do instead is recommend that the client put aside 20-50% on top of the original bid for tweaks to the delivered site which meets their spec but it unlikely to meet their needs. This allows them to get the lowest possible price, gives them complete control over the final cost (you want us to keep tweaking unimportant things, we’re more than happy to bill for it) but also keeps all our interests aligned as we make much less money billing on an hourly basis when compared to building new apps and taking advantage of the profitability of building apps using our SPL.

Conclusions

From my experience, there are a number of business issues that are raised when you consider substantially changing productivity as a consulting firm using MDD/SPL techniques. I’d be fascinated to learn more about how other people are handling this – especially on projects that run more than $100k and are harder to specify upfront.

Session notes from my DSL design session at BCS SPA conference

Last month was a little crazy. I presented on DSLs to a Groovy usergroup and on productive work practices at WebDU in Sydney. I then flew to New York to present at the local Grails meetup about DSLs in Groovy and four days later flew to London to co-present a 5.5hr session on Xtext and DSLs at SPA, Groovy DSLs to the London Groovy/Grails usergroup and a session on DSL design at the BCS SPA conference.

I then flew out to catch the second day of the Gr8 conference in Copenhagen and then back to London to present on Productive work practices at Scotch on the Road before returning to New York to chill for a couple of weeks.

So, apologies for the lateness, but below are my session notes from the DSL design session I ran.

Systemsforge featured in IEEE Software magazine!

After presenting at the inaugural Practical Product Lines conference in Amsterdam last fall, John McGregor contacted me to ask whether I might be interested in writing a short experience report on the SystemsForge software product line for an edition of IEEE software magazine.

The issue was released last month and there is a great summary of SystemsForge as well as lots of good content relating to Software Product Lines.

Published in “ColdFusion Anthology”

Been a *lot* going on recently, so here is a flurry of postings getting things caught up!

For a number of years I have been writing articles for Fusion Authority – for a long time the only print publication with technical articles for ColdFusion developers. A while back, Judith asked me whether I’d like to contribute some of those articles to a new book by APress. After a lot of reworking and editing, the book was just published. Check it out!

WebDU – Productive Work Practices Deck

Here are my slides from the Productive Work Practices presentation I gave earlier today at WebDU. What technique are you going to start using on Monday?!

Adobe ColdFusion Anthology just released by FAQU

The Fusion Authority Quarterly has been the premier source of quality technical content for CFML developers for a while. They have just produced a book with the “best of” the articles over the years. It has content from a number of top ColdFusion developers which should help any developer wanting a single resource packed full of ideas for improving your CFML development. I have three chapters – on base classes, separating layout from logic, and exposing the service class. Looking forward to getting my hands on a copy to see what other content is in there!

Is Steve Jobs Channelling Bill Gates?

Really? I love Apple products. I have an Air, a MacBook Pro and an iPhone. I’m pretty much the certified Apple fanboi. But recently, I’ve been having some really weird flashbacks to when I used to use Windows X . . .

Firstly, my Macs seem to need to be rebooted all the time. I’m losing count of the number of recent Snow Leopard upgrades to things like iTunes which have required a reboot. Really? A reboot on a *nix powered system just to upgrade one of the applications? What is up with that? Reminds me of WinXP.

And then Apple got into the whole AppStore debacle where they basically said to developers – you go, work on an app, and thern using arbitrary, undocumented rules we’ll decide whether to let you sell it to anyone. We’re not just (reasonably) enforcing published standards on what we’ll sell through the AppStore. We’re saying that if we don’t happen to like your app, you can’t sell it to anyone with an iPhone or iPad – period. Way to go pissing off developers. Reminds me of how Visual Studio seemed to completely change the way you had to work every year or two making me choose to develop using anything but VS. Also reminds me of how for a long time Microsoft tried to tie you into their (lame) VSS vcs offering and made it hard to use best practices like CI and automated builds until they finally wised up and started treating the alt.net community as a resource instead of the enemy.

And now they’re categorically blocking anything developed in anything other than objective C (from what I can tell) – and certainly Flash based apps (including flex based apps) from their platform. I get it – I really do. Old school business 101 is to use what you have to gain more control of your customers and to push out large potential competitors using whatever leverage you have. I definitely see how it could be in Apples interest to make this move – especially if we let them get away with it.

And let me make it clear – despite the fact that I was an Adobe Community Expert in the past, I’m not exactly an Adobe fanboi. Heck – I do work for Railo – a direct competitor to Adobe’s ColdFusion product, I don’t use CS as I am a horrible designer, and I don’t have any kind of affiliation with Adobe. I just expected more from Jobs and Apple.

Oh well. Anyone want to suggest the best hardware for running a linux dev laptop? I heard that a while back at one of the RubyConfs, anyone who still had a Windows laptop in the midst of all the MacBook Pros got a “think different” sticker or something similar. Hopefully by this time next year either Apple will have got the message and opened up the iPad, or we’ll all have Dells running Ubuntu and anyone at a conference who still brings their MBP along will get a “Think Proprietary” sticker handed out instead.

SPA Conference Coming Up Soon – Not to late to book!

I’m really excited about the upcoming Software Practices Advancement conference in London May 16-19th. It is a chance to meet a really eclectic group of top developers from a range of industries that use a range of different technologies and a great place for cross-polination of different ideas.

Language or domain specific conferences are a great way to learn from your peers, but at SPA a wide range of developers from different industries using different technologies come together to share their experiences and ideas and it’s an amazing place for learning from a wide range of top professionals.

SPA is also really interesting for its focus on pedagogy. Instead of just a bunch of chalk and talk presentations, there are lots of formats designed to engage the participants in the learning process. I’ve certainly learnt a bunch about how to communicate information effectively by presenting at SPA for the last couple of years.

This year there is a great lineup. I’ll be co-presenting with Marina Haase on openArchitectureWare (now part of Eclipse Modeling Framework)  and I’ll be running a session on DSL design – “What Makes a Good Domain Specific Language?“.

If you’re in or around London, I’d thoroughly recommend the conference – hope to see you there!

Do you want to see this in LightWire?

Thomas Messier recently blogged about supporting “arbitrary runtime constructors” in LightWire. Check out his posting and comment at the bottom as to whether you like or dislike the idea. If it’s popular enough (strong positives, weak negatives) it may end up in the core . . .

Presenting on “Spring Roo and Code Generation” at Code Generation 2010

I just got acceptance last week confirming that I will be presenting a session on “Spring Roo and Code Generation” at Code Generation 2010 in Cambridge, England this June. Roo is a fascinating Java framework that uses some really interesting techniques to elegantly generate Java code allowing for much DRYer development than regular Java programming without the overhead of dynamically typed languages like CFML or Groovy.

As the session description notes:

“Spring Roo is a code generator / framework for quickly generating Java web applications. It uses some very interesting patterns for elegantly generating code. In this session we will combine study of the patterns used by Roo together with hands on experience of Roo as a generator. In addition to learning the basics of a specific generator, we’ll also be “consuming” a generator so we can explore the experience of using a generator and what we can learn from that when choosing or creating generators or tools for others.”

Code Generation is one of my favorite conferences of the year, bringing together some of the top practitioners and academics in the fields of Domain Specific Modeling and Code Generation. If you have an interest in learning how to develop custom applications more efficiently, I’d strongly recommend it.