My stepbrother is a realtor – a good realtor at that.  He bought and sold our last house, and in this economy, kudos to him.

I remember when we were shopping for that house that in one day he must’ve taken my wife and I to at least 20-30 different houses.  After a while, they all became a blur of bedrooms and basements, and kitchens with islands, and kitchens without islands, and backyards….. Eventually, my wife and I narrowed down the options to 3 houses that we really liked.

At this point, I remember turning to my stepbrother, and asking him which of the three shortlisted candidates he would recommend.  I’ll never forget his response.  He looked at me and said (more or less):

“I can’t make that decision for you.  It’s your house, not mine.  I can point out the number of bathrooms, the carpet, the kitchen layout.  I can provide statistics about the school district….but at the end of the day, that’s not a decision that I can make.”

This is a phenomenon that we as consultants run into every day.  How much of a decision can a consultant make for a client?  How is that complicated when the consultant is reporting to other consultants within the client?  In some organizations where seemingly everyone is a consultant, that begs the question of what exactly defines the organization as a decision making body?

As a consultant, I will admit that’s a tough call.  As a Project Manager though, it’s important to remember that your job is not to make the key decisions regarding scope.  Your job is to present the options with the pros and cons, and costs, and all available data, and allow the project stakeholders to make decisions.  The tricky part however is figuring out what the threshold is for when to kick up those decisions and when to make them on your own.

In a simplistic world, the answers are simple….The PM should be empowered to make decisions as long as they don’t impact the parameters of scope, cost, and schedule – or if the decisions fall within prearranged, predelegated parameters for scope, cost, and schedule variance.  That’s the PMBOK answer, and I agree with it.

But what about seemingly minor scope questions of configuration?  Should I toggle this switch on or off?  What charts should we use to report on our projects?  In an EPM deployment setting, each of those scope questions may not have cost implications, but they do have significant process implications.  So the question really when making a decision as an EPM implementer should be “Am I empowered to make this decision in terms of potential impact to scope, cost, and schedule – and in its potential implications to the client processes?”

Only the process owner, if one indeed has been identified, is the one who can answer that last part of the question.