Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
Pulpit Comments
Status: [CLOSED]

I worked for a large biotech company from 1994 until 2005. For the most part they used very little if any consultants. They had an information management division that employed somewhere in the neighborhood of 500 people to serve the 5000 global employees. Development projects were routinely assigned to various teams within that department. As a result they ended up with no uniformity in platforms and were thus hindered from ever reaching truly successful implementations. They had sybase, oracle, SQL and Access databases scattered all over the network. It was frustrating for a power user like myself who could write queries against some of the databases but was never given the authority or capability to query information from 2 different databases at the same time. Ultimately I ended up creating my on MS Access reporting database(s). I would pull down information I needed from the various databases that I could and then consolidate them in my own database. When I finally left the company that little backend Access database contained approx. 2 million records, was over a 1 gig in size and was used by over 50 people in the department I worked.

drewby | Apr 18, 2008 | 2:50PM

Best definition of an expert; anybody from over 50 miles away.

Tim | Apr 18, 2008 | 3:04PM

When I finally left the company that little backend Access database contained approx. 2 million records, was over a 1 gig in size and was used by over 50 people in the department I worked.

One of the greatest joys, and most smothering moments of despair, come when discovering such a thing just before starting an IT project for such a department. Joy for the billing, smothering because I wished I could jump off the roof.

GuyFromOhio | Apr 18, 2008 | 3:06PM

You implemented a data warehouse using MS ACCESS?

http://databases.aspfaq.com/database/what-are-the-limitations-of-ms-access.html

I'm glad I didn't inherit that project.

howard | Apr 18, 2008 | 3:07PM

Holy smokes a pulpit article in 2008 that DOESN'T STINK?! Let's hope it's a turn around.

Good job.

Noah | Apr 18, 2008 | 3:10PM

I enjoy almost all your columns, Bob, and I especially liked this one. Thanks for putting in the work!

Steve Ehrmann | Apr 18, 2008 | 3:27PM

A number of years ago I was starting a project with a client who thought they needed re-engineering and one of my brother-in-laws, who was a CIO at a major firm, offered me a copy of their latest presentation about re-engineering to share with the client. He said, however, don't use page 5. I of course asked why and he said you'll see when you get it.

What page 5 said was something I agree with 100%-consultants can be very bad for re-engineering, particularly if the client falls into the trap of not understanding and owning their own project.

I called him back and said you missed the fun analogy. He asked "What's that?" I told him consultants as vampires. "Huh?"


Well....according to lore a vampire can only enter a building when invited and once you've let them in the front door they're really hard to get rid of.

We had a good laugh.

Gary | Apr 18, 2008 | 3:39PM

Additional background....

From ZDnet (links from Bob).
General market conditions made things worse. While all this was happening, the market for ALF’s products tanked.
**The Emergency Vehicle industry is currently depressed. Many competitive manufacturers are experiencing financial difficulties and several have ceased operations.

JUstin | Apr 18, 2008 | 3:40PM

"A consultant is a man who knows 186 ways to make love, but doesn't know any women."
-- Mark Russell

Al | Apr 18, 2008 | 3:42PM

from the following link.. http://talkback.zdnet.com/5208-13604-0.html?forumID=1&threadID=44222&messageID=817251&start=-9930


>During the transition, ALF outsourced “accounting,
>inventory, payroll, and manufacturing process
> services” to Freightliner.

In other words they outsourced ALL CRITICAL business functions. BAD.

>As part of the transition, ALF developed a
>“standalone” ERP system designed to support the
>firm after the Freightliner separation was completed.

So they tried to "develop" from scratch a new UNTESTED system and we all know how well that turned out.

Which begs the obvious question- why didn't they just clone the existing systems and processes and just keep the business model that had worked for them in the past in place WHILE they developed a new system?

This is a leadership failure and a complete failure in business planning.

They can blame IBM all they want, but any experienced businessman worth their damn wouldn't have approved such a stupid gamble on untested technology to run your core business systems and processes.

I'm sorry but the leadership at the helm of ALF seeded this disaster. Either out of ignorance or complete incompetence it doesn't matter. They made a stupid decision and lost.

BTW - I work for IBM GBS.

JUstin | Apr 18, 2008 | 3:44PM

I guess I'm a Type D consultant then - I help companies figure out how to make open source software work for them (very little commission in the FLOSS world), and I get paid only T&M when we decide on a course together. If a project were to not succeed the customer wouldn't be billed for planning or implementation if I recommended the direction as that would reflect a failure in the analysis phase.

Bill McGonigle | Apr 18, 2008 | 3:55PM

I guess you are a consultant too, Robert. I can tell you are because you don't know what you are talking about. Here are the lowlights;

1.)"bring your smartest and most crotchety nerds into the room and ..." This one is funny. If you had such smart people, you wouldn't need a consultant anyway. If you knew you had smart people like that, you would have never brought the consultant in to begin with.
2.)You clearly do not understand what SOA is.
3.)Server consolidation and virtualization will save you money if you do it right. Just because a consultant is a lying sack of crap doesn't mean the product or idea he's yapping about is bad.
4.)Storage consolidation and virtualization will save you money. Same comments as server virtualization.

You remind me of Gartner group. You talk about a lot of stuff that you have no experience with. Or to quote Gartner group "Gartner Group studies have show that Gartner Group is the best bunch of consultants money can buy."

Some IT Guy | Apr 18, 2008 | 3:55PM

When I started at my current company 4 years ago the entire network was farmed out to EDS. We had 14 offices and none of their servers were configured the same way, nobody who setup ANY of our systems was available after they went live, and it took weeks for issues to be addressed.

About a year later my company hired someone to work full time as the IS manager so there would be at least 1 employee who knew what was going on.
He realized just what a mess we were in and said we could do a better, cheaper job in house.

Now we have 0 consultants 18 full time IS employees caring for the needs of 26 offices. All offices are well on their way to being standardized.

Les | Apr 18, 2008 | 3:56PM

Bob, you left out a fourth class of consultants. These consultants are often brought in to tell managers what the employees already know. They're so out of touch that they don't know what to believe or who needs another bran muffin to think clearly.

So they ask a bunch of consultants. The employees may have been saying the same stuff for years, but when a consultant from out of town walks in, everyone listens.

As Scott Adams pointed out in The Dilbert Principle: This is the first generation in which the managers truly do not know what the employees do for a living. And that's why we see so many people who are so busy thinking outside the box that they don't even know where the box is or what it has in it.

Jake Brodsky | Apr 18, 2008 | 3:57PM

Having worked at a Fortune 100 company for many years I can relate to much of this.

In that environment we HAD to bring in consultants - really expensive consultants, to sell upper management on the projects that we had already designed for our company.

Their thinking was "if you're not from out of town, you don't know what you are talking about." It's been the same for thousands of years.

"Only in his hometown and in his own house is a prophet without honor." Matthew 13:57

DGT | Apr 18, 2008 | 4:09PM

Why didn't American LaFrance not just say, "Create us a clone of the system we're already operating successfully under, and once that is solid in 2 or 3 years, we can consider looking at improvements"?

Hey, Bob, which type of consultant do you feel ALF got?

David B. | Apr 18, 2008 | 4:47PM

Jake Brodsky hit the proverbial nail on the manager...

Andrew B. | Apr 18, 2008 | 5:07PM

There is another type of consultant. These are the ones brought in to break the bad news management know needs to happen but don't want to be the ones that say it. They are often brought in to confirm what senior management thinks and then to be the ones who are recommending the fix to senior management. Who can then be seen not to have been the ones who came up with this need to make 2000 staff redundant. It's just avoiding being the one who brings the bad news and blaming a faceless IT Consultancy for it.

I am a consultant myself and self employed, I am the type that should be the only sort of consultant there is, which equates nearest to your type B. That is a person who you call in, explain what you want to do from a business perspective and ask him or her to tell you which is the best IT solution that achieves those aims.

If you are a good consultant you spend some time getting some background on your client and try to get your head around the bigger picture of their business. Once you have that you can then recommend the solution, or more likely, point out that maybe they should consider asking a different question. I say that, because I often find that the client is very focused on a particular issue that is causing them a problem and to just fix that may treat the symptom, not the cause.

I often end up identifying that the real problem is elsewhere and fixing that problem will cure the immediate one and also a lot of other ones they haven't asked you to fix, but are there nonetheless!

A lot of the other consultants you mention are not consultants, they are just IT technicians who can implement the IT Solution a true consultant would have recommended.

Siv | Apr 18, 2008 | 5:22PM

As an outside consultant, I follow the three old rules of IBM - the ones Big Blue forgot about along the way and no longer remembers as they speak Indian ...

Respect for the employee (my customer and staff)
Spend alot of time making the customer happy.
Go the extra mile to do a thing right.

I support small business infrastructure, email, backup and disaster recovery. I monitor my accounts with a firm but light touch and have associative relationships with other networking partners. I live for my clients and their success because if I fail to do my job, their entire business can, in effect, fail.

I know the importance of this: as a survivor from the 101st floor of 2 World Trade Center (I worked for Aon which outsourced to CSC in 2004 with disasterous results), I take my job and my clients most seriously.

Bob Eisenhardt | Apr 18, 2008 | 5:25PM

#10 got a good LOL out of me

Dan | Apr 18, 2008 | 5:39PM

#10 got a good LOL out of me

Dan | Apr 18, 2008 | 5:42PM

I once worked in a consultncy that rhymes with H - P and worked on successful and not so successful projects.

As Bob noted the successful project did a lot of worked detailing requirements up-front and had an attilla the hun project manager whose sole role seemed to be managing (i.e. rejecting) scope creep.

The un-successful one(s) were totally the converse rushed at the start, fuzzy requirements, poor management, 10 million dollar spent, nothing delivered. The only winners were the lawyers who came to clean up the mess later.

Jimbo | Apr 18, 2008 | 6:16PM

I once worked in a consultncy that rhymes with H - P and worked on successful and not so successful projects.

As Bob noted the successful project did a lot of worked detailing requirements up-front and had an attilla the hun project manager whose sole role seemed to be managing (i.e. rejecting) scope creep.

The un-successful one(s) were totally the converse rushed at the start, fuzzy requirements, poor management, 10 million dollar spent, nothing delivered. The only winners were the lawyers who came to clean up the mess later.

Jimbo | Apr 18, 2008 | 6:18PM

I know a large farm products company in my city. In about 8 years that I have known people who work there they have been through something like 4 different ERP solutions. Non of them have worked out and before it is over they are back to thier home grown solution done with an old first generation DB. I am amazed that a company in business for 30 or 40 years developing their manufacturing systems and honing them to a fine edge then decide their IMT solution is outdated and figure they can then hand that off to a company and magically a solution will happen in a year and be what they want?

Michael G | Apr 18, 2008 | 7:20PM

I like most of Justin's comments. I've been in meetings as the technical (lamb) where having given my spiel about needing N months minimum to do a job, they tell me I have N/3. I say we need to run both the old system and the new in parallel to make sure we get the new version debugged without hosing our data, they say it is too expensive. Well how d*mned expensive is it to hose your accounts receivable!

Grrr.

Doug | Apr 18, 2008 | 7:25PM

Er. I don't understand why 4 is on the list. Why is that necessarily a lie?

And I don't understand what's wrong with 3 either. Optimization I could see being bad for the old "premature..." motto, but debugging? After installing and configing something what's wrong with that? Maybe it counts as being a part of installation or what? Be more clear cringley.

And why is email address required?

Bog | Apr 18, 2008 | 7:25PM

Er. I don't understand why 4 is on the list. Why is that necessarily a lie?

And I don't understand what's wrong with 3 either. Optimization I could see being bad for the old "premature..." motto, but debugging? After installing and configing something what's wrong with that? Maybe it counts as being a part of installation or what? Be more clear cringley.

And why is email address required?

Bog | Apr 18, 2008 | 7:27PM

An awful lot of weasel words here:

The company is close to failure probably because a consultant didn't perform as it promised.

The consultant didn't perform as it promised most likely because there was no way to do so...

That was most likely the case with American LaFrance.

The new organization was probably incapable of setting its own requirements and the consultant didn't help.

Craig | Apr 18, 2008 | 7:35PM

And government is even worse about using consultants. They don't bother to consult employees, just go to the big name firms. They love accountanting companies and of course the IT company that rhymes with I-B-M. have been there, watched it happened and retreated to my IT cave to wait out the collapse. One I remember well cost the State 23 million.

Barry Winters | Apr 18, 2008 | 7:36PM

My observation from working on an ERP implementation as part of the user project team, is that the ERP consultants who were assigned to us were not subject matter experts either on the software or on the business processes for the area they were responsible for. They were marginally qualified people who were willing to be "road warriors", sucking up endless amounts of travel, lodging and per diem billings while we had to figure out how to make things work.

This was confirmed to me when after 1 implementation I too could have become a consultant.

I don't mean to demean any dedicated IT professionals out there. There were several on the project I worked on. But ... with all of the collaborative technology out there, isn't it time to retire the road warrior model in favor of something else less drastic? I bet the quality of the consulting would increase dramatically.

Julie L | Apr 18, 2008 | 7:53PM

Number # 11 (and IMHO, should be # 1). "The old code is hopeless - it needs a re-write". For some reason people always fall for this line from IT consultants. As a programmer, it always harder to read code than write code, and invariable the poor schmuck that has to pay is the client. My advice, if you hear these words, you have 2 options:
1) Sack the consultant
2) Think about it for a while and then sack the consultant

Charlie Needle | Apr 18, 2008 | 8:28PM


# 11..... hey get a Mac !!

Fast Fred | Apr 18, 2008 | 8:38PM


# 11..... hey get a Mac !!

Fast Fred | Apr 18, 2008 | 8:39PM

Ha! Shorten the article to:

The Truth About IT Consultants: Some are great but most are not.

When you hear this line spoken you fire the consultant on the spot.

"If you install Tivoli it will solve all your support problems."

Bob (too) | Apr 18, 2008 | 8:49PM

Response to GuyFromOhio and Howard's response to my original post on creating an MS Access backend database.

Just to clarify, this database was simply a reporting/read-only copy of data already existing in other databases. Every night I would purge all of the data from my database and re-write new data from the various centralized databases. If my database were to vanish over night, no real data would be lost.

I created this database because I couldn't get the IT/IM department to address my needs so I figured out a way to do it myself. The office in which I worked was located 5000 miles away from the servers where most of the various databases resided. By consolidating data from a variety of Sybase, Oracle, SQL and Access databases into a single local Access database (Access was the only tool that a lowly peon such as myself had at his disposal), my ability to generate speedy queries increased dramatically and the amount of network traffic diminished greatly as all of the data resided locally. Once completed, I simply distributed copies of the front-end to colleagues within the same location to use if they saw fit. Turns out that about 50 of them (all peons like myself) greatly appreciated the tool.

Since my "project" was created as a skunk works project of sorts and never officially condoned by management, much to the chagrin of my local colleagues, the project died a slow death after I left. The company approved projects/developers/consultants were too busy addressing the esoteric needs of management versus the day to day needs of the employees in the trenches.

Jake Brodsky made the following comment and he is abosolutely right:
As Scott Adams pointed out in The Dilbert Principle: This is the first generation in which the managers truly do not know what the employees do for a living. And that's why we see so many people who are so busy thinking outside the box that they don't even know where the box is or what it has in it.

drewby | Apr 18, 2008 | 9:29PM

Ah, I remember the day my company rolled us from our VAX/VMS system and VT terminals, and introduced us all to the wonders of Microsoft Word version 3 on networked PCs.

Back then, the IT department wasn't almost as big as the actual working revenue-producing side of the company. Now, it's huge, and tells the other people how to do their job.

Consultant: "You'll love Word. There are five or six different ways to do anything."

Staff: "But we share documents. Can we lock out all but one way to do each thing, so everyone does it the same way throughout the document?"

Consultant: "They shouldn't do that."

Consultant: "And with Word you can create really big documents. Why, I'm working on a forty-page document here."

Staff: "We often work on two hundred page documents."

Consultant: "Uh ... I'll check on that."

Consultant: "Each time you want a new document, go to 'File' and choose 'New' ..."

Staff: "No one here creates new documents. The language we use over and over again is known to be safe with the courts, and it would be malpractice to draft it each time. Every writer here can go to the archive and get a known good document and copy it for reuse. They've been doing that since before they brought in typewriters more than a century ago."

Consultant: "Uh, they shouldn't do that."

Staff, to management: "We have three computer people now for the whole firm. Will we have to have a bigger computer department when we get rid of the VAX and go to this networked Windows system?"

Management: "The new head of our IT Department assures us ...."

ankh | Apr 18, 2008 | 9:33PM

Having worked in the IT industry as internal IT and as a consultant for 15 years I completely agree with this article. Why? Because I can think of times when I have been all three of these types of "consultant."


Also, these are better titles:



Type A is the Engineer:

- A specialist in the product/industry

- Knows the tools and how to use them but may not have strong enough business skills to deliver the best project

Type B is the Sales Engineer:

- Someone trained in the technical details and how to sell the product

- This person is usually a jack-of-all-trades and does not specialize like the Engineer

Type C is the Project Manager

- A necessary evil. Engineers focus too much on the technology and not the big picture and what is best for the client
- Without a good, dedicated PM long or team projects have little chance of coming in on time and on budget



Something I have noticed is that most customers do not ask for reference projects. Too many assume that just because you are a Microsoft Partner that you must know how to deploy MS products. Right? Customers do not know that it only takes a couple of (paper) certified guys and some cash to get that title. There is nothing guaranteeing they have deployed any of the products in production before.



IT Managers, do your self a favor and ask for reference projects.

Brian Kronberg | Apr 18, 2008 | 9:39PM

> Best definition of an expert; anybody from over 50 miles away.

An expert is a person who has made all the mistakes that can be made in a very narrow field.

Niels Bohr
Danish physicist (1885 - 1962)

Brian Kronberg | Apr 18, 2008 | 9:47PM

Consultants, outsourcing and customers

Is not outsourcing simply managers trying to ship responsibility for managing to an outsider ?
ie incompetent or timid managers ?

As for Tivoli, I have yet to see any commercial monitoring system do as well as locally written scripts, some open Source code and someone who can make good graphs for the PHBs.

Could not agree more with Bob on "bring your smartest and most crotchety nerds into the room and make the consultant explain his or her statement to their satisfaction then back it up with some performance guarantee and penalty clause."
The problems with this is the nerds are nearly always ignored because they are not managers and few managers have the cojones to shirtfront a big 3 letter outsourcer.

Denarius | Apr 18, 2008 | 9:55PM

My workplace was never a Democracy, it was an Autocracy.

But now it's turned into an Hipocracy: Rule by Consultants.

Perite | Apr 18, 2008 | 9:56PM

Here's a summary of my experience with project consultants, from their perspective:

RULE 1: GET PAID
RULE 2: ADD TO THE SCOPE OF WORK
RULE 3: SEE RULE 1
RULE 4: USE POWERPOINT, NOT PLAIN LANGUAGE
RULE 5: SEE RULE 1
RULE 6: ALWAYS SAY "WE" AS IF I'M NOT JUST MAKING THIS STUFF UP
RULE 7: SEE RULE 1
RULE 8: "WE'LL GET BACK TO YOU", NEVER "I DON'T KNOW"
RULE 9: SEE RULE 1
RULE 10; DON'T USE THE FIRM'S RESOURCES, BORROW THE CLIENTS WATCH TO TELL HIM WHAT TIME IT IS
RULE 11: SEE RULE 1
.
.
.
RULE n: REVISIONS ARE ESSENTIAL, PREFERABLY WITHOUT RECONCILIATION
RULE n+1 SEE RULE 1

and on and on until the very last rule when all else fails:

FINAL RULE: SHUT UP AND DRAW (OR CODE if it's IT), THE SUCKERS ARE CATCHING ON

ALTERNATE FINAL RULE: QUIT WHILE AHEAD AND BILL FOR TERMINATION (SEE RULE 1!)

Don Hodges | Apr 18, 2008 | 10:03PM

I agree with many of the points but I would add a few key points:

1. Many consultants are extremely over-rated, particularly consultants from other countries; there seems to be a misconception that there are no strong IT consultants in the US so therefore, all foreign consultants are qualified...even ignoring the differences in work ethic, ethics in general, language and cultural barriers, many don't deliver

2. Consultants are not to blame, executives who make the decisions to use consultants are to blame...many of these decisions are based on bottles of wine, on the back nine, or in luxury boxes, or on yachts

3. Following poor executive decisions are poor managers usually hired by the same executives, who convince each other consultants are the answer - this obsolves both mgmt/execs from taking the blame if things go wrong

4. HR who screens potential consultants are also to blame because they don't take the time test potentials, or they allow managers to pre-select consultants are skip the screening process

5. Finally the consulting firms are the real culprits. Consultants are sales people. The more flamboyant and compatible you are, the further you go. Being able to speak well, roll three letter acronyms off their tongue for hours without saying a damn thing that matters seems to impress those managers who are more concerned with those consultants paying for an expensive bottle of wine at dinner, even if they don't realize it gets charged right back to the company

So, the way to avoid getting bad IT consultants is not using them in the first place which can only be avoiding by hiring competent management who can do their job - whether it's the task itself or hiring a skilled consultant to do it

James | Apr 18, 2008 | 11:44PM

The 'crotchety nerd' filter *can* be a good one; I've been the 'crotchety nerd' a few times (won't comment on the 'smartest' claim) and I like to believe I've made a positive difference in those instances.

BUT: This one can fall down, and fall down very badly, in a couple of ways. One way is what I call "Shiny Object Disease"; or the tendency of nerds (myself very much included) to get distracted by the underlying technology, which can be sexy and cool (to a nerd) while being unusable in any real-live context.

