Managing Expectations

Selecting and beginning a project is always complicated - no matter how well you plan, something will (probably) go wrong. Sometimes, and I'm guilty of this myself, it's easy to get caught up in how great things will be at the end of the project, or once things get up and running. Managing expectations, especially preparing for the worst in the beginning (for me during the transition period) is important.

To start with, I've learned to help keep expectations realistic, it's important to have a thorough conceptualization process that uses tools like decision-making trees to help the customer understand that costs associated with feasibility and requirements studies aren’t necessarily part of the project scope and budget. This work needs to be done before the project to determine what a realistic scope will be, and if it’s even possible to solve the problem while creating value. This should be done in a separate selection process - and I know it sounds intuitive, but I'm surprised by how many examples I've seen where this up-front work somehow gets thrown into the planning stage of the project.

The customer also has to understand that there may be times were a no-go decision is made with “sunk” costs that can’t be recouped. These types of expenses need to be budgeted at the business-level, so that they don’t impair project performance. This basic form of expectations management helps ensure the project team isn’t overloading the initial stages of the project at the expense of execution, and helps the customer focus on the real business need and appropriate solution before the projects are initiated – so we know the deliverable will be acceptable.

Finally, and this is from personal experience, sometimes the transition from where they are to where they'll be (i.e. what you're going to accomplish with the project) is going to have some rough patches. As I mentioned previously, it's easy to get caught up talking about how great things will be when you're done. But to launch into a project without discussing the potential problems (which could be part of a formal risk management plan) is setting the expectation for your client that nothing will go wrong. So when it does, they are completely unprepared and the relationship can quickly turn adversarial.

By managing your stakeholders up-front, and focusing on potential problems and risks, you create realistic expectations and prepare them for the worst. If the project still makes sense, even if some things go wrong, then it's probably something worth doing. Now that you've sort of "under-promised," and the client is not expecting miracles or nothing but blue skies, you've set a solid foundation for the project to progress. By communicating and remaining practical from the start, you also build a rapport with the clients that will be invaluable in the future should problems occur. You'll have their confidence, because they'll know you're working with them, and that they can trust you.

A New Constraint

Going through project management courses, I've become intimately (if not sickeningly) familiar with the so-called "triple constraint" of time (AKA schedule), cost, and performance (AKA quality or scope). The basic idea here is that there is a balance, and a trade-off, between these three factors that is necessary to successfully complete any project. I even remember telling my old clients (back when I was doing some consulting work) that they could choose any two (i.e. time and scope; scope and cost) but their choices would influence the third, which was under my control (i.e. if they wanted to dictate time and scope, then I got to tell them the cost; if they wanted to control cost and scope, they had to work on my schedule). This concept is so ingrained into the project management mentality that I assumed there wasn't much left to discuss about project constraints. So imagine my surprise, fellow thinker, when I learned of a bright, shiny, new (to me at least) fourth constraint - customer acceptance!

Customer acceptance is a constraint that can change the way we view our role as a project manager. It forces us to think outside of technical success and shift to more of an outward focus on customer requirements. In this manner, it also increases the importance of communication and understanding during the conceptualization and planning phases - what good is a project that comes in on-time, on-budget, and meets the design criteria if the customer isn't satisfied?

In a way, this new constraint reminds me of a topic in quality management. Quality is a term that really has two definitions: one is the objective view of how well the product conforms to design standards; however, the more important measure of quality is the subjective measure of how happy the client is with the final product. In projects, the triple constraint is basically the technical criteria. But it's this fourth constraint that adds a subjective perspective and says that a project isn't truly successful unless the client says it is.

The idea of a fourth constraint lends itself to another topic from quality management - Quality Function Deployment. QFD uses the "Voice of Customer" (VOC) to thoroughly and accurately define the requirements of a product. Once identified, those requirements are translated into design requirements, which are then translated into engineering requirements. This flow-down ensures that the "how's" from one level become the "what's" at the next level and sight of the original customer "what's" is never lost.

So the fourth constraint is vitally important to any project team, and serves as a bridge between the technical and the subjective measures of project success. And it's about time that someone has defined this link and clearly articulated the importance of the customer in an existing model. I know that I'm sometimes guilty of focusing too much on the internal aspects of a project. Changing the mindset of a PM to look at all four constraints should have a substantial positive impact on performance.

Value Reversion

So I'm just finishing up a course on cost and value management in projects, and I got to thinking about value creation. More specifically, what types of value do projects create for an organization? My initial thought was that myriad types of value can be created - increased productivity, reduced loss, enhanced brand awareness, improved quality, increased sales, etc. The outcome of a project designed to achieve any of the preceding objectives is an increase in value for the firm.

However, we all know that goals and objectives have to be measurable to be meaningful. And pretty much anything that can be measured can be quantified. Improving quality may be the project objective, but quality has to be defined in real terms, not just as an abstract concept. For example, if quality means less waste, then the performance indicators for your project are the amounts of waste produced. As waste is reduced, value is created.

So if you can quantify the value, won't it always be possible to convert it back into monetary terms? If you're measuring the amount of waste, it's good business to know what that waste is costing you - I mean, that's really the business case for undertaking the project in the first place. The same holds true for any project objective. Viewed in these terms, value always reverts to money. And if you can't revert value back to dollars, I'd venture to say that you either aren't measuring performance correctly, or that the project really isn't creating any value.