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.
Our series has taken you end-to-end through how to deliver smooth success with HR technology implementation, from business case and project inception to a supported go-live and early days phases.
This final part addresses something which there is little guidance out there about: managing the mid-contract and that which is called ‘BAU’ (Business As Usual).
Here I answer some neglected questions:
- What is the difference between project and BAU? What can change?
- What should you be doing mid-contract to get the best out of systems?
- How do you know if you’re getting the best from your system?
I look at tips on keeping up your vigilance, securing sufficient resources and how to revisit the benefits of your technologies.
Finally, I will recap on the series and point you towards some key reflections.
Tip: I refer to the ‘myth of mid-contract’. Think about time-frames. Typical licence terms are for three years. Many implementations extend well beyond six months in large organisations, certainly when the time taken for new roles to bed down is included. You should begin considering ‘what next?’ at least 12 months ahead of expiry with a revisiting of benefits and business case. Spot the squeezed middle!
What is the difference between project and BAU?
At the beginning of the ‘Smooth Steps’ series I explained that projects achieve change; they have a defined start and end point. This is the academic difference between moving out of project and into an consistent operational running.
Academics are a pretty ineffectual currency when it comes to working with people technology! Many of the tips in this series show you that success is all about a combination of planning and method, know-how and working well with people.
In practice, after a project ends behaviours change:
- Suppliers provide services on a different basis
- Internal project team members move back to day jobs – they have less time
- End-users take systems for granted
The common thing to notice here is a shift in attention. This can impact the business with creeping costs, poor support and decaying functionality. Tricks can be missed by missing updates. Perhaps the most unfortunate outcome can simply be that intended benefits are never realised – and no-one notices.
Tip: One of my leading consultants likes to warn those he works with about a sense of loss among internal project team members once a project is formally over. Be mindful of this among your team, because they might well feel daft piping up about it.
How do you avoid the impact of mid-contract inattention?
Your four strategies are:
- Maintain good system housekeeping
- Secure sufficient resource for supporting the system
- Keep in touch
- Revisit the benefits
One role of a system administrator is to safeguard system housekeeping, keeping things tidy. This is best understood as maintaining a notional (or real) checklist of watch-points as to whether things are getting messy. Your product supplier should offer you advice (and not just about new releases) about the best practices to follow to maintain system efficiency.
There is another kind of efficiency and that is in the ongoing development. Make sure this is congruent and planned. Develop; don’t tinker.
Key Question: At headline level, what should you be looking out for? Are you noticing the use of extra spreadsheets off-system? Are your functional teams describing work-arounds and manual calculations? Does there seem to be a lot of effort involved in any one process? Are you confident that management information provided is actually used? Is there out-of-date information or configuration that is not archived or erased? What are the continuing complaints and bug-bears?
I would not rely on standard updating that product suppliers, whether in a SaaS arrangement or on premise, carry out in the natural course of system update. You need to look at your own use of the HR technology, such as your processes and your team roles too. Extra configuration or integration that you implemented in-project needs updating too. And then there is your data.
Securing sufficient resource
When your organisation moves out of project, your external project team goes away from you. This may seem obvious to point out but consider the implications:
You must make a fresh contact if you need help, which means working with new names – new people to give your background to and with new views. Unlikely it’s yet been paid for. Unlikely you have a guarantee of availability and lead times are often several weeks to access consultants. In part 11 I explained the limitations of most helpdesk support. Some service providers overcome this with excellent managed service plans and this is one way to crack that nut.
Another style-shift you’ll notice from product companies is that you will be asked to form a new relationship with an account management or customer care representative (job titles of course vary) rather than a project manager. In general, these professionals are equipped to spend less time on your account and are less able to provide immediate answers. There are exceptions and some excellent practitioners and service styles.
In summary, not least if your contract involves milestone payments, your technology provider may be rather more keen to move beyond project than you are!
Tip: Although there are negatives for you as a customer in moving out of project mode, be aware that there are likely some hidden advantages. Effectively as a customer you become more ‘free’ of some implementation terms or practices that may not be suiting you. You may lose access to capital (as opposed to operational) funds. And don’t underestimate the pressures and importance of internal politics and PR in achieving timely goals.
Assuming you now need to go it alone, you need clearly defined people to take care of maintaining the system.
Last time’s focus was much about the role of a super-user. One type of super-user is a system administrator, or system analyst. It is a common mistake that the case for one or more salaries to cover this is over-looked and underestimated.
System administrators should cover your good housekeeping. Will they also cover user support and guidance? Are they skilled to provide the pure application support from an IT perspective? Does their role include business intelligence too? Do they have operational day jobs, such as in payroll or HR transactions, as well? These questions form the basis for your justification of a headcount.
These functions you can:
- Outsource
- In-source (typically to an adept IT team)
- Resource within the HR operational team
One of the most significant factors to consider about being sure of adequate resource is that of business continuity. A problem with system administration roles is that – particularly in mid-sized organisations – they can become a single point of failure. And of flight risk.
Never accept a situation where you are aware you are dependent on one person’s uncaptured knowledge. Safeguard this with documentation, on-boarding for super-users, aiming for the fullest of automation and keeping a wider network.
In this series, we have already looked closely about how to make the most of being part of a user community and keeping in touch.
Key Question: how big do you need to be to employ an HR system administrator or analyst?
How many FTE do you need in these roles in relation to your organisational size and employee numbers?
This is a question that independent consultants are often asked because managers do struggle to make their case. One tip is to make sure you do so as part of considering the Total Cost of Ownership and in your business case – get it covered as part of the up-front internal deal!
I feel comfortable offering a clue that it is above about 1,000 employees that typically there is a sure need for someone dedicated. But a more important factor when it comes to pure application, as opposed to user, support is the breadth of business functions that you are using the system for. For example, if you are live with a fully integrated product suite and self-serviced by end-users then you have a much heftier requirement than for supporting a system just used within the HR team for core HR and payroll.
Whilst there does tend to be an approximate direct correlation between employee numbers and system team FTE, I challenge you if you are not seeking to make economies on scale.
This leaves your fourth strategy to avoid the impact of inattention in the BAU:
Revisiting the benefits
Ideally at project inception, prior even to initiation, there is an exercise performed in an analytical way to identify the benefits of potential HR technology. [Part 1 covers getting started in this way with advice on business case, including examples of the benefits referred to below.]
A firm piece of advice for mid-contract is to review whether or not those benefits have been achieved.
You should identify milestone intervals with which you wish to do this. I recommend a first review in the first six months of post-project use and at least one more before you begin to consider licence renewals or another tender and selection process. This assessment is often called ‘benefits realisation’.
How do you go about assessing whether benefits have been achieved?
Assuming that you do not have the model baseline analysis simply to return to and tick-off, then likely you are in a position of needing to assess how well your HR system is working for you from scratch. There are templates out there for benefits realisation analysis. Try this straight-forward approach:
- Identify benefits that you can quantify (cashable/financial)
- Translate each of these into the same currency (money!). [Many people stop at this stage but you should move on] but
- Add benefits you cannot quantify. Things that cannot be measured may be less easy to manage but they do not disappear!
- You most likely will wish to categorise these benefits (for example: by module or business unit)
- Spread these across the lifespan (to-date and anticipated) of the HR system
- Total the benefits achieved per period. Some will remain as qualitative comment and you could always apply a H/M/L sense-check on their importance
- Offset against costs. Consider the full system TCO
- Compare this return, both as a sum of return and at item level, to your expectations. If you did not baseline your intended returns, then apply your nous about whether stuff is good enough!
- Conduct an associated re-assessment of outstanding risk. Do not congratulate yourself for past risks that did not materialise, because these what-if scenarios do not affect the ongoing position
Key question: why bother with revisiting the benefits?
Analysing methodically whether your HR system is working for you gives you evidence you need to take corrective action. Success makes for a great PR story. If by contrast you find you were over-optimistic in the beginning and outcomes have not been so great, then taking stock and examining the evidence allows you to intervene.
Intervene by, for example, putting together a plan for next development work or changing models for supporting resource. Find the system waste that is caused by poor housekeeping. Raise new business questions about the scope that you aim for. Ask amongst the user community about your options.
I use an analogy which may be useful to you about benefits realisation:
“Looking at the weather forecast does not bring on the rain!”
Do not be an ostrich.
Step 12 in short
Whilst there is a real difference between project-mode and BAU, this can lead to a dangerous ‘myth of mid contract’, which assumes that all can afford much less attention to your HR technologies.
There are sensible ways in which you can maintain a vigilance to optimum performance, including practices of good housekeeping, appropriate resourcing and playing an active part in the user community. Carry out planned re-assessment of benefits and keep an eye on the licence and contract timeline.
It can be difficult to acknowledge project disappointments but to do so gives the opportunity and impetus to improve and develop. And if success is 100% then enjoy an enormously positive story-telling.
Take 1 Step on Step 12!
Clarify operational roles. Who:
- works with product supplier’s advice to support the system application?
- offers direct first-line user support?
- provides your business intelligence and analytics?
- carries out functional roles as super-users?
- keeps in touch with the business, managing stakeholders?