Understanding Pricing around Drupal Services
OK, brace yourself. Let’s talk about the issue that inevitably causes everyone to become squeamish. Budget, hourly rate, time and material, fixed bid, etc. – you have heard the pricing terminology before. It is no secret that Drupal and open-source in general has struck a positive chord with organizations of all sizes. Why? One undeniable factor is because it’s free – pretty cool, hey. You can download, poke around, and tire-kick as long as you desire.
However, a problem has been marinating – think Economics 101. Demand is exceeding supply. The perk of free software is great, but it’s causing false expectations and confusion. The buyers that are attracted to Drupal purely because of the "free" cost are in for a rude awakening. They struggle to understand the expertise differentiation in the Drupalsphere – hey, code is code. The mentality is I’d rather go with the $30/hour consultant v. an agency charging $200+. In short, oftentimes organizations base a purchasing decision entirely on price v. overall value.
There is this widening gap between complete newbies wanting to dive head first into doing billable Drupal work and those with a proven track record of building Drupal sites. Simply put, in a specialty expertise like Drupal – experience matters. You’ve heard the saying before – if I only knew “x” years ago, what I know now. At Mediacurrent, we’ve completed over 100 custom Drupal implementations, and each one has been a unique learning experience.
The “focus on the cost line-item only” train of thought is certainly not new. But, that is really bad for Drupal. When the experienced firms and developers are at max capacity, the slippery slope starts. As a result, there are a lot of poorly architected sites being built that are grossly under bid and scoped. There is an influx of firms over-advertising and over-stating their capabilities as Drupal specialists or experts. This is also illustrated in the “project management triangle” – pick good, cheap, or fast, but you can only have two.
Many would argue that this is a talent issue, and that we need to concentrate more on training or dare I say it, some kind of certification program. This may be true, but the problem goes way beyond that. The Drupal community should place an equal amount of emphasis on educating organizations on the level of effort that goes into custom engineering a Drupal site “the right way.” We should assist them in coming up with ways to properly screen and qualify Drupal vendors. Isovera, a Boston-based Drupal firm, recently conducted a survey (official results soon to be released) that showed over 50% of organizations were on at least their second Drupal vendor. This means a lot of organizations are regretting their decision to adopt Drupal.
At Mediacurrent, we advise enterprise-level prospects that our biggest take-away on any successful implementation is almost always predicated around how much up-front investment there was in planning. Simply put, the organizations who grasp the concept that a discovery or diagnostics period is critical vastly improve the likelihood of success on the project. For us, the strategic planning part is an involved process that entails drafting detailed information and architecture documentation that will serve as a road-map. We manage engagements with enough flexibility though to make agile-based changes as the project evolves.
To recap, my plea to companies that are about to engage in a Drupal project is this – please understand that experience matters. What you are paying for is predictability, processes, and most importantly people. The product is secondary. The decision-making process is no different in the medical field – would you rather have brain surgery with a doctor that has performed a similar operation hundreds of times or someone that is learning as they go?
How about you? Any thoughts on pricing in Drupal or open-source software in general?