The Dos and Don’ts to build a successful HR Portal

Many organisations have been for years investing in HR technologies, trying to lower their operational costs and raise efficiencies by letting employee and managers access HR processes through specific Self-Service functionalities.

Yet, not all organisations have been successful in obtaining the expected results. Whether as a specific implementation project, or as part of a larger HR Transformation effort, HR technologies play a key role as the enabler of a lot of today’s HR processes. but their implementation poses challenges that are not always comparable to the ones other ERPs face.

The main one is that HR systems are addressed to all employees, and not only specific ones. Not only, in many cases they also need to involve people that are not yet employee (interns, contingent workers, free-lance) or people that are not anymore employees (retired, but also people who changed job). So, how to implement a system that can really be usable by all these type of people?

In many cases, the idea of a HR Portal came through, in an effort to really create a simple to use point of access for employees and managers to all HR transactions. If until a couple of years ago this was often just to create an easier to use front-end for the all-in-one ERPs mostly used (such as PeopleSoft, Oracle Business Suite, SAP), today portals also play a key role in connecting different best of breed HR solutions (such as Taleo for recruiting, Saba for learning, SuccessFactor for Performance Management, just to cite some of them).

But why is it so difficult to achieve the desired results?

From the different examples I’ve seen so far, I believe we can identify at least five common mistakes:

1. A Portal is not a Project: this is one of the most evident mistakes. Many organisations treat the realisation and implementation of a Portal as a project, with its budget, its governance model, its design and build phase and its final go-live. But here lies the problem: a Portal needs resources, governance and continuous update to work after the go live. If an organisation fails to understand this in the early stages of its inception, the whole Portal idea will fail at a certain point. 
   
2. A Portal is not (only) about Technology: yet in many organisations this is seen as a (mainly) IT project. In reality most organisations already have the technological capability of building a portal. Issue is that a portal is a lot more about understanding user interactions then about setting a technology environment alone. Similarly to web design, the key elements are: usability, content management, taxonomies… elements that sometime a hardcore technologist does not always understand.
3. A Portal is not an Intranet: putting a couple of documents on a Sharepoint site, and linking in 2-3 transactions, doesn’t make that a portal. A Portal is all about a unique experience for the user. Which should evolve and grow and accomodate different types of usages by different kind of suer profiles.
4. A Portal is not a “one size fits all” tool: on the contrary, one of the key feature of a well-designed portal is to make sure it delivers content that is unique for each user profile. And it should also accomodate different user behaviors in searching for content, as well as in accessing portal content (from work, from home, via mobile…).
5. A Portal is not a “link collection”: I think that the era of creating a one pager with links to all HR applications is over. Although this could be used to give access to all applications from one page, and maybe solve single sign-on problems, just creating a landing page with links is definitely not a solution.

So, what are the best advices to get a real Portal off the ground that can help achieve the organisation objectives? There are many articles online on Best Practices, yet I believe that talking about Best Practices is somehow dangerous. There’s no way that a successfully built HR portal for one organisation, can work, and achieve the same level of results, in another.

However, here are some basic suggestions that I believe you should take into account:

1. Design your portal around your own people: start from the pain points and the real needs of your employees and managers, not from the way HR or Technology see them. If you are able to create a dialogue with the final users of the Portal itself, and possibly embed this dialogue also in the Portal design (through whatever “social” feature you think to be most appropriate: comments, tagging, forum etc.), you will not only obtain a good initial design, but you will create a community that will help bringing that design forward.
2. Deliver a “beta” version… : like many “Web 2.0” sites have taught us, it is impossible to foresee all different types of tools, interaction points, features etc. that a Portal may require. Instead of trying to have an extremely long design phase, to take all this into account, try to get your Portal live as a “beta” release as soon as you have built the core functionalities. Then release something new every 2-3 months, maybe using the Viral approach that Facebook and Google have so successfully implemented (releasing a functionality to a small group of people first, looking at their reaction, and seeing how new people start asking for those features).
3. Think of HR holistically: in many organisations the responsibility of a Portal sits under one of the specific HR functions or Centers of Expertise. Although this may sound sensible, your Portal needs to become the core of your HR Service Delivery Model. This means you need to be able to connect all the different functions and areas of HR. Not only, you should be able to embed into the HR portal also elements that are considered “HR” from your end-users perspective. A typical example is the Employee DIrectory. Administered often by IT as part of the provisioning system, often sits on another system as is not integrated with the HR portal. Now, try to explain this to an average employee… Same destiny for areas like Health and Safety, Travel Policies, Expenses etc.
4. Develop a Clear Governance Model: this is one of the areas in which most organisations fail. Managing an HR Portal means defining clearly who does what, and who is responsible for what, at all content levels. Your Governance Model should take into consideration that you will be having different types of content (a Policy might have different approvals rules than a news item), as well as different customers (employees of one country may be affected by one policy more than others, specific HR actions may be for one specific region only etc.). If your organisation is big and spans multiple country, you will amplify the need of a clear governance model due to language and local regulations needs.
5. Be “open” in terms of technology: this is the only technological advice I’d give: be open in terms of platform. Meaning, make sure that what you have chosen can accomodate interaction with different systems: SaaS, other ERPs, web-services, API etc. Portal are often becoming integration points with many systems. As such you need to be able to accomodate both the AS-IS technical scenario, as well as the future TO-BE… whatever that may be.

Although these may sound “generic”, these suggestions are really key in defining a Portal that is going to be effectively used by your workforce, thus driving the results you want to achieve.