Please Share Feedback


Questions, comments, suggestions? Let us know what you think on our Forum.

To contact us privately, please use our contact form.

Author: Elyse, PMP, CPHIMS
November 30, 2004


The principal I?m arriving at is shouldn?t there be a right of Eminent Domain for IT. Ultimately, isn?t the need for a business decision based upon a technology belong to the IT department? Should this fact need to be communicated? Or should it simply be understood?

What I?m attempting to drill down to is that over a period of time, technology has become more usable for the masses. The masses utilize it. This is a good thing. There are many new creative ideas on how to accomplish tasks at hand.

After a certain period of time, the lines become blurred as to who owns the right of eminent domain for technology. One trend that has been seen is having the CIO report to the CFO, therefore the ultimate decision point would be a CFO. Another trend is entrepreneurial individuals develop or utilize an open source tool to meet a business need. Normally these business needs are ones that IT hasn?t been resourced to meet. Finally there are the driven individuals, who do IT on a part-time basis or full time within a department, in a silo who need to manage their own technology. Also when conference occur, it ends up being the driven individuals who attend alone rather than with the IT department. In an organization that has two or maybe all three of these trends, how is a technology decision the responsibility of the IT department?

As IT support comes from disparate resources, an IT organization needs to clarify the right of eminent domain through the use of policies and procedures. Standards that combine with the business strategy of the organization and the level or risk propensity of the organization are the pathway to eminent domain. For example, customer support agreements with department clearly define the level of support being provided for that department from the IT organization. Technology standards, Security standards, Development standards, Architecture Standards, Usability standards and others define the policy of the organization. The policies need to be published, but they need to be processed and understood beforehand. Have the standards reviewed by the C-level management and understood the need and reasoning. Afterwards publish the standards to the organization and have an open comment period for the organization. Diligently review and work with the commenters, if any changes to the standards occur rereview with the C-level management. After this period publish the standards so they become the rule.

Subscribe and Share!

Did you enjoy this article? Your feedback is very important! I'd like to invite you to keep up to date with the latest posts from Anticlue. We offer several venues. If you have some questions, help can be found here.