Another way is the historic tendency of nerds to suffer from relatively poor social skills (yes, I understand that's an unfair generalization). This kicks in when the nerd, who can generally figure out how to operate systems that the average user finds to be hopelessly impenetrable, doesn't realize that the system he is being asked to evaluate/debunk really is very difficult to use. This situation is much worse if the product actually does it's job; then any problems can be chalked up as 'training issues.'

Ah, 'training issues.' We love 'training issues.' 'Training issues' means it's nobody's fault. The techs can blame management for not buying enough training. The employees can blame the product because 'it's just too hard' or because there wasn't enough/any training. The consultants can ask for more money weekly. Management can blame the employees for 'not being on board' and/or HR for high turnover of trained employees. There's just nothing quite like 'training issues' to doom a project while at the same time keeping it alive forever (after all, the system works; we just need more training). I've had to scrap more than one project not because the product didn't work, but because I couldn't get the resources to properly train the people that needed/were expected to use it. After a while, the level of negativity that is built up amongst the target users reaches a point that no amount of training will ever be enough, because the users are completely convinced that 'it'll never work' and 'it was a waste of time from the start,' etc. I'm not talking about resistance to change, that's a separate issue. This comes up after the change has happened, and results from the frustration levels created by the lack of training.

Personally, I think the heart and soul of the whole consulting issue comes down to what Terry Pratchett generally describes (indirectly) as the attractiveness of distant wisdom; much like familiarity can breed contempt, wisdom from far away is always better than wisdom from up close.

Scott Horton | Apr 18, 2008 | 11:48PM

Re: Christine Comaford-Lynch

I was wondering where she went.

George Brickner | Apr 18, 2008 | 11:51PM

I'm a senior IT person in a fortune 100 company, and this article is correct. In fact, I would probably say the situation is even worse. IT staffing has been in squeeze mode for several years, however demand for IT work has dramatically increased over the last 18 mos. Instead of hiring more good people, the business fears having to squeeze again, so they bring on an army of consultants. We have large critical IT projects where the ratio of employee to consultant is 1 employee to every 30 consultants. Not so surprising, they are all dramatically over budget with little hope of getting back on track. Few of them could write a real requirement to save their life. Sad.

Zed | Apr 19, 2008 | 12:03AM

The word consultant means many different things to different people. I break the consulting market down like this:

Consultants - This is the IBM and Accentures of the world (maybe Booz Allen, Deloitte, and Cap Gemini but its really just IBM and Accenture). These guys do the really big, risky projects, typically for Fortune 500 or government clients. These guys have their own methodology, deep industry knowledge, and partnerships with everyone. They use their experience, their methodologies, and any other reusable asset to do almost anything - and charge a premium.

Offshorers - Typically Indian companies who can use their offshore workforce to implement medium to large projects. InfoSys and Wipro come to mind. While not too dissimilar to IBM and Accenture, offshorers use their offshore capability as a primary tool rather than a single offering.

Implementors - These are the guys who focus on implementing a particular software system. Microsoft Services is a great example as would the services arm of any software company.

Staff Augmenters - Sometimes referred to as "body shops". These companies sell their people rather than their company's experiences, processes or other assets.

Now, I assume this article is referring to consultants as defined above - IBM and Accenture. I have seen companies who do not know how to manage consultants fail miserably (similar to some of the comments). I have also seen companies successfully utilize consultants, implementors, and staff augmenters is such a way as to create the perfect balance of skillsets and costs. Staffing an IT project is hard unless you plan to make long term investments in a large number of people. Most companies don't want to have those people on staff permanently.

The project I am currently working on has the following mix: 40% internal, 25% consultants, 25% staff augmentation, and 10% software vendor supplied. The formula is working great. The company has complete control and responsibility for the project. The consultants are pointing them in the right direction and managing some of the teams. The staff augments are filling the skill gaps on a temporary basis, and the software vendor is providing access to their internal knowledge. This company knows how to leverage all of its partners in the most appropriate ways.

No runaway costs. No empty promises. No sales pitch. Just really smart people doing really good work with the right people. This is what it's about. Most companies don't have a clue how to work with third-parties and end up creating stories like this column and the comments above.

Zach | Apr 19, 2008 | 12:54AM

The word consultant means many different things to different people. I break the consulting market down like this:

Consultants - This is the IBM and Accentures of the world (maybe Booz Allen, Deloitte, and Cap Gemini but its really just IBM and Accenture). These guys do the really big, risky projects, typically for Fortune 500 or government clients. These guys have their own methodology, deep industry knowledge, and partnerships with everyone. They use their experience, their methodologies, and any other reusable asset to do almost anything - and charge a premium.

Offshorers - Typically Indian companies who can use their offshore workforce to implement medium to large projects. InfoSys and Wipro come to mind. While not too dissimilar to IBM and Accenture, offshorers use their offshore capability as a primary tool rather than a single offering.

Implementors - These are the guys who focus on implementing a particular software system. Microsoft Services is a great example as would the services arm of any software company.

Staff Augmenters - Sometimes referred to as "body shops". These companies sell their people rather than their company's experiences, processes or other assets.

Now, I assume this article is referring to consultants as defined above - IBM and Accenture. I have seen companies who do not know how to manage consultants fail miserably (similar to some of the comments). I have also seen companies successfully utilize consultants, implementors, and staff augmenters is such a way as to create the perfect balance of skillsets and costs. Staffing an IT project is hard unless you plan to make long term investments in a large number of people. Most companies don't want to have those people on staff permanently.

The project I am currently working on has the following mix: 40% internal, 25% consultants, 25% staff augmentation, and 10% software vendor supplied. The formula is working great. The company has complete control and responsibility for the project. The consultants are pointing them in the right direction and managing some of the teams. The staff augments are filling the skill gaps on a temporary basis, and the software vendor is providing access to their internal knowledge. This company knows how to leverage all of its partners in the most appropriate ways.

No runaway costs. No empty promises. No sales pitch. Just really smart people doing really good work with the right people. This is what it's about. Most companies don't have a clue how to work with third-parties and end up creating stories like this column and the comments above.

Zach | Apr 19, 2008 | 12:55AM

The word consultant means many different things to different people. I break the consulting market down like this:

Consultants - This is the IBM and Accentures of the world (maybe Booz Allen, Deloitte, and Cap Gemini but its really just IBM and Accenture). These guys do the really big, risky projects, typically for Fortune 500 or government clients. These guys have their own methodology, deep industry knowledge, and partnerships with everyone. They use their experience, their methodologies, and any other reusable asset to do almost anything - and charge a premium.

Offshorers - Typically Indian companies who can use their offshore workforce to implement medium to large projects. InfoSys and Wipro come to mind. While not too dissimilar to IBM and Accenture, offshorers use their offshore capability as a primary tool rather than a single offering.

Implementors - These are the guys who focus on implementing a particular software system. Microsoft Services is a great example as would the services arm of any software company.

Staff Augmenters - Sometimes referred to as "body shops". These companies sell their people rather than their company's experiences, processes or other assets.

Now, I assume this article is referring to consultants as defined above - IBM and Accenture. I have seen companies who do not know how to manage consultants fail miserably (similar to some of the comments). I have also seen companies successfully utilize consultants, implementors, and staff augmenters is such a way as to create the perfect balance of skillsets and costs. Staffing an IT project is hard unless you plan to make long term investments in a large number of people. Most companies don't want to have those people on staff permanently.

The project I am currently working on has the following mix: 40% internal, 25% consultants, 25% staff augmentation, and 10% software vendor supplied. The formula is working great. The company has complete control and responsibility for the project. The consultants are pointing them in the right direction and managing some of the teams. The staff augments are filling the skill gaps on a temporary basis, and the software vendor is providing access to their internal knowledge. This company knows how to leverage all of its partners in the most appropriate ways.

No runaway costs. No empty promises. No sales pitch. Just really smart people doing really good work with the right people. This is what it's about. Most companies don't have a clue how to work with third-parties and end up creating stories like this column and the comments above.

Zach | Apr 19, 2008 | 12:56AM

The word consultant means many different things to different people. I break the consulting market down like this:

Consultants - This is the IBM and Accentures of the world (maybe Booz Allen, Deloitte, and Cap Gemini but its really just IBM and Accenture). These guys do the really big, risky projects, typically for Fortune 500 or government clients. These guys have their own methodology, deep industry knowledge, and partnerships with everyone. They use their experience, their methodologies, and any other reusable asset to do almost anything - and charge a premium.

Offshorers - Typically Indian companies who can use their offshore workforce to implement medium to large projects. InfoSys and Wipro come to mind. While not too dissimilar to IBM and Accenture, offshorers use their offshore capability as a primary tool rather than a single offering.

Implementors - These are the guys who focus on implementing a particular software system. Microsoft Services is a great example as would the services arm of any software company.

Staff Augmenters - Sometimes referred to as "body shops". These companies sell their people rather than their company's experiences, processes or other assets.

Now, I assume this article is referring to consultants as defined above - IBM and Accenture. I have seen companies who do not know how to manage consultants fail miserably (similar to some of the comments). I have also seen companies successfully utilize consultants, implementors, and staff augmenters is such a way as to create the perfect balance of skillsets and costs. Staffing an IT project is hard unless you plan to make long term investments in a large number of people. Most companies don't want to have those people on staff permanently.

The project I am currently working on has the following mix: 40% internal, 25% consultants, 25% staff augmentation, and 10% software vendor supplied. The formula is working great. The company has complete control and responsibility for the project. The consultants are pointing them in the right direction and managing some of the teams. The staff augments are filling the skill gaps on a temporary basis, and the software vendor is providing access to their internal knowledge. This company knows how to leverage all of its partners in the most appropriate ways.

No runaway costs. No empty promises. No sales pitch. Just really smart people doing really good work with the right people. This is what it's about. Most companies don't have a clue how to work with third-parties and end up creating stories like this column and the comments above.

Zach | Apr 19, 2008 | 12:57AM

Sorry for the multiple posts. The captcha was giving me problems.

Zach | Apr 19, 2008 | 12:59AM

I work in an IT shop of about 500 people, I've been there 2 years, and I can tell you the folks that have a clue are NEVER consulted or taken seriously.
So, these folks come in, play a shell game, and go home. SOS every day. Nobody is interested in their ideas, so they gave up trying to get folks to listen.
The folks that have FEW clues are the ones making decisions.
It is scary to think where this company will be in 5 years, but like MOST companies: as long as folks are getting paid, and the work is getting done (barely), nobody cares. Anymore.

WT | Apr 19, 2008 | 1:21AM


You are being a bit harsh on virtualization, it may be a bit complicated to handle for in house IT staff.

But it can consolidate your 10 servers into one box, so lowers hardware costs. But does increase the cost of managing the system.(need to check the effect of TCO)

as of now only 6% of servers have Virtulization, so it is going to be the fastest growing field in IT.

Praveen | Apr 19, 2008 | 1:33AM

Virtualization absolutely does save you money. With the costs of power and cooling getting higher and higher, not to mention that its even hard to find available power in a data center these days, virtualization is the smart way to go. Not everything can or should be virtualized but only a fool will tell you that everything can be virtualized and only a fool will believe that person. Either way, those two fools deserve each other.
A good solid virtualization product such as vmware for windows and micro-partitioning on IBM pSeries machines can reduce your hardware costs and associated costs dramatically. It is in your best interest to have someone familiar with the inner workings of vmware but you can easily pay for a few extra bodies with the hardware and power costs you will cut. I have done this.
Why do you have a beef against virtualization Bob? Just because you and the other consultants don't understand it, doesn't make it less of a great solution.
I suggest you read and then experiment with the contents of Brian Ward's VMware workstation book. Thats a good start for you.

virtualization expert | Apr 19, 2008 | 1:56AM

It's really amazing how management will listen to consultants but not their own people. Whatever it is that makes them do that, someone should bottle it and make a fortune. :)

anon | Apr 19, 2008 | 2:35AM

Rob....I tune in each week hoping to get a sneak peak of the future of some technology ( or business ). Are you saying in a lateral / obligue way something about the future of business here? This arty was not particularly sexy but that's just me...maybe its my lack of understanding?

Fred X | Apr 19, 2008 | 3:13AM

Not the case in Australia. Me and my friends have never worked as consultant or contractors. A lad from UK now work with me in a major bank just two weeks after he arrived.

AK | Apr 19, 2008 | 7:03AM

Bob -

As a consultant, I have often said that the tragedy of our profession is that we can only work for people who are unready and unwilling to listen to what we say. Most organizations have people already there who know what the problem is and what needs to be done to fix it. But since the organization cannot listen, separate the wheat from the chaff, and implement that internal knowledge, our attempts from outside are most often doomed unless we can ride roughshod over the blockers (not, unfortunately, eliminating them) or the company is in such dire straits they are forced to break their dysfunctional behavior. My goal in life is to work for a company that doesn't need or use consultants.. but I haven't found that company yet. Maybe Expedtiors in Seattle - their CEO at least tells the Wall Street analysts to piss off.

This does not apply to pure outsourcing - IF the customer knows what they want and have clearly understood they are eliminating mature and marginal processing (e.g. check processing for a bank) while retaining control over any intellectual capital and opportunities (see: JP Morgan taking their processing back in house). But, too few companies retain the knowledge in-house of *why* that business was considered marginal and how to properly evaluate the remaining processes or business functions for opportunity. Once those people are gone (too often they are considered unnecessary once the work is outsourced) bad decisions follow.

I agree - good consultants are hard to find, just as top-notch people in any field are rare. Most at least do no harm. The trouble is in the customer, where there's no one who can recognize bad advice when they hear it. I remember in the 90's having our company (now gone, in part because of a runaway $150 million IT project) blow man-years on projects from Ernst & Young, Andersen, Price Waterhouse at $250/hr. Nowadays we still have the same "winning" percentage of successful projects, but at least the companies are blowing just $25/hr on Wipro and Infosys.

I think what too few people understand is that we're going to have the big 3 (Microsoft, Oracle, SAP)in business systems in another 5 years. (Spare me the outraged howls of the open source crowd... as soon as Struts or something else actually starts to make money one of the big 3 will buy it.) It's very doubtful that anyone will get more than an extraordinarily marginal value from proprietary tweaks to any of the functions these groups will cover: HR, Finance, TMS, WMS, ...

IT strategy is not yet an oxymoron, but the industry has done a bad job of explaining what it can be, and too often (as you say) tries to sell the expertise it already has. We don't generate revenue, and those that do don't care if their physician order entry system or pilot scheduling application uses J2EE or .Net. M&A is one area where IT still can add value - too often called in after the deal is done, IT can still make-or-break that sort of growth. Let's get over ourselves and focus on the business.

GMF | Apr 19, 2008 | 7:26AM

This is not a consultancy problem, this is a problem with bad developers/managers. Those developers/managers that follow the Agile Manifesto are like Comaford-Lynch and provide great value.

Scott Carlson | Apr 19, 2008 | 7:59AM

This is not a consultancy problem, this is a problem with bad developers/managers. Those developers/managers that follow the Agile Manifesto are like Comaford-Lynch and provide great value.

Scott Carlson | Apr 19, 2008 | 8:02AM

Thank you for telling me how to be a higher paid consultant with those 10 points. We need all the help we can get, since we cannot get real jobs, as a result of the far right takeover 25 years ago.

david jensen | Apr 19, 2008 | 8:16AM

Thank you for telling me how to be a higher paid consultant with those 10 points. We need all the help we can get, since we cannot get real jobs, as a result of the far right takeover 25 years ago.

david jensen | Apr 19, 2008 | 8:18AM

I work in IT consulting for a firm that's fairly successful. Parts of your article are dead-on, and parts of it are woefully uninformed.

I hate to be the bearer of contradictory news, but we have customer accounts where we are the driving force behind critically important IT projects. Not only are these successful engagements, but they're efforts where the customer has no clue of how to plan and execute on their own.

Likewise, to be transparent, we also have accounts where we have struggled to make impact and where projects have failed, been re-scoped or otherwise changed beyond recognition. While I know the industry stats are somewhere between 1/3 to 1/2 failure rates, our project/relationship failure rate is less than 1 in 20.

Then again, we're probably closer to a large category A firm where we focus on concrete technical problems that are reasonably well-defined.

The notion that corporate IT is the purview of a lot of shining stars unappreciated by management and forced to suffer the incompetencies of outside consultants is pretty amusing. Flip it around and it looks a little more like my world. I'm embarassed for the state of corporate IT and its practitioners. Some very smart folks out there, but they're very much the exception, not the rule.

The industry is filled with charlatans, no doubt about it. But business stakeholders have budgets that don't fit the work and only an outside consultant is willing to gamble on being able to figure out some kind of workable solution on the ground. With a budget that's frequently less than half what it would take to do the job correctly, I'm unsurprised management has to find a cut-rate outside consulting vendor who is willing to risk success on their project for prospective upside--they can't get it done internally, they don't know how and if it fails who else will there be to blame?

Point is, corporate IT is equally culpable in the matter. And success or failure never has anythign to do with technology capability. As you rightly point out, it's typically about defining requirements (have you ever taken stock of what the average business or IT owner thinks qualifies as a requirements definition--now, that, my friend, is high effing comedy), ensuring the customer actually makes required decisions when needed and both sides being flexible. Anything else is unrealistic b.s. that will lead to failure.

Your 10 lies sort of blow, Bob. You give us too little credit or at least aren't hip to the more nuanced and costly ruses afoot.

1) "This can only be accomplished through a large custom development project."

