Recently I chronicled my frustration while serving as guest lecturer in a management of information systems technology MBA class at a local university.
As one student put it: "I still don't understand why IT isn't completely responsible for their projects, just like I am responsible for my projects."
Much to my dismay, I had been unable to get the class to understand this point, which became apparent during a group discussion toward the end of my time with them. As one of the students put it, "I still don't understand why IT isn't completely responsible for their projects, just like I am responsible for my projects."
Despite my ineffectiveness — or perhaps because of my frustration — the professor invited me back for the next class. Apparently the students had enjoyed my presentation even though they didn't agree with me. For the second go-round, the professor and I met several months before the class and devised a better way to get the point across. We adjusted the timing of the governance lecture, expanded the case study depicting a fictional steering committee meeting to select the next year's projects and, most important, totally changed the final exam.
Instead of the typical multiple-choice or essay exam, I created a series of scenarios depicting systems problems that typically occur during development. The five scenarios were as follows:
1. The system is way behind schedule, and the user blames IT while IT blames the user for changing the specifications.
2. The chief financial officer complains to the CEO that finance is not getting its fair share of IT time and wants to consider going to an ERP system. The CFO feels that ERP would solve the problem, since it would help his people get projects done more easily, with less IT time.
3. The chief marketing officer complains that the marketing system that was selected by the committee has been deferred in favor of a mandatory, government-imposed system.
4. IT has encountered a major technology problem that will require either a system upgrade or rework of the system logic.
5. The major vendor involved with the new system has just announced its decision to withdraw from the market, leaving the developers facing more expensive alternatives.
The final exam required each of the five groups in the class to present one of the scenarios to the entire class. Members of the groups played the roles of CEO, CFO, CIO, CMO, IT project leader and IT-marketing liaison. Their objective, in 20 minutes, was to outline the problem, discuss alternatives and reach some kind of reasonable decision or follow-up. They were also expected to bring into the discussion many of the items that they had learned in the class.
I was absolutely delighted with the results. It was great to hear the students discussing the issues that typically affect IT systems and showing their understanding that this kind of a collaborative meeting is the only way to resolve problems between IT and users. I believe the students understood much better than the previous class the dynamics that occur in this kind of environment. It was also great to see these primarily non-IT students discussing IT issues in a forceful and committed way.
After the role-playing was over, I had an opportunity to ask students about the experience. Their reactions to the process they'd gone through were overwhelmingly positive. I believe that they came to an understanding that will serve them and their IT departments well as they return to their respective companies.
After the class, I thought about how this simple exercise would probably be just as effective in companies that are having similar problems with understanding the dynamics between IT and user departments.
If this fits your situation and you would like to try this at your own company, drop me an e-mail. I'd be happy to send you all the materials that I used. I believe this approach to understanding the roles of IT and users in IT systems development is crucial for our long-term success. Good luck, and I look forward to hearing from you.