I’ve been consulting in software development for almost 10 years now, in several different areas in the United States. I am currently working as a consultant in Houston, TX.
I would like to share a couple things I’ve learned over the years with you, especially if you hire technical consultants within your organization. The following is how, in my experience, a lot of consultants think. Not all. It may be the majority, it may not, but it’s certainly a large percentage.
You see, these consultants, particularly in the software development world, have an agenda. A dark, secret, Bilderberg style agenda. Ok, I’m joking about the Bilderberg level…but before we get to what that agenda is, let’s examine the Number One Rule of Consulting, and see how that fuels this agenda.
If you think the number one rule is to do what the client wants, you’re wrong. Or at least mostly wrong. Keeping your client happy is definitely high on the list though, and certainly related to the number one rule.
The number one rule is simple: Stay Billable. That’s the number one rule, and it’s largely an unspoken rule, but the reasoning behind it isn’t hard to figure out. I think most people would agree that a big disadvantage of being an consultant versus a permanent employee is that typically (though not always) consulting engagements are short term. Typically, consultants are brought in to perform a specific task, or to help out on a specific project. So the life of a consultant is that of constantly looking for your next gig. So by finding ways to stay billable, you put off this search as long as possible.
Staying billable in and of itself isn’t a bad thing, because as I mentioned, it’s related to keeping your client happy, which of course is a good thing. But it’s important that you understand this unspoken rule before moving on to discussing the Secret Agenda.
Now that you understand the Number One Rule of Consulting, we can move on to the secret agenda. Again, this shouldn’t come as a particular shock, but the secret agenda is: Create Dependency. You see, by creating dependency, consultants can adhere to the Number One Rule of Consulting. The more you depend on them, the longer they can stay billable.
It’s like a politician: most of the time, the real reason that they want that fancy new law that they are talking about on TV (pick your issue, it likely fits) is this exact same secret agenda: dependency. The more people depend on the government, the more power they will have, and the longer they can stay billable, in a sense. But I’m getting off topic…
This secret agenda (that isn’t so secret) is a problem, particularly in the software development world. Now that we understand why these consultants want to create dependency, let’s examine how they create dependency, and what this means to your organization.
There are a lot of ways that these consultants create dependency, but the big one that will cost your organization a lot of money is through creating large, complicated architectures and implementations, when a simple architecture or implementation is all you need. Now don’t take this the wrong way, as sometimes things are inherently complicated and require a more involved design or implementation. But by in large, simple is better, and is almost always an option. Simple can take less time to build, and if done properly, is easier to support and adapt to future use cases.
Simplicity is hard to build, easy to use, and hard to charge for. Complexity is easy to build, hard to use, and easy to charge for.- Chris Sacca
Avoiding complexity is one of the best things you can do keep your implementation costs down. Here are some ways to reduce complexity and avoid the dependency trap.
If you’re trying to decide whether or not you need an architect for your project, I’ll make it easy on you: you do. The role of the architect is not the subject of this post, but the architect is the most important role you need to fill for your project, and as such, the architect should be the first person on the project and the last one to leave the project.
Remember the Law of Diminishing Returns – this applies to software development as well. Often projects will start out on target, but along the way the scope increases and features are added, both visible to the user and technical (often performance related). As soon as the application has reached the stage of “good enough”, both from a features standpoint and a technical standpoint, stop.
Smaller teams are more efficient, and will by their very nature create more targeted and simple implementations. Especially if you have a good architect. Even if you get behind on your project schedule for some reason, remember Brooks’s Law and keep your team size small.
Nine women can’t make a baby in one month.- Fred Brooks
These observations are certainly generalizations, and the Number One Rule of Consulting and Secret Agenda do not apply to all consultants. I have had the privilege to work with some of the best and have learned a lot from them, but you must watch out for the consultants whose main goal is interweave complexity throughout your architecture or implementation. If that happens, good luck getting rid of them.
Copyright © 2011 | Brandon Zeider