A lot of attention has been given to the hijacked title of Business Analyst by the trade press recently. The title used to be used by the “Independent” analysis firms for people who were doing “research”. Some time later they started calling these people “Industry Analysts” leaving the other title open for thieving. Since the vast majority of MBA’s who get put in charge of IT departments do whatever these marketing…I mean analyst firms tell them to do, they started using the title for another batch of MBA’s brought into the corporate structure to oversee off-shored projects.

This title is usually broken up into junior and senior. The senior Business Analyst is fresh out of MBA school. They took their one day/week course using a worthless Microsoft product (insert your favorite Microsoft product name here) to point and click their way into creating a contact manager, got their certificate, and were now certified to head up IT departments and projects. Being able to use this title to bring in more MBA’s below them set a twinkle in the older MBA’s eyes. They live for the “minnie me” principal.

In theory, the Business Analyst is supposed to be what a Systems Analyst used to be years ago. Way back, before we had computers, there used to be people called “Efficiency Experts”. These people walked around factory floors, job sites, offices and every other place the company had operations. They took all kinds of notes, then disappeared into a room for days or weeks. When they emerged, they put together a document which showed how to improve business processes to either reduce waste, reduce injuries or cut costs. The “cut costs” part always appealed to the MBA’s. They just had to say it cut costs and toss out a big number. MBA’s would never read far enough into the document to see there was no supporting data.

Computers came onto the scene and the programmers were initially under the domain of the finance department. As we discussed earlier, the first systems written or purchased were for accounting. After accounting was quasi taken care of, the order processing systems started getting written. Every first cut at an order processing system did the same thing, replicate the paper forms. Later came picking tickets for those actually filling the orders, shipping tickets and invoicing. It all revolved around accounting.

Some efficiency experts embraced the technology. They started hanging out with the IT people long before it was cool to do so. The IT people passed along some basic IT books of the day and the efficiency experts read up on the topic. The efficiency experts started looking at the systems in place, walking around asking questions and taking notes. They disappeared into that same little room and came out with a document about how to improve one or more systems. The difference this time is that the IT people read the document all the way through.

By the time the 1980’s rolled around, the title of “Efficiency Expert” pretty much didn’t exist anymore. Those who embraced the new technology were called Systems Analysts. Those who didn’t usually ended up driving a cab or a truck. Education also started changing drastically for IT people. Books were written and classes taught on systems design. Every wanna be programmer was required to sit through at least one. (The classes don’t exist anymore and you will probably have to find the books in a used book store.)

More and more IT departments sprung up around the country at companies too small to have had an efficiency expert. A new crop of Systems Analysts had to be found. By default, it was the programmer who spent the most time walking around the various company processes learning how the company actually worked. They knew who to invite to meetings that would generate real answers rather than schedule additional meetings. They had come from programming stock, so they knew what was and wasn’t possible in the time frame available. It was a win-win situation as far as systems development was concerned. A lot of the people who were best at accomplishing a project weren’t so good at cultivating a team or handling interpersonal problems.

Networking invaded IT departments in force by the 1980’s. Management didn’t have a clue about it, but they were told they needed it and threw money the direction they were told to throw it. The systems analyst got saddled with this task. At first it was fun working with new technology, but once management learned it cost money every month they started wanting to “cut costs”. The Systems Analyst as we knew them disappeared by the mid to late 1980’s. The title still existed for a while, but then it morphed into various “network” or “communications” titles. Basically, they became saddled with the task of chopping telecommunications costs while keeping everything talking. Not a fun job at all.

Who designed the systems written from the 1990’s through today? The short answer is nobody. Worthless pick and point GUI tools washed into the market. Shiny new buzzwords were coined to say “hacking” in as sexy a manner as possible. Some of these buzzwords were “Rapid Applications Development”, “Extreme Programming” and “Iterative Design”. There were far too many count. Every new PC product or 4GL which came onto the market felt compelled to coin yet another phrase for hacking. The lone voice of sanity at the few “design” meetings which actually happened was the DBA. They couldn’t fix the system, but they could enforce good database design on a system which got rid of at least some hacking.

