Subscribe in a reader

« China Pictures | Main | Grasping the Concepts and Benefits of the Wiki »

September 20, 2005

It Needs To Do What It Does Today

Mark Cuban had a post recently about doing things simply because that's the way things have always been done. I've been thinking a lot about some of the project kickoff and requirements meetings I have had for system upgrades over the years and one of the phrases that has always stuck out at me is "It needs to do what it does today."

Exactly what is that? In some cases, companies are able to produce documentation that shows the intentionality of a system from its conception all the way through every feature change and bug fix report. That is really the exception, though. Even as a system expert for many systems, I'm not entirely sure what some of these things "do today." My exposure to them as a software architect is generally in terms of what they don't do today or, more precisely, what they don't do well today.

Companies of all sizes would be best advised to assign software owners within their business units. The knee-jerk reaction to that is to say that IT needs to own it. IT should only own the plumbing, though. Things like the hardware (PCs, servers, network, switches, etc) and commodity software (productivity suite , email, operating system, etc). If the finance dept. decides to use T-Value, one of its members should become an expert with it, field questions from co-workers about it, and act as a liaison with the company that wrote it if problems arise. If the accounting department requests a custom reporting facility be built on top of their JD Edwards implementation, someone within accounting should be appointed system owner and be responsible for making sure the requirements are understood by all parties, the product developed is properly tested, and users are trained. They should know the system and have documentation of what it is supposed to do. System owners should also have someone to back them up in case they win the lottery or otherwise leave the company.

I see a future where the IT department isn't a silo sitting off on the horizon. In particular, I see developers within departments other than IT. They undoubtedly still report to Software Development Managers and up the chain within the IT department, but the organization chart will probably start to show dotted lines across to another department as well. Bringing a sense of system ownership within other departments is the first step towards bridging the gap between the geeks and those that run the business. And isn't system ownership what the American Dream is all about?

As for my response to people who say "well, it needs to do what it does today" ... "Great - we're already finished."

Posted by Mike on September 20, 2005 7:45 AM