Every good consulting engagement begins with a good written proposal.  Most proposals that I’ve seen include some section somewhere buried amongst the boilerplate which discusses the specific roles and responsibilities of the consulting and implementing organizations.

Typically, the verbiage appears something like the following:

The Consulting Agency Responsibilities:

  • Install the tool
  • Understand the client’s processes
  • Configure the tool to support the processes
  • Identify and mitigate risks

The Implementing Organization’s Responsibilities:

  • Provide the technical environment to install the tool
  • Provide the business processes (and any missing processes identified during the deployment cycle)
  • Confirm that the tool is configured to support the processes
  • Identify and mitigate risks

So what happens when the EPM Consultant shows up on day one to find that the project management processes are still being defined, and that the consultant is expected to take a role in the process definition activity?

As a consultant, I can’t tell you how many times I have heard “Well, since you have so much domain knowledge, YOU tell US what the best practices are.”

…if only it were so simple.  There’re best practices and good practices.  There’re best practices for high maturity organizations and there’re best practices for low maturity organizations.  There’re practices that must be tailored to staffing levels, organizational politics, and basically all of the elements that get lumped into the PMBOK’s “Enterprise Environmental Factors” – or EEF’s.

Sure best practice for construction scheduling is to use Monte Carlo risk loaded schedules with stringent Earned Value and cost tracking systems (unless you’re working with a CCPM consultant).  Try proposing that in some organizations and you’ll be told, “Yeah, great idea, but we’re not ready for it.”

So at the end of the day, there is best practice, and there’s best practice scaled to the constraints of the implementing organization.  It’s the consultant’s job to understand  the organizational processes, the limits of the tool, and the constraints of the organization – then compile all of those together to deliver a tool that adds value to the organization.  That value is often in direct proportion to the level of process definition when the implementation begins.

To paraphrase Rumsfeld, “You go to an EPM deployment with the Implementing Organization you have.”  There’s no one size fits all when it comes to EPM implementations.