Skip to content

It Needs To Do What It Does Today

Today's Best of Mike post comes from September 20, 2005. I recently flashed back to this post following the Connections launch. We had an existing "white pages" search at McKesson, but Profiles was to be that and more. After we launched, we got reports of certain things not working, including the ability to search on a person's user id. Neither I nor the business side PM was aware of that capability, so when we were verifying that the people search capabilities preserved existing functionality, we did not consider this use case. Hopefully we now have the best blend of new functionality and desired existing functionality.   

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."

No comments yet

Leave a Reply

You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS