You are here

Craig Perue - July 6th, 2007 at 8:34 am

15 January, 2016 - 09:27
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at http://cnx.org/contents/f6522dce-7e2b-47ac-8c82-8e2b72973784@7.2

Thanks for great questions. I hope my answers do them justice.

However, while I wholeheartedly agree FLOSS provides the means for implementing a broad arrayof systems and services, especially in resource restricted institutions, many who argue againstthe use of FLOSS site the same as the very reason to use commercialofferings, emphasizingcontracted support supplements the limited resources on campus.

    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 technicalrequirements 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 1 , ITIL 2 , PMBOK 3 ) 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.

Most clients I have met believe that a half good solution implemented today is better than the best solution that never gets deployed. On the other hand, I have seen clients develop immense resistance to a software implementation projects because, with the best intentions in the world but the wrong approach, IT staff preached to the clients that this newest project was critical to taking the clients out of the dark ages, reforming their business processes, and saving the organization from perdition. This approach is usually unproductive for two major reasons:

1. As Andrew Carnegie pointed out decades ago, criticizing someone almost always raises their resistance to you.

  • So, should the IT department tell the Bursary that their business processes are archaic - in effect questioning their competence - it is usually fanciful to expect the Bursary to respond by asking the IT department what new multi-million dollar software the IT department would like to install to facilitate the necessary re-engineering. Sometimes functional departments are well aware of the need for change but have different priorities from the IT department. The IT department's job is to keep the dialogue open so that when the functional department is ready, they will look to the IT department as a partner; or, the IT department can help to change organizational priorities through an IT Governing Council or any of a wide range of organizational change techniques (which do not include preaching).
  • At the level of the individual worker, we need to consider that many people's jobs are a huge part of their identity - after all, they spend a large part of their waking lives at work. It is therefore critical that in our eagerness to achieve “faster, cheaper, better” that we not trample upon the significant personal investment many persons have in the way they do their work. In contrast to preaching, I think one of the most effective ways to get staff members to adopt a new technology is to show them how it will reinforce their sense of worth and increase the value they bring to the organization. On the other hand, I have seen staff members develop immense resistance to technology deployments for the sole reason that they believed the technologies were being insensitively deployed.

2. It is very rare that IT staff will know as much about the reasons for the organization's functional processes as much as the functional staff, whether these functional staff are accountants, registrars, estate managers or teaching staff. So while it is helpful for IT staff to bring their learning about the best practices in the functional area to the discussion, it is even more essential that they dialogue with the functional staff openly to uncover the nuances which are essential for a good implementation in the particular organization.

I guess what I am saying is one has to work really hard to become a trusted advisor 4 , by showing the clients respect, gaining their trust and working really hard to keep it.

    Regards, Craig.