Ever cringed when a client, customer or colleague told you at the end of what you thought was a very successful project that it took longer than they thought it would, that they had to do more work themselves than they expected, or that the project cost more than they had planned? It’s even worse when the person posts that opinion somewhere public without talking to you about it. On every project the people you’re working with have expectations before the project even starts. They might not even know they have them until the expectations aren’t met. To successfully avoid these nasty surprises we need to understand our partners’/team’s and our own expectations and assumptions and agree to them right at the start. Sometimes it seems unnecessary, especially for people we work with regularly, but you never can tell what people are thinking. (This holds for personal as well as professional life – ever had cereal for dinner because you expected your spouse to pick something up and your spouse expected you to whip something up? Or suddenly had to make 500 copies by yourself for a PTA project?)

An expectation is defined as “the feeling or belief that something will or should happen”. Unfortunately, talking about ‘feelings or beliefs’ usually doesn’t jump to the top of the list during the excitement of putting together a plan…but it should. We need come to agreement on expectations with our teams at the beginning of the project; after that, we need to address any changes as we go along (hard to do if we didn’t set expectations and clarify assumptions at the start). The best way in most situations is to write them down - it’s easy to misunderstand or misremember verbal communications, especially by the end of a project.

We all have assumptions and expectations – life would be pretty difficult to navigate without them. We get into trouble when we don’t actually know our own or our teams’ expectations and when we don’t talk about expectations with the other people involved in our activities. We have built-in assumptions and expectations, both professionally and personally, that guide and color our work and actions. We also have them per person with whom we interact (for example, personal style/habits/preferences) and per project. Members of our teams have their own sets of expectations, recognized or not. As project managers, we need to learn to identify and articulate our own assumptions and expectations and talk with our teams about them. Gaining agreement that everyone is operating from the same place is important in setting the baseline for any project.

One handy thing is to have a standing list of your usual project assumptions and expectations. These are things like roles and responsibilities, types of tasks you do, types of tasks you expect your team to take on, and communication. These can even be separated by type of project or knowledge of team. After that it’s a matter of identifying your own assumptions and expectations about a specific project and adding them to the list.

After we identify our own assumptions and expectations, discussing them with our team is a good way to open communications and begin to understand what the members assume and expect.

Another good way to ferret out the team’s expectations is to do a ‘4-dials’ exercise with them. The four dials in any project are cost, schedule, scope, and quality. All of these should have goals, but in any project only two can really be fixed (you can either pick the two up front or have things fall through unexpectedly). A discussion with the team sets the expectation that there can be firm limits to two of these but the other two may change (with notification and discussion, of course). Walking through the four areas helps draw out assumptions , sets expectations for both you and your team and gives you some good direction on how to proceed.

Something related that can come back to haunt us are dependencies we haven’t recognized or articulated. In any kind of project, some tasks depend on other tasks. If we don’t lay these out at the beginning of a project (or as soon as the dependency is known), the project (or pieces of it) can slip without warning. For example, if you are planning to have an installer come in to put up shelving in an area that needs to be cleared, the installation is dependent on the clearing being complete. If you’re expecting someone else (your spouse?) to complete the clearing and you don’t make that point early on in the plan you may have an installer showing up and having to reschedule, an extra charge from the installer for waiting around while things are moved, and a slip in the expected time the project takes overall. The dependencies are especially important for any areas not under your direct control – tasks you expect your team to complete, products that may be backordered, third-party work or products, etc. It’s important to note the dependencies and let your team know they exist and what to expect for each if it’s not met. If you have a formal project plan, the dependencies should be incorporated into the task definitions.

Alrighty now, you’ve got your list of assumptions and expectations – the background ones and the project-specific ones – and your dependencies. How to proceed?

• After your initial meeting, pull up your standard lists of assumptions and expectations.
• Get rid of any that don’t apply in this situation (but have them ready as backup in case you get more information that changes the list). Be sure to add the ones that are specific to new clients, teams, or partners if you’re in that situation.
• Think carefully about your expectations and assumptions for this project. Lay them out in a clear, concise list and add them to the baseline.
• Order the expectations and assumptions in whatever way makes the most sense for this team and project.
• Note any dependencies you already know for this project – more will magically appear as you get deeper into the planning, but you can probably already lay out a few.
• Once you have your list you can move forward, discussing with your team and documenting.
• During the discussion, take careful notes and be sure to walk through the four dials. Question the team about their assumptions and expectations and add these to the list.
• Add the results of your discussion to the document you’re building. Be sure to couch things in terms of assumptions and expectations, rather than commitments. This isn’t the place to put delivery dates or costs, just to document your discussion on assumptions and expectations.
• Get the team an updated list and ask for agreement

Review and update the list throughout the project to be sure you’re on track. At the end of the project, be sure to whip out your list and review it with the team so they remember it all and can be impressed by how well you’ve all done!