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.