Creating a PDR System

by Benjamin Williams


Posted on 27th March 2019


Creating a PDR System

I have a new task to complete at work, and it's turned out to be more fun/interesting than I thought it would after it was initially suggested. Created a Personal Development Review (PDR) section for our company Intranet.

Having already built a task support system as a standalone addon, the initial requirement was to get the PDR process back online instead of having it paper based. The old PDR process used to be on our Intranet but it was awful and would need a lot of manual work to set it up every year thanks to how it was built into Drupal, which I don't really like as a CMS. With our PDR's moving to be every 3 months (or every month for people in certain positions), making the old system live again filled me with dread. Thankfully, it was agreed that I could build it into my task support system that I built from scratch, since that uses LDAP to log in and technically completing a PDR is a task - just instead of creating a support ticket, you create a new PDR process that your head of department can then complete with you.

The process will follow that a user has to start their own PDR. This gives them the chance to write their own comments into the relevant sections, if they have any, for their manager to then view before the actual PDR meeting where they will then add their own comments and discuss anything that was written by the user initially.

Example of how a user views or starts their PDR

The benefits of creating this PDR system online:

  1. Encourage users to use the ticket support system, since they'll have reason to log into it and use the system. Users are notoriously bad at submitting a ticket and instead preferring to just email one person in a department that manages one of the ticket support systems lists (IT, Facilities, Marketing).
  2. Users have a chance to submit any problems/queries before their PDR and can easily check their previous ones for reference.
  3. Managers can view any potential problems/areas of concern from their member of staff before the PDR meeting takes place.
  4. HR and the Managing Partner can have better visibility of PDR's and can check that they are actually being completed.

The head of department needs to be able to close off a PDR upon completion, ticking a box to confirm that they have completed and discussed everything on the PDR form with the relevant member of staff. This will then disable all the inputs so that no further comments can be added, to prevent situations like staff saying they raised a concern on their PDR when in fact they added this after the actual meeting. The head of department also needs to be able to view all users from their team so that they have a list of open PDR's along with a history of ones that they have marked as completed for everyone that they manage.

HR and the Managing Partner will have their own section where they can view the history of everyone in the company.

There's a lot of processes to build in that will make the PDR process better than it's current paper form. It's hard work, but it's been rather interesting so far. There's some way to go with building it, but hopefully there'll be a lot to learn along the way with some new ideas/techniques to talk about on here.


Latest Blog Posts

One to Remember - GET Equals 0 is Empty
One to Remember - GET Equals 0 is Empty

The joys of programing is always learning. Like how zero equals NULL in a GET value.

Check it out next
The Importance of Error Pages
The Importance of Error Pages

Why is this one of the most important pages on a website the 404 page?

Check it out next
MagicMan13 brought up to date
MagicMan13 brought up to date

It's been a while, but MagicMan13 is finally mobile friendly whilst still keeping the look that that Chris loves.

Check it out next