THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is an author and engineer who enjoys building and automating data integration solutions. Andy is co-host of the Data Driven podcast. Andy is no longer updating this blog. His current blog is AndyLeonard.blog.

Value

Numbers don't lie!

One of our mottos at Enterprise Data & Analytics is, “Deliver Value.” I can hear you thinking, “That’s nice, Andy. What does that mean?” I’m glad you asked.

!Value

Let’s start with what value is not, shall we?

Value is not the least expensive. As a consultant, I often “bid” for consulting work, sometimes referred to as “gigs.” How does bidding work? Someone calls or emails. I usually set up a meeting to discuss the problem they are trying to solve. I listen – a lot. I inform the potential customer whether I can help or not. Usually, if I cannot help, I know someone who can; and often I can subcontract someone who can help. Next we talk about hourly rate.

Let’s talk about hourly rate. And experience.

I once had a conversation with a customer that went something like this:

Customer: “We would like for you to help us develop a business intelligence and analytics solution.”

Me: “Cool. I can help.”

Customer: “So what is your hourly rate?”

Me: “$___ per hour.”

Customer: “Wow. We can hire several people to help with our business intelligence and analytics for that rate!”

In this instance (and several similar instances), the client opted to hire several people at a lower rate. In this instance (and several similar instances), the client called back later and asked if I had some availability to help them. Why? Experience. The consultants they hired at the lower rate did not deliver. I’ve done this several times before. I know what to expect, and I recognize the unexpected.

The value of that last phrase is not to be underestimated.

Having experience means I immediately recognize something new and different. I raise the flag. Having experience also means I know what to expect. Experience often translates into time saved. My hourly rate may be double the competition, but I know how to deliver major portions of the project in 1/4th the time. (Some portions I know how to deliver in 1/100th of the time.) If I’m able, at (hypothetically) $300/hour, to deliver some aspect of the project in 25 hours; and the lower-rate consultants, at (hypothetically) $150/hour, are able to deliver the same functionality in 100 hours; which of us is the better value?

Let’s do the math.

Me:
$300/hour * 25 hours = $7,500

The “less expensive alternative”:
$150/hour * 100 hours = $15,000

Which of us is the better value, me or the less expensive alternative? To quote Foghorn Leghorn, “numbers don’t lie.” Foghorn is correct. I am the better value, even though I charge more per hour.

But Wait, There’s More

Lots more. You see, when a project is under development everyone is laser-focused on the costs of development. Why? Well, those costs are right there in front of everyone. The math is easy, it’s the number of hours invoiced multiplied by the consulting rate. But is the cost of development the highest cost of a project?

The answer is no. Most business intelligence, data warehouse, or analytics projects are used in the enterprise for five to ten years. In my experience, the costs of maintaining and supporting are often more than the costs of developing the solution in the first place.

If you read that last paragraph and thought, “Of course you’re going to write that, Andy! You want us to hire you instead of your competition who charges a lower hourly rate!” If you thought that, don’t hire me. Hire someone you trust. Your data, in 2016, needs a consultant you trust. Your customers need a consultant you trust. The people behind the personally-identifying information (PII) in your databases need a consultant you trust. In my opinion (again, subjective), integrity should be your number one consideration when selecting a consultant for a data project. Please hire someone you trust. If that’s not me, I will understand.

The combined costs of developing, supporting, maintaining, and extending a solution is called the total cost of ownership, or TCO.

The costs of supporting, maintaining, and extending the solution are spread across the years the solution is in production. The individual costs are small – especially when compared to the hourly rate of a consultant – but they are manifold. Over time these costs can, and most often do (in my experience), overtake the costs of development. Designing for supportability, maintainability, and extensibility can save thousands of dollars (sometimes orders of magnitude more) in TCO.

It’s not just costs of supporting, maintaining, and extending the solution, though. Think about the opportunity cost – the cost of opportunities lost because your team is spending extra time fiddling with this solution – when they could be thinking up killer applications and solutions that will make you a go-zillionaire!

I design for supportability, maintainability, and extensibility. To design for TCO, one needs experience supporting, maintaining, and extending data-related projects. Not everyone has that experience. Some brilliant consultants have never led or managed a team or project from inside a large enterprise. I led a team of 40 ETL developers when I worked at Unisys. I can tell you, experience managing a team of developers is very different from being an independent consultant.

Conclusion

Because the money for development projects usually comes out of a different accounting bucket (the capital budget) and support, maintenance, and extending projects comes out of the operations budget, it’s understandable that TCO is often overlooked and development costs are often over-scrutinized.

Please consider experience and the total cost of ownership when selecting a consultant. You’ll be glad you did.

:{>

Related Training:
IESSIS1: Immersion Event on Learning SQL Server Integration Services - April 2017, Chicago

Learn More:

Biml Academy
The Basics of Biml – the Execute SQL Task
The Basics of Biml – Populating the Biml Relational Hierarchy
Stairway to Biml
Stairway to Integration Services
Varigence.com
BimlScript.com
SQL Server Central

Need help or training implementing a Biml solution?
Contact Enterprise Data & Analytics today!

Published Tuesday, September 20, 2016 3:31 PM by andyleonard
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Greg Low said:

Spot on Andy. Share so many of my own thoughts.

In many IT project management books, they suggest 10% of the cost of the overall project as development, but as you say, the person making that decision is only focused on that 10%.

I also say that in this industry, you need to be comfortable that 80% of what you know today will be useless in 4 years time. But that 20% is what keeps you out of trouble. (And that's what experience is).

September 20, 2016 8:16 PM
 

andyleonard said:

Agreed, Greg. It's an easy mistake to make (focusing on the costs of development instead of TCO). I understand it. I want to help people see the bigger picture.

:{>

September 20, 2016 9:52 PM
 

MonkeyMan said:

"If you pay Peanuts, you get Monkeys!" --MonkeyMan

September 21, 2016 3:39 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

News

My Latest Book:

Community Awards



Friend of Red Gate

Contact Me

Archives

Privacy Statement