Soft Skills Sustain Success

Like any other “business case”, this one starts with a business problem or opportunity. The problem is that a large percentage of business “change” projects (most involving IT) fail to meet their goals. In too many cases this failure is total.

Failure, including dismal failure, is NOT theoretical – examples abound. The IRS has spent 10 billion dollars twice on two projects over two decades without achieving their “business” goals and objectives. The Department of Homeland Security is scrambling to save some of the $110 million they spent on projects to track “Guest Visitors” – projects that resulted in unusable code and flawed requirements documentation.

Such problems are not limited to government ventures, nor are they ascribable to “bad ideas” or “less brilliant” practitioners. Blackberry was the dominant handheld smart phone for years, and is now struggling to remain relevant. Search engines come and go, and even Google feels the risks (patents expire, and winners are not always beloved, and lawsuits continue to settle behind the scenes).

Countless smaller, un-newsworthy projects fail every day, some to be abandoned and others to be repeated. Most common of all – many projects that are out of immediate public view “declare victory”. This happens in spite of the fact that everyone involved (especially the users of the “change”) knows the projects are challenged or even failures. The Space Shuttle program (not just the two failed flights) is one extremely public example (no comments please, unless you first look up the original stated goals and objectives of the Shuttle program).

OK, this is just a blog, so I am going to stray for a minute, for BOK sake. Some say that Google’s brilliance is not their patented search technology, but is actually a “business rules” based success (read the BOK technique of “business rules analysis”). Much of Google’s revenue is generated from a business policy of aggressively and consistently using other people’s intellectual property (search Ford, find Chrysler AdWords) combined with knowledge of the browsing public’s “private” behaviors and actions to generate revenue. The simplicity of their interface is quite brilliant, but exists only to hide the “back room”, where the deals get made.

Then we have the example of the iPad – an Apple product that people buy just to find out what it does! This is no small feat – “tablet” type computers have been tried repeatedly and have always failed in the past. Look at GE, which has a sustained success record that is the envy of many organizations and a history going all the way back to Thomas Edison. Consider the Post Office and the Social Security Administration and even your local Department of Motor Vehicles – these institutions have all improved operations and automation, even as other agencies have struggled. What about all the “un-newsworthy” projects that succeed (G.E.’s latest toaster is probably profitable, IIBA’s outsourced delivery of online CBAP tests has resulted in 400% growth in CBAP test takers, the U.S. Mint’s online coin sales and automated subscriptions seem to work for most people).

What is different? Is it just pure luck? If only luck is involved, we can quit right here. Assuming that there is more than luck involved, can we try to understand the difference?

Let’s try some Root Cause Analysis. According to an oft-cited 1995 Standish Group report (the “Chaos” report), projects that fail or succeed seem to fail or succeed for reasons like the following, organized according to how they seem to relate to each other:

 Let’s start with “Lack of User Input” vs. “User Involvement”. I will use a table structure in place of the “fishbone” diagram for ease of reading (and writing!).

Now, let’s keep it simple (frankly, I am out of time and space for this blog). Given that we know some success and failure factors, do we really need to keep digging into causes of causes and ultimate causes? If a logger were failing to cut logs, we would expect leadership (not the same as “the leader”) to intervene and help fix it. If a logger were failing to cut logs on Mars, we would expect leadership to intervene and put a stop to the wasted effort.

When we build lists like “Unclear Objectives”, but fail to clarify objectives, this can only be a failure of leadership, unless we enter a new society where “underlings” give themselves their own job, and raises too. To quote one of the participants in the Chaos study, a programmer who was interviewed as part of a focus group:

“Sometimes you have to make a decision you don’t like. Even against your own nature. You say well, it’s wrong, but you make that decision anyway. It’s like taking a hammer to your toe. It hurts.”

And another, an IT manager:

“Probably 90% of application project failure is due to politics!”

Apparently failure doesn’t hurt enough, because to challenge destructive forces one must risk displeasing one’s overseers, and that is far more painful. Only leadership, starting from above, can change this, and only when it values leadership over power.

Once again the BA profession must face it – while some problems cannot be solved with mere leadership (you can’t yet code up a physicist, or an artist, or a fair judge), the majority of problems can be traced to poor leadership, and not just from the bosses.

If you can face the challenge, leadership training, soft skills, communication, even sales – these investments will pay you the most. There is no lack of intelligence (the engineers knew the Space Shuttle was at huge risk), only a lack of influence by intelligence.

If we can stop just knowing what we know, and embrace the need to sell and teach and politic for what we know, we have the best chance to do good work and be recognized.

Keep up the good work, all you BA folk!

Don’t forget to leave your comments below.