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.
Advertisement
Nice post, Peter – thanks for putting a realistic view out here. One thing worth noting: you take this from the perspective of a consulting firm that delivers a (software) product. Things are slighty different (although I haven’t analysed the details as far as you did): in case of a consulting firm that provides resources (body shop) and advice on software engineering, the pricing issue revolves around the question of ‘how much can we charge for an engineer, and how much will introducing MD(S)D be worth to the customer’. You cannot charge by the hour for people you don’t provide, but you may get a good price for a consultants team that succesfully introduces MDD in a development department of 3-600 engineers, who get more productive afterwards.
Angelo Hulshout
June 25, 2010 at 5:10 pm
Hi Angelo,
I think there is no question that if a customer is sold on MDD a “body shop” can deliver engineers to implement a model based approach. However, there are challenges with this.
Typically when I do Software Product Line or MDD consulting, I go in as a single consultant and in just a few weeks of effort I have helped the clients to identify the domain model, create a first cut implementation, create a first cut of the DSLs and maybe the other tooling required to start off a software product line. It simply doesn’t take that many man hours to introduce an MDD initiative and to train up a smart team to the point where they can work with it, so I think body shops that want to put 100 bodies in for 18 months are going to have a hard time doing that for MDD – I am just not convinced you need those sort of resources. But then I also echo the saying I once heard which was something like “within every 20 person software development team there’s a 6 person team trying to break out!”.
Another issue is the quality of “bodies”. In my experience, only a subset of programmers think in a way that is consistent with designing elegant MDD solutions. And most of them don’t want to just be one of a team of 20 people with very little control of their work or clients. As such I think most of the “bodies” in the body shop might be incapable of leading MDD initiatives, and I’m not convinced that it is purely a training issue – I believe some developers do better at “thinking meta” and others find it harder to do well. In my experience there is also a huge difference between the elegance of solutions that programmers write in all spheres.
Thirdly, this all assumes that the customer *wants* MDD. Despite the caveats above, I agree that a consulting firm can absolutely charge engineers by the hour to deliver MDD solutions. What I don’t see if that the firm will be able to drive MDD adoption if the customer is just looking for bodies. So I do believe that if/when customers start requesting MDD, body shops will try to provide it, but I don’t see consulting organizations driving the adoption of MDD.
Also, because of my earlier points about the number of hours required and the importance of highly skilled practitioners, I think most firms that *do* want MDD consulting would be better served hiring Markus Voelter or you or one of the other small independent teams (Itemis, etc) rather than going with a general purpose body shop which is a little bit to me like going to your family doctor for brain surgery
peterbell
June 26, 2010 at 8:47 am
Hey Peter, fascinating post even for someone not in consulting. I would say though that the problem you pose is not unique either to MDD specifically or to software development in general.
Starting with the second point, even auto-repair shops deal with this type of problem. Which is partly why they quote hours based upon the typical man-hours an average technician would take to complete the task. Really good mechanics can often get a job quoted as 5 hours done in 1, but you still get billed for the 5. Since, in many respects, you have an “a la carte” sort of service in a sense, couldn’t you quote based upon the equivalent man-hours it would take to complete the task? The client doesn’t need to know (as with the mechanic) that it didn’t take you that many hours in the end…and your key differentiator could be time to delivery rather than your rate.
On the other hand, any consultant worth their weight is going to face this problem to some degree. The more experience and projects you have under your belt, the more existing code and general knowledge you can bring to a project to get it done faster – regardless of your use of an MDD process. Charging hourly isn’t fair to you the consultant, especially when it comes to leveraging code you already wrote than can be ported over. When I faced this problem in the past as a consultant, I did as the mechanics do and charged what it would take me to write it on an hourly basis…as you state in different words, the fact that I *didn’t* actually write it all over again makes no difference to the client. They don’t care how i got it done, just that I got it done and well – and if I get it done quicker, then even better.
What’s the old saying…good, fast, cheap, pick 2? Well, you seem to have found the solution to pick all 3, but it turns out no one really wants cheap, so offer them good, fast and reasonable.
Brian Rinaldi
June 26, 2010 at 12:13 pm
Hey Brian – long time no CF Argue! I’ll be in Boston some time over the summer – will hit you up when I have dates . . .
As for the comments, very good points. I guess the problem I run into is that for my use case (most of the time) it’s pretty easy, but I can’t figure out how to scale it to larger projects. Most of what I do is similar to a mechanic changing out a component. I’ve done similar classes of things before, have clear acceptance criteria I can share and I can easily fixed bid. But lets say you need a complex, sophisticated system for providing a custom web UI that interacts deeply with SAP and a couple of legacy mainframe systems to provide an integrated reporting API. There is a huge amount of uncertainty so fixed bid is unlikely to be practical. Actually to be accurate, fixed bid+scope is the problem – we could say it’d be $200k and just add as much value as possible within the bid, but we couldn’t say anything very meaningful about what the solution would look like upfront.
I suppose the answer might be to agree a fair hourly rate and to do our best to estimate specific tasks within the project in terms of hand coding and to charge for the theoretical time for those instead of the actual. I guess the problem I have with Time and Materials is that while I am happy to quote an hourly rate, give a fixed bid and then charge the fixed bid even if I beat my hourly rate, if I am genuinely billing by the hour and I bill for a number of hours that is different than the number of hours it took me, that sounds to me very much like fraud. In the car example, if I’m told it will be $300 to fix the radiator, I don’t care how long it takes. If I’m told I need to pay $50/hr until the radiator is fixed and I take that on, I don’t want to pay $300 if I get the good mechanic and he’s done in an hour – I want to pay the $50 we agreed.
The underlying challenge is that in programming (and as you pointed out, in other fields also), better developers tend to be cheaper by functional unit of delivery. I’d argue that in general (with plenty of specific exceptions) you’re gonna get a lot more value per $ from $100,000 programmers than from junior $50,000 programmers in the same market. It is one of the reasons I only ever hire the very best developers for projects.
However, the downside as such a developer is that you are not compensated appropriately for the value you add if you charge by the hour, because there is a cap for developer hourly rates. I don’t know exactly what it is, but I can’t imagine being able to ever explicitly charge (say) $400/hr – even if I was able to add that value per unit time.
My solution is that I fixed bid what I can, I suggest the client puts aside a budget for tweaks and I do those on a genuine hourly (or where I can, mini fixed bid) basis. Anything I have to do hourly I treat as a loss leader. Again, it works for small projects, but I’m not sure how you scale it to the big projects . . .
peterbell
June 26, 2010 at 12:56 pm
Great post, Peter. Your analysis makes a lot of sense, but (maybe due to my lack of experience as consultant) I have some ideas for addressing the issues you raised:
“Negative Return on Investment”
Try to spread the effort of building reusable artifacts across multiple customers. You don’t need to build the entire toolset/templates at once. Improve (breadth/depth) over time, and reap higher benefits as time goes by.
“Price isn’t Everything”
Don’t charge a small fraction, but charge 10%-20% less. You will still have a better margin than the competition.
“Keeping the Money”
Totally. Invest the time you saved by generating code into providing higher quality: designing a better domain model, or better UX, improving your tools, stricter testing, more training. The paying customer will benefit directly from that.
“Changing the Rate”
Charge a slightly higher rate, that is only fair as you deliver much better quality than the competition (which can barely meet the deadlines/minimum quality requirements because they are too busy writing everything from scratch).
Does any of this make sense?
Rafael Chaves
June 26, 2010 at 1:13 am
Hi Rafael,
Many thanks for the comment! My initial thoughts:
Negative return on investment:
I agree that the way to build tooling is a little bit at a time, but if I have a choice between losing $100,000 all at once or $10,000 per project over ten projects, I choose neither!!! Spreading a negative ROI over time just means you lose less money. Even if I spend one un-billed hour to decrease my revenues by 1%, I’ve still wasted an hour and my revenues are down by 1%. Keeping on doing that makes no sense. So I do agree that if there was a positive return on investment (somehow we got more projects or higher rates or fees for using the tooling) we could spread the investment over time to conserve working capital, but as long as the ROI is negative, it makes no economic sense to undertake the activities over any time period.
Price isn’t everything
I agree that you don’t charge much less. In fact, you don’t even *have* to charge less at all. A good rule of thumb is that if you get 3-5 bids on a project, you throw out the cheapest and most expensive and pick one of the middle ones. This is not always true, but you either need a good story for being the cheapest or you want to actually charge the same as the competition. The issue though, is what do you put on the invoice? You estimate the project to be $45,000 – same as the competition. You get picked. You spend 10% of the time at a similar rate to your competitors, so you can now invoice at the end of the project for $4,500 worth of time. What do you charge the other $40,500 for? That was the crux of the second part of the article.
Keeping the Money
I certainly agree you keep the money. The question is what are you billing for now? It seems to me that the easiest and least controversial way to “keep the money” is to do fixed bid projects as then you are charging $45,000 for solving a business problem. But now you have all of the issues with emergent design, not understanding the problem, scope creep, and the fundamental difficulties with setting the scope when you know the least about the project that drove the agile movement. As I mentioned, I’m a fan of pay per iteration, but then we’re back to charging $4500 (OK, $6,000 if we charge a modest premium) which is going to be really strange. I suppose one strategy would be to estimate $45,000 but only charge $6,000 but I’m not sure how people would react to that!!! Could be interesting . . .
Another strategy I’ve seen is – for the lack of a better word – lying. People estimate how long it would have taken to hand code something and then charge for the time it should have taken instead of the time it took. While I have some issues with this approach, it does have some practical benefits. I do something similar but without the lying part! I give people a modest hourly rate (probably below market – certainly below market for my skills). I then provide a fixed bid based on the number of hours I believe it would take a regular coder to do it (and I double check that the number is fair from a competitive and business perspective), I then work my magic and often deliver the project in less actual time, and that allows my actual hourly rate to be much higher than my nominal hourly rate. Given that I am actually doing fixed bid projects, I have no problem with this as I am telling the client the cost upfront and delivering on that, but again we’re back to small discrete projects in a well known space which is one of the few places where fixed bid works well. I have ethical questions about just plain billing for 80 hours on a T&M basis when you did it in 20 – although I agree that from a practical perspective it is one way of solving the problem and the client is still paying less than they would and getting better code than they would from your next competitor down the street.
Changing the Rate
I don’t think it’s a matter of fair – it is a matter of sales. I clearly charge more than a student in Russia or in Indonesia on Rent a coder (I believe the going rate is $8-$10/hr). However, I tend to charge at a rate that is close to the people that I am bidding against on a class of job. My “rate” for a simple cms that you could build in Drupal is lower than my “rate” for MDD consulting. However, because I fixed bid the simple stuff and have my various magic tools I’ve built over the years, I actually end up making a much better rate on the simple projects than on the nominally higher rated consulting gig as I can deliver simpler apps incredibly efficiently. However, I definitely see hourly rates as something that should be driven by marketing concerns (ability to sell) and limited by operational concerns (it needs to be worthwhile doing the work) rather than necessarily any sense of fairness.
All your comments made a lot of sense. Hope some of my replies did too. This is a fascinating discussion!
peterbell
June 26, 2010 at 9:06 am
I fully agree with Peter and consider that integrators and consulting companies as well as developers are a major problem for MDD adoption.
MDD allows companies:
- to reuse existing model and therefore reduce billing. It is not what consulting and integrators want !!
- to be independent of internal codding team and therefore be able to outsource or reduce the size of the team. This is not what developers want and I understand them.
I think that MDD is dead because companies which should be adopting MDD to reduce expenses are listening to consulting/integrators companies and internal teams.
Vlad Varnica
June 27, 2010 at 4:38 am
Most of the discussion here is based on three “narrowing down” steps:
1) Charge by Time & Materials or by Fixed Price
2) Charge by Time & Materials
3) Charge by Time
By the time we get down to the last one, there are clear problems if you are much faster than your competitors. The possibility of Fixed Price has been discussed already, so let’s look at the step from 2 to 3. If I want to pay someone to clear an acre of forest, I used to just give money to a guy with an axe. Let’s assume that because of differences in growth rates, terrain etc., paying per hour rather than per cubic foot of lumber was the norm.
Along comes someone with a modern Timberjack harvester, who can do the job ten times faster. That’s game changing – what Geoffrey Moore calls a discontinuous innovation. If Timberjack harvesters are free and anybody can learn to use one straightaway, the industry will change so that the price per hour stays the same, but the expected yield per hour is ten times greater.
This can actually take a surprisingly long time, and may indeed never happen – see Moore. The key factor pushing the adoption is the increase in overall productivity. Even if the Timberjack is expensive, and learning takes time, the TCO per unit timber is small enough that it doesn’t affect the productivity calculations much. The key slowing factor is social: many people will only move to new technology after seeing most other people move. But with a 5-10x productivity increase, it’s reasonable to expect that things will eventually change.
This of course has happened in our industry too: we moved from assembly language to 3GLs, and productivity increased by a factor of around 5. Back then, compilers cost rather a lot (anyone have actual data?). Even if it cost a year’s wages, buying a developer one still made sense: it paid for itself in the first 13 weeks.
So how to charge customers now, with domain-specific languages and generators offering 5-10x productivity increases? My suggestion would be to factor the tooling into the costs as “Material”. In effect, the part of your organization that makes the metaware rents it to the consultants. You can even make two bids: one without using metaware, of 500 hours @ 100$/hr, and one with the metaware, of 100 hours @ 150$/hr for time, plus rent of metaware for 100 hours @ 250$/hr. Sell the customer on the metaware version with the Timberjack analogy. Having an explicit charge for the rental also sets the development of the metaware on a sound economic footing.
Another variant or optional extra for this would be to leave the customer the modeling tool, models and generators (or some part of them). That would give them the ability to make changes themselves, and of course allow charging for the tool, and an ongoing charge for maintenance. The justification for the tooling price should be based on the cost of doing another project. I think this requires a higher standard of tooling, though: something you can use in-house to do consultancy is a long way off what customers expect. Still, there is at least one solid commercial tool that I could recommend
.
I don’t think we can avoid the fact that project prices will drop eventually because of the increased productivity. However, at the moment most consultants don’t have that productivity, so those who do can benefit from this assymmetry. This is a positive problem, people! There’s no lying involved: we really can deliver more functionality, more reliably, faster, and with better quality, than our hand-coding competitors. Our customers really do get all three of fast, cheap, good.
Steven Kelly
June 28, 2010 at 6:37 am
Hi Steve,
This was the approach I originally took with SystemsForge. AFter a while I stopped. At least for my target market, trying to sell MDD, my MDD tooling AND my company was just too hard. As soon as I mentioned MDD or code gen or DSM it suddenly became this big decision and all of these issues came up. Now I just build websites better, cheaper, faster and I don’t get any of those roadblocks when trying to sell my solutions.
I do believe there is a space to sell the MDD, but for companies that aren’t familiar with the benefits, if you’re competing against other firms that are just selling bodies, the sales process is going to be much, much harder as you have to sell three things instead of one and a good rule of thumb in sales is to only sell one thing at a time.
peterbell
June 28, 2010 at 9:27 am
Hi Peter, nice post.
However, I believe there are even better reasons to use MDD than just accelerated delivery time. Think of: better collaboration and alignment between business (analyst) and IT and “truly” enabling agile and reducing long term maintenance costs. These factors are easily sold (and proved) and typically trigger less discussion than the argument of reduced initial turn-around time. In fact, at Mendix we partner primarily with business/management-oriented consulting firms (instead of traditional IT-dev/body-shops) to sell and deliver solutions. Our partners have (business) domain-specific knowledge, that is automatically less of a commodity and therefore rarely results is a discussion about hourly-rates. Using business-driven MDD, business consulting firms are now able to provide added value that they couldnt before.
Fixed price, fixed date is a nice bonus.
Derek Roos
June 28, 2010 at 1:30 pm
Hi Derek, Thanks!
That’s an interesting model. One thing we have played with in the past is providing UI’s to the design firms we partner with to allow them to do a lot of the application development. It has strengths and weaknesses from a commercial perspective, but it is definitely an interesting approach. I think what makes it work is that it is empowering a different group to deliver the solutions. A business consulting firm isn’t losing the money that could have been made selling programmers by the day because that isn’t a business they are in.
Maybe one answer is that given the mixed incentives for most “body shops” to adopt MDD is that some of the support on the consulting side will indeed come from organizations that would not previously have been considered as programming shops.
How do you partner with the firms? Presumably some of the effort still requires people with a traditional programming skill set even if you’re allowing the analysts to enter their executable requirements. Do you provide the programming skills and how do *you* charge the consulting firms? By the hour or on some other basis?
peterbell
June 28, 2010 at 1:52 pm
Peter, exactly my point. MDD should add value to everybody, otherwise its not adopted. I guess its hard to get someone to understand something if his salary depends upon him not understanding it
To answer your question, typical Mendix users are tech-savvy business analysts who understand software (and to sometimes even code) but prefer to focus on the business side of IT (requirements analysis, domain modeling, process modeling, UI design, etc). We call them “business engineers” since it is kind of a new role…
Now, in many cases we are able to model up to 100% of the application without code. Of course, some of the more low-level models (“microflows” or “mapping DSL”) can get fairly technical at times, and there is also the “escape” feature to resort to custom Java for edge-cases (the tool allows for integration of Java as part of the Mendix model). In practice, this is often used for legacy integration or high-volume transaction algorithms…
The focus of our partners is in selling their solutions (and domain knowledge), rather than commodity development services. This is illustrated in how their teams are organized. In general, Mendix partner teams typically have 1 developer on the team per 5 business /functional consultants.
Derek Roos
June 30, 2010 at 12:44 am
Very interesting article!
So if I understand well, the main goal is to convince new clients.
I was working in a consulting company which also owns a MDE tool vendor. So they were selling the tool (with the strong knowledge of the tool vendor) and consultants.
To convince the potential client, the consulting company invites him at the head quarters of the tool vendor company. Then, they invite the potential client to see a success story for real at a privileged client.
This way, MDE benefits are not only numbers on documents, it’s real.
With this approach, you justify your lower price. And because a java developer is much more common than a MDE specialist, there is no doubt you can charge with an higher hourly rate. So you can adjust lower price and higher hourly rate to find an acceptable final price.
Obviously, this is not every consulting companies that have their own MDE tool vendor. But when you see that calls for bids are sometimes only open to a small set of consulting companies, there is no doubt that a tool vendor won’t be able to be referenced.
So I think MDE expertise, MDE tool vendors may find a reliable business model in strong technological partnerships with consulting companies.
Regards,
Xavier
Xavier
June 28, 2010 at 2:33 pm