Dressing information technology in business clothes

Dressing information technology in business clothes

Given what passes for appropriate business attire these days, it seems hard to imagine that we once made a big deal out of “casual Fridays.”
(In the spirit of full disclosure, I have to admit that my own professional attire trajectory has gone the other way – while a software engineering manager at Digital Equipment Corporation, I was once asked if I was part of a construction crew working at our building.)
If you need any more evidence that the world described in your policies and procedures manual may vary just a bit from the reality on the ground, trace the meteor’s path of “appropriate business attire” over the last ten years. The short-cuts and gurus, the hallway conversations and hand-written checklists, the holiday party and the kids who happen to be on the same soccer team are the casual Fridays of business process. Just like casual Fridays, they slowly become the way business is really conducted.
That difference between the formal, explicit view of our companies and the informal, implicit reality of how business is conducted every day is a gap that can swallow any IT project, large or small. Just to keep us on our toes, it’s also a gap that is constantly changing. I can’t believe the amount of time I and my management peers invested over the last ten years trying to keep the policy and procedures manuals on the same planet as current trends in dress.
If you think that’s just an HR problem, then consider a company of my acquaintance that implemented RFID for its inventory control and saw a huge jump in missing inventory in one of the pilot warehouses. The old policy was that everything that left the warehouse was diligently keyed into a tracking program. Everybody knew the procedure and followed it pretty well. Once RFID was implemented, the sensors at the loading dock automated that process and folks didn’t have to worry about that data entry anymore. Only problem was that a good portion of the inventory at this and another warehouse didn’t go over the loading dock. It went out in smaller batches over a front desk where there were no RFID readers. Amazingly enough, the volume of missing inventory pretty much exactly matched the volume out the front door.
Turns out that the IT folks had actually asked their local warehouse folks about how stuff left the warehouse and got a “loading dock only” answer which was correct for that one warehouse. The folks in the pilot warehouse (at a different location) heard that RFID meant they didn’t have to key in inventory data anymore – and Lord knows, it was a hassle for all those small batches &ndahs; so they stopped. Poof! Vanishing inventory. In that case, the solution was pretty simple. An investment in additional RFID readers and a little more training for the warehouse staff up front cured the problem.
But the moral of the story remains. Developing your business savvy requires more than an MBA and financial fluency, more than annual reports and policy and procedure manuals, more than best practices and golf with the CEO once a month. IT business savvy requires that you become familiar with how your co-workers and other consumers of your service conduct their business on a day-to-day basis. Traditional input/transformations/output requirements collection or business process analysis won’t get the job done.
The Rational Unified Process’ “use cases” or Extreme Programming’s “user stories” begin to capture some of the daily translations of official procedure into individual action. However, given a choice between the heavy methodology of the Rational Unified Process and Capability Maturity Model or the collectivist mysticism of XP, many organizations will remain on the sidelines.
That’s too bad, because these narrative approaches or something like them are a good antidote to the “solution-itis” that seems to be sweeping through IT these days. It’s hard to jump into a pre-packaged “solution” once you’ve heard and understood some of the war stories about how business actually gets done in your organization.
That doesn’t mean you won’t ever change business processes to accommodate some well-thought out technology solution to the common problems of your given industry. It just makes good business sense to take advantage of efficiencies others have developed. However, becoming familiar with the specific narratives of your business will help prevent the twin bulldozers of automation and best practices from plowing under those few truly unique activities that separate your business from the next one.

Byron Glick is a principal at Prairie Star Consulting, LLC of Madison Wis. Prairie Star specializes in managing the organizational impacts of technology. He can be contacted via e-mail at byron.glick@prairiestarconsulting.com or via telephone at 608/345-3958.

The opinions expressed herein or statements made in the above column are solely those of the author, & do not necessarily reflect the views of Wisconsin Technology Network, LLC. (WTN). WTN, LLC accepts no legal liability or responsibility for any claims made or opinions expressed herein.