In this 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.

At a half-way point in our series tackling the steps to smooth success with HR technology implementation, this part gets stuck into the territory of “in project” mode.

All too often this feels to be the prerogative of your product supplier to lead on, whereas that leadership could and should be yours.

Here is a recap of what we’ve covered so far in this series:

1. In part 1, I underlined the value of the business case as a baseline and compass for you throughout
2. Part 2 helped with a navigation of the HR technology market, hence some of the key choices in system selection
3. This is supported by a guide to the right process for selection, questions which I’m keen to encourage as separate from the choices made within that process
4. Having chosen a product and supplier(s), in part 4 there’s help with the homework you can do to get ready to start
5. How HR professionals can adopt a project mindset to create a control around change and work within project method – that’s part 5
6. Last time I gave you some advice about the types of professionals out there and who to use when and how

Implementation used to take the lion’s share of the calendar timeframe for the adoption of people technologies.

Typically this is still true, although agile deployments as well as increasing complexity of selection choice and integrations begins to change this and it is not necessarily the way of the future.

That said, the building blocks of first phase implementation is where you will need a good deal of your guidance.

The usual way to manage this is to accept that guidance from your product supplier as it’s offered to you during consultancy included in project – and surprisingly unquestioningly. Do not follow your supplier’s lead but lead your supplier!

Generic advice about design and configuration choice specifics is not sensible to give. Each project has a unique context. So this part shows you how to:

• Make contextual choices about configuration
• Work well with consultants (and see part 6)
• Be sure you are appropriately internally resourced
• Avoid the typical mistakes 

Tip: Many of those typical mistakes I see organisations make during a first phase derive from this unquestioning approach to working with advice. Play an active and inquisitive approach to the system design, focusing always on impact of choices. This is not at odds with having great relationships with the consultants and colleagues around you! It is the win-win style of project work.

Configuration and customisation: the choices about design

The larger the scope and scale of your context and the system(s) to be implemented, likely the greater number of detailed design choices to be made.

Beyond the smallest products, little is “off-the-shelf”. Work together with the implementation consultants to make these decisions to be sure that they deliver the right result both at first go-live and with a future-proofing.

Understand the difference between configuration and customisation. Configuration is the use of system design options to allow a natural use of the technology to suit you; customisation is design that is un-natural to the technology to suit you. Customisation modifies the product; configuration does not.

In general, go for design solutions that use configuration rather than customisation.

Customisation:

• Leaves a solution that end-users cannot see nor readily change
• May need updating when the natural product is further developed
• Incurs more costs up-front to achieve
• Support professionals may be less happy about ‘owning’ the project if there are faults
• Suggests you are tending towards replicating what’s gone before in your organisation, rather than using new technology to create more natural processes

That said, there is a place for customisation at times. Just please take care to appreciate when your organisation’s needs really are different from the majority for whom the system has been developed.

Key question: Is it better to design the system as fully as you might want to use it or to keep it simple? Such an apparently simple question is very tricky. More commonly the greater pitfall is to aim too high and achieve too little of it, as opposed to setting lower sights and arriving at to time, to budget and to good effect. Keep it simple and get it right before you move on. But if you do, then set up the project team and Board expectations that there will be a revisit. Avoid the (also common) scenario whereby those good intentions for phase 2 become swallowed up in the day job with a discipline to keep tight hold of diary flags, milestone meetings, allocated budgets – and the invaluable exercise of assessing progress achieved against business case.

The most important thing about system design choices – and the process of making them – is that your organisation is fully understanding of the impact of those choices.

Keep actively asking and exploring.

Tip: Precise blueprinting is of debatable value. Consider if you really have the know-how as a client, before you get stuck into implementation further, to understand the impact of the options blueprinting asks you describe. You could instead focus on securing fuller configuration documentation later on (see below)

Working well with consultants

In part 6 I explained that there are experts available in quite a few differing guises and whichever the choices you make there to resource at the specialist level the project is sure to involve days spent with those experts working alongside you and your colleagues.

The role of the visiting consultant, particularly from the technology supplier and as scheduled as part of that company’s project plan, is often both assumed and unquestioned.

It is however worth considering how to make the most of that consultancy experience in the interests of success.

Here are four key points:

1) Avoid the practical concerns about scheduling and associated costs.

My advice is to press on with an insistence until you arrive at confirmed bookings or availability. Asking for named consultants, ideally with a point of accountability as a lead in that team, helps. Lead times and discontinuity are big industry issues. You need real names and real dates or guarantees.

2) The consultancy value is not limited to scheduled dates or times of work.

Prepare and follow-up well. Give a scope brief in advance (and see tip 4) and note down your own expectations for the day/call/meeting/remote session. Capture the work done by reviewing documentation of the consultant’s design choices.

Agree at the outset on a common understanding that any write-up will take.

3) Use classic interviewing skills

Remembering how vital it is that configuration choices are made appreciating their impact, I appreciate too that here at times you may feel clueless.

Roll out the interviewing skills that are classic for HR professionals! For example, some generic, open and funnelling questions might be:

• “What are the consequences if I take your advice there?”
• “Does that have later implications in other modules or project stages?”
• “Where else will that issue come up? Where else will I see that appear?”
• “Why do you tend to advice choice A over choice B? What if I were to take the opposite option?”

The half-decent professional will explain nearly as far as you need, but many not quite. Unfortunately, some not at all.