Some companies had a few people left in upper management who actually understood technology and saw this trend for the train wreck it is. They started bringing in consultants who had actually worked on systems design. The consultants were somewhat short legged when they hit the ground running due to the fact they didn’t know who in each department actually did the work. A corporate structure chart will tell you who is in charge of getting the work done in a given department, but it won’t tell you who actually understands how to do it. In order to design a really good system you have to talk to the people actually doing the work. Don’t expect their managers to have a clue.

Managers who actually understood how IT was supposed to work were quickly moved to other departments doing tasks they knew nothing about so they would flounder about like the rest of upper management. This paved the way for the invasion of more PC servers running Microsoft Windows and Linux with even more thrown together hacks. Sprinkle in the fad of “rightsizing” and you pretty much have the 1990’s. Systems analysts got shoved into networking or systems management and nobody actually designed applications.

Now we approach 2010 and “off-shoring” is all the rage just like “rightsizing” was in the 1990’s. The Y2K wall pointed out to the known universe that “rightsizing” was the most asinine concept published to date. It was put into place pretty much so upper management could commit rape-pillage-and-plunder in the form of artificially inflated stock options and bonuses. Waiting until 1998 to start trying to sweep up the problem nearly bankrupted quite a few companies.

Can you guess what wall is going to slam down on the “off-shoring” debacle? That’s right! A wall created by the MBA’s themselves, the mythical Business Analyst. These people need to be what the original Systems Analyst was and “off-shoring” ensures that you cannot create one. Even if you try to hang onto a token few actual citizens from your IT department, they are not going to do the design for people who cannot even speak their language. I don’t care what country you are in or what country you are “off-shoring” to, the situation is the same. Even if you get one to stay they will be far less effective without the comradery of a local IT department to bounce ideas off of or ask questions.

You might remember that I said most of the really great Systems Analysts weren’t so good at solving “people problems” on a team. They were phenomenal at design and accomplishing projects, but the interpersonal thing wasn’t usually their strong suit. Now, once they do the analysis, 100% of the job is managing the “off-shore” team. IT people aren’t flocking to this. They are taking jobs with their former companies competitors who haven’t ridden this train off the cliff.

Now, we have a shiny new class of MBA at the company, the Business Analyst. They don’t have the tiniest shred of knowledge about the history of IT. Ninety percent of a Systems Analyst job was knowing the history, both of the industry and of the company. Not the history published for investors, but the history of what used to get done at each location and why.

Please allow me to relay a story to you. It is a story which is being repeated all across the globe from what I can see. Let me also state that any resemblance to persons or projects which may have crossed my path in the past is strictly coincidental.

The company in this story decides to bring in an MBA with “the right credentials” (they graduated from the same college as one of the managers). This shiny new MBA has learned all of the MBA tricks of things to say when they are clueless to make it sound like those actually doing the work don’t have a clue. They also have taken that one day/week course and got the little piece of paper certifying them to manage an IT department.

It is decided that this new MBA should be groomed to one day take over the IT department. They decide to give him a department’s first “off-shoring” project. This project has been highly publicized for all of the costs that will be cut. It will be a real career builder! Upper management has already signed a contract with an “off-shoring” firm, so the body shop has been chosen for him.

The project is to replace a system used to track pricing from suppliers and provide pricing to various other parts of the company including actual customer retailers. This system has been in place so long it uses a hierarchical database as its core. Various other things were bolted onto it along the way. Some members of the department have batch jobs and scripts they run “out of their desk drawer” for job security.

All of the bad things like the desk drawer jobs are supposed to go away when this new system is in place. Since the “off-shore” team doesn’t have skill one if they can’t pick and point, a Web based Java interface is to be developed. The new system is to use a relational database from a big name vendor.

