Thursday, May 26, 2005 3:53 PM
I have recently left the consulting world, and have come to a conclusion about consulting. I find it interesting (disturbing actually) that current trend in most IT shops around the country has been to outsource much of their work to consulting companies, either local or abroad. My conclusions are based on observations that I’ve had in dealing with consultants for the past 7 years, both in working with them and being one of them.
There are 4 main problems that I can see with betting your project's success on a consultant workforce. I’m sure this isn’t an exhaustive list of the problems with staffing your project team with consultants, but these are the issues that come to my mind as most severe.
1. Consultants don’t understand the problem domain.
2. Consultants don’t have a vested interest in creating a maintainable solution.
3. Consultants will do what ever they have to, in order to get and keep the contract.
4. Its hard for a dev team to have a development process when consultants coming and going.
Consultants don’t understand the problem domain: Large scale applications usually have a fairly extensive set of business rules. These rules apply to the problem domain that the application is trying to solve. As a project goes version to version and staff consultants are brought in to work in these different versions, they must spend billable hours familiarizing themselves with this logic as well as the existing project architecture. This process happens over and over, which is a huge waste of time. When the business logic is fairly complex, changes in one class can have dramatic affects on several other classes, but if the new consultant is not familiar with the entire object model and business rules, they can often cause more problems then they fix. The main point is that a FTE (Full Time Employee) who has been around for several versions will have a much better understanding of the problem and business domain. An FTE does not have to spend several days getting up to speed on the project architecture and if they are fairly competent, have a better chance at not messing up the existing business logic when they are making changes.
Consultants don’t have a vested interest in creating a maintainable solution: Funny story…I once did a Proof of Concept project on BizTalk 2002. I was given a year to make it work or make it go away. We brought in a highly paid Microsoft consultant who was supposed to be an expert in BizTalk. I was the dev lead and we worked together to design a solution for a vendor document exchange system. After a few months work we had a working model. Since I was new to BizTalk and the consultant was the “design expert“, we pretty much went with his design. It looked and ran just like the books say it should. Awesome!!! Then we put it into limited production with 2 vendors and found out something kind’a fun. The solution worked great when nothing went wrong. But once miss-formatted documents started feeding into the system, our solution could not handle the failures gracefully. The process was only half way through, but we had to start a brand new process in order for the vendor to submit a corrected document. Then we tried to add a third vendor, we found out that the solution was locked to a limited number of vendors. Basically, the solution that we designed was crap.
Why was this? Because I didn’t know what I was doing and the consultant had designed exactly what we had asked for: a system to successfully trade documents between us and two vendors. He was blinded the way I’ve noticed that most consultants are. They are there to create a specific ‘thing’. They don’t often look at the big picture and think about the problem they are trying to solve. They just solve the limited example put before them. They have no vested interest in making sure it is solid, stable, and maintainable solution, because as soon as the project is finished they are on to the next client and the next project. There is a different mindset that you get when you know that, a year from now, two years from you, you are the one who has to maintain the application.
Consultants will do what ever they have to, in order to get to contract and keep the contract: This is a touchy topic. Consulting is an extremely competitive gig. Consulting companies need contracts in order to stay operational. In order to get the contract, they must present a solution where they have to appear to be an expert in the subject matter, present a time-line that is faster than anyone else, and often at a cheaper rate. But how many times have you seen a consultant come in and after two to three weeks, it becomes painfully obvious that they are just as new to the technology as you are, and sometimes more. Most likely they are spending their evening poring over some Sam’s publishing ‘Learn * in 21 days’ book.
Ok, so say the consultant has made it into your door and is now working on your project. What happens when deadlines are starting to get tight? Shortcuts of course. Why? Because of problem number 2. No vested interest. I don’t know how many lines of code I’ve had to rewrite after a contractor left the company. Some of the worst back door, hack code I’ve ever seen were when the pressure was on, time was short, and the contractor was just trying to finish the contract and move on.
Its hard for a dev team to have a development process when consultants coming and going: How many teams have a some sort of development process in place? Most I hope. But what happens when a company staffs 80% - 90% of their programming staff with consultants? Zero development process. It’s hard to create and maintain a working dev process when your staff turnover is 80% every version of the product. And no dev process usually translates into a poorly designed, developed and tested application. On the flip side, what if a consulting company is contracted to bring in an entire team. That team might have its own development process, which the client is then forced to learn. But what happens when the project is over and the consultant team leaves? Does the client switch back to their old process? You should pick a process that works and stick with it...not swap them in and out. A development process only gets better with time. You should
So is all this the consultants fault? Of course! Ha, just kidding. Every one of these issues can be avoided or at least minimized if the client is very diligent with their project management (then again, how often are PMs consultants?). But I still believe that with knowledgeable, competent full time employees these problems can be minimized. And is every consultant like this? Absolutely not! I was a consultant myself, and I try my best to create an application as though I’ll be working on it for the next few years. I’ve gotten into fierce arguments with my client because they path they were taking was not the long term correct thing to do. But I would have to say that I this mentality is in the minority. So many consultants that I’ve work with are just there for that gig, and then they are off somewhere else. They just want to put in their 9 – 12 hours a day and go home. They get paid either way, and a year from now its someone else’s problem.