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:

FAIL	SUCCEED
Lack of User Input (we take “User” to mean “Stakeholder”, a more “modern term and important concept)	User (Stakeholder) Involvement
Incomplete Requirements & Specifications	Clear Statement of Requirements
Changing Requirements & Specifications
Lack of Executive Support	Executive Management Support
Lack of IT Management	Ownership
Technology Incompetence	Competent Staff
Lack of Resources	Hard-Working, Focused Staff
Technology Illiteracy
Unrealistic Expectations	Realistic Expectations
Unclear Objectives	Clear Vision & Objectives
Lack of Planning	Proper Planning
Unrealistic Time Frames
Didn’t need it (the project outcome) any longer	Smaller Project Milestones
New Technology
Other	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!).

FAIL	SUCCEED
Lack of User Input because:	User Involvement
Users aren’t given time to provide input because: No one asked for their time Inaccurate planning & estimation It isn’t worth their time It isn’t a priority for their manager Too much time is (has been) wasted in the process	Users are given time
Users don’t want to cooperate or give bad information because: They are afraid for jobs and stability They are loyal to friends and secrets They are obligated by Union loyalties They don’t trust the process They don’t trust the organization Their jobs ARE ACTUALLY at risk	Users want to cooperate and give their best information
There are no Users because: The project involves a new invention The outcome is invisible to users The project is new to the organization The users have all quit The users were all hit by a truck	Project gets cancelled or it is handled as a “research and development” project or an internal “systems” project or leadership is changed and the users rehired.
Users don’t do anything or can’t because: The current process is completely broken The current process exists to create jobs Users are not asked to do anything Users are punished for taking action	Hence the project, hopefully not in place of improved leadership.
User input is never sought because: There are no users (see above) No one knows or believes that it matters The users are too expert for the project team to understand	User input is always sought
Users cannot be observed because: Thinking is impossible to “observe” Work rules, law or social convention forbid observation User behavior changes under observation Cost of observation is high (deep sea divers) Users don’t do anything (see above)	Users know what they do or can be observed
Users don’t know what they do because: It is not easy to explain thinking in words – explaining how I wrote this is much harder than simply writing it It is not easy to explain actions in words (explain “hitting .330 in the Major Leagues, as opposed to the more general process of merely “hitting a baseball”). Users may have invented their own processes, without enough understanding to document (“it just works”) What users do is complex and cannot be explained to non-experts Users don’t repeat any process in their jobs Users don’t do anything (see above)	Users know what they do or can be observed

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.