IT BS Watch

We’ve heard about the wonders of teams to the point that our minds can barely hold another iota of information about how marvelous they are. With captivating analogies from sports to the humanities, pundits, authors and educators extol the virtues of teams to near-religious proportions.

While in many situations teams are all well and good, there are quite a few notable exceptions. Many have heard the story of Steve Jobs’ personal involvement in the design of the iPhone. Eschewing teams, committees, focus groups and “centers of excellence” (whatever that means), Jobs’ selfishly designed the phone he always wanted. What resulted was a purity of vision and tight integration that became an icon. Similarly, the granddaddy of today’s smart phone, the blocky Palm Pilot was initially a lumpy, hand-carved wood prototype that Palm founder Jeff Hawkins carried around in his pocket for weeks to determine if the size was what he wanted. One man, one vision, one pocket, one amazingly successful product.

In the management ranks, we often forget this lesson, outsourcing our key products to committees, teams, SMEs and other seas of ambiguity, half-hearted compromise and CYA-motivated mentalities. Whether it’s a presentation on strategy, a critical decision on the project portfolio, or a tough call on an HR matter, sometimes abandoning the morass of the team is the best way to go. After all, how often do we hear about Henry Ford’s great team, the committee that helped Dr. King pen his speeches, or Joan of Arc’s focus group.

There are two main problems with BI software.

First, too little thought is put into the post go-live analysis portion of implementing a BI package. All the effort is spent setting up software, gathering reams of data, and cooking up a few canned reports, and at the end of the day, when you’re sitting atop a mountain of data everyone looks around and says “now what?” More thought should be put into what the key drivers of that particular business are (there should be a handful, not a pile), and providing “real people” (i.e. not from IT) the tools and training to mine this pile of data as they see fit.

The second problem is with business reporting as a whole, and the reason why many BI implementations are billed as unsuccessful. By its very nature, BI looks at the past, and it is easy to look at your stack of fancy reports and believe it contains the tools you need to predict the future direction of the business. This is abjectly false, and the best example is the financial industry. Finance always has the highest IT spend in the industry, and a very high penetration of BI tools, yet nearly all the big financial organizations missed the recent financial crisis. You need strong management that realized BI provides clues to the future, but not the future itself. IT often is a partner in crime, overselling this aspect of BI.

Like all software, BI is a tool to be leveraged, it is not a magic potion that will predict the future, despite all the fancy dashboards, reams of data and fancy analytical terms.

Many failed ERP (or other package software implementations) fails due to some combination of these three factors:

1. Companies mistake a unique back-office process for a competitive advantage. Usually a process evolved organically over a long period of time, and after several years is left with an “evolutionary hangover” of inefficiencies and steps whose justification has long since been forgotten. Rather than spending months trying to cobble these processes into packaged software, focus your creative energies and innovative efforts on your products, services and R&D and settle for simplified, generic and ruthlessly efficient back office processes.
2. In a “design” phase, spend some time trying to simplify your organizational structure, and examine if you are making your business more complicated than it needs to be. Follow the rules above.
3. Build a cadre of “outside the project” advisors, either external or internal people not closely tied to the project, and in the case of outside resources, consultants who do not provide implementation services or have a financial interest that might bias them. Review the objectives of the project with them before you start, and let them serve as an unbiased sounding board should things go awry or should you need to make a critical scoping decision.

First, I would NOT skimp on performance evaluations. As a manager it may be personally hard to tell someone they are a low performer, but especially when there is little/no pay to go around, you need to honestly evaluate your top people, recognize your high performers, and provide a detailed career map for everyone that tells them how to advance. Rather than splitting what little monetary pot may be available among everyone, allocate it to your key players. This is not the time to attempt some schoolyard notion of fairness.

In terms of staff development, let employees explore new technologies, or build small prototypes then present their findings, essentially letting them do “independent research” in an area that interests them, that vaguely ties into the goals of the corporation. It’s free, would likely have been time lost to web browsing anyway, and improves morale, develops staff presentation skills and just might produce useful prototypes that can be leveraged into an enterprise project.

I recently wrote about this on my Tech Republic column which has some additional ideas: http://blogs.techrepublic.com.com/tech-manager/?p=1153

1. Certification Surfing. Many in IT use certification or “guru” organizations as a shortcut to hiring key project staff. While a PMP or other certification may be nice, the person sporting a raft of letters after their name may be an exceptionally poor project manager. If you have a critical project with significant money and time at stake, take the time to vet candidates for key positions in person. The cost and time required far outweigh even a few days lost to poor management once the project is in full swing.
2. Focusing on Deliverables. Many of the project management methodologies focus on the wrong thing, so-called “deliverables” that are generally supporting documentation or ancillary tasks that do not directly relate to the business objectives of the project. When deliverables become disconnected from business objectives, you can easily get into a situation where the project is 99% complete from a deliverables perspective, but 0% complete in actually meeting the core business goals of the project. Ensure that projects are measured and tracked on objectives that are “MAD:” Measurable, Actionable and Dollar-based. While a functional spec or technical document may move you towards a business objective, it should not be used in reporting the project’s completion until the underlying business goal (getting sign-off on a prototype, resolving a process question, hiring appropriate staff, etc.) is complete.
3. Postponing Decisions. While postponing decisions is often done in the name of “keeping our options open,” the longer you postpone a critical decision, the fewer options you actually end up with. To make a project effective, ensure that decisions are made in a timely manner, and that the actual decision making process is transparent and limited to key parties. While anyone can have an opinion, the actual decision should be made by a group that is specified in advance, otherwise you will spend weeks soliciting opinions and building consensus. With high-dollar burn rates, a good decision today is often cheaper and equally effective in the long run than a great decision a month from now.

Yesterday’s WSJ has a great article on the failure of process improvement projects based on a study that was performed at an aerospace company. They basically concluded that these projects go through an initial period of great success, and then gradually revert to the same (or worse) performance than at the beginning of the project.

The big take away from my perspective is twofold:

1. None of these “magic methodologies” will solve your problems in the long term if they are applied like pixie dust, then essentially left to wither. Just as major surgery might take a day or two, but require a year of physical therapy, your initial intervention, regardless of the methodology used, will likely need months or years of care and feeding for the changes to become permanent.
2. Related to the above, you simply cannot continue compensating and evaluating your people in the same manner after launching a process improvement project or they will return to their old way of working. If I provide no incentive to embrace process change (either monetary, job advancement, a reporting change, or more time dedicated to the project) then any changes will gradually regress.

You can find the full text of the article here: WSJ Where Process-Improvement Projects go Wrong