Sometimes true, sometimes not. I think customer appdev is proposed more often than it should be, so you're right there. But the industry has pulled its head out of its ass a bit and this is a waning issue.

2) "Of course your data is safe."

Non sequitur. Most corporate data is marginally safe to begin with. And obviously this is the kind of blind generalization that I'd be embarassed for any consultant to make or any customer to believe.

3) "We'll need a day or two for optimization and debugging."

Same as #2. This isn't happening in consulting A-ball. If someone's willing to believe this on the customer side then they deserve the consultant who spouted it to him.

4) "Yes, we've done this before. There are several companies using this product (or technology). They really like it."

Useless statement. Can be true, can be false. Companies don't hate every product, there are actually some winners out. This is just lazy cynicism.

5) "Server consolidation and virtualization will save you money."

Absolutely can. Absolutely needs to be done well and you had better understand the business case before you start to do it. I've yet to meet a customer who doesn't love what consolidation and virtualization have ultimately done for them.

6) "Storage consolidation and virtualization will save you money."

See #5 although the level of investment required and reliance on product-driven consultants definite contributes to this type of project seeing substantial budget overruns.

7) "The upgrade (or change) will be seamless and will not affect production."

Same as #3, no credible, big league consultant is saying this kind of crap on a regular basis. You're delving into uninformed characticture here.

8) "The upgrade (or change) will be transparent to users."

Mostly the same as #7. Messaging, directory, server upgrades or migrations can actually happen fairly transparently. Most other things don't. But transparent is also what customers are asking to here. Do you naively think the average IT buyer is ready to hear "well there will be some initial pain but it's outweighed by the long-term benefits you're targeting, so the key is to manage towards minimizing that pain and being very flexible working together to make sure it's impact on the business is as small and well-communicated as possible"?

That's not what we call a "win theme", Bobby. People get the answers they want sometimes. Just the same, I'll let you keep this one, I can see it being prone to abuse by disreputable folks.

9) "Yes, we tested this thoroughly before installing it."

Meh. Testing is weak both internally and in consulting. And customers really don't want to pay what adequate testing throughout the project lifecycle really costs. So, nudge, nudge, wink, wink, we'll test it sufficiently.

We budget dedicated testing effort at roughly 100% of execution effort, not including execution phase testing activities. As often as not, it's an incredulous customer who carps about the price and advocates a much lower level of testing effort.

Come on, Bob--you know this is like everything else, at some level, we get what we deserve.

10) "If you install Tivoli it will solve all your support problems."

I'll give you that one (and Unicenter is even worse).

I'll say one thing I think is lost on a lot of folks. The job of a consultant is nowhere as easy and luxurious as some folks seem to want to believe. People travel four/five days a week to work at a customer site, way from their families, for months at a time. On balance, we don't make much more money than if we did this in corporate IT, but the type of work we do seems like can be more exciting/interesting--we get decent training and spend a lot of time trying to solve really hairy types of problems. And most of our firms don't really make all that much money--our NOI is
This is one tough business and I think most people who don't do it for a living at the higher levels don't realize this. I'm not talking about some guy goofing around doing 1099 work or body shopping.

Someone Who Does This | Apr 19, 2008 | 9:09AM

Incidentally, here's my list of customer behaviors that I recommend no matter which color hat you wear, call it some rare free consulting:

1. Meet the players. Either meet your project team, or if you're selecting too far out to be able to require a locked team, meet a representative team. Making sure you know the types of consultants you're engaging, if not the specific ones, is key. Your comfort level with your project leads, quality owner and account owner will be some of the most critical success factors.

2. Don't buy on price. Trust me, the lowest priced vendor is knowingly or unknowingly underestimating your project by maybe as much as 100%. And they're not going to suck it up and lose that much money on your project. They're going to deliver crap work that meets the test of not getting themselves sued. It's going to cost you what the most reasonable, high bid is anyway, it's just a question of whether you pay now, later or in turnaround.

3. Buy from the vendor that seems like they understand your requirements the best. Requirements will make or break your project. The consultant who best understands your requirements on the way in has the best shot at success, regardless of the other factors (they're just noise).

4. References are useless. We're not going to give you a bad one (even if you try and ask for one).

5. Don't fix price. Combined with #2, this almost guarantees a crap outcome. If you fix price, you're just going to get change ordered into oblivion. Shared risk works against the actual behaviors a combined customer+consulting team needs to succeed and doesn't actually share any risk. The risk of your continued business is enough incentive for a qualified consulting firm, and if you need this to manage the commodity hacks, then that's your own fault. But using fixed fee as an across-the-board buying strategy is similar to a company requiring all travel be booked through priceline. Good luck.

6. Don't let the geniuses in Purchasing drive your decision. If you want cheap toilet paper that chafes your ass, leave it up to Purchasing. Same thing goes for IT consulting services.

7. Give vendors more than a week or two to respond to your patchy RFP. The less time we have, the more likely you are to get dodgy approaches and tenuous estimates. An RFP for anything substantive should allow at least a month for responses--we'll put in the free labor on our side, why would you want to cap free, up front labor?

8. What you're calling agile is probably just cutting corners. If you want to do true agile, we do too--but don't get pissed off when we explain what it really is and why it requires you to shift your focus from a fixed budget and delivery schedule.

9. Limit buying implementation services from vendors who sell anything but services. i.e., Oracle, Microsoft, EMC, HP... the consultants at these firms just exist to sell more product, they're not the companies' core business and few of them are better than product flacks. Sometimes you need them for spot roles and to support their product. If you're hiring one of these firms to do your large scale project, you're doing yourself and your company an embarassing disservice. The sales pitch sounds great, but trust me, this is probably some of the worst snake oil on the shelves.

10. Ignore the first 9: Bid and award all work in phases. Specifically, never bid full cycle projects. Break envisioning, planning and requirements definition into a first phase and bid that out. Wait until that's complete to bid implementation through run state. Remember, insufficient requirements and underestimation are the source of pretty much every significant project failure. So limit your risk by making sure these precursors happen in phase 1--even if implementation needs to be more agile.

I sleep pretty well at night. We have a lot of successful customer relationships. We have to bust our ass and pull our hair out to stay ahead, but that's the game. It's not a game for rubes and neophytes, you need to partner up very smartly and you need to be as good at being a customer as the consultant needs to be at their job. This isn't like having your lawn mowed, unfortunately. But if you can find the right types of vendors and manage your relationships and projects effectively, you can get things done that you might not get done with your in-house team alone.

Someone Who Does This | Apr 19, 2008 | 9:11AM

Bob,
There are two sides as "Someone who does this" points out.
A good friend, recently laid off went back to consult for the old company. Strange, but not that unusual. He has learned a ton about the business side very quickly. He has always been one of the "smart and crotchety" nerds. Here is his consulting wisdom.
"If the customer asks you to do something you know is stupid, tell them it is wrong. If they ask for the same thing again, say "are you sure?", when they say yes, do it and be sure you get paid."

Doug | Apr 19, 2008 | 10:22AM

???

dud | Apr 19, 2008 | 10:57AM

"Someone who does this" is dead-bang on. I've been on both sides of the fence. One thing nobody has mentioned so far is how badly many customers treat the consultants the hire. I know of a large state agency that asked a consultant to help with a serious problem that was causing outage to a public service on a weekend. Even though this problem was outside the scope of the contract the consultant pitched in to help. When he billed for his services, the bean-counter said "NO, That's not in the contract" and screwed the contractor.

I could write a whole page on this but won't do it here.

Fence Straddler | Apr 19, 2008 | 11:05AM

"Someone who does this" is dead-bang on. I've been on both sides of the fence. One thing nobody has mentioned so far is how badly many customers treat the consultants the hire. I know of a large state agency that asked a consultant to help with a serious problem that was causing outage to a public service on a weekend. Even though this problem was outside the scope of the contract the consultant pitched in to help. When he billed for his services, the bean-counter said "NO, That's not in the contract" and screwed the contractor.

I could write a whole page on this but won't do it here.

Fence Straddler | Apr 19, 2008 | 11:06AM

"Someone who does this" is dead-bang on. I've been on both sides of the fence. One thing nobody has mentioned so far is how badly many customers treat the consultants they hire.

I know of a situation where a large state agency's project manager asked a consultant to help with a serious problem that was causing outage to a public service on a weekend. Even though this problem was outside the scope of the contract, the consultant pitched in to help since a change order could not eveb begin to be approved until Monday. When he billed for his services, the bean-counter said "NO, That's not in the contract" and screwed the contractor.

I could write a whole page on this but won't do it here.

Fence Straddler | Apr 19, 2008 | 11:10AM

"Someone who does this" is dead-bang on. I've been on both sides of the fence. One thing nobody has mentioned so far is how badly many customers treat the consultants they hire.

I know of a situation where a large state agency's project manager asked a consultant to help with a serious problem that was causing outage to a public service on a weekend. Even though this problem was outside the scope of the contract, the consultant pitched in to help since a change order could not even begin to be approved until Monday. When he billed for his services, the bean-counter said "NO, That's not in the contract" and screwed the contractor.

I could write a whole page on this but won't do it here.

Fence Staddler | Apr 19, 2008 | 12:08PM

You know, Bob makes this whole IT pundit thing look pretty easy. Mind if I try my hand at writing a column? Thanks for loaning me some space, Bob! Perma-archived at cringelysucks.blogspot.com.




------------------------------------------




The Truth About IT Columnists: Some are great but Cringely is not.




These days everyone in IT is a columnist, a blogger, or both. Is there a difference any more? Easy to use content management systems, the proliferation of tools like blogger and wordpress, and third party advertising networks have led countless thousands to realize that they to can combine a top ten list and a hoary "there are only three types of" trope and kick out a column in less time than it takes to re-heat some leftover pizza. This has led to the production of some of the laziest and obtuse IT commentary in the 38 years I've been reading. It's scary. I'm scared. Aren't you?




So here is my advice on how to select and read an IT columnist followed by a grim list of the 10 most common lies told by bad columnists.




What let me to write this column were the troubles of a DC-based public television network -- PBS -- a storied maker of children's programming, nature documentaries, and pledge drives. Several years ago, PBS spun off a web site and hired a columnist whose name rhymes with "C-R-I-N-G-E" to pen a weekly opinion piece for them. Fast forward several years later, and PBS suddenly has no idea what the hell their columnist is writing about. PBS's good name is sullied with the total lack of insight and formulaic writing that one typically associates with Cosmo magazine. At least if Bob were writing about orgasms and how to pluck your eyebrows the website might actually garner a few readers.




Who does YOUR IT columnist work for? Why did I write that? What does it have to do with the rest of the column? I don't know, and neither shall you, for I will not return to this theme again in this column.




My editor tells me I still have several hundred words to go, so here is my guide to the various types of IT columnists and how to read the most good and the least bad for your invested time.




There are generally three types of IT columnists because that's how much space I need to fill this week. I'll simply label them A, B and C because after Good and Bad I couldn't come up with a third name that made any sense.




Type A columnists are the good ones. They typically know something about what they're writing about. Maybe they have a background as a programmer, or designed chips for a living. Because they have actual experience in the field, they are able to more accurately identify important trends and game-changing technologies amid the overwhelming deluge of breathless enthusiasm and paid hype that characterized the IT industry.




Sometimes, however, people want breathless enthusiasm. That's why we have columnist B. I already tipped my hand here, but just to make things clear: these are the bad ones. Columnist B is supposed to open readers minds to new ideas about how technology will change absolutely everything absolutely any day now. They also keep a highly sensitive finger to the wind, and serve as a early warning about when the direction is changing. This is called taking a contrarian position.




These days it is doubtful that any Type B columnists can provide any good ideas. They are mostly expert at dinner table conjecture and bong-inspired delusions of profundity. In the early days -- back when your dad was deeply confused by that strange PC jr. sitting on his desk -- people would believe whatever Type B columnists would tell them. Now that the computer industry is mature, people understand Type B columnists for what they really are: some guy living in Charleston who knows how to edit the Windows system registry. Useful if he's your neighbor, but nothing that especially qualifies him to predict the next moves of Google or Apple.




There is another class of columnist that isn't really a columnist at all -- they're editors. But for purposes of my word count, I'm going to refer to them as Columnist Type C. Type C columnists don't actually write columns themselves. Instead, they manage other columnists and tell them what to do. The best ones are like Attila the Hun. Or maybe Ghengis Khan. I'm not sure which cliche is more apt here, really. But you get the idea. Tough. If you get one of the good ones, they can sometimes turn bad Type B columnists into good Type A columnists by making the columnist work hard and refusing to publish sub-standard work.




The best Type C columnist I ever knew was Harold Ross, who is now dead and no longer does columnist work at all. A key part of his success was to carefully read the work of columnists he employed. He was merciless about sloppy thinking, reliance on cliche, and misplaced commas. As a result, columns produced for his magazine were insightful, logically consistent and erudite (look it up). Why do I bring this up? Not sure, but hey -- 81 more words. Now it's 84. 85. Roses are red, violets are farts, I hope I can wrap this sucker up before Lost starts.




I never would have put up with a boss like Harold Ross.




OK, home stretch now. Time for a list and we'll be done:




10 Most Frequent Lies Told by IT Columnists




1) Thirty years as an IT journalist makes one qualified to tell IT developers how to do their work.




