Thanks for more useful questions Pat.
What methods did you use to understand and develop your IT portfolio (even distance learning),especially considering the previous deployment of WebCT, where, after considerable time andeffort, you where informed that the University simply could not afford that many licenses?
At the outset I used strategic analysis and planning methods such as SWOT analysis, forecasting, and the Balanced Scorecard but it was Service Level Management as defined in ITIL v.2 together with the Management Guidelines of PO3 (Define Technological Direction) in COBIT that were most helpful. Seeing the organization as the Executive Management team, faculty members, students and non-technology staff saw us - as a bunch of services (and costs) was important - so we created a Service Catalogue for dialogue with our clients, with a lot of ancillary data for internal management use (such as associated human resources, profitability etc.). Corresponding to the Service Catalogue, the Architectural standards would usually be the basis for beginning discussions about specific technologies with IT staff.
Was that a reference point through which you demonstrated the need to better understand,perhaps not only your IT portfolio, but institutional goals and business processes as well (under-standing the hesitance to preach or criticize)?
Yes, it certainly was a major reference point. I think a lot of IT organizations have been battling with IT-business alignment in recent years. The buzz around IT governance and enterprise architecture, and the emerging prominence of frameworks such as ValIT 1 and TOGAF 2 , and new journals such as Microsoft's The Architecture Journal 3 attest to this. In the early days I did make a presentation to the IT Management team in which I suggested that we needed to do some soul-searching just as you have stated. I was gratified when I found an acronym I had coined to describe our core business processes (TLAR - for Teaching, Learning, Assessment and Research) started showing up in various discussions across the campus.
I am also very impressed to hear of your, what might be called “institutional values.” I waswondering if you could give some examples of specific instances where these principles came intoplay, either with existing faculty/administration/IT staff (those who pre-dated your arrival) orwith regard to a project?
The deployment of OurVLE itself is probably the most visible example I can think of on this campus, where the right approach in deployment was critical. There was an immense amount of initial resistance from both IT staff and from faculty to the deployment of OurVLE for several reasons including:
- No one had ever heard of moodle before, much less OurVLE.
- 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.
- The Commonwealth of Learning's review of open-source learning management systems 4 that came to our attention during the evaluation phase recommended ATutor 5 and Ilias 6 over moodle, so some IT staff were less enthusiastic about moodle than these others.
- 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 secondbest.
- 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 cultureand 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 avoidthe 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(http://agilemanifesto.org/principles.html). While agile methods are usually associated withsoftware 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.
- 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.
- 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 7 , 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.
- 956 reads
