0.4 Craig perue - not it, not business processes, but organizational  (Page 9/13)

I think both arguments are valid in different contexts. In choosing between any number of products regardless of license types, I urge IT organizations (and their clients in appropriate situations) to look at “total cost of ownership,” “long term support,” “quality,” “added staff,” and how these software acquisitions would fit into the larger IT portfolio. In some markets contracted support for some products, whether FLOSS or proprietary, may be cheaper than hiring and training your own support staff. In that case the sensible thing to do is to contract the support. Even in such situations though, it may be to the organization’s advantage to choose a FLOSS rather than a proprietary product to avoid vendor lock-in for support.

In the Caribbean paying for contracted support usually means paying for international airfares and telephone bills because of the scarcity of appropriate local technology support staff. It also means paying fees for consultants that live in higher cost cities, and thus charge higher wages, than local staff would. All this makes for a very strong business case for hiring and training our own technology support staff who develop deep organizational smarts and contribute to our own capacity to innovate using FLOSS.

In my post, I posed this very culture as the ideal: a faculty and administrative body who derives functional requirements/needs based on their business processes and leaves the technical requirements to the IT department.

Please share you secret, how did you achieve such a paradise?

First, I was very fortunate to get the opportunity to build an IT Unit from scratch within the larger IT department. In that respect I was more fortunate than some CIOs who find themselves dropped into hostile organizational cultures which they must try to change both within the IT department and outside in the functional departments. Having the rare opportunity to build an IT Unit from scratch, I decided very early on to take the long view and try to develop a very specific type of IT organizational culture by:

1. emphasizing the development of deep understanding of the technology but an even greater focus on meeting client needs
2. developing super-effective systems that work (based on COBIT , ITIL , PMBOK ) rather than personal heroics
3. hiring staff who seemed to share appropriate values and attitudes.

It is critical to have systems and employees that project appropriate values and attitudes in all the interfaces or touchpoints with clients, so that an appropriate culture of partnership and interaction develops. At the start of my tenure in the IT department here, my goal in working with our clients was to build their trust in:

1. The eagerness of the IT department to understand their needs and meet them unselfishly (that is, without succumbing to the urge to suggest the most sophisticated or “fun” technology even though it may be overkill or simply inappropriate for the context).
2. The absolute honesty of the IT department, including knowing that the IT department will tell the client if his/her needs cannot be met, and why, rather than stringing him/her along for months without a proper solution.