In our 12-part series, Kate Wadia – Managing Director at Phase 3 Consulting – guides the HR professional through how to navigate, succeed and lead with HR tech project-work. From the inception of the business case to the handover into BAU, we’ll follow an indicative project timeframe to explain the way and the why of a project step-by- step, to give you a full toolkit of practical points, a deciphering of definitions and the top tips to get results important to HR and the wider business.
One of the key success factors in HR tech implementation is a project mindset. A project:
- Achieves a defined change
- Has a start and a finish point, where you can see that change has been delivered
Yet project-thinking does not necessarily come readily to the average HR professional and project management (PM) techniques are not in our training.
We have already in this series got you going in progressing some of the project steps – business case, system selection, contract negotiation
In this part I will help you to understand some of the fundamentals of project work, terminology you’ll come across and practical tips in the context of HR system implementation.
Project Management Method: made meaningful
Most organisations recognise the benefits of professional project management involvement in any significant HR technology implementation. Sometimes an internal PM is appointed, typically from pre-selection stages; sometimes I see internal teams waiting for the arrival of an external PM at “kick-off” (more on this below). These professionals bring expertise in one or more methodologies.
Here is a crash-course in concepts to help you make sense of jargon!
PM methods are more or less formal and structured. Typically those techniques now regarded as traditional are still used in HR systems work. Likely you’ve heard of Prince 2, a UK-developed framework, or perhaps PMBOK, the most significant global PM organisation accrediting method and training. By contrast nowadays there is an increased shift towards “agile” methods.
What are the pros and cons and should you care?!
Tip: By the way, I encourage HR leaders to adopt a project approach elsewhere. Learn to differentiate responsibility to steer something ongoing (GDPR, for example, is a new one for us) as opposed to change initiative, such as a re-structure or cultural re-positioning. As you read this, think about how you can use helpful concepts that PM’s apply in formal projects to your own day-to-day ways of leading to achieve a surer control over progress.
Quite likely your organisation has a preferred method and you have no choice. Or your product supplier brings their method along. Or you may not hear any specific method mentioned at all.
- Formal methods (e.g. Prince 2): provide a series of structured stages, planned to follow each other, in order to achieve tight controls. The benefit is a rigour and the safety of structure. Such methods are also widely shared and understood. The disadvantages can include more formal documentation and less flexibility.
- Agile method: developed in the context of software design, this allows you to work in shorter stages and respond to results with less pre-planning. There is greater focus on collaboration and teamwork. Within the context of HR technology projects, the risk could be less visibility and definition ahead. Agile methods are thought to be speedier!
Unless you have significant amounts of time to invest in studying PM methods, I encourage HR leaders and managers to concentrate on the selection choices you likely face for resourcing, both internal and external, rather than the particular method those appointees plan to use.
Key question: who should the PM be? Your supplier will provide a project manager as one of the implementation team assigned to you. However it is a mistake to rely on this person as the only PM role within the project. You do need an internal PM too, even if that role is part-time. Expect the supplier’s PM to offer a project plan, resourcing schedule and reports that cover the work that they are doing. But this misses the lion’s share of the implementation effort, as well as the internal perspective. Usually it is also a mistake to assume that someone in HR can be the internal PM, if you have alternatives. Not only does this require the kind of project-thinking we’re not trained in, but it is very hard to juggle with an operational job. My own story I point to briefly below as a real experience of this.
In a later part I’ll address specifically the options for resourcing your project. For now, you may wish to read this guide to a good job description for a project manager.
Simple ways to plan and control
What if you find yourself acting as Project Manager on top of your day-job in HR?
Yes, this is hard and it’s not ideal. But in smaller contexts or where budgets are tight, or perhaps where you’ve not yet succeeded in the buy-in from Board to invest in that way, you may find yourself alone.
Sometimes there is the misguided belief from senior stakeholders that, because you’re paying for expensive supplier PM-ship, there cannot possibly be justification in appointing internally too.
This is my story of becoming an HR technology specialist. To manage a transition point in our HRM team, I was asked to take on project management for our system implementation. That sounded fine and so I said yes. One of the reasons I write with a passion to translate between HR and technology is because I remember all too well quite how sharp and steep that learning curve was. And with hindsight quite how much I could have done had I not been deeply, despairingly lost.
So I offer a few straight-forward suggestions to create an easy means of planning and controlling project progress:
- Create a structure: be clear – and share – internal team project roles, including accountabilities for tasks and how far to take those tasks before reporting back. Structure regular meetings and reports for those people.
- Diarise: even if you are on your own, to overcome the challenge of juggling other priorities, it is essential to have the discipline of desk-time to review progress as a regular diary slot. The start of a week can work well.
- Write highlight reports: borrowed from Prince 2, this is a regular note of what has been done, issues arising, what next to do and a track against key metrics, such as time and budget. Documentation does not need to be wordy.
- Keep a log: the second type of report that I find invaluable despite the most modest of scale is a brief diary-style log of events. Managing suppliers effectively is much easier if you have your own brief record without trawling through emails. And managing your own to-dos too. Link in meeting notes.
- Recognise risk: often an unfamiliar exercise for HR – maintaining a risk register. This just means up-front identification of project risks and giving each a rating for likelihood and impact. Note how you plan to reduce risks and deal with them if arising. Make part of your regular project desk-time a continuing watch of that list.
Tip: when we considered system selection my suggestion was that you carry out a lessons learned workshop from previous implementations and/or other projects carried out internally, whether or not in HR. Post-selection, when devising your own approach to managing the project ahead, it’s a good time to look back at those notes. If you didn’t do that exercise, then do it now!
- Buy in to the business case: in part 1 we looked at how vital the business case is. Keep that visible for yourself. The benefits you identified, against their respective due dates and allocated budgets, are your key baseline tracker tool.
- Consider a critical friend: if you cannot afford a full-time expert project manager, consider engaging a specialist for occasional but regular dates with you as a project mentor, guide and critical friend. This safeguards your dedication to discipline, tops up your know-how and can boost your stakeholder leverage with the weight of objective advice.
Tip: the 7th of 7 principles of Prince 2 is that of “tailoring”. This means adapting method to suit the style, scale and scope of your organisation’s context. Apply tailoring by creating your own techniques, with confidence, that focus on the purpose of project management: Managing is about controlling; projects are about achieving change / Project management controls how that change is achieved, to be sure of the right results. Keep this in mind and your tailored method cannot go too very far wrong! Example: above I suggest you keep a risk register. You could download a template from one of the recognised PM websites and simplify it, asking whether all of the information adds a value, reducing the recipient list suggested or changing terminology to suit you.
And if you are not the internal PM?
Working with the combination of both a supplier and internal PM can prove just as challenging as handling all alone!
In this situation, your stakeholder role is as a type of user. This is the interest you represent. The best ways in which to engage with one or more project management colleagues require you to support the requisite processes for communication and to work to the clear parameters of your own role and team tasks. Understand the PM role to manage and control as distinguished from who is the decision-maker or sponsor – and that could be you.
Importantly, as the lead HR system user voice, make that interest loudly heard.
Success lies in successful stages
The project manager draws up a project plan, which they should then maintain for you.
Project-work that extends over more than a few weeks is probably planned in stages. Whether you use formal, structured or agile methods, to think in terms of milestones and stages is really helpful.
It is most common that at the project initiation (or “kick-off” – and read on) the supplier will gather the facts required to write a baseline plan. The first stage is most likely to be planned in the greatest detail. And this baseline plan they will give to you….
Here I’d like to share 3 clues about working with plans in the context of HR technology:
- You do not need to accept an off-the-shelf plan. Nor do you need to accept the first draft of a plan that is devised for you, even if with the greatest of diligence by your new external PM. You will be aware of an internal context that they are not, such as important dates, priorities, people’s availability and how change is managed most successfully within the organisation.
- Differentiate effort requirement (in days) and calendar time (in days too). To explain: it may take 30 consultancy/team days of effort to complete a work stream. But can everyone work every day? If they do, does the intensity allow enough time for others to test, to learn and to cope with change? Slow it down, space it out. Take a break between phased releases. Plan for this. Please expect a delay between the kick-off meeting date and the start of implementation. Manage expectations here. There will be a lead time for consultancy bookings, which is very reasonable. If you were in their shoes, would you book up your resources until you’d had the commitment from the other party?
- Understand the difference between piloting and testing when you review a draft project plan. A pilot phase must allow time for those involved to feed back to you (as with testing) but also time then to consider, configure and re-pilot any changes that those users suggest. Do you wish for and intend to act upon preferences from your pilot group? Or is it more likely that the project team will intend to make decisions based on their own design preferences anyway?
And that project plan all starts with a first meeting:
Tip: it is extraordinary how often holidays get forgotten. This simple omission could mean the difference of a month or two of progress if you and your supplier do not factor in holiday seasons. Whilst you don’t know ahead of time precise dates, you can guarantee that project team members will take holidays – in discussions about resources, remember these are people! This is for sure a case where to fail to plan is to plan to fail.
Milestone moment – what to expect at kick-off
The first meeting of internal and external project nominees after contracts are signed is often called a kick-off meeting, or more formally a project initiation meeting. Expectations tend to ride too high for this.
It is essentially a terribly friendly hello and a first dive into detailed fact-gathering to allow your system supplier to disappear and come back with a detailed, resourced and (ideally) scheduled plan.
Very unlikely will you come away from the meeting itself with too many answers. If you have done the homework (link to part 4) suggested amongst yourselves then this will help. (I found this article from Mindtools which, whilst not perfect, includes a handy checklist download if you want to create a simple PID).
An outcome will be some form of Project Initiation Documentation (or “PID”). The supplier may well bring a draft to the meeting with the aim that more details can be agreed during and shortly after. This is then signed off.
Key question: what’s in a PID? There is not a fixed format for the document(s) that comprise the PID. It should include: the project outline scope and context, the business case, governance arrangements (roles and responsibilities, communications), budget, timeframes and risks (the constraints), information about methodology, a space for sign-off of the PID. The term Project Charter tends to mean an abbreviated form of PID.
Kick-off is the starting gun and you’re off! The good news is that your supplier team now have a clear onus upon them to deliver to the agreed plans made. Soon the implementation work will start and how to do best with that is coming soon.
Next time we focus on something closer to the HR heart which is the “who is who” of HR technology and getting the right people on board.
Take 1 Step on Step 5! Consider how stages will best serve you: invest a bit of thinking time with your more senior colleagues to determine: the most appropriate pace of rolling out the HR systems, the priority of different modules against the organisational strategy, lessons learned about cultural uptake. How much breathing space do you need between? What else is going on? How much certainty of project vision do you want/need?