Best Practice in HR - And then came Prism…

Having an “online appraisal system” isn’t a panacea for the often dreaded appraisals. To make it work there are key beliefs on appraisals itself that the organisation should have and the system needs to be designed keeping these beliefs in mind. SUDHEESH VENKATESH of Planetasia shares his experience on how the online appraisal process was revitalized in 2002.

Pre-PRISM: Appraisal was something Planetasians did to relieve the tedium in a project.

Circa 2000, the organisation adopted an online system, christened the Performance Management System (PMS). HR dreamt of productivity-on-steroids. A happy ending to a usually fractious activity. The paperless promise meant forests saved.

Teething troubles were to be expected. A week into actual usage, root canal surgery seemed more appropriate. Tedium turned into ennui. The new system was actually found to be slower compared to the old-fashioned offline way. Worse, some managers had fallen prey to the easy exit, the system offered, to, face-to-face interaction. HR’s productivity was on a bungee jump - with no strings attached.

Most users were wont to curse the user interface (UI) with the choicest expletives. But the malaise was deeper; as usual, only the manifestation was in the UI.

With the raison d’etre for the revamp established, a core team of six - 3 developers, a tech lead, an interface engineer, and a project leader - was assembled with HR as client.

And voila! The unfortunately named PMS was out and PRISM came in …

Insight: Obviously, it wasn’t so simple. In the first few days, as the Group of 6 focused onto the Planetasia appraisal universe, two objects d’action swung firmly into their field of view:

a) find out what was off-kilter with the philosophy of the previous appraisal system

b) implement the solution so that it offered an optimum mix of control and flexibility

At its heart, any online appraisal system is workflow. The garnishing in the form of controls and specifications may vary but the goal of the solution designer is to ensure the shortest possible path from Appraisee to the final repository.

That’s the system POV. For the ‘philosophy’, read on…. 1-2-3...

There’s something about an idea whose time has come. It is moot as to how many Planetasians would have heard of Herbert Meyers’study at GE (see box ‘The GE Study’) but the sentiments they voiced were amazingly congruent. “We aren’t feeling heard,” was the common refrain. “We do it because we have to. We don’t believe our rating is a consequence of the data on this system. You can’t decide on an individual’s future in one fell sweep.”

It became clear to us that appraisal had to be treated as a process rather than as an event. That was how it ought to have been anyway (our internal quality system mandated it, in fact) but circumstances had pushed us far enough from that for us to actually make it a testament of intention (see box ‘The GE Study’).

Second, we decided to address the problems of Planetasians who did not work on projects per se - functions like Biz Acquisition, Finance, Admin, Information Services and indeed HR itself, which were not under the Delivery umbrella. Like the existing system, we too made ‘project’ as our pivot but with sufficient flexibility for it to include these functions in an organic manner. Project became a generic term for any task, assignment or even function.

Third was the decision to feed off existing systems, like data sources within the company that kept tabs on which Planetasian was staffed on which project and for what duration.

The Nuts & Bolts

We defined two kinds of appraisal - a local appraisal, associated with an individual’s exit from a project, and a final appraisal associated with a fixed periodic review of performance and possible compensation, role and designation. The local appraisal concerned itself with performance on a project. The final appraisal concerned itself with performance across the appraisal period (typically half-yearly) and was conducted at a fixed time for all Planetasians.

Thus, we envisioned Planetasians using PRISM for setting KRAs when they were staffed on a project and being appraised against these when they were released, accumulating ratings and reviews which would all be filtered into a single rating and review during the final appraisal. A process culminating in an event. QED.

The KRAs input by the Appraisee had to be approved by the Appraiser (locking). During rating, the Appraiser’s rating would be followed by that of the Reviewer and lastly by HR.

Thus, the 3 issues of source, schedule and scale were decided (see box ‘The Rule of 3’). For source, we had information as filed in by the Appraisee himself, his immediate superior, a Reviewer, and an endorsement of that by HR following an off-line moderation meeting. For those in vital client-facing positions, the source was expanded to include a client rating. The schedule was bi-annual. A four-point rating scale was followed (2-5, with ‘2’ standing for ‘Below Expectations’ and ‘5’ connoting ‘Far Beyond Expectations’). Also, Reviewers had access to ratings of 2 previous cycles.

In theory, we had everything: a continuous participatory approach which suggested performance management rather than judgment from the pulpit, a rating history, and as many as 4 sources of ratings that ensured a degree of normalisation.

In practice? See ‘Impact’ below.

Highlights

+ The system told the Appraisee what projects (s)he worked on during the
appraisal period under question

+ The Appraisee could himself ‘create’ projects - this was vital for non-Delivery
functions. It also enabled any Planetasian to record assignments off their beaten track

+ An event (E1, a mail alert) determined the beginning of final appraisal and a similar event (E2) closed it.

+ KRAs could be re-used from previous appraisal cycles. Appraisees were also provided with a repository of KRAs and Job Goals online.

+ The user interface made the whole task a breeze. With the entire organisation using IE 5+ as the browser and the web solution built on MS-ASP-SQL, the interface engineer could use ‘cool’ JavaScript functions to advantage, even customising right-click functions.

+ Powerful HR modules were built with the aim of equipping HR to deal with every eventuality.

+ Mail alerts sent out whenever an Appraisee submitted KRAs, when the Appraiser locked (to the Appraisee) and when he rated and passed it on (to the Reviewer).

Implementation Challenges

Resistance to allocate a dedicated internal team for 12 person-months to work on this project was the first hurdle. Next were technology challenges related to security, remote access and migration of past data. There was an adoption challenge where large sections of the company had to be convinced about benefits. Also, given the target audience, they’d be quick to ruthlessly pounce on not just small bugs that might have eluded the development team; they could also proffer solutions! For the team to come out unscathed, it was essential to get it right the first time.

Impact

A little early to say (we have had one run and the really heavy run is
scheduled later this month). Yet, it is clearly visible that:

+ A higher percentage of employees use the system.

+ No stage is given a go-by - hence process compliance has increased.

+ Time spent on the setting of KRAs,review and performance assessment has decreased.

+ There are fewer cases for grievance redressal - since the system is
data-driven and hence perceived to be fairer.

Areas of improvement

Users have adopted this system with glee. “Great!” they chorused. Yet, there exists the danger of swinging to the other extreme - where everything is technology-enabled and human interaction becomes non-existent. HR will then have to devise something else… another Best Practice, perhaps!

Issue BG21 Dec02