So, you are the lucky project manager working either in or alongside the HR or Payroll team(s). It may be that the role of PM is your day job or that you are adding the duties to your day job (a common occurrence).

First, review the job description of a Project Manager which will allow you to review to expectations of the role.  We’ve also put together our top ten tips on Project Management – following the Principles of PRINCE2 but not necessarily the formality.

1. Define Roles

  • Work out, even if just to yourself, some of the key stake-holders.
  • Who is the decision-maker?
  • Who represents the user or employee interest?
  • Who pays the bills? This person could be the same as the decision-maker (very likely) but perhaps there is a distinction.
  • If you have a supplier, who do you regard to be your representative there?

This little team might comprise your Project Board. As the project manager, if you are fortunate enough, you’ll also wish to define areas of work responsibility below you and, ideally, a project support member.

2. Structure Time

Make time to save time! If you have a team, then the very least you need to do is to fix regular project team meetings. And if that team is just you, then I suggest setting aside just half an hour a week in the diary which is your PM time.

Your job here is to check in with yourself that the ideas you’ve decided to adopt here are all in place. Even if you are just taking stock. Note, if you have devised a formal Board, make sure you manage those regular meetings too. The agreement that you make with yourself about reporting will also need a small amount of structured time allocation too.

3. Remember the Project Elements

Above, I note from my PRINCE2 training the 6 elements of cost, time, scope, quality, risk and benefit. Here are 6 ways in which to go wrong within a project, and 6 ways to get it right!

Keep these concepts in mind if you are grappling with what might be going awry and focus on the need to maintain the balance of these elements in your decision-making. It’s not a great deal of use to come in under a shoe-string budget if your organisation doesn’t achieve the benefits of bothering: to cut costs, to buy a system, to change a process or structure, to introduce a strategy, to outsource or change a supplier.

4. Manage Risk

Risk can be an intimidating prospect to address head-on for all but the skilled PM professional, but I suggest making it easy for yourself to do so, bravely, by devising a simple way to assess project risk. Often this is done by scoring and weighting probability and impact.

If nothing else, you could use a scale of 1, 2 and 3 for each, multiplied together for an overall score of 1-9. It takes no time at all and it may give you exceptional clarity.

The next step here is to think through the ways in which you can mitigate that risk – trying to avoid it, or to prepare for it if likelihood is high, or to limit the damage if the risk materialises. Highlight any risks that score high and those risks which are changing during the course of the project.

5. Control Change

To the less technical mind, again here is a difficult concept, but it is worth translating into a way in which you can make sure you don’t go wrong where so many do. It can be tempting to give up when change threatens to become out of control, so get ahead with this.

  • How are you going to know about change?
  • How are you going to deal with it?

For example, you could set a “tolerance” level with each piece of work assigned to a team member, so that they own progress as long as it remains within your defined parameters (for example: spend, deadline or the precision of outcomes).

You could keep in one place all of the agreed changes and decisions, with naming conventions, dates and version numbering for saved forms, files and documents.

Word of the day: Change Control

Change Control is a structured way in which to make sure (inevitable!) change is effectively managed. The point of having such a method is not to prevent change, but to make sure that how it is dealt with is agreed, unnecessary change does not happen, change is documented and understood, and change coordinated to make the best use of resources. Typically, a change control method involves reporting, impact analysis, decision-making and documenting/referencing activities, for example. Often the phrase “change control” is used interchangeably with “configuration control/management”. To be pure about these terms, “change control” relates to project, whereas “configuration” relates to product.

6. Report

It is up to you how much reporting you want to do, but do some. At one stage in HRIS implementation, I reported to myself! Documenting takes very little time in this kind of style and it can accelerate your thought processes dramatically. This allows decision-makers, influencers you have identified (as well as yourself) to see the next decision or priority much more strikingly.

My favourite idea is that of the regular highlight report, including:

  • Key things that have happened – good and bad
  • What needs to happen next – include the decisions that need to be taken
    Issues and risks that you are alerting about
  • Whether the elements (particularly time and cost) are under control

This report must be regular – it is using calendar time as a tool with which to maintain that elusive project control.

7. Keep a Log

I recommend writing a diary or a daily log. This isn’t arduous. Choose your most accessible note-taking space, whether it is a running document on your desktop, voice-recorded messages on your smartphone, or an old-fashioned notebook.

Perhaps keep your reflections and moods to the home journal, but if your stress levels are rising due to a horrible combination of (a) complexity and (b) lone responsibility then your log can provide a good deal of reassurance that you are on top of events, as well as a second memory to fall back on.

Note dates, decisions, events, deliveries, milestones, communications and to the degree of detail that you feel comfortable to maintain but sufficient to form a decent record.

8. Document the Business Case

Rarely will it not be appropriate for a project in HR to document the business case.

The up-front purpose is, of course, to help persuade decision-makers into initiating a project, taking a decision as to the approach or securing budget and resources. Also, remember that this document serves later as your guide to how you are doing and whether benefits are due to be realised.

The benefits are one of the elements of the project, without which you don’t have the success you’d like. Perhaps I should make this my number one “how to” tip, but I choose not to because my suggestion is that it’s a mistake to consider the Business Case as a ‘one-off-and-now-it’s-forgotten’ task.

Word of the day: Baselined

In projects, agreed versions are often described as “baselined” or “baseline”. The Business Case is one such baseline and you will find the term used about project plans or versions of product descriptions, for example. The baseline document or plan is the starting point that has been agreed, typically by the project decision-makers. It is kept as a reference point, after which variation is managed using change and configuration controlled processes.

9. Start and End your Project

Note that the Business Case is a part of the successful start. You may also need to start with definition of roles, making the project plan, assessing the risks and setting up the systems you need to project manage in the ways you have determined you’ll do. In formal PM structures, we might refer to this collection of documents as the “PID” (Project Initiation Documentation).

The start is rather more obvious than the end. I hope it’s going to prove satisfactory to say “phew”, but what else to do? Please recognise the scope we all have at this point for learning for the next time.

  • What lessons did you learn?
  • Are there other relevant organisational projects happening in the business that could learn from you?
  • Get feedback from your team.
  • Give feedback.
  • Document.

If you have ever suffered from turnover, then you’ll appreciate why this is worth the bother of it.

I recommend marking in the diary when you are going to revisit the benefits. There will be a handover to the “business as usual” (BAU) team – perhaps HR Operations – but training should be part of your project plan, rather than something considered post-project. You may wish to reflect on whether good relationships or services developed have created opportunities and ideas for the future that you’d like to keep warm.

10. Manage in Stages

This concept is a really great one for making sure that your organisation doesn’t rush headlong down a track unwisely.

Managing a project by stages identified means the extent to which you are prepared to make a detailed plan and commitment, marking that milestone and, as it arrives, taking the decisions necessary for the next stage. A stage or phase provides a sensible planning horizon, a focus point for revisiting the Business Case, releasing budget or reviewing approaches and, if confidence in the project itself is not 100%, then it’s a way to mitigate the risk of getting started in the first place. Therefore, define all of the stages in outline in your plan, detail the first one only, get sign-off until the next one and go for it!

For more resources and articles on Project Management and People Technology projects please visit the our blog.