2) It doesn't matter where I live. There's plenty of inside dirt to be learned if you know what parts of Charleston to frequent.




3) I slaved over this for hours.




4) No, really.




5) We never, ever simply phone it in.




Ah, hell. Let's just stop at 5 and call it even. My torrent of Too Trusting Teenage Babes #8 just finished downloading. Now both of us have better things spend our time on than this drivel.

SpanktheUser | Apr 19, 2008 | 1:02PM

Obviously a consultant helped design the comment system for this web site.

Obviously a consultant helped design the comment system for this web site.

Obviously a consultant helped design the comment system for this web site.

Obviously a consultant helped design the comment system for this web site.

Frank from Florida | Apr 19, 2008 | 1:04PM

You know, Bob makes this whole IT pundit thing look pretty easy. Mind if I try my hand at writing a column? Thanks for loaning me some space, Bob! Perma-archived at cringelysucks.blogspot.com.

------------------------------------------

The Truth About IT Columnists: Some are great but Cringely is not.

These days everyone in IT is a columnist, a blogger, or both. Is there a difference any more? Easy to use content management systems, the proliferation of tools like blogger and wordpress, and third party advertising networks have led countless thousands to realize that they to can combine a top ten list and a hoary "there are only three types of" trope and kick out a column in less time than it takes to re-heat some leftover pizza. This has led to the production of some of the laziest and obtuse IT commentary in the 38 years I've been reading. It's scary. I'm scared. Aren't you?

So here is my advice on how to select and read an IT columnist followed by a grim list of the 10 most common lies told by bad columnists.

What let me to write this column were the troubles of a DC-based public television network -- PBS -- a storied maker of children's programming, nature documentaries, and pledge drives. Several years ago, PBS spun off a web site and hired a columnist whose name rhymes with "C-R-I-N-G-E" to pen a weekly opinion piece for them. Fast forward several years later, and PBS suddenly has no idea what the hell their columnist is writing about. PBS's good name is sullied with the total lack of insight and formulaic writing that one typically associates with Cosmo magazine. At least if Bob were writing about orgasms and how to pluck your eyebrows the website might actually garner a few readers.

Who does YOUR IT columnist work for? Why did I write that? What does it have to do with the rest of the column? I don't know, and neither shall you, for I will not return to this theme again in this column.

My editor tells me I still have several hundred words to go, so here is my guide to the various types of IT columnists and how to read the most good and the least bad for your invested time.

There are generally three types of IT columnists because that's how much space I need to fill this week. I'll simply label them A, B and C because after Good and Bad I couldn't come up with a third name that made any sense.

Type A columnists are the good ones. They typically know something about what they're writing about. Maybe they have a background as a programmer, or designed chips for a living. Because they have actual experience in the field, they are able to more accurately identify important trends and game-changing technologies amid the overwhelming deluge of breathless enthusiasm and paid hype that characterized the IT industry.

Sometimes, however, people want breathless enthusiasm. That's why we have columnist B. I already tipped my hand here, but just to make things clear: these are the bad ones. Columnist B is supposed to open readers minds to new ideas about how technology will change absolutely everything absolutely any day now. They also keep a highly sensitive finger to the wind, and serve as a early warning about when the direction is changing. This is called taking a contrarian position.

These days it is doubtful that any Type B columnists can provide any good ideas. They are mostly expert at dinner table conjecture and bong-inspired delusions of profundity. In the early days -- back when your dad was deeply confused by that strange PC jr. sitting on his desk -- people would believe whatever Type B columnists would tell them. Now that the computer industry is mature, people understand Type B columnists for what they really are: some guy living in Charleston who knows how to edit the Windows system registry. Useful if he's your neighbor, but nothing that especially qualifies him to predict the next moves of Google or Apple.

There is another class of columnist that isn't really a columnist at all -- they're editors. But for purposes of my word count, I'm going to refer to them as Columnist Type C. Type C columnists don't actually write columns themselves. Instead, they manage other columnists and tell them what to do. The best ones are like Attila the Hun. Or maybe Ghengis Khan. I'm not sure which cliche is more apt here, really. But you get the idea. Tough. If you get one of the good ones, they can sometimes turn bad Type B columnists into good Type A columnists by making the columnist work hard and refusing to publish sub-standard work.

The best Type C columnist I ever knew was Harold Ross, who is now dead and no longer does columnist work at all. A key part of his success was to carefully read the work of columnists he employed. He was merciless about sloppy thinking, reliance on cliche, and misplaced commas. As a result, columns produced for his magazine were insightful, logically consistent and erudite (look it up). Why do I bring this up? Not sure, but hey -- 81 more words. Now it's 84. 85. Roses are red, violets are farts, I hope I can wrap this sucker up before Lost starts.

I never would have put up with a boss like Harold Ross.

OK, home stretch now. Time for a list and we'll be done:

10 Most Frequent Lies Told by IT Columnists

1) Thirty years as an IT journalist makes one qualified to tell IT developers how to do their work.

2) It doesn't matter where I live. There's plenty of inside dirt to be learned if you know what parts of Charleston to frequent.

3) I slaved over this for hours.

4) No, really.

5) We never, ever simply phone it in.

Ah, hell. Let's just stop at 5 and call it even. My torrent of Too Trusting Teenage Babes #8 just finished downloading. Now both of us have better things spend our time on than this drivel.

SpanktheUser | Apr 19, 2008 | 1:06PM

Part-timers and temporary employees should never be called "consultants".



It's an example of "definition shifting" that is used to obscure the truth and make people feel better. ("sanitation engineer" instead of "garbage man")



Consultants that sell software should never be called consultants either. They are "Dealers".


Consulting should mean giving guidance, as Bob alluded to in type B. Guidance should be given without the bias caused by a product or platform to sell. It started out that way.


Overblown titles and greed killed the true meaning of the title "Consultant", to everyone's detriment.

Stu | Apr 19, 2008 | 1:14PM

Part-timers and temporary employees should never be called "consultants".



It's an example of "definition shifting" that is used to obscure the truth and make people feel better. ("sanitation engineer" instead of "garbage man")



Consultants that sell software should never be called consultants either. They are "Dealers".


Consulting should mean giving guidance, as Bob alluded to in type B. Guidance should be given without the bias caused by a product or platform to sell. It started out that way.


Overblown titles and greed killed the true meaning of the title "Consultant", to everyone's detriment.

Stu | Apr 19, 2008 | 1:16PM

Looks like the guy who wrote the parody column needs to learn how to use the rules of english grammar. A spell checker wouldn't hurt either.

I'm Sam Moshe

sam moshe | Apr 19, 2008 | 1:27PM

To quote a plaque that my daughter gave me when I worked for a consulting firm:


"Consulting
If your not part of the solution, there a lot of money to be made prolonging the problem."

Plaque from http://www.despair.com

JimR | Apr 19, 2008 | 1:50PM

"The company is close to failure probably because a consultant didn't perform as it promised. "

It's far more likely the company is failing due to lack of planning, documentation of expectations, and communication.

me | Apr 19, 2008 | 2:06PM

Wow! Some folks really took offense at this one.(Methinks thou dost protest too much...??)

Bob, I am an IT consultant and I agree with you completely. I have been on both sides of the fence and seen both good and bad from full-timers and consultants. You forgot to mention that the really good IT people (consultant or not) are the ones that help the business understand what IT can and CANNOT do to help the business succeed. IT staff that fail in that area fail both the business and themselves. More importantly, as more work is outsourced, companies hav fewer internal people that can truly identify and understand business needs/goals and their relationship to IT and/or how IT can help those needs/goals to be met.

Good article/viewpoint (btw,I have over 20 years in IT and have worked with more computing platforms than other people can identify).

And for those that are not mentally challenged...
Purgamentum init, exit purgamentum.

and

Sona si latine loqueris!

Ray | Apr 19, 2008 | 2:31PM

Wow! Some folks really took offense at this one.(Methinks thou dost protest too much...??)

Bob, I am an IT consultant and I agree with you completely. I have been on both sides of the fence and seen both good and bad from full-timers and consultants. You forgot to mention that the really good IT people (consultant or not) are the ones that help the business understand what IT can and CANNOT do to help the business succeed. IT staff that fail in that area fail both the business and themselves. More importantly, as more work is outsourced, companies hav fewer internal people that can truly identify and understand business needs/goals and their relationship to IT and/or how IT can help those needs/goals to be met.

