Managing the Process of Automation: Leveraging Capabilities Without Forfeiting Accountability

“It ain’t easy leading a software company these days.  Customers are sick of poor quality, inadequate security, old-fashioned business models, and pie-in-the-sky claims for trends like open source.  They just want software that works.  That was the message coming from customers, industry experts, and even some company executives at the Software 2005 conference last week in Santa Clara, California.

from “Execs Tell Software Makers: Some of You Are Doomed,” by David Kirkpatrick (May 6, 2005)

This was one of those articles that resonated with me from the moment I first read it in 2005, to where I sit even today.

While the “some of you are doomed” statement by senior executives from corporations such as BP, Kaiser Permanente, Lockheed Martin and Unilever inspired diverse coverage by countless writers, the central theme remained relatively consistent.  Specifically, and according to one account “business leaders are really steamed” that it takes an inordinate amount of time to “install and deploy software,” and even longer to derive any meaningful “value.”

From a personal perspective, I can certainly attest to this fact as my own experience with EDS saw considerable budget overruns and consistently inferior results.  This despite my considerable investment of time to attend multiple JAD sessions as they were called to outline the framework for the application they were hired to build.

In retrospect, it is clear that the EDS model was structured more around a disconnected utilization of bench time capabilities by diverse and at times competing teams of developers.  Think of it as having different parts of an automobile built by different car manufactures from different regions of the world.  Each wants to demonstrate that their way is the better way, and rather than collaborate toward a collective best result, they work in competitive silos never really checking to see if the individual components will actually fit together let alone work as a single, cohesive unit.

Even though the 2005 article appeared years after my misguided foray into the realms of enterprise application development, I did gain some sense of a “I am not as dumb as I thought I was” vindication, as I was according to Fortune, not alone in my experience.

As I read further, I also discovered that there had been a significant increase in the percentage of organizations that were opting to repatriate software development back in-house.  While I could not un-ring the past development nightmare bell, my first decision post EDS turned out to be a sound one in that I had chosen to keep future development under my own roof.  The end result of this strategy was a far more robust solution that was produced at a fraction of the cost and time, as compared to the sizable sum I had squandered on an application that never quite got there with EDS.

Now here is the key point . . . the only reason it succeeded was due in large part to tight controls and the experience of those involved in the development process.  To be succinct, we maintained both capability and accountability for the project from start to finish.

This leads to an obvious question, what if you do not have the internal capabilities to effectively manage the development process within your organization?  What are the options?  Enter offshore outsourcing.

Unfortunately, the offshore outsourcing of software development requirements can quickly become a fools gold promise that are more reflective of the “results” highlighted in the Fortune 2005 piece.  That is if you outsource accountability as well as capability.

What I am of course talking about is the importance of maintaining the same degree of responsibility for the project as if it were truly an in-house effort.  This includes the coordination of a collaborative process with different stakeholders involving the integration and tracking of requirement definitions, problem resolution and application testing.

Now many of the companies who outsource indicate they do so for a variety of reasons including the need to focus on their core competencies, or the absence of the necessary skill sets, as well as budgetary considerations.  While these provide a reasonable basis for making the decision to outsource, they are not a Carte Blanche excuse for surrendering accountability for the project’s success.

For this reason enterprise-requirements software providers like Blueprint can help companies maintain the delicate yet critical balance between outsourcing unique skill sets, without forfeiting the control that is necessary to ensure a cost effective, on-time end result.

According to Blueprint’s web site, they have “enabled global companies of all sizes and industries to eliminate risk and reduce cost through a focus on visual requirements definition and collaboration.”

I will be interviewing Blueprint’s Senior VP and CMO Matt Morgan on the August 20th PI Window on Business Show to learn more about “visual requirement definition” as well as the myriad of other resources that are now available to organizations who want to gain access to needed resources without losing control of the development process.

Use the On-Demand Player below to tune in to the live broadcast.

Vodpod videos no longer available.