4) Your consultant is your friend!

Be conscious if you find your approach unhelpfully bipartisan. Sometimes it can feel that, as consultants, we are being put to the test by our clients.

You, your colleagues and your consultancy team are all human and to get the best out of all we can all be encouraged to do our best for you.

Tip: Try not to tie consultants up with meetings. Bear in mind that every hour spent in meetings or update calls is an hour not spent applying that specialist time elsewhere. Much meeting time proves to be for internal debates. Strike an effective balance between making sure the right people are updated and decisions made in the right forums and allowing those appointments to crowd an expert’s diary.

In practical terms, I recommend staying with the consultant if onsite for as much of the work done as viable. Work together.

Internal resourcing…..

……where six of one can become half a dozen of the other

The article about the project resourcing offered a checklist of the internal skills you will need to cover.

Later in the guide I’ll address more about how to engage stakeholders too. Quite a few implementation difficulties arise due to internal resource management:

• Underestimating the overall effort required in hours leads to “our end” delays. Seek guidance about time to be put in. Allow a contingency in making that time allocation. Note the difference between the passage of calendar time for your team and working days that apparently fall between consultancy jobs done by others.
• Taking a short-term view in your resourcing to cover the project plan timeframe only makes it very hard to end a reliance upon external help with intensity. This should taper off. That means from the start working out the HR system support role(s) needed. [In final articles I will look at whether self-sufficiency is the right aim for your BAU.]
• Over-involving the project team ties your operations up in knots and results in much time wasted; under-involving nominated project team secondments is demotivating. I suggest asking individuals whether they are involved enough for their liking. If someone wants more, then use delegation as an opportunity to step aside rather than double-up. That is the strong vote not the cop-out!

Don’t allow concerns you have for external help become just as much your in-house problem.

A few more tips….

• Recall how best to use the project plan. This is your plan. As you work through each project stage and plan the next, be led by the pace you know that your organisational context can cope with absorbing. You do not need to accept something that is off-the-shelf
• Discuss analytics (MI or reporting requirements) from the start. If the implementers understand the design of the data you are going to want out then they can advise you to make sure that the data goes in such as that’s possible
• Reporting is an example of a part of your HR technologies that conceivably it may be right to adopt a tool other than your core HCM solution. At the time of writing, the capabilities of various product types is such that it is no longer always true that the fullest use of a core system’s internal integrative offer is right for you. [Look back to a navigation of the market for more on that point.] If you aim to avoid (a) manual process (just ask your payroll team about retrospection to understand why!) and (b) too much customised design then there can be creative, automated solutions less obvious. Of course you’ll need to ask the experts outside of your core supplier’s team if you have a clue that this could be true

Key question: How much comes “out of the box”? What if I want or don’t want “vanilla”?

These phrases I have heard a lot from clients introducing their aims for implementing HR technologies. Most often the motivation in the ask is ease, speed and cost control. Sometimes I’m admiring that the question comes from a real desire to hear about “best practice” from an objective view, unfettered by the past.

From the supplier side, look out for phrases like “pre-configured” or “business pack” (and as these become well-worn companies invent new words to promote similar concepts). More informally techies talk about things being “pre-canned”, “pre-shipped” or even the old “plug’n’play”.

Systems differ in how much is already set up for you. The simplest cloud solutions, delivered on a SaaS basis, include few remaining choices. If you are working with a more complex product then expect nothing out of that box and to receive an empty shell to populate with, for example, organisational structure, processes and much page design. Likely there will be some default examples of design, such as a recommended set of security profiles to be cloned.

Evolving from this empty shell, suppliers have created associated products – available to you at lower cost – which include some of the configuration done for you. This limits your options, but yes it does reduce cost and time to go-live. You can establish the facts with surprisingly simple questions about how many default profiles, reports, processes etc are available to you and how many options you have left.

In short, avoid buzzwords without exploring just what is meant.

Step 7 in short!

This part provides some building blocks that smooth you to success in implementation.

It’s deliberately placed halfway through this series because it’s vital that you regard tips here in also applying the concepts introduced about:

• How to work with project method
• How to work with technology professionals
• How to work with your data
• How to design your processes    

An important thread is the ownership you can take of your implementation phases. Do not step back from being the leaders of your own new change mission, assuming that it can be done for you. You risk the right result.

A first-stage implementation can span 12-18 months and even those most agile in deployment are likely to be working for a good quarter year period.

Consider the number of decisions that will be made along that way. Make those your decisions. That is why I offer tips about an approach rather than advising you to adopt a process that looks like this, to buy this particular system or to tick this particular box if you do.

Context is everything.

Use the tools to their best advantage – configure naturally. Work as partners with consultants during their visits, documenting carefully and securing an internal team set up for ongoing in-house know-how.

Some of the particular questions during early implementation still warrant closer attentions.

Next time I’ll look at the requirement to test and pilot – the types of testing and the what, who and how of each.

Take 1 Step on Step 7!

As you work with the experts, nail your own way to understand the impact of design choices you are making. There is no harm in your form of a stuck-record technique for doing this, to get to the bottom of the effect of choosing between options put to you.

Data objects, process or structure design elements rarely sit in isolation – behind the scenes configuration choices have an effect back to links between and data contained in data tables. That’s why understanding impact is so key.

I have given some suggested opening questions above. Probe into the effect, for example, on field visibility, security, other processes, system space left available, reporting, upgrading and support.