The majority of IT professionals are employed by companies whose core business is outside the IT industry, which sets up an interesting relationship between the internal IT group and the business units running the other internal functions. All too often, management mistakenly views any IT hardware or software project as an IT issue and passes the project responsibility to the internal IT team. We’re not addressing external, customer-facing technology here, rather how IT serves the organization itself. Although it sounds counter-intuitive, but the fact that an initiative involves IT hardware or software should not automatically make it fully an IT responsibility.
Your organization likely has one or more staff members managing core internal IT responsibilities such as network management, messaging, server maintenance, etc. As you explore optimizing or expanding the technical environment, it is important that these kinds of internal IT services be categorized differently than function-specific projects such as setting up a financial application, HR software or an inventory management system. IT often does not understand the business functions, and the business does not understand IT functions. In smaller business environments, including regional or satellite offices of larger companies, there are generally only a few junior IT staff, but a management tendency to have IT own anything that is even vaguely IT related. Passing full responsibility to IT because it is a hardware or software implementation is a mismatch of technical knowledge versus operational functionality. This situation can result in an implementation that is technically sound, but functionally hopeless. Larger companies generally have a team of business analysts or project specialists as the middleman to be able to bridge between IT and the Business. Other companies add and dedicate temporary resources as needed, employ specialist project managers or even contract the actual vendor to do their implementation. Although it is often more expensive initially, this type of structure tends to lead towards a more successful project, because it brings together the different business functions and aspects that are needed to make it work. The project can be done by properly the first time, which saves money in the future. Basic administration functions seem to be moving towards having that department or functional group be responsible for it. HR administers their software, Finance theirs, etc. Non-IT managers responsible for such functions may be very passionate that implementing a particular software application is critical to their group, but they need to be clear that there a long term commitment of maintenance and administration in addition to the initial implementation. They will need to factor in overhead in their group to make sure that it is operationally well managed on an ongoing basis; setting up users, assigning rights, running reports. This will require business staff developing some application administration skills, with the responsibility for the infrastructure, hardware, OS admin, and coding/break-fix continuing to lie with IT. A software application is ultimately just another tool to be used by the company staff. When moving forward with a software project, the company management structure needs to be responsible for a quality functional design, good training, a usage policy and ongoing adherence, including a portion of the ongoing application administration. This usually winds up 80% business and 20% IT responsibility, and you would be right to feel cautious if this seems to be reversed. Keeping data and segregated safe is another critical aspect to consider. Although it may be inconvenient to split rights and responsibilities between ICT and the business owners, having checks and balances will serve you well in the long term.
Generally speaking, there needs to be very heavy business involvement if a technical project is to be fully successful; especially if it is to be an effective tool and contributor to efficiency and productivity in the company. If an effort happens fully as an IT oriented project, it will likely be doomed to mediocrity, effectively having to be redone sooner or later, which is a costly proposition.