Glenn Kline and I recently presented a session on some classic portal mistakes we’ve seen over the years. We’ve decided to parse out the 12 mistakes into 12 days of posts on the topic. Today, marks the first of these posts.
What Happened
I was working on a fairly large portal project at an insurance company. Our first project was very successful and portal caught on. We started two more projects and continued the first. At the same time, a development team in another department decided to move their app to the portal. Within a couple days of their kicking off their project and starting to work in our shared portal environment, we lost our homepage.
Turns out this development team had co-opted the homepage by taking over the first level of the portal page structure. By doing so, their page became the homepage and our shared homepage among three other projects literally disappeared. It didn’t take us long to hit the admin console and figure out what happened. It also didn’t take long to sit down with the lead of the team and work out a shared taxonomy. We restored the homepage in a few hours and it only affected our development environment.
What Should Have Happened
As part of a multi-channel, multi-project team, we should have set some pre-defined conditions on how to interact together. Yep, I’m talking about Portal Governance. This blog has addressed governance a couple time before with Sharepoint vs Java Portal Governance and Best Practices in Governance. Here’s what should have happened:
- Create a Portal Center of Competence or CoC. This means setting up the strategic governance around the CoC and setup the roles to make it work. A potential org structure is in the image below.
- Make foundational artifacts available. The CoC should be active in setting standards, creating code samples, making training available, and in creating reusable portlets like login, account management, reporting, etc. If they do so, project velocity increases and you have less issues with homepages disappearing.
- Create an Information Architect role. This is really important. An enterprise taxonomy typically comprises more than just one portal site. It can be multiple portal sites. It can support multiple departments within one site. It can include sites that aren’t even served by a portal. The Information Architect will help manage this and help create a searchable and browsable set of sites that make sense to the end user.
- Train the PMO to work with the Portal CoC. If you have a PMO, they are typically in charge of getting other projects up and running. They should understand what the CoC provides and how tactical projects should leverage the CoC
Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth. More Info / Register
