(Cost vs. Price) vs. (Price vs. Cost) Part 1
My previous arguments regarding cost versus price were from a wide view. Now, I’ll carry the argument into a narrower perspective. I’ll try to address this by drawing on a story many of us have lived through.
You’ve got a project that’s just gotten approval. You helped develop the estimate and based on that estimate it’s budgeted for 60 man-months (60MM) of development. Your available internal staff is comprised of you (a lead developer), Ben (a solid developer) and Bob (a good junior programmer with limited development experience).
Now, if you had 20 months to get this project done, your productivity might average 3MM per month. Ben is a solid 1MM, Bob would get better over time, and he would require less of your time to guide him, and by the end of the 20 months he’d be producing at a 1MM level. You? Well, between overseeing Ben and Bob you’ll start out at less than 1MM, but probably average 1MM over the 20 months. The trouble is that you don’t have 20 calendar months to deliver this 60MM effort—you’ve got 5 months. So, what do you do?
Your estimates are all based on solid Web developers. Bob can’t produce at that level, and you’re going to need to spend a lot of your next two months doing everything but developing. And, as always, one of your main constraints is price. Your shop has always paid a max of $20 per hour for developers. (Humor me here—the issue isn’t price anyway!) Do you bring on 9 developers at that rate, or is there value in being a bit more creative?
We’ve all worked with someone that was exceptional. The developer that everyone on the team went to for solutions and that everyone knew wrote the tightest, most efficient and most maintainable code. The developer that asked the questions that nobody else thought of, that thought of issues before they became problems, and always seemed to be the go-to person in the shop. They may or may not have coded faster than everyone else—but their code was always production ready faster than anyone else’s.
If one or two such developers were available, what would they bring to your team? Would they make others on the team better? Would they out-produce others on the team? Would they make those around them better by being the one they go to with their technical questions? Would they free you up to also do more development? And if they would, what is their value?
Call these stars any name you want, but we all know one or more such people. They deliver so much to a team and to a development effort—and they do so without a fancy title and generally with very few management or ego issues. They know they’re good, and they make everyone in the room that much better for their inclusion.
But you’ve got that cap of $20.00 that you’re company pays for contractors and the star costs $30.00. And someone in your purchasing or in HR wants to talk about a price without thinking about cost. This is when you really have to start thinking creatively.
Can the star produce more than 5MM of results in 5 months? If we understand and accept that Bob may, if you’re lucky, produce 0.5MM in month one, and may only work up to 0.8MM in month five, isn’t it also reasonable to assume that a star should produce 1.5MM of effort in month one, and as much as 2.0MM in month 5?
Now, to be honest, most of the people I would put in this star category typically out-produce the average developer by two to three times. They write better code that’s far easier to maintain, and it is production ready with far fewer iterations. They make everyone on the team better and they do it with a smile, a nod, a nudge—what if you did it this way, or what if we tried this? They make us all better by bringing us with them.
Stars are the hardest to attract but the easiest people to identify. People always talk about them, their references are impeccable, and they’re easy to get along with. These are not the unmanageable egotists that think they’re great—these are the real deal, and they’re worth the effort and they’re worth the price.
So you hire two stars at the price of three regular developers, but your contract team is seven people not nine, and we haven’t even talked about the savings the company will experience over the life of the system based on its maintainability. That’s a contract savings of about 11%, plus a long-term savings that should at least equal that.
Yes, you’re going to increase the rate to accommodate these two stars, but the trade off is that you can buy the production of four for the price of three—and you’re saving your company money.
Start the conversation