Many of you may remember in Book One where I mentioned “design sessions” where veins would pop out on foreheads and vile things would be said about ones relationship with close family members. While some people weren’t cut out for them or found them distasteful, there were a necessary part of proving an application design before writing one line of code. You don’t get that with “off-shoring”. Not one member of the “development team” had any more IT experience than our poor little MBA.

Lots of meetings were scheduled and notes were written. Our hapless little MBA was quite dutiful when it came to logging lots of hours and generating lots of paper. The MBA also paid way too much attention to one line uttered when they were given the project “should have no impact on systems this application was feeding”. All of those “desk drawer jobs” suddenly became “systems this application was feeding” once those who had them learned of this magic phrase.

Oh, don’t waste your laughter yet. The best is still to come.

Our little MBA dutifully transferred the structure of the hierarchical database to the relational database verbatim. Even used one of those nice drawing tools to make a picture representation of the database. He didn’t bother fixing the keys, or replicating data which was needed to access other databases and indexed files. All of the warts came forward. The DBA’s tried to politely get our little MBA to correct this design. He responded with all of the tricks and phrases they teach you in MBA school. The all time favorite was “You just don’t understand the data, it has to be that way”. The all time favorite come back was “I understand the difference between a relational and hierarchical database and if your tables match, I don’t have to understand the data. You’re screwed before you start.”

Some people should never be taught SQL. It sounds horrible to refuse knowledge to anyone that can pay for it or read, but once you encounter one of those people you won’t think the statement was horrible. Our little MBA is one of them. Somewhere in that day/week training class they taught our little MBA enough SQL to know select statements existed. That and one pick & point tool was all he knew about IT. The application needed to display on a single screen data which was contained in databases from more than one database vendor.

I told you not to waste all of your laughter.

People who came up through the ranks of IT think nothing of needing data from more than one vendor’s database. We do it all of the time. We choose a driver table or set of tables from the most restrictive and get a cursor. We feed the results of that cursor into a subroutine which uses it to drive queries against one or more of the other databases. This is not rocket science, it is what we do.

Our little MBA mandated that an unproven middleware product be installed which would let the “off-shore” team issue one SQL SELECT across all of the databases. Apparently the little MBA had clout, because it got installed over the protests of the DBAs. Laugh all you want. Not one person on the conference call with the “off-shore” team stood up and said “Listen idiot, we can do it without that.”

By now, you can all see that this train isn’t only off the track, it isn’t touching ground anywhere. I won’t bore you with the details of all the tragedies which followed. Suffice it to say the system was completed and installed. It did not meet one single requirement, but was papered over as an “off-shoring” success. The departments continued to use the old systems since absolutely nothing functioned. All of those who had job security with their “desk drawer jobs” still had it. When the system was used it had a tendency to publish the wrong prices to those who were most likely to buy costing the company untold financial loss.

This is not an isolated case.

Companies everywhere are trying to manufacture Business Analysts to specify things for the “off-shore” workers. Since management is in charge, they want MBA’s, not people who actually know what is going on. Train wrecks are happening everywhere and being redefined as successes when passed out for external consumption.

“Off-shoring” your IT work guaranties you will never manufacture an effective Business Analyst. If you managed to turn one of your IT staff into one before “off-shoring” everyone else’s jobs, you will never replace them. Effective Business Analysts evolve. They spend years walking around your company locations talking with people and finding out who does what. Yes, they work as a programmer while they are doing that, but they learn the entire business while plying their trade of developing software. The “off-shore” people will never do that. In a few short years your company will be jumping to a different country where IT talent can be bought for $1.00/day because the “independent” industry analysts told them to do it. None of the bodies you contract will have the ability to spend hours out of every day going out to the factory or other locations just talking with the people who actually generate your company’s revenue.

If your company has already “off-shored” more than 20% of its IT staff, it is already out of business, they just don’t know it yet. I’ve worked in IT lot of years. I have met a lot of IT people over those years. One in ten IT workers will tell you they have what it takes to be a Systems Analyst. They actually believe it. I have met at most four IT workers in my life time who actually were Systems Analyst material. Being able to see and solve the whole problem is a very rare skill.