Whoever you choose should be honest and clear up front about what the sticky points of projects are. Typically I deliver a resourcing curve. Estimated resources for the customer against project resources. Timing and quantity are critical. If as a customer you can’t resource the project how can you expect it to be a success? We are the experts in HCM / WFM, but as a customer you’re the expert for your business.

As the graph above shows, it’s a basic estimation of time (in days) against each phase of the (waterfall) project. At the start of the project, there is some basic discovery, but ultimately nothing really starts happening until the implementation team start configuring. At this point the customer’s resources are not really required. Not until the testing phase in which case the customer should be driving all of the testing with guidance from the implementation team.

You can see the issue with using a typical waterfall methodology which is uneven resourcing on the customer’s side. Some customers want a nice steady line because when their resources are assigned to the project, that’s it until the end. Waterfall can be useful for customer resources who need to do day jobs.

Agile is useful if your customer wants a nice steady line of resourcing where they have segmented responsibilities (ie, the persons engaged with the implementation team are not the one tasked with business change management).

Ultimately the resourcing comes down to cost. Always make sure that you budget enough for your own (or even 3rd party) costs.

Fixed Price contracts are great to control resourcing costs, but there’s a diminishing return. As a supplier, I’m adding extra percentages onto it which are an average of previous implementations time to implement. Some will come in under, some will come in over. If as a customer you’re happy with that percentage, fine, but if you get your ducks in a row up front and go in with your eyes wide open (sorry too many metaphors in one sentence) you should know what it will take and what it will cost.


No WFM project is risk free, from implementing a solution from scratch (moving from excel for example) to adding optimised scheduling or expanding / improving existing solutions. Picking a methodology can be critical in achieving your project aims. Don’t let IT persuade you it’s just a software implementation, it isn’t. I designed one (based on traditional waterfall) below that is simple, clear can be used with existing PM practices (PMP / Prince2 etc…). I plan to write a series of articles on the truth of WFM / HCM Implementations. Not the fuzzy warm fluffy bunny materials that often accompany sales pitches. Anyway…

I recently advised a company about to embark on an optimised scheduling implementation how best to go about the project. I would hope the software company they pick when they finish their tender to advise them of the best practices, but my experience tells me otherwise. I’ve worked on all sides of the fence (Yes Sales tend to sit somewhere else completely), so I hope I know from practical experience what works and what doesn’t.

First things first. What are you goals, aims, objectives of implementing a WFM solution? If they’re not quantifiable, ditch them. If you can’t prove you’ve improved, don’t waste your time attempting to. Ultimately it comes down to


Money, in the form of Payroll Savings from limiting overtime or reduced headcount. However don’t assume optimised scheduling is going to suddenly cut through your payroll bill. Supplying extra labour can improve turnover.

KPI’s with examples being Sales, Customer Service, Turnover, Engagement, Satisfaction (yes all measurable facts).

Baseline what you have. If you have paper based WFM (they still exist), then you should have payroll costs at the least. If you have an existing system, make sure you baseline and use standard KPI’s so you’re comparing apples with apples. Make sure you know the calculations as well as the results.

Don’t use the implementation to change your employee practices, unless you a) have the resources to spare or b) have the experience and knowledge to do it. I’m not just talking about the part where you’re optimising or standardising business rules, but the ‘lets re-contract everyone’ while we try and discover what it is we’re trying to implement. Change before, change after, try not to change during. If you shorten the time to implement, you increase the chance of success. Understand that the project doesn’t just finish when the first manager / employee logs onto the solution. It’s continual, constant.

Business Impact Assessment is a great place to start, looking at how the solution can / will change business practices. If you go from paper to a fully automated solution, you’ve got practical considerations such as training, job responsibilities being changed, removed etc… to take into account. You may have an idea of what will happen up front and a task such as Readiness Assessment will help you to understand.

Business Change Management / Communications go hand in hand. Communicate in short bursts, often. Get the target end users involved as power users and give them responsibilities in the project. How you manage the change can be the difference between a successful project and a perception of a failure. Proving facts and figures of what the system will deliver to managers will not help if they’re alienated throughout the implementation. Your Managers are great and you’re helping them to be greater. If you have problems with your managers deal with it through HR and not a WFM Solution!

And this is all before you start the project.

Take a look at my blog for some more tips!


Welcome to my the professional side of my life!


My name is Kieron Bissett and I’ve been in IT for over 20 years now. I’ve had a variety of roles in my career so far, from an NVQ Assessor to a Network Engineer and a IT Vendor Manager in a number of companies. See my CV for details.

What’s next

Over the coming weeks and months I plan to create blogs based around the following themes:

KISS – Keep it Simple….
Takes from the Past
Not all about the Software
How not to go about implementing a new WFM solution
Example Methodologies for your WFM implementation and why they are key to success.
Cloud Solutions
Employment Wheel of fortune