10.1 Not it, not business processes, but organizational culture  (Page 13/13)

1. No one had ever heard of moodle before, much less OurVLE.
2. Our University had never deployed an open-source enterprise system before, and so some IT staff were very vocal about their doubts that the deployment would succeed.
3. The Commonwealth of Learning’s review of open-source learning management systems that came to our attention during the evaluation phase recommended ATutor and Ilias over moodle, so some IT staff were less enthusiastic about moodle than these others.
4. Most of our faculty members who had recently returned from Universities in the United States had worked with WebCT and BlackBoard, and saw a free (open-source) alternative as inherently second-best.
5. The recent deployment of another major (proprietary) enterprise application had left a bitter taste in some faculty members’ mouths.

The only way I saw to overcome this resistance was by building trust with potential clients. In particular I told faculty members that I could not guarantee that OurVLE would be prettier than any of the proprietary alternatives, but I would guarantee that it would be easier to use. I would not guarantee that it would provide all the features of the alternatives, but it would provide all those they were used to using. I would not guarantee that it would always work, but I would guarantee that I would always be honest with them about its status. And perhaps most importantly we did not tell anyone that if they did not adopt it, that their non-adoption meant they were backward. Quite the contrary, we emphasized that at the start we only expected the adventurous first adopters to jump in, and that we knew that others would come onboard once the system had been proved. Of course, increasingly more and more staff wanted to be “with it” and enthusiastically adopted. I think it helped that we did have major technical issues, especially with the chat module in the first year, and because we were very open with faculty members and students about it, and they saw that we were committed to working with them to get around the obstacles, they became very loyal clients, and evangelized our services all the more.

Did the issues with the WebCT deployment trigger a reassessment of the IT department’s culture and operations? Or if the culture was in place prior to or during the deployment of WebCT, what advise could you give for those who would like to implement the same culture, but avoid the first outcome?

I don’t know that it is entirely possible to avoid the first outcome, since once you are using proprietary software you may be at the mercy of your vendor regarding license fees. However, one can significantly reduce the risk by having good data and using that data in a structured planning and managing framework such as is described in the PMBOK. Unfortunately, as you have pointed out this data is not always readily available.

And finally, the values described sound very much like the principles of the Agile Manifesto ( (External Link) ). While agile methods are usually associated with software development, how do you feel they might apply to the general field of IT project management and the various practices mentioned: COBIT, ITIL, PMBOK?

In 2003-2004 I was very much a fan of the Agile Methods movement which may explain the similarities. But as a manager within a large institution, it is important to emphasize that work must be aligned with the larger formally defined institutional strategy and executed within the parameters defined by the overall control framework. At least two of the practices associated with agile methods are relevant to the provision of a wide range of IT services.

1. Frequent unfettered communication among team members is very helpful to providing the best quality of service to clients. For example, I frequently overhear my team-members’ conversations with clients, and having been familiar with these clients longer than my team-members have, am usually able to provide some insight into the clients’ needs, or to be able to relate them to larger organizational goals, which better equips the team-member to serve the client. Frequent (several times a week) discussions among staff about the services being offered, the controls in place, and the methods being used, deepens the shared understanding of these different practices and strengthens the organizational culture. It also makes for easier business continuity. However, I do believe in the need for high quality documentation – that is, documents that will be used. COBIT and ITIL are especially helpful in defining some of these.
2. Rapid iterations with frequent client input is especially useful in all kinds of projects, whether one is planning a large multimedia supported event, developing an online course or a new learning space. Whether the client is just located across campus, or seventeen hundred miles away in Toronto , frequent oral communication is critical to developing the shared understanding and trust levels that enables project teams to collaboratively overcome obstacles. It may appear as a paradox, but some documentation is also critical to ensure a shared understanding (especially for a widely distributed, multi-lingual team) and efficient collaboration. A Guide to the Project Management Body of Knowledge is useful in suggesting what some of this documentation ought to be, in guiding the team in its collaboration, and in the best of worlds provides a common language for discussion.

Regards, Craig.