Identifying Assumptions and Constraints - Project Management


An event or action believed to be true. Project assumptions should always be

Remember the old saying about assumptions? Well, throw it out because in project management you want to make assumptions, but here's the key. Are you ready? You should document all project assumptions. You'll want to document assumptions regarding people, resources, places, things, or anything that you presume is going to perform in a certain way, or be available at a certain time, and so on. This is a critical step that's often missed in the project planning process. That's too bad because misunderstanding assumptions, or believing something to be true that isn't, can kill your project.

This is an often missed step because we tend to take things for granted, thus assuming business as usual. When you leave work for the evening (assuming you're driving a car), you walk out to your car, put the key in the ignition, and assume that the car is going to start. It's not really something you think about because the car starts every day—that is, until the day you put the key in and nothing happens when you turn it. Then the diagnosis process begins…battery, starter, alternator…or crisis mode sets in. "Oh my, little Sweet Pea is at day care and I have to be there in twenty minutes!"

Project assumptions work the same way. We're so used to operating a certain way or expecting the A team to drop what they're doing and lend a hand whenever we need it that we don't think about it, until the day they're not available. Don't skip this step—be certain to define and document your assumptions and communicate them to the project team and stakeholders.

Defining Assumptions

Assumptions presume that what you're planning or relying on is true, real, or certain. For example, your project might require someone with special programming skills from the IT department. Your assumption is that this person will be available when needed and will exercise their skill on the activity you assign. Document the assumption that this person will be available when needed. (Oh, it's a good idea to check with that person's functional manager ahead of time to make certain that they will be available when needed.)

Discovering and documenting assumptions works just like the requirements-gathering process. Designate one of your project meetings, or a portion of one of the meetings, to discuss and document project assumptions. Use brainstorming techniques in the meeting to get the juices flowing. You could also interview key stakeholders, the project sponsor, and key members to uncover as many assumptions as you can. Risks are associated with assumptions in many cases, so if you do a good job defining the assumptions, you'll have a good head start on risk identification. Sometimes it's helpful to have someone outside of the project help with this step because they are not as focused on the details as you are. They may see something you wouldn't.
Assumptions might include any of the following:

  • Key project member's availability
  • Key project member's performance
  • Key project member's skills
  • Vendor delivery times
  • Vendor performance issues
  • Accuracy of the project schedule dates

Okay, let's assume that you've documented your assumptions. The next step is to validate and verify them. This means that if you're assuming that a key resource is going to be available to work on the project, you must verify with that person's functional manager that they'll be available at that time.

If you're working with vendors or suppliers on your project, make sure that they document and verify their assumptions as well. In fact, if a vendor delivery is one of your critical success factors, make sure that they document assumptions concerning that delivery. In the Logan Street Move project, we're relying on a moving contractor to show up on the right day with three trucks at each location and enough workers to load everything and get it moved in one day. Consider putting a clause in the contract that says the moving contractor will pay the cost of hiring temporary laborers or leasing rental trucks if for any reason their own trucks are not available (due to mechanical problems, etc.) or their regular work force is not available (a strike, sick-out, etc.). We'll discuss more situations like this when we talk about risk and risk response plans.

Assumptions should be documented in your project notebook. They will be incorporated into the scope statement, as you'll see shortly, but it wouldn't hurt to copy and paste them into their own document and keep them handy. You will want to verify and validate these assumptions throughout the course of the Planning process and whenever necessary during the project Executing and Controlling phases.

Defining Constraints

We talked about constraints in Topic, "Building the Foundation." Remember that constraints are anything that restricts or dictates the actions of the project team. That can cover a lot of territory. The triple constraints—time, resources, and quality—are the big hitters, and every project has one or two, if not all three, of the triple constraints as a project driver. Many projects in the Information Technology area, for instance, are driven by time. Projects in the pharmaceutical industry are driven by quality but may have time or resources as a secondary constraint.

The Logan Street Move project is constrained by time. We must move on March 4. The secondary constraint for this project is budget—there is a limit to how much we can spend. What you want to do now is to document the project constraints. And yes, you can use the same techniques we've already discussed for deriving project requirements and assumptions.

Besides the triple constraints, don't overlook constraints like these that can cause problems on your project:

  • Lack of commitment from the executive management team or project sponsor—I would consider passing on the opportunity to lead a project with this constraint. You'll have a hard time getting support or resolution of problems. Watch out for this constraint because it can creep up on you later on in the project. The sponsor may lose interest because other things have come along that usurp the priority of this project and so on.
  • Business interruptions or reorganizations in the midst of the project—this could potentially realign your project resources, leaving you empty-handed.
  • Stakeholders who have unrealistic expectations of project outcomes— this one is overcome through good project communications and requiring sign-off of the project charter and scope statement documents.
  • Stakeholders' unrealistic expectations of the project schedule—this is also overcome through good project communications early in the project.
  • Lack of skilled resources—this could cause project delays or unfilled deliverables.
  • Poor communications—this is a potential project killer. Misunderstandings regarding scope, activity assignments, project schedules, risks, or a long list of other project essentials could cause uncorrectable problems.
  • Uncertain economic times or business conditions—difficulty obtaining funding for projects, resources for projects, and general economic disturbances could restrict the project team.
  • Technology—advances in technology can cause project delays due to lack of knowledge of the new technology, training needs or availability of training, availability of resources with experience in the new technology, and so on.

Constraints, like assumptions, are also documented in the scope statement. These should be updated as you progress through the project to make adjustments to the constraints you've listed, add new ones that may come up along the way, or delete those that are no longer a constraint. Sometimes you'll find that constraints are also project risks and may need risk response plans.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Project Management Topics