About Assumptions, Constraints and Dependencies

Related Articles

Business case document (Banking CRM System)

5 hours ago

CRM for Banking Secter

5 hours ago

Q2. What are project priorities? Why this is important? How to handle this?

1 day ago

• ASSUMPTIONS:

An assumption is something an event that is believed to be true and which can expect to happen during a project which does not have any proof, though they can be turn out to be false. It can expect during the project life cycle. To move forward with in the projects there were some assumptions should be made. Documenting the assumptions and managing them is an important and the next step is to verify and validate them. Some assumptions may affect your project significantly and they add risks to the project because they may or not be true.

 

Managing assumptions in projects can be solve in 5 steps:

 

1. Define

There were some assumptions you should definitely need to define. You will come to know that you will have to make a lot of assumptions during the course of a project.

2. Assess

Make a list of all project assumptions and prioritize them. Which assumptions are almost 100% certain to occur, and which are less certain? The whole project team should be involved in this step as they can contribute the accurate assumptions. There are two factors on which you can assess an assumption:

• The probability of its occurrence
• It’s possible impact on the project.

3. Document

Assumptions should be written down in the project initiation document, along with the project constraints and dependencies. This will help you keep an overview of all aspects that might restrict your projects.

4. Monitor

Documenting assumptions also enables you to monitor and control them better. Assumptions are often true, but that doesn’t mean that they can’t turn out to be false during the course of the project. Remember, that assumptions are not facts. You need to constantly track and monitor assumptions.

5. Review

As assumptions are based on experiences, we have to review them at the end of the project.

• Which assumptions are true?
• Which assumptions had the biggest impact on the project’s outcome?
• Which turned out to be false and had to be dismissed?

Answering these questions will help you make more accurate assumptions in future project.

 

• CONSTRAINTS:

Constraints are limitations used on the project, limitations such as cost, schedule, or resources, and you have to work within the boundaries restricted by these constraints. All projects have constraints, which are identified and defined at the beginning of the project.

 

The PMBOK Guide recognizes six project constraints:

1. Scope,
2. Quality
3. Schedule
4. Budget
5. Resource and
6. Risk.

Scope, schedule, and budget are combiningly known as the triple constraints among the six project constraints.

 

Constraints are of two types:

1. Business Constraints
2. Technical Constraints

Business Constraints:

Business constraints depend on the state of your organization; for example, time, budget, resource, etc.

Technical Constraints:

Technical constraints limit your design choice.

For example, let’s say you are constructing a website for the client purpose, and according to the design your maximum visit to the page is 10 million, if that number of visitors exceeds then there will be technical issues. This limit here we can call as constraints.

Note: From above definitions, we can say that Assumptions need to be analyzed and constraints are needed to be identified.

 

• DEPENDENCIES:

 

A  Dependency describes a relationship between two tasks in which one task depends on the finish of another task in order to begin.  Dependencies can be created between two or more tasks, tasks and tasks groups or between two or more task groups.

There are four types of project planning dependencies. They construct the relationships among the tasks.

• Finish To Start (FS): The first task must complete before the second task can start.

For example, imagine you’re building a house and start with building the roof, then you build the walls, and only then you start with the foundation.

• Finish To Finish (FF): The second task cannot finish before the first task finished.

For example, we cannot finish reading a book before we finish reading the last its chapter.

• Start To Start (SS): The second task doesn’t start until the first task starts.

For example, the task “write training manual” must start before the task “write chapter 1 of training manual” can start.

• Start To Finish (SF): The first task should start before the second task can finish.

For example, new shift of a security guard starts working at a factory after previous one has finished.