Good article/viewpoint (btw,I have over 20 years in IT and have worked with more computing platforms than other people can identify).

And for those that are not mentally challenged...
Purgamentum init, exit purgamentum.

and

Sona si latine loqueris!

Ray | Apr 19, 2008 | 2:34PM

Wow! Some folks really took offense at this one.(Methinks thou dost protest too much...??)

Bob, I am an IT consultant and I agree with you completely. I have been on both sides of the fence and seen both good and bad from full-timers and consultants. You forgot to mention that the really good IT people (consultant or not) are the ones that help the business understand what IT can and CANNOT do to help the business succeed. IT staff that fail in that area fail both the business and themselves. More importantly, as more work is outsourced, companies hav fewer internal people that can truly identify and understand business needs/goals and their relationship to IT and/or how IT can help those needs/goals to be met.

Good article/viewpoint (btw,I have over 20 years in IT and have worked with more computing platforms than other people can identify).

And for those that are not mentally challenged...
Purgamentum init, exit purgamentum.

and

Sona si latine loqueris!

Ray | Apr 19, 2008 | 2:36PM

To quote a plaque that my daughter gave me when I worked for a consulting firm:


"Consulting
If your not part of the solution, there a lot of money to be made prolonging the problem."

Plaque from http://www.despair.com

JimR | Apr 19, 2008 | 3:18PM

Some IT Guy writes:

You clearly do not understand what SOA is.

More unintended humor.

One of my interview questions for QA/Test is "What's the difference between validation and verification?" The correct answer "What are you talking about?!", which demonstrates that they've actually done QA/Test, and not just read some book.

One of my interview questions for a web dev is "What is MVC?" The correct answer is "MVC sucks!", which demonstrates that they've actually done some web dev, and not just read some book.

Your enthusiasm for SOA reminds me that I have yet to phrase a trick question for SOA. Thanks. (The correct answer, of course, will be "SOA sucks!")


Cheers, Jason

zappini | Apr 19, 2008 | 5:56PM

There are good IT consultants and there are bad IT consultants just as there are good IT "pundits" and there are bad IT "pundits". Some IT pundits make lofty sounding (but usually wrong) predictions and often write hyperbole filled articles, others use their actual experience in the real world to publish honest and useful essays about the state of the industry. I've been an "IT consultant" for almost 20 years now, and I can tell you that there are also 2 kinds of IT customers, smart ones who want a *working* solution done properly (surprise, that takes both time and money!), and stupid ones who read articles like this and think solving complex and unique business problems should take a couple of weeks and require no input or feedback from them.

James | Apr 19, 2008 | 7:51PM

I think Mr Cringely needs to explain the 10 lies as to why they are indeed lies!

Thurstan Johnston | Apr 19, 2008 | 11:34PM

10) "If you install Tivoli it will solve all your support problems."

I have been doing Tivoli consulting for about 15 years and have never met a Tivoli worth his/her soul who would say #10.

John

John Willis | Apr 20, 2008 | 8:57AM

>>I have been doing Tivoli consulting for about 15 years and have never met a Tivoli worth his/her soul who would say #10.

Just replace the word 'Tivoli' with 'Lotus Notes' and you'll get that Deja Vu feeling.

I remember lots of people telling me I really should get into Lotus Notes because the money was so good. I thought Lotus Notes people must be very special indeed.

Then I went in to do some work at a big global finance corp and there were lots and lots of Lotus Notes 'consultants' sitting round doing very little. And when I asked them some fairly basic questions, they seemed surprisingly clueless - for 'special consultants' I mean...

I think it's called 'jumping on the bandwagon, then when the wheels fall off, jump onto the next one'

Joe Jann | Apr 20, 2008 | 9:20AM

Would you be willing to elaborate on #5?

John | Apr 20, 2008 | 1:39PM


Recommended Book ...
(I am not the author, I promise)

Rip-off!: The Scandalous Inside Story of the Management Consulting Money Machine
http://www.amazon.co.uk/Rip-off-Scandalous-Management-Consulting-Machine/dp/1872188060

or directly from his site:

http://www.consulting-moneymachine.com/ripoff.html

Joe H. | Apr 20, 2008 | 5:21PM

The point you make about Type Bs is very important. I remember working with Accenture's SITE group (their IT Strategy group.) Nearly every "study" resulted in the same recommendation -- outsource big time [to Accenture.] Few people in our group felt proud of their studies, because the results of the studies were known beforehand - SELL.

Rez | Apr 20, 2008 | 7:46PM

So, the moral of the story - anything with the word 'FRANCE' (or derivates) in it is bad. But... I thought this was common knowledge and everyone knew it already...?

The 11th lie: Yes I know I am French/my company is French/my name has some French in it, but I will still deliver this project 100% up to your expectations sir/madam.

Nick T | Apr 21, 2008 | 3:30AM

If you don't know where you're going, don't be surprised if you end up somewhere nasty. Just look at Columbus!

Requirements definition is a considerable skill that seems to have been lost. The best consultants are those with considerable experience who can look at a company and know what is required even before the first serious interviews take place. Often they are industry experts who only have to look for the nuances that differentiate a company from its peers.

Unfortunately most of these consultants are on the point of retiring!

Charles | Apr 21, 2008 | 3:49AM

If you don't know where you're going, don't be surprised if you end up somewhere nasty. Just look at Columbus!

Requirements definition is a considerable skill that seems to have been lost. The best consultants are those with considerable experience who can look at a company and know what is required even before the first serious interviews take place. Often they are industry experts who only have to look for the nuances that differentiate a company from its peers.

Unfortunately most of the experts in requirements definition are on the point of retiring.

Chaswin | Apr 21, 2008 | 3:55AM

If you don't know where you're going, don't be surprised if you end up somewhere nasty. Just look at Columbus!

Requirements definition is a considerable skill that seems to have been lost. The best consultants are those with considerable experience who can look at a company and know what is required even before the first serious interviews take place. Often they are industry experts who only have to look for the nuances that differentiate a company from its peers.

Unfortunately most of the experts in requirements definition are on the point of retiring.

Chaswin | Apr 21, 2008 | 4:10AM

As a consultant I can tell you that it's soul destroying being in a large organisation that focuses on delivering mediocre services at minimum cost instead of the high performance spiel you see on the marketing prospectus. Before I became a consultant I used to hire independent consultants through Consulting Crossing (link above for ease of use) and found the quality of candidate was pretty high.

zensunni | Apr 21, 2008 | 8:07AM

As a consultant I can tell you that it's soul destroying being in a large organisation that focuses on delivering mediocre services at minimum cost instead of the high performance spiel you see on the marketing prospectus. Before I became a consultant I used to hire independent consultants through Consulting Crossing (link above for ease of use) and found the quality of candidate was pretty high.

zensunni | Apr 21, 2008 | 8:10AM

I'm seeing reactions to the 1 GB MS Access database that are the hallmark of bad IT management. When you run across this type of system, instead of beating your chest and giving the IT alpha (fe)male yell, recognize that 50 people wouldn't be using this thing if it didn't address real requirements. Try thanking the power user who put this together for the good effort, and then talk about migrating it to a platform that will scale, can be backed up regularly, and may allow them to do even more. If you make friends with the owners, and they get that you recognize that the thing has value, they may even listen when you suggest ways that the schema could be improved, or when you suggest a new client tool. Not all information management knowledge lives in the IT profession.

Bob Duniway | Apr 21, 2008 | 9:00AM

I boil it down even simpler... there are only 2 types of consultants. The first type is someone who has a great deal of specific skill that is desirable to a number of businesses, and who can demand a premium rate beyond the going "full-time-employee rate" for that level of skill, and is damn happy about it. These folks trade the perceived job security (HAH!) of a full-time employment for managing their own future, with an attitude of "I'll let my skills speak for themselves" and don't mind a few months "on-the-beach" every once in a while. These consultants Come in, deliver the goods, and look forward to that month in Belize before starting their next job.

The second type is the consultant who has tried and tried to keep that full-time employment status, but really has very little to offer and usually gets canned straight out for NOT delivering the goods, or is the "most dispensible" when cutback time comes. After getting tired of trying to explain why no job lasted more than 18 months on their resume' they realize it can all be explained away if they become and independent consultant, and adopt a revisionist view of their employment history. These consultants come in and try to blend into the corporate wallpaper, and hope no one actually checks up on the project plan. Of course, if anyone ever DOES check, it is usually the end of that assignment, since nothing has gotten done ecpect a lot of cashflow from customer to consultant.

I have had the pleasure of working with a very few of the first type (Bill McCune, where are you?), and firing quite a few of the second.


BillP | Apr 21, 2008 | 9:46AM

I boil it down even simpler... there are only 2 types of consultants. The first type is someone who has a great deal of specific skill that is desirable to a number of businesses, and who can demand a premium rate beyond the going "full-time-employee rate" for that level of skill, and is damn happy about it. These folks trade the perceived job security (HAH!) of a full-time employment for managing their own future, with an attitude of "I'll let my skills speak for themselves" and don't mind a few months "on-the-beach" every once in a while. These consultants Come in, deliver the goods, and look forward to that month in Belize before starting their next job.

The second type is the consultant who has tried and tried to keep that full-time employment status, but really has very little to offer and usually gets canned straight out for NOT delivering the goods, or is the "most dispensible" when cutback time comes. After getting tired of trying to explain why no job lasted more than 18 months on their resume' they realize it can all be explained away if they become and independent consultant, and adopt a revisionist view of their employment history. These consultants come in and try to blend into the corporate wallpaper, and hope no one actually checks up on the project plan. Of course, if anyone ever DOES check, it is usually the end of that assignment, since nothing has gotten done ecpect a lot of cashflow from customer to consultant.

I have had the pleasure of working with a very few of the first type (Bill McCune, where are you?), and firing quite a few of the second.


BillP | Apr 21, 2008 | 9:49AM

Any else find it funny at how LONG the posts are by the consultants? How typical. One would think they get paid by the word. Long winded and lacking in useful content.

Monkey | Apr 21, 2008 | 10:31AM

My experience with consultants and consulting for over 30 years can be summed up in one short statement.

There are two types of programmers, inhouse programmers and outhouse programmers.

Maud Dib | Apr 21, 2008 | 11:16AM

Sorry for the multiple posts. The captcha was giving me problems.
Zach | Apr 19, 2008 | 12:59AM


Does anyone else think its ironic that a successful consultant has trouble with a simple captcha?? Yet some company is no doubt trusting him with a multi-million dollar project. I almost feel sorry for that company. Nah...I am sure they are getting what they deserve.

Steve Dean | Apr 21, 2008 | 12:13PM

“No prophet is welcomed in his own native land.” I think this applies nicely and provides meaning to the definition "Best definition of an expert; anybody from over 50 miles away."

The best companies are the ones that listen to their customers and listen to their employees. The one's that don't depend on others to give them ideas on what to do. An outside perspective is often helpful, but what you can get internally could be worth more.

I guess the more clueless one's management becomes, the more they are dependent on consultants...and more at risk the company becomes if the advice is bad.

Christine Comaford is alive and well. I just Google'd her and found her at http://www.mightyventures.com/. Very interesting, she's trying to help people become internal Entrepreneur (Intrepreneur). Another way to look at it "an internal business transformation" person. Hmmm!!!

John | Apr 21, 2008 | 12:18PM

5. Don't fix price. Combined with #2, this almost guarantees a crap outcome. If you fix price, you're just going to get change ordered into oblivion.


Someone Who Does This | Apr 19, 2008 | 9:11AM




Your auto mechanic must love to see you pull into his garage!!!!

BillaBong | Apr 21, 2008 | 12:25PM

1) "This can only be accomplished through a large custom development project."

If one took the time to look, they'd find some amazing applications that have been on the market for years. The problem is they may not run on the latest, hot hardware that is being touted in the press. It may not have a slick user interface. It may still be text based. When you start a project with a bias on how it should be done, you could be ruling out your best choices.

2) "Of course your data is safe."

This should be obvious. If I had a dollar for every time I found unsafe data, I'd be retired early and living somewhere really nice.

3) "We'll need a day or two for optimization and debugging."

