Restore Your Balance and Reap Rewards

We have seen something growing over the past few years within IT organizations that is beginning to create a significant liability for the enterprise as a whole.

Much like a chronic but unknown condition — something along the lines of being diabetic but not knowing it or managing it for years — eventually the weakness is found, and generally when the demand for immediate action is at its height.

Getting on top of this issue and figuring out what resolution best suits your enterprise’s needs is thus an important issue, and one where the CIO needs to be supported in having whatever other changes are required made to facilitate the preferred course of action.

Where is the rot? Generally, it is found in the “development” organization, now often known as “solutions”. In many enterprises, this remains one of the largest sections of the IT group, yet it has seen great diminution of the scope of its responsibilities over the past twenty years, as follows:

Around twenty-five years ago, new application development started to slow for this group, as major projects started to be turned over to external system integrators, consultancies and contractors rather than be done “in house”. The maintenance quotient in the work to be done rose.

About twenty years ago, the platform shift away from central processors (MVS [now Z/OS] or VMS or OS/400-based) toward server farms was initiated (either to Windows or Unix [now mostly Linux]). Maintenance requirements for the existing portfolio kept great chunks of this group from being able to participate early in the cycle.

Around fifteen years ago, the role of relationship manager (or client service manager) started to break away from development. In the ensuing power struggle for “control of the client” that unfolded in many companies, development managers found their former role as “discussers of the future” taken out of their hands.

Also around fifteen years ago, the shift from in-house code to packaged solutions was seriously ramped up, mostly out of Y2K worries. Package implementation provided less scope for creativity than did the former algorithm design and development roles.

Shortly after the turn of the century, enterprise architecture came to the fore; in many cases, solution architecture was the first major success area. This took away the ability to design the future that had previously been part of the development team’s role.

At around the same time, the creation of “corporate” offices — a project management office, a program management office, etc. — began to take shape, again taking former “development” responsibilities out of the organization.

Throughout, the failure of most organizations to adequately implement and use the discipline of portfolio management kept the “development” staff locked in place to support an ever-aging portfolio.

All of these have acted to demoralize the development teams, particularly at the team lead and manager levels.

Staff still strive to move upward — in almost every case I observe, there is no parallel technical ladder to provide an outlet for stymied staff or to handle pay issues in technical work — but their managerial scope offers little opportunity for work of interest.

They have become deeply disaffected, and deeply conservative, resisting any IT change, in an effort to hold onto what is left.

No two organizations try to solve this problem in the same way.

Some choose offshore or outsourced maintenance, to refresh and revitalize their development teams with a high percentage of new work.

Some choose to effectively dismantle “development” as we have known it, creating practice areas and centres of excellence that can serve the task of the moment (bespoke code creation, package implementation, etc.).

Still others will use this opportunity to rethink the issues surrounding having created departments for client relationships and architecture, and various offices, and rebuild the former “team” structure using collaborative tools to create peer communities from these specialties.

The answers must fit the needs of the company, which vary by industry, and industry position; there will be no “best practices” here.

But solving this situation is critical, for any organization looking to depend upon its adaptability, speed of response, or responsiveness to situations.

Sitting down in the bowels of IT, and left alone, this drag on corporate capabilities will continue to fester and grow. A word to the wise: face up to the situation now (it is far less a problem of the people involved and more the accumulated effects of history) and begin migrating toward what will be needed.

Leaving it to the end will simply create even more competition for scarce external resources at a time when demand for these is highest.

That’ll get you a steady diet of people you will train, at premium rates, and then not retain. Or didn’t Y2K teach us anything?


About passionateobserver

I am a passionate observer of our society, the economy, and politics. Mostly I don't like much of what I see, so I write as a concerned citizen. To the fray, I bring a background in the philosophy of history, a lifetime's reading, a work history in information technology management, consulting and education.
This entry was posted in Development, Enterprise Architecture and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s