There has been a lot of discussion lately about the concept of IT and business alignment. Over the years and in my journeys I have seen this topic come up in one way or another time and time again. I believe that the place to start is much simpler than what most consider. I would like to start this discussion with one question, "What's in a name?"
IT was conceived around the concept of storage and retrieval of information (data) . This subtle but important detail results in the way many IT professionals view their job and results in a narrowing of scope and a significant gap between IT and business expectations.
One small example of this gap is that many IT project teams take the approach that it is their responsibility to build the system, while it is the business' responsibility to learn and understand how to use it. Whenever I encounter an IT system development project that is not planning help files, user documentation, and training (which unfortunately is quite frequently), I ask "where's the training?" and "how will the business know how to use the system?". Most often, the standard response I receive is "they didn't ask for it". This is just one small example of where my view of an IT team's responsibilities so often differed from that of the norm.
After years of deliberation on the the matter of IT's roles and responsibilities within an organization, it became clear to me that the answer may be more fundamental than earlier thought. It might not be IT's responsibility at all. The gap between the responsibilities of IT and the business may need to be filled by some other entity. For the purpose of this article, lets call this new entity Business Technology (BT).
Now, let's compare and contrast some potential differences between IT and BT. An IT system may be successful if it successfully stores and retrieves information, regardless of whether the system meets the goals of the organization. In order for a BT system to successfully fulfill the business' objectives, the systems must be designed around business processes and functions rather than data storage. BT requires a broader set of project team responsibilities which include process analysis, training, communications, and a seat at the table in business planning. In addition, BT looks at all the technology in an organization as an integrated ecosystem, rather than simply the IT hardware and software. This additional technology can include physical security and surveillance systems, manufacturing equipment, and other facility related infrastructure. It puts the focus on the business and not the information, and takes into account that the business is the customer and not a "user". BT demands more than a software development life cycle (SDLC) that focuses mainly on the build/construction effort, instead, it requires an advance life cycle (ALC) methodology that incorporates all concepts from inception and architecture to deployment, training, and support.
While some may argue that I am being trivial and focusing on semantics, there is a significant difference between the concepts of IT and BT. If you don't believe me, here's a test. On your next project, focus on understanding a day in the life of the stakeholders that will use your system. Walk a mile in their shoes and try to understand how the systems that we build often make their jobs more difficult and redundant, and not simpler. Make your measure of success whether you improve their jobs rather than simply whether the system gets built. Whether or not you are practicing IT or BT will be determined by your response to this challenge.
Tuesday, January 19, 2010
Subscribe to:
Posts (Atom)