Conventional wisdom is the debugging process will take over 50% of the time in a project. Despite all the new ways to create applications, it still takes time debugging them. This is often the first reason projects go 100% over budget.

4) "Yes, we've done this before. There are several companies using this product (or technology). They really like it."

Several times in my 20 year career I've helped a customer rollout a project they purchased from a consulting service, only to find out whoever has never really done the project before. They start with a good idea and sell it to someone. If they can sell it once, they will then try to sell it to others before the first sale has been delivered.

5) "Server consolidation and virtualization will save you money."

6) "Storage consolidation and virtualization will save you money."

This deserves come comment. Yes consolidation and virtualization can save you money -- if done right and for the right reasons. I've seen too many experts go in and sell consolidation and virtualization as the solution to any problem. It is not.

The hardware needed for consolidation and vitualization often costs more than what you have now. Think about that. The real problem is not the hardware, but the lack of management of what you have and the lack of standardization. The problem was from not doing things right in the first place. Consolidation and virtualization could be only treating the symptoms of a deeper problem. Fix the problem first. Don't be surprised if the project does not save you any money. There will be benefits...!

7) "The upgrade (or change) will be seamless and will not affect production."

8) "The upgrade (or change) will be transparent to users."

9) "Yes, we tested this thoroughly before installing it."

I believe in the old Missouri slogan "show me." Insist on seeing the application being used by someone. Insist on seeing it run in the lab. This should be a project milestone. Insist on seeing a plan to load test and functionally test the application. Insist on seeing the load and functional tests!!! This should be in the project plan too.

10) "If you install Tivoli it will solve all your support problems."

You can replace the word Tivoli with almost any other product -- and the result is the same. A very good rule for IT projects is to set some rules and expectations on your recommendations. They should NOT contain an named vendors or products. What is YOUR business problem that is to be fixed? How will the solution (not with what..) help? What is the financial benefit or opportunity to your company? This is important as the next step is to do an ROI analysis and make sure the cost of the investment is consistent with its value.

Cardinal Fan | Apr 21, 2008 | 1:03PM

The problem with consultancy is the bottom line. Money controls the entire relationship, and with means for the hiring company to produce incentive, it becomes a war of attrition until something, or more often nothing, gets done.

I hated being on the consultancy side of things, as there was very little I could do to make my position defensible. For at what point can one objectively decide that the little fixes (at smaller billable increments) can't fix the problem and the large guaranteed fix (a static cost, with long hours associated) is the only solution?

califguy4christ | Apr 21, 2008 | 5:25PM

I usually make my money from cleaning up after Toilette and Douche, IBM GBS, and the rest of them.

They usually leave a snake nest of bad scratch product installs, no configuration management or software engineering processes, no testing and had exclusive staffing contracts they filled with eater-breathers.

Then they get bounced and if the company is still in
business they hire guys like me who actually get stuff done.

Con Sul Tant | Apr 21, 2008 | 10:53PM

I wouldn't necessarily say that most consultants aren't very good as your first paragraph states. I would state that most consultants are not properly placed by their recruiters.

The consultant field is cut throat. The firms work very hard to secure a company and will place any warm body into a position so that they do not lose out to another consulting firm. This leads to dishonest recruiting practices by the consulting firms, not only for the company that is hiring but also for the individual person who the recruiter suckers into the position. This can lead to a bad reputation for the employee who didn't realize what he was getting into.

S Scott | Apr 21, 2008 | 11:29PM

Modern companies use consultants the same way the Roman military used foreign mercenaries.

Clancy | Apr 22, 2008 | 3:48AM

it's funny how Bob finds a way to write "IBM" in all and every article.

noonewhocares | Apr 22, 2008 | 8:48AM

>> Your auto mechanic must love to see you pull into his garage!!!!
>> BillaBong External Link | Apr 21, 2008 | 12:25PM

For roughly one picosecond I thought you made a great point--defining and executing an enterprise technology initiative and getting one's car repaired are very nearly the exact same thing!!!!

Wait a picosecond...

Someone Who Does This | Apr 22, 2008 | 10:09AM

“As Scott Adams pointed out in The Dilbert Principle: This is the first generation in which the managers truly do not know what the employees do for a living. And that's why we see so many people who are so busy thinking outside the box that they don't even know where the box is or what it has in it.”



That’s so acute that it deserves it be quoted again (many times). In my experience, the managers that are take-charge, and therefore have the most power, are ones with their own agenda – not necessarily a selfish agenda per se, as in, “What can I do to make me look good?”, but just an agenda that they formed in their own minds and are going to follow through on, come hell, high water, or emotional fallout on the part of others. They’re so full of their own corporate buzzword-powered BS that no one can stop them. As far as I’m concerned, they can take their “forward thinking” “synergy” and stick it where the sun don’t shine. But I’ll be darned if the board doesn’t eat this stuff up, and they’re the only ones who can stop a highly-placed decision maker.



You can tell I’m speaking out of personal frustration here. Ever since a new director started at my current job, there’s been an endess series of issues she’s created by saying, “Let’s cut this,” because she wasn’t willing to stop and see why that thing was valuable (she wants to cut our one inhouse IT person because she doesn’t see how useful she is… oh God no). But she talks a better game than anyone I’ve ever met, so she became bosom buddies with the board inside of a month, and now they wouldn’t listen to us even if everyone in the agency went crying to the board about her bad management, which we already basically did, and got shot down. Sorry, run-on sentence.



“It is scary to think where this company will be in 5 years, but like MOST companies: as long as folks are getting paid, and the work is getting done (barely), nobody cares. Anymore.”



For some reason, this seems to be true, sad as it is. I think it’s mainly the employees’ fault for being lazy, more than the managers for keeping them on, because after all, how often can you afford to fire people without it making you look bad or without it hurting the company? It’s hard to find good help these days. Municipal workplaces in particular are an absolute joke in terms of inertia and laziness, a joke that’s gone so far it’s not funny anymore. This snowballs into a perfect hell when consultants are brought in.



“It's really amazing how management will listen to consultants but not their own people. Whatever it is that makes them do that, someone should bottle it and make a fortune. :)”



Amen to that.



Now let’s move beyond blaming consultants to move on to three other groups who are all wrapped up in this Gordian knot of high-sounding ideas that lead to poorly-implemented solutions that confuse the end users.



1. The first group is management. Often a manager wants to look good by cutting costs so they go with the lowest bid. This is root of much evil. Also, the consultant can’t be contradicted or properly led by managers who don’t know tech, so it’s the drunk leading the blind sometimes. (Seriously, our consultant was fairly drunk most of the time she was here.) The org. may or may not have nerds on staff who could call out a consultant on something, but they are never asked. It just doesn’t happen.



2. Group two are the developers. Yes, programmers, software engineers, whatever you call yourselves, it’s often your poorly-designed and barely-tested interfaces that cause the most problems down the line when employees are stuck in training hell. I don’t know if it’s your fault or your managers', but day-umn, are your programs unintuitive sometimes. It’s clearly because you don’t use them yourself, not on a daily basis as part of your job like us poor white-collar schmucks in Finance, but is that any excuse? Nobody’s teaching interface design to software engineers very well, I can tell that. Here’s a hint: Read the Apple Human Interface Guidelines. It’s what makes Apple’s interfaces great, in a nutshell, and it’s been published by Apple for years for anyone who wants to read it. So, uh, how many programmers have actually read it?



There’s also an onus on the managers here, to make sure that their software engineers are writing something that’s useable, but I think in this day and age programmers should be designing their own GUIs, rather than breaking that job out to someone else, and it should be required that they do it well. Programming is easy; good interface design, not so much – so if you’re so smart, you shouldn't be content with the program "working"; you should be making simple, user-friendly programs even for abstract purposes like strategic planning and financial work. Trust me, it’s doable.



3. Group three are the companies selling programs by module who use their strategy to bilk customers of money. “What, you want to move a line on that form down half an inch? That’s gonna take the $800 Forms Designer module.” They’re not selling functionality such as A/R, Payroll, etc. by module, they’re selling patches to uncripple the software.



P.S.: Hopefully no consultants are getting paid based on how many comments are left on this blog, because the number of actual posts is greatly exaggerated; I think we all know why by now. Here’s hoping I don’t do the same thing when I hit Submit.


P.P.S.: As further proof that this comment system blows, the words "br and p tags are not necessary for line breaks" has a "not" in it that shouldn't be there, based on what I'm seeing in the comment preview area. Yeah, kinda changes the meaning, doesn't it?

The Rambler | Apr 22, 2008 | 12:10PM

Okay, very funny. The comment preview area is pretty useless since it doesn't reflect carriage returns when the actual post does. Now I have three linebreaks where there should be one. At least the instructions are accurate (the "not" is correct). Unlike a bad consultant, I can admit to making a mistake.

Also, subsequent posters, if you get an error when submitting your comment, the post might still have gone through, so refresh the View All Comments page to make sure you're not there within a minute before Submitting again.

The Rambler returns | Apr 22, 2008 | 12:16PM

The error that it gives you while letting your comment through is a Proxy Error, to be more specific. There's another error you may get that *will* block your post.

Also, give it more like 2-3 minutes to show up.

The Rambler part troix | Apr 22, 2008 | 12:22PM

Hi --
Performance bonuses for management is the root of much evil. Why can't they be expected to just do a good job like anybody else is expected to do?

The only time performance bonuses for management pay off is when they have to ax a whole bunch of employees/costs. Unfortunately, the "merit pay" comes first, and the only think that they can think of is to ax a whole bunch of people and/or costs.

Management isn't really that difficult -- learning facts, understanding circumstances, and reaching conclusions. Basic logic, though experience helps.

It's the mere "deciders" who cause all the problems, and those are too often the people who get hired with performance bonuses.

Batman's Byte | Apr 22, 2008 | 12:51PM

Hi --
Performance bonuses for management is the root of much evil. Why can't they be expected to just do a good job like anybody else is expected to do?

The only time performance bonuses for management pay off is when they have to ax a whole bunch of employees/costs. Unfortunately, the "merit pay" comes first, and the only think that they can think of is to ax a whole bunch of people and/or costs.

Management isn't really that difficult -- learning facts, understanding circumstances, and reaching conclusions. Basic logic, though experience helps.

It's the mere "deciders" who cause all the problems, and those are too often the people who get hired with performance bonuses.

Batman's Byte | Apr 22, 2008 | 12:53PM

It's a simple point but I think you failed to address the often realized advantages of hiring IT Consultants over doing things internally.

1) Many IT projects fail, whether they are managed by external consultants or internally.

2) Many companies simply don't have the capability to implement big technologies in-house (or they lack the abilities in a specific area). Which makes more sense - trying to implement a huge SAP project with no experience, or hiring a company like SAP or IBM to implement it for you?

If a project fails where you hired permanent staff members to implement it, what do you do with those staff members after it's long gone?

Drew | Apr 22, 2008 | 7:24PM

I was an IT consumtant for seven years before finally getting out. I agree with everything you said, and then some.

whiskey breath | Apr 22, 2008 | 9:34PM

Actually, I'd take exception to #4. With proper proof (and reference checking), my experience has been that this is the only real predictor of project success or failure. Never mind that it's a complex project, very large, or has intractable stakeholders. Having done something over and over again is the main value that a consultant has.

Michael Tutty | Apr 23, 2008 | 8:57AM

Working in IT is like being a carpenter. Once the project is done, you have to move on, or become an in house carpenter.

Project management is an aptitude as much as a skill, just like selling or coding. And just like other aptitude's if you've got it you know it and if you don't then you can't wrap your arms or you mind around it.

But here's a few things: You don't need uber project software to plan a project. All you need is a spread sheet and on that spread sheet all you need is a to do list, with dates and contingencies. If this doesn't work, the project might be getting too big.

The way you manage it is this: You build a team, preferably with diverse talent. Preferably from diverse groups, including users, especially for the requirements phase - but all the way through testing - they help solve a lot of communications problems with management when things don't go as planned.

You make a list of what you think needs to be done. You bring in the team, throw the list up on the white board and ask them what they think is missing and what can be taken out, what needs to be moved. Then you ask who will do what. People will naturally gravitate towards their areas of aptitude, but you have to be careful of the guy that wants to try something entirely new.

Then you ask them how long it will take. You need to add about 45% time on to a technical persons estimate: they imagine in their mind everything they have to do but never anticipate the snags that emerge. If the time estimate is too long, tell them what the time constraints are and ask them if they can meet them. They will tell you they can meet them. If they can't then it really is impossible and you might as well tell management up front.

It's important that the people doing the work have as much say as possible in who will do what and how much time it will take. This has a profound impact on moral and effort. People will work like the dickens to meet their own deadlines (by the way, you don't have to tell the 'doer' that you added 45% to the time horizon of his specific effort).

Under these circumstances people will work their heads off to meet the challenge and not really complain. You don't even have to ask them work late or harder or whatever. Most of the time they will do it on their own.

Finally you have to CREATE an environment of open communications. You have to appear to be approachable. One thing to do, is for you, as project manager to get caught by the rest of the team making a mistake, and let them see you go about fixing the mistake. This makes making mistakes OK, reducing work performance anxiety. People don't worry about making a mistake, they just do their job confidently and when they do make one, they take your lead and just go about fixing it.

Being approachable is very important. You want team mates telling you about a problem closer to its first instance then it's last. If you're approachable, they tell you as soon as they find out about it.

You don't have to put pressure on team mates to do things directly. Really that's the last thing you do, right before the project fails in which case, it's too late.

There are three stages to pressure application: There's the original pressure that they put on themselves the minute they gave you their time estimate; theres the second pressure, the accountability they have to the rest of the team, and their's the pressure of accountability to higher ups. In most instances you have to sheild the team mates from all presure but the pressure they put upon themselves. But if things lag, and as they lag you expose them to pressure on things at higher and higher levels of accountability.

To put pressure on people you make sure they show up at meetings where they are given exposure to broader levels of accountability: first to the team, but then to outside and higher managment. The point of this is to educate them of the importance of working through the problems and the reletive importance of their work and the point that most people are aware that their work is increasingly becoming a constraint.

This is somewhat cruel, but it saves you from having to provide direct pressure which is counter productive on several levels. Direct pressure breaks the back of the worker and his moral and possibly the teams. Also direct pressure creates a wedge between you and the teammate - its important that project managers and team members maintain their camaraderie.

In regard to projects, they most important phase is the requirements definition phase. This means intense interaction with users. Work and data flows should be charted using flow charts, the best being the Ganes and Sarson (30 years old). I once worked on a large complex material management system with a major manufacturer of diesel engines. The requirments gathering took 6 months. The solution definition took 4 months. The coding took 3 months, was tightly designed for easy maintenance and worked perfectly first time, upon installation.

This is how to do it. The problem is not identifying people who are naturally good at managing projects. People get put in these positions for all the wrong reasons. Generally it has to be a person with both good analytical and communication skills.

The worst IT comes from accounting firm related consultants. They sell projects with high powered partners. Once the contract is signed, the partner is on a plane to some other sell, and school bus pulls up and a bunch of people jump off who are smart with technology but no nothing about the requirements. They spend two thirds of the project deciding who will be the chiefs and who will be the Indians (often this culture invades the host company killing good will between long time coworkers), and then go into over time work mode to scramble to get the project done. The end project is typically garbage. Back comes the partner who's real core skill is convincing management that the projects failure is nobody's fault but could not be anticipated (See Condi Rice appearing before the 9/11 commission). This is the real core competency of successful consulting firms and their ilk (see the Bush administration).

I could go on but this is more than enough for those struggling to find success.

Tim Kane | Apr 23, 2008 | 10:43AM

Thank you Tim. Nicely done.

Project management sometimes means different things to different people. I work for a company whose approach to project management is "documented denial-ability." My approach and philosophy is closer to yours.

I like project plans/task lists that fit on 4 or less pages. It is important to keep the project understandable. In a past life as a design engineer, we put our project plans on D-sized (22x36 inch) drawings and we had a cheap way to print them (blue print). This was a very easy way to chart a project. It was easy to read. With the advent of PC's, 8.5x11 inch printers, and Microsoft Project we now get 100 page project plans that have to be assembled. We've taken a giant step backwards in our ability to communicate a project on paper. If 8.5x11 is our only form of printout, then we have to use it in the way it works best. I print a list of tasks, assignments, dates, and meaningful descriptions. I keep the total number of pages to something very manageable and convenient to use.

To me project management is a communication and teamwork process. The objective is to have an efficient team who can focus on their assignments, and keep management informed on the status. Teams should be empowered to make decisions, brainstorm, etc. If they need to buy some stuff to test or prototype things, I let them.

I also believe in management by walking around. I encourage hallway conversations, noting ideas on napkins at the lunch table, ...

Email, when used right is a wonderful project facilitator. On Monday morning I send out a "marching orders" note that lists the tasks that are due that week, or in the very near future. I do not attach a file, I simply list things in a list in the body of the email in a short, concise, and convenient form. When I see my team printing off this email and posting it over their desks, I know it is something that is helping them. Observing one's team is invaluable! As key decisions or milestones are met, I send out an email documenting the accomplishment. I check the plan to see for others that are dependent on the given task and I tell them (usually in my walking around) that the task is ready for them.

I don't like many, long, boring meetings. I've run projects that have had exactly two formal meetings. In the kickoff meeting we assembled the plan, assigned tasks, and got everyone going. In the final meeting, we had our celebration party. I believe the best projects are the ones where the meetings happen spontaneously, when needed.


MidwestGuy | Apr 23, 2008 | 1:54PM

After more than twenty years, I feel there is a direct correlation between the rate clients are willing to pay, and the quality of the consultant.

Michael Ervick | Apr 23, 2008 | 4:02PM

After more than twenty years, I feel there is a direct correlation between the rate clients are willing to pay, and the quality of the consultant.

Michael Ervick | Apr 23, 2008 | 4:03PM

I shouldn't comment because I fear I've had so much more experience than either Bob, Tim Kane or Midwest Guy. I take issue with the following:


1. Bob's "...key to my simplified concept of IT consulting is adapting a limited number of very robust and proven products and to do it all in a reasonable amount of time".


2. The simple spreadsheet with a to-do list including dates and contingencies....


3. liking "....project plans/task lists that fit on 4 or less pages."


Please! These projects don't need a team of talented people with diverse expertise. These "projects" shouldn't be called "projects" because they are too trivial to discuss. If you already have "trusted and proven" products that can solve the problem at hand, you don't have a problem to begin with. You're selling your approach to people who are simply too ignorant of IT and you're probably applying very outdated techniques that will leave the company behind its competition and eventually out of business.

John Kennedy said we choose to go to the moon and other things...because they are difficult.


Don't ever stop searching for the "Holy Grail"! I have no doubt that, if you can sell your approach, you will make money by working on simple minded problems. If that's your thing, so be it. I wouldn't call it success. And I wouldn't sleep well at night.

Jamey43 | Apr 23, 2008 | 4:46PM

I am a 'consultant' and I agree entirely (mostly because the big consulting firms I've worked for in the past are precisely those that this piece's commentary is based upon). There is a type D though: a consultant who, having left their previous employer(s), now makes their living clearing up the mess left behind by those very same organizations. As Mr Ervick says though, you get what you pay for: The talent knows what they're worth and aren't afraid to either charge it, or no-bid when a spendthrift client is sniffing around.

Alex | Apr 23, 2008 | 5:01PM

"penalty clause"

I think thats a VERY important part that too many managers overlook when hiring consultants.

cris | Apr 24, 2008 | 5:48AM

To: the Bob Sux guy above --- You should consider getting a life. I read Bob, I like Bob....Bob is a friend of mine and Yes ...You are no Bob X Crinchly.

Fred X | Apr 24, 2008 | 6:52AM

You get what you pay for.
I have been one of the highest paid consultants in the US, now working on my own software projects.
I worked for Amex, Philip Morris, GF, JP Morgan and some smaller clients. At Morgan they kept me for 7 years hourly.

There is another point on penalty clauses.
Often the consultant is forced to play the corporate game along with some agenda that delays, underbudgets, overspend, and or give unrealistic time frames for completion.

Once I was forced to expend 0ver 40k in resources to get a 500 dollar piece of software, that was the only solution to a given project.

So who overspent? Who layed the egg.
I agree most consultants are incompetent, but a good one can save your career and your Company.

Respectfully
Ernie V

Ernie | Apr 24, 2008 | 7:49PM

Wow!!

Who knew there was such a way to see if you were the one of the highest paid consultants. I suppose that if you work at "Amex, Philip Morris, GF, JP Morgan and some smaller clients" and if Morgan keeps you on billing for 7 years that would qulaify someone to that status. Are you sure it wasn't JT Marlin?

Your humbleness is breathtaking, especially since this article really does not discuss payment rather than performance.

Jason | Apr 25, 2008 | 10:40AM

Who knew there was such a way to see if you were the one of the highest paid consultants. I suppose that if you work at "Amex, Philip Morris, GF, JP Morgan and some smaller clients" and if Morgan keeps you on billing for 7 years that would qulaify someone to that status.


7 Years at JP Morgan says a lot about JP Morgan...not so much about hot-shot consultant guy.

Steve Dean | Apr 25, 2008 | 11:26AM

A consultant is not usually kept on an hourly retainer, but contracts for a project. Ernie sounds like an position padding IT employee similar to many folks I meet in banks which seem to have IT departments with more HR resources than the executive branch. Also if you are a true consultant then you will probably only be around to gather information and suggest options. I did find this article to be very well written and though provoking. I have seen a number of my customers get dupped by IT "Consulting Firms" that were more salespersons than consultants. You can usually tell by the suit and tie that you are talking to a salesperson and not anyone that knows anything about IT systems. Thanks for publishing this article on-line. I love PBS :)

Tom | Apr 25, 2008 | 1:05PM

You forgot "Sure it's vista compatible"

Michael Haggerty | Apr 29, 2008 | 12:04AM

If I may be more emphatic: Without good, solid requirements, built by a team of IT and Users working together, treated as a living understanding of the needs of the business, NO TECHNOLOGY can be successful.

To use an awkward analogy, requirements are the map of the territory, the technology is the vehicle that gets you across the territory. If you don't have a good map, you won't get where you want to go, whether you drive a jeep or a jet-fighter.

An hour spent on good requirements is worth almost 100 hours of arguing and finger-pointing. I know from hard experience.

Steve | Apr 29, 2008 | 11:21PM

An excellent article - my question is: why do we keep on choosing these large companies that rhyme with I-B-M and keep failing? We need executives to be a bit more willing to take a bit more risk at the expense of agility, to find out if the business/IT is really trying to bite more than they can chew earlier on. To do this, the business/IT needs to know what they want, and not expect the consultant to come in and strategise/tell them what they want... I have seen this happen time and time again - and that's where I say STOP! Have a think about what you're trying to achieve and then we can together define SUCCESS... I rather have an early failure to prove something cannot be done, than find out after spending a whole lot of money down the track.

Sergio Tarzia | Apr 30, 2008 | 3:25AM

An excellent article - my question is: why do we keep on choosing these large companies that rhyme with I-B-M and keep failing? We need executives to be a bit more willing to take a bit more risk at the expense of agility, to find out if the business/IT is really trying to bite more than they can chew earlier on. To do this, the business/IT needs to know what they want, and not expect the consultant to come in and strategise/tell them what they want... I have seen this happen time and time again - and that's where I say STOP! Have a think about what you're trying to achieve and then we can together define SUCCESS... I rather have an early failure to prove something cannot be done, than find out after spending a whole lot of money down the track.

Sergio Tarzia | Apr 30, 2008 | 3:28AM

An excellent article - my question is: why do we keep on choosing these large companies that rhyme with I-B-M and keep failing? We need executives to be a bit more willing to take a bit more risk at the expense of agility, to find out if the business/IT is really trying to bite more than they can chew earlier on. To do this, the business/IT needs to know what they want, and not expect the consultant to come in and strategise/tell them what they want... I have seen this happen time and time again - and that's where I say STOP! Have a think about what you're trying to achieve and then we can together define SUCCESS... I rather have an early failure to prove something cannot be done, than find out after spending a whole lot of money down the track.

Sergio Tarzia | Apr 30, 2008 | 3:30AM