![\"Project](\"https:\/\/plaky.com\/blog\/wp-content\/uploads\/2022\/12\/Project-assumptions-cover-1.png\")
<\/figure>\n<\/div>\n\n\nWhat are assumptions in general?<\/h2>\n\n\n\n
They say it\u2019s rude to assume, but this isn\u2019t always<\/em> the case.<\/p>\n\n\n\n We make unrude assumptions all the time \u2014 assumptions that are essential to our everyday lives and that we couldn\u2019t properly function and keep our sanity without!<\/p>\n\n\n\n In case you think this is an exaggeration, here are some examples to convince you otherwise:<\/p>\n\n\n\n But, are you wrong to assume any of this? <\/p>\n\n\n\n No!<\/p>\n\n\n\n You make these assumptions because you have no reason not to. If we questioned these assumptions at all times, we\u2019d all be:<\/p>\n\n\n\n It was important to first explain how we can\u2019t function without everyday assumptions because project assumptions are basically the same thing as assumptions in general \u2014 only project related.<\/p>\n\n\n\n The definition of project assumptions in the Project Management Body of Knowledge (PMBOK\u00ae 7th Edition)<\/em><\/a> explains them as \u201cfactors that are considered to be true, real, or certain, without proof or remonstration<\/em>.\u201d<\/p>\n\n\n\n In other words, project assumptions are things we assume will be the case when pitching, planning, and managing a project.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This list could go on. <\/p>\n\n\n\n The key takeaway is that assumptions are necessary for project planning.You just have to be aware of which assumptions you\u2019re making.<\/p>\n\n\n\n Reading the definition of project assumptions in isolation makes it seem like assumptions are straightforward, but \u2014 in practice \u2014 they are often confused with other project management terminology, most notably:<\/p>\n\n\n\n To help you distinguish between assumptions, constraints, and risks, let\u2019s look at the definition of each and see where the key differences lie.<\/p>\n\n\n\n If you wanted to argue semantics, you could say that project constraints \u2014 time, budget, and scope<\/a> \u2014 are just assumptions.<\/p>\n\n\n\n We assume that these limited resources (budget) will enable us to do the work (scope) necessary to create the final deliverable<\/a> before the designated project deadline<\/a> (time).<\/p>\n\n\n\n But project management isn\u2019t a place for arguing semantics \u2014 clear boundaries must be drawn for both assumptions and constraints to be used in project planning and documentation without causing confusion.<\/p>\n\n\n\n Once again, we will default to PMBOK\u2019s definition of project constraints, which describes them as \u201climiting factors that affect the execution of a project<\/em>.\u201d<\/p>\n\n\n\n It follows that the key difference between project assumptions and project constraints \u2014 as they are understood by the majority of the project management world \u2014 is that constraints define and impose project boundaries:<\/p>\n\n\n\n Project assumptions, on the other hand, don\u2019t define the project\u2019s boundaries \u2014 regardless of whether they\u2019re correct or incorrect.<\/p>\n\n\n\n For example, when you decide on a vendor, you\u2019re making an assumption that they will be able to provide the things you need to keep the project moving. This is not an unreasonable assumption \u2014 the vendor wants your business (and they likely have a penalty clause for late deliveries in their contract).<\/p>\n\n\n\n But none of this guarantees that their deliveries will arrive on time. Whatever the reason \u2014 supply issues, price spikes, or the vendor closing shop \u2014 late deliveries will cause delays in your project schedule.<\/p>\n\n\n\n This, however, won\u2019t necessarily affect your deadline \u2014 you\u2019ll just have to find a way to get the project back on track<\/a>.<\/p>\n\n\n\n \ud83d\udca1 Plaky Pro Tip<\/strong><\/p>\n\n\n\n To learn more about project constraints and get some examples and tips on how to manage them, check out this guide:<\/p>\n\n\n\n We can define a project risk<\/a> as anything that has the potential to impact a project, both in positive and \u2014 more often \u2014 negative ways.<\/p>\n\n\n\n These impacts could range from inconsequential to catastrophic (or fortunate, should the pendulum swing in the other direction). <\/p>\n\n\n\n In extreme cases, the impact of a negative risk can be so severe that shutting the project down is the best response plan.<\/p>\n\n\n\n While still not synonymous with one another, project risks bear a much closer resemblance to project assumptions than project constraints do.<\/p>\n\n\n\n They\u2019re both things that may or may not happen that can affect the project.<\/p>\n\n\n\n The main difference is in our attitude towards them:<\/p>\n\n\n\n A lot of the time when we make assumptions, we don\u2019t do it consciously.<\/p>\n\n\n\n You don\u2019t actively think to yourself: \u201cHmmm, I\u2019m sure electricity won\u2019t go out at the office tomorrow. It\u2019d be weird if that happened<\/em>.\u201d <\/p>\n\n\n\n No, you just assume, subconsciously.<\/p>\n\n\n\n But, unlike regular assumptions, project assumptions have to be stated<\/strong>. Ideally, they should even be written.<\/p>\n\n\n\n This is because you don\u2019t know that other stakeholders<\/a> aren\u2019t making different assumptions about the same thing.<\/p>\n\n\n\n Maybe the project sponsor and project manager<\/a> assume that different features should be given the highest priority.<\/p>\n\n\n\n To make a plan based on different assumptions like this is to set the plan up for failure.<\/p>\n\n\n\n Therefore, it is crucial to identify and manage project assumptions.<\/p>\n\n\n\n We can borrow a lot from risk management<\/a> to manage project assumptions.<\/p>\n\n\n\n But, before we can walk you through the steps needed for managing project assumptions, we have to talk about the different types of assumptions and how they can affect projects.<\/p>\n\n\n\n\n Take control of your team's workload and achieve better project results with Plaky by CAKE.com.<\/p>\n There are many assumption models out there, but in this guide, we\u2019ll use (a part of) the assumptions model devised by Daniel Kies, professor emeritus at the College of DuPage, Illinois. <\/p>\n\n\n\n While not made for project management specifically, this model is simple enough to convey everything you need to know to start systematically thinking about project assumptions.<\/p>\n\n\n\n Kies analyzes assumptions by asking whether or not they are:<\/p>\n\n\n\n If an assumption is supported<\/strong> (not necessarily true, but substantiated through some evidence), it is warranted<\/strong>.<\/p>\n\n\n\n If an assumption is not supported<\/strong>, it is unwarranted<\/strong>.<\/p>\n\n\n\n If an assumption is written<\/strong>, it is explicit<\/strong>.<\/p>\n\n\n\n If an assumption is not written<\/strong>, it is implicit<\/strong>.<\/p>\n<\/div><\/div>\n\n\n\n Combining these 2 sets of descriptors leaves us with 4 possible combinations for each assumption:<\/p>\n\n\n\n To quote Neville Turbit<\/a>: \u201c[Assumptions] are typically documented at the start of the project and filed in a safe place. Aside from helping to pad out the project charter, they are usually ignored<\/em>.\u201d<\/p>\n\n\n\n It is best to manage project assumptions every step of the way, as you would with project risks.<\/p>\n\n\n\n As PMBOK apparently has nothing to say on this matter, we\u2019ve analyzed the works of experts who have written on the topic of managing project assumptions \u2014 like Neville Turbit and John Kinser \u2014 and arranged their tips into the following steps:<\/p>\n\n\n\n First things first, you need to identify what assumptions you\u2019re making.<\/p>\n\n\n\n In his paper Don\u2019t make an ass out of you and me\u2014using assumptions effectively<\/em>, John Kinser stated that 4 of the 9 assumption identifying techniques from Assumption Based Planning (ABP)<\/a> by James A. Dewar can be applied to project management, which he dubbed:<\/p>\n\n\n\n To identify project assumptions through storytelling is to use descriptive language to paraphrase the objective statement from the project charter<\/a> in as many words as you can.<\/p>\n\n\n\n For example, let\u2019s say our project statement reads: \u201cThe goal of this project is to create a team communication tool for our company so that we can have direct control over our data<\/em>.\u201d<\/p>\n\n\n\n That\u2019s a decent project statement \u2014 it\u2019s got the what, the who, and the why.<\/p>\n\n\n\n But let\u2019s see what assumptions are hidden in this statement by using storytelling:<\/p>\n\n\n\n \u201cOur company is unsatisfied with the team communication tool it\u2019s using, as the provider has recently been hacked, leaving our confidential data exposed. It now considers keeping internal communication data on 3rd party servers of any kind a risk no longer worth taking. We will develop a team communication tool that will offer higher security than anything available on the market.<\/em>\u201d<\/p>\n\n\n\n What assumptions can we glean from this?<\/p>\n\n\n\n The one that stands out the most is this: Our team communication tool will not use 3rd party servers.<\/p>\n\n\n\n This isn\u2019t just an implicit assumption, but it\u2019s probably unwarranted as well, given that even many tech giants like Twitter<\/a> don\u2019t use their own cloud servers.<\/p>\n\n\n\n Real-life examples will have more context to draw from for even more detailed descriptions.<\/p>\n\n\n\n Looking for \u201cwills and musts\u201d is meant to be understood quite literally. <\/p>\n\n\n\n You go through all project documentation and search for all instances of the words \u201cwill\u201d and \u201cmust\u201d. You\u2019ll be surprised by how frequently these words are used. You can use them to identify assumptions made while these documents were being written.<\/p>\n\n\n\n Sometimes, you\u2019ll find that project documentation contains planned actions that don\u2019t correlate to any explicit assumption. <\/p>\n\n\n\n As Dewar says \u201cplanners do not usually plan useless actions. Figuring out why an unconnected action is being planned usually reveals an assumption about the future that has yet to be explicitly stated<\/em>.\u201d<\/p>\n\n\n\n To rationalize the plan is to go through documentation and look for these instances of planned actions that aren\u2019t linked to any explicit project assumption.<\/p>\n\n\n\n Kinser does point out that, of the 4 methods for project assumption identification, this one is the most difficult, as it cannot be performed until the project has a comprehensive plan. Nevertheless, it\u2019s worth taking a mental note of this strategy.<\/p>\n\n\n\n Lastly, you can ask the so-called journalist\u2019s questions::<\/p>\n\n\n\n Dewar adds a slight twist to these questions by suggesting to cut out the sixth question \u2014 \u201cwhy\u201d \u2014 and instead compound it to the first 5 questions, so that you get:<\/p>\n\n\n\n The same goes for where, how, and who.<\/p>\n\n\n\n Explaining the \u201cwhy\u201d for every question should bring some previously implicit assumptions to light.<\/p>\n\n\n\n Before we get any deeper into discussing step 2, we need to point out that assumption identification is not something you should only do once, at the start of the project. <\/p>\n\n\n\n It\u2019s a continuous and iterative process. As you update or write new documentation, make sure to check what new assumptions are being made.<\/p>\n\n\n\n Now then, whenever you identify an assumption, you should analyze it.<\/p>\n\n\n\n To do this, you can borrow from risk management.<\/p>\n\n\n\n In risk management, we rank each risk by: <\/p>\n\n\n\n When analyzing project assumptions, just flip the script:<\/p>\n\n\n\n Analyzing assumptions like this will help you prioritize them, which you\u2019ll have to do, given how many assumptions a lot of projects rest on.<\/p>\n\n\n\n Because of the sheer number of project assumptions that proper assumption identification can uncover, it can be difficult for project managers to keep track of all of them.<\/p>\n\n\n\n That\u2019s why, in many cases, project managers will assign ownership of project assumptions to project team members.<\/p>\n\n\n\n As mentioned, just because an assumption is warranted, doesn\u2019t mean it\u2019s true. Project members should periodically \u2014 ideally at predetermined intervals \u2014 check up on project assumptions to verify them. <\/p>\n\n\n\n You often won\u2019t be able to verify if an assumption is true as soon as it is identified, which is why returning to it several times to see if anything has changed as the project progresses can be beneficial.<\/p>\n\n\n\n The whole point of this entire process is to monitor project assumptions. Whether the project manager assigns ownership of project assumptions to project team members or not doesn\u2019t change this.<\/p>\n\n\n\n As with all things nowadays, monitoring project assumptions is best done through software. Not all project management tools have dedicated assumption management features, but if you use a customizable platform like Plaky<\/a> by CAKE.com<\/a>, you\u2019ll be able to do this effortlessly.<\/p>\n\n\n\n In Plaky, users can create an unlimited number of custom boards and tweak the appearance of each one by adding relevant fields.<\/p>\n\n\n\n In the picture below, we can see how a Plaky board can be made to give you a clear visual state of project assumption tracking by showing:<\/p>\n\n\n\n Last, but not least, make sure to document the assumption management process throughout.<\/p>\n\n\n\n Once again, we can look to risk management to glean some ideas, such as creating an assumptions log \u2014 a document that will contain a list of all project assumptions identified in every project organized by the company.<\/p>\n\n\n\n The log shouldn\u2019t merely be a bulleted list of project assumptions, but instead, it should cover each entry in detail.<\/p>\n\n\n\n Sometimes, assumptions may only become clear when conducting the post-implementation review (PIR)<\/a>, also known as the project post-mortem.<\/p>\n\n\n\n This log can be used to facilitate assumption identification and tracking in future projects.<\/p>\n\n\n\n\n Track your progress and achieve better project results with Plaky by CAKE.com.<\/p>\n Assumptions in project management are not something that can be avoided \u2014 turning a blind eye to them can only make things worse.<\/p>\n\n\n\n To increase the chances of project success, you should try to maximize the number of warranted, explicit assumptions.<\/p>\n\n\n\n This is done by identifying, analyzing, and monitoring them, ideally through a project management platform that can support assumption management, like Plaky by CAKE.com.<\/p>\n\n\n\n\n
\n
What are assumptions in project management?<\/h2>\n\n\n\n
\n
What project assumptions are not<\/h2>\n\n\n\n
\n
Project assumptions vs. project constraints<\/h3>\n\n\n\n
\n
\n
Project assumptions vs. project risks<\/h3>\n\n\n\n
\n
How to communicate project assumptions<\/h2>\n\n\n\n
![\"Plaky](\"https:\/\/plaky.com\/blog\/wp-content\/themes\/cake-blog\/theme\/images\/banners\/features@2x.png)
\n <\/picture>\n <\/div>\n<\/div>\n\n\n \n\n\n\nTypes of assumptions<\/h2>\n\n\n\n
\n
\n
How to manage project assumptions<\/h2>\n\n\n\n
\n
Step #1 \u2014 Identify project assumptions<\/h3>\n\n\n\n
\n
Technique #1: Storytelling<\/h4>\n\n\n\n
Technique #2: Looking for \u201cwills and musts\u201d<\/h4>\n\n\n\n
Technique #3: Rationalizing the plan<\/h4>\n\n\n\n
Technique #4: Asking the journalist\u2019s questions<\/h4>\n\n\n\n
\n
\n
Step #2 \u2014 Analyze project assumptions<\/h3>\n\n\n\n
\n
\n
Step #3 \u2014 Assign ownership of project assumptions<\/h3>\n\n\n\n
Step #4 \u2014 Monitor project assumptions<\/h3>\n\n\n\n
\n
![\"Example](\"https:\/\/plaky.com\/blog\/wp-content\/uploads\/2022\/12\/Example-of-a-project-assumption-board-in-Plaky-1.png\")
Step #5 \u2014 Document for posterity<\/h3>\n\n\n\n
![\"Plaky](\"https:\/\/plaky.com\/blog\/wp-content\/themes\/cake-blog\/theme\/images\/banners\/pricing@2x.png)
\n <\/picture>\n <\/div>\n<\/div>\n\n\n \n\n\n\nConclusion: Don\u2019t avoid assumptions, analyze them<\/h2>\n\n\n\n