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.
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:
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.
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:
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.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.