Hi Bill, Really informative and rich content. after viewing the video I seek some clarifications and wish to ask some queries. If you read this comment and have some time then, please throw some light. I want to ask in an SDLC context. Clarification: In the section of technical constraint (time elapsed of the video 9:54), where you say that you want this video to run on all media platforms, you also correctly mention that it is a technical requirement, so as a developer of the company I know that the video can't be run on certain devices like a PSP, so it would be correct to write about this fact in the technical constraint? Query: Q1. Can Assumptions be classified in any way like you have classified the constraints into business and technical? Q2: Is it correct to say that all three (Ass, Con and Dep) are out of the control (direct or indirect) of the PM? Q3: Example: As a website dev company X, when I say that for the website to load and run properly, the user must have a min internet speed of 256 kbps, the user must have IE 8 or above, etc, then under which head these statements should be put, assumptions, constraint or dependency? I choose internet speed to explain what I am thinking - if I say it is an assumption it seems to be correct as this is not under my control, but when I think deeper, it comes out that it can also be a constraint, because if the user does not have a specified speed then the website will not load. Also, we can say that loading of the website is dependent on the internet speed of the user, so it becomes a dependency (external). Please take me out of this loop, where I am thinking each factor can be classified under Assumption, Constraint, Dependency Many Thanks in advance! Manish
Hello, Manish, I will do my best to answer your questions below: “Query: Q1. Can Assumptions be classified in any way like you have classified the constraints into business and technical?” Q1: Yes, there are many different ways to categorize assumptions. Remember that assumptions support the decision making process of your document - so categorize them in a manner that allows you to logically work with them in your document. For example, you might choose to categorize assumptions depending on how they impact your document - those that impact your schedule planning, budget planning, or scope could all be grouped together. This might be a logical way to think of your assumptions - lots of other valid ways also exist. “Q2: Is it correct to say that all three (Ass, Con and Dep) are out of the control (direct or indirect) of the PM?” Yes, constraints and dependencies are usually out of the control of the PM and it is important to highlight them and to describe how they have had a direct impact on the planning process. Identifying them will help to build the reader’s confidence in the plan, and will help the reader to understand why the plan was developed the way it was. (Remember that simply not listing a constraint or a dependency does not make it go away!) Assumptions represent a best understanding of the relevant project trends. The trends themselves are outside the direct influence of the project manager. The PM does not know for sure if a particular trend is relevant and valid, but by making an assumption on how the trend will impact the project, it allows the PM to proceed with the planning process. “Q3: Example: As a website dev company X, when I say that for the website to load and run properly, the user must have a min internet speed of 256 kbps, the user must have IE 8 or above, etc, then under which head these statements should be put, assumptions, constraint or dependency? “I choose internet speed to explain what I am thinking - if I say it is an assumption it seems to be correct as this is not under my control, but when I think deeper, it comes out that it can also be a constraint, because if the user does not have a specified speed then the website will not load. Also, we can say that loading of the website is dependent on the internet speed of the user, so it becomes a dependency (external). Please take me out of this loop, where I am thinking each factor can be classified under Assumption, Constraint, Dependency” You can look at this issue from several different perspectives, and you are right that you can go around in a circle if you are not careful. My recommendation would be for you to think about it from a planning perspective - ask yourself: Why do you need to point out the 256 kbps minimum speed limitation? Why is it relevant to the planning process? How does it affect the planning process? Considering its impact and how you use this information will help you to determine if it is a constraint, dependency, assumption or if it exists as multiple things. Let your categorization of the information be determined by how you plan to use it within the document - if you need to use the information in different ways, then it can be included in different categories. Let’s look at the bandwidth limitations from a number of different perspectives: CUSTOMER REQUIREMENT: The customer may have specified a required bandwidth range for the application. If so, then this is a customer requirement that you need to accommodate. (Initial customer requirements are usually identified in the project charter or statement of work.) ASSUMPTION: Selecting the ideal bandwidth range might be an assumption. (Bandwidth often determines what functionality the application can have.) Thus you may have had to make an assumption as to the bandwidth range that you think is most likely used by the potential user base. Clearly, in the absence of reliable customer survey data, you have to make some kind of assumption as to what bandwidth to target your application for. CONSTRAINT: Depending on who imposed it, this limitation might be a constraint. Key functionality that is critical to your application might only work in certain bandwidth ranges - therefore, the operational bandwidth requirements of this key functionality becomes a project constraint that has been imposed upon your project by whomever created the application’s development environment. REQUIREMENTS: The limitation might represent a technical requirement. If one of the acceptance criteria for the project is for your application to work with a specific set of users, then the ability to synchronize with these specific slow bandwidth computers becomes one of the project’s technical requirements. DEPENDENCY: If these slow speed users can impact the success of the project, then they represent external stakeholders (dependencies) that need to be managed. Identifying these users as dependencies might mean that they have to be included in the project communication management plan or in some other section of the plan. RISK: It’s possible that slow speed users might constitute a risk to the application (of some kind), and therefore require the PM to create some type of a mitigation strategy. So there you have it - the same information can be viewed from several different perspectives, and in doing so (potentially) provides more insight into the development of different areas of the plan. Remember: It’s OK to use project characteristics in multiple places within your project plan, as long as each time they are included they provide useful insight into the planning process. I hope that this helps. Bill Bowen
Hi Bill,
Really informative and rich content. after viewing the video I seek some clarifications and wish to ask some queries. If you read this comment and have some time then, please throw some light.
I want to ask in an SDLC context.
Clarification:
In the section of technical constraint (time elapsed of the video 9:54), where you say that you want this video to run on all media platforms, you also correctly mention that it is a technical requirement, so as a developer of the company I know that the video can't be run on certain devices like a PSP, so it would be correct to write about this fact in the technical constraint?
Query:
Q1. Can Assumptions be classified in any way like you have classified the constraints into business and technical?
Q2: Is it correct to say that all three (Ass, Con and Dep) are out of the control (direct or indirect) of the PM?
Q3: Example: As a website dev company X, when I say that for the website to load and run properly, the user must have a min internet speed of 256 kbps, the user must have IE 8 or above, etc, then under which head these statements should be put, assumptions, constraint or dependency?
I choose internet speed to explain what I am thinking - if I say it is an assumption it seems to be correct as this is not under my control, but when I think deeper, it comes out that it can also be a constraint, because if the user does not have a specified speed then the website will not load. Also, we can say that loading of the website is dependent on the internet speed of the user, so it becomes a dependency (external).
Please take me out of this loop, where I am thinking each factor can be classified under Assumption, Constraint, Dependency
Many Thanks in advance!
Manish
Hello, Manish,
I will do my best to answer your questions below:
“Query: Q1. Can Assumptions be classified in any way like you have classified the constraints into business and technical?”
Q1: Yes, there are many different ways to categorize assumptions. Remember that assumptions support the decision making process of your document - so categorize them in a manner that allows you to logically work with them in your document.
For example, you might choose to categorize assumptions depending on how they impact your document - those that impact your schedule planning, budget planning, or scope could all be grouped together. This might be a logical way to think of your assumptions - lots of other valid ways also exist.
“Q2: Is it correct to say that all three (Ass, Con and Dep) are out of the control (direct or indirect) of the PM?”
Yes, constraints and dependencies are usually out of the control of the PM and it is important to highlight them and to describe how they have had a direct impact on the planning process. Identifying them will help to build the reader’s confidence in the plan, and will help the reader to understand why the
plan was developed the way it was. (Remember that simply not listing a constraint or a dependency does not make it go away!)
Assumptions represent a best understanding of the relevant project trends. The trends themselves are outside the direct influence of the project manager. The PM does not know for sure if a particular trend is relevant and valid, but by making an assumption on how the trend will impact the project, it allows the PM to proceed with the planning process.
“Q3: Example: As a website dev company X, when I say that for the website to load and run properly, the user must have a min internet speed of 256 kbps, the user must have IE 8 or above, etc, then under which head these statements should be put, assumptions, constraint or dependency?
“I choose internet speed to explain what I am thinking - if I say it is an assumption it seems to be correct as this is not under my control, but when I think deeper, it comes out that it can also be a constraint, because if the user does not have a specified speed then the website will not load. Also, we can say that loading of the website is dependent on the internet speed of the user, so it becomes a dependency (external). Please take me out of this loop, where I am thinking each factor can be classified under Assumption, Constraint, Dependency”
You can look at this issue from several different perspectives, and you are right that you can go around in a circle if you are not careful. My recommendation would be for you to think about it from a planning perspective - ask yourself:
Why do you need to point out the 256 kbps minimum speed limitation?
Why is it relevant to the planning process?
How does it affect the planning process?
Considering its impact and how you use this information will help you to determine if it is a constraint,
dependency, assumption or if it exists as multiple things. Let your categorization of the information be determined by how you plan to use it within the document - if you need to use the information in different ways, then it can be included in different categories. Let’s look at the bandwidth limitations from a number of different perspectives:
CUSTOMER REQUIREMENT: The customer may have specified a required bandwidth range for the application. If so, then this is a customer requirement that you need to accommodate. (Initial customer requirements are usually identified in the project charter or statement of work.)
ASSUMPTION: Selecting the ideal bandwidth range might be an assumption. (Bandwidth often determines what functionality the application can have.) Thus you may have had to make an assumption as to the bandwidth range that you think is most likely used by the potential user base. Clearly, in the absence of reliable customer survey data, you have to make some kind of assumption as to what bandwidth to target your application for.
CONSTRAINT: Depending on who imposed it, this limitation might be a constraint. Key functionality that is critical to your application might only work in certain bandwidth ranges - therefore, the operational bandwidth requirements of this key functionality becomes a project constraint that has been imposed upon your project by whomever created the application’s development environment.
REQUIREMENTS: The limitation might represent a technical requirement. If one of the acceptance criteria for the project is for your application to work with a specific set of users, then the ability to synchronize with these specific slow bandwidth computers becomes one of the project’s technical requirements.
DEPENDENCY: If these slow speed users can impact the success of the project, then they represent external stakeholders (dependencies) that need to be managed. Identifying these users as dependencies might mean that they have to be included in the project communication management plan or in some other section of the plan.
RISK: It’s possible that slow speed users might constitute a risk to the application (of some kind), and therefore require the PM to create some type of a mitigation strategy.
So there you have it - the same information can be viewed from several different perspectives, and in doing so (potentially) provides more insight into the development of different areas of
the plan.
Remember: It’s OK to use project characteristics in multiple places within your project plan, as long as each time they are included they provide useful insight into the planning process.
I hope that this helps.
Bill Bowen
Thank you so much for explanation.
Muhsin Kassem