Coralie said it is going to be part of a show-n-tell session, with an analysis of things that have and haven’t worked.
The University has about 15,000 users, composed of 13,000 students and 1600 permanent staff. The portal will be extended to further audiences in the near future. There are 2000 papers taught on campus, online and by distance education. The portal went live in August 2005. It is built on Plumtree Corporate Portal.
There are lots of relationships at the University, between staff, students, external research partners, alumni, etc. There’s a host of online applications and content (student management, HR, purchasing, e-learning, webmail, content and documents). Universities tend to have quite a mixture of centralization and decentralization. There is central IT development and support, along with devolved IT development and support. The development environments are diverse (Oracle, Java, .NET, BEA/Plumtree, Open Source, Mac), although there was a single identity management system across the University.
Because the University had 3 separate portals … which isn’t a portal at all. Some students had to visit two different portals to get their work done. The University had a one-size-fits-all website. The website plan recommended changing this.
Over a six-month period, went through a selection analysis process involving lots of different groups. One of the issues faced was describing what a “portal” was, even though they had three existing portals (people didn’t think of them as “portals” however). 5 systems were short-listed and demonstrated. Plumtree was finally selected because:
- It was a pure-play portal. It could be used to deploy portals through.
- It wasn’t an identity management system.
- It was well-rounded, well-integrated, and easy-to-use.
- It offered a strong suite of collaboration tools.
- It was easy to deploy existing applications.
A phased implementation from March 2005, with iWaikato going live in August 2005. Some expertise from Plumtree was engaged to help get the portal live in time.
- Phase 1 Foundation Portal … Focus on getting iWaikato in place, and replacing existing applications portal. Didn’t make changes to applications or business processes. Management of the portal was kept central in the first iteration, which minimized training and risks.
- Phase 2 Devolution … devolution of management and development out to key community stakeholders. This involved defining roles within the portal, providing training, establishing standards and procedures, and establishing peer groups.
- Phase 3 eEducation … this is the current phase, involving extending the portal into teaching and learning. Introduced ‘MyPapers’ communities, to provide seamless student access to resources aligned with their papers/courses. Resources include teaching resources, but more importantly interaction to staff and peers, course administration and management. Today there are 3,000 communities that are generated automatically based on enrolments in the course management system. Membership is refreshed nightly. Templates for layout are provided, but the community manager can customize it. The killer application is that staff members can finally get an up-to-date class list! One of the lecturers in the Law School took the base capability, provided online access to class presentations and also to podcasts of the teaching sessions.
A quick/stable deployment has worked well. People could start engaging with it immediately and giving feedback on a live system, rather than merely concepts.
Collaborating on the development of the portal worked well. Having developers from different schools working together on a centralized team worked very well for the development of things like MyPapers. The developers could see that it was core infrastructure, and they wanted to play a part.
The portal provided an easy way to deploy existing applications. Many are simply launched out of the portal, rather than being portalized.
Sponsorship and visibility was at senior management level. The lack of this is why many projects fail, but sponsorship at Waikato has been there from the beginning. There’s been a steering group. People know what’s going on, and that’s been helpful. eEducation has a potential to hack people off, because it infringes on their core teaching capabilities. But it’s worked well.
Well-managed environment and processes.
Finally, the portal is becoming the natural place to deploy new corporate applications.
It takes some people a long time to “get” what a portal is all about, and how it can be used well. This includes developers as much as users. Re-orienting thinking around to how to build applications within the portal takes time.
Users only visit for the things they need to do. Anything else on the main page apart from what they’re looking for is an obstacle.
Fostering community hasn’t really occurred yet. Perhaps this hasn’t happened because the focus until now has been on building the infrastructure, rather than fostering community.
Changing business processes takes time. We have to get people thinking with co-workers in new ways, such as “can we use the portal to …”. People have to stop thinking about how to use email, and instead “how do we use the portal”.
A portal may not be what you thought it would be. There are some changing perceptions on this.
Users don’t want a portal … they want the tools, services and information. Need to be careful about language.
Finally, how much does the Portal Management team “tell / direct / instruct” people? What’s the line on style, quality, usability, etc?
Key Issues that Keep Coming Up
Is the portal corporate or personal and social?
Centralized decisions are taxonomy (have gone subject-based), layout, user interface, and the color red.
Who is responsible for the system? If something is broken, who is responsible?
Does the Portal Management team have to be the final decision makers on everything?
Keeping high quality and fresh information.
What is important?
The four things that have proven to be important are stability of the platform, usefulness of content, easy to use and find, and it has to work well. “Little” issues can kill enthusiasm.
Categories: Conference Notes