As a precursor to consulting engagements, project managers are commonly asked to price their projects. But how does one go about pricing a consulting engagement? A common method of pricing is to collect a set of requirements or use cases and collaborate with the individuals who will perform the work. From this collaboration comes an estimated time per requirement or use case. All of this is a good starting point for pricing.
Typically, the next step is to add up all the hours, multiply by the rate(s) of the resources and calculate a price figure. The calculations become more complicated if there are multiple rates, time for testing, project management, and perhaps start up time are added, but one key point, I believe, is missing with this approach.
As project managers, we have all developed a project plan complete with our work breakdown structure (WBS), resources, and dependencies. It is these dependencies and the resulting float or slack that drives the fundamental question for this post. The above approach to pricing implicitly assumes that each resource is utilized 100%, a logical assumption and goal. But we all know that each project has some float/slack in it so all resources spend some time outside of the effort defined in the estimates and are, therefore, not utilized 100%. This additional time consumes budget and rightfully so. The concept of the PERT chart was developed to both highlight and calculate this float.
This is not to say that resources are at times unproductive but they work on items that are not explicitly defined as their task during the times of float/slack. For more senior resources, this can be assisting less experienced resources. Cases can be made to begin a dependent task before the predecessor is complete. Even in those circumstances where all tasks with float are started as their early start dates, these periods of float/slack continue to exist which moves us away from the 100% utilization implicit assumption. This leads me to the conclusion that consultants should base pricing on duration and not effort.
So what do about this since the amount of float on any project is different? We left off above with detailed estimates of either requirements or use cases that were defined by the individual doing the work that remains a good starting point. From this starting point, defining the project schedule is the next step as it will have all the WBS dependencies, define the float for this project, and the timing of when resources are staffed and rolled off the project. From here, I develop a project budget by laying down the staffing plan that defines on a week by week basis what resources are required on a project using the project schedule as basis for which resources are needed at any particular point. Typically, I use a spreadsheet application to calculate on a weekly basis the cost of each resource, then sum the weekly amounts for a project budget and therefore price.
The above approach assumes consultants are 100% dedicated to a project that is almost but not always true. In instances where multiple projects are utilizing the same staff, moving resources between projects will minimize the differences between pricing based on effort and duration. In most consulting engagements, this proves difficult so the duration based approach has worked well for me.
