Creating a PDR System

Web Development
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 members 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 a 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 a 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 its 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.