Words have the incredible power to set the trend in a business agreement, nothing new there, but at times differences can get subtle. That’s the case with using “assumptions” vs. using “dependencies”, they can mean the same thing but give a different message in the same context.
There will always be things that are unknown in a projects life cycle. Now, when do you use which word?
- Filling in those particular blanks is critical for the success of the project? Then go for dependencies, reducing ambiguity on showstoppers is always good.
- Need to make one choice over another to keep the story in the document intelligent, then you’re safe with assumptions.
Assumptions tend to take care of the unknown but dependencies imply someone will need to take responsibility for them.
It’s a choice that keeps coming back in project charters, proposal texts and product case descriptions.
edit: The thing is that those terms get used as topic headlines a lot in standard PM templates, and sometimes when arguments arise it’s a lot easier to point to dependencies than to assumptions.
Tags: assumptions, dependencies, lessons learned, writing
Hmm, I’m having a hard time thinking of a concrete example where the two terms could be mixed up. An assumption is something you believe without it being made explicit beforehand e.g.: you assume the assets will be delivered on time. A dependency is a relationship between 2 things where the outcome, success or absence of one directly affects the other, e.g.: making the deadline depends on the assets to be delivered on time.
Unless you’re trying to tell people to stop wrongly using the two as synonyms, I’m missing the ambiguity. On the other hand, maybe you have a very specific definition for either of those terms, but then you need to provide the definitions
The words rarely get mixed up, everybody knows very well what they mean, you give good definitions.
The thing is that those terms get used as topic headlines a lot in standard PM templates, and sometimes when arguments arise it’s a lot easier to point to dependencies than to assumptions.
That also works the other way around, it’s pretty silly to be totally flexible all of a sudden on something you called dependencies at the start of a project.
You see?
Yep, I’m having scary visions of powerpoint presentation headers being referred to in deadline now.
Maybe you are saying that people often make assumptions regarding dependencies and treat them as facts? Dependencies should be facts (e.g., Company A will provide X to Company B on 2/1/09). Assumptions are best guesses of future facts (e.g., The unemployment rate for March 2009 will be 7.4%). I don’t see the confusion.
That’s exactly what I noticed, it often happens that people twist the meaning of the words as they see fit.
In my experience, assumptions and dependencies do get mixed up. It is easy to write a dependency as an assumption of a positive outcome. For e.g. the dependency ‘Company x shall deliver assets by the 1st Friday of each month.’ can be written as an assumption ‘the assets are delivered by the 1st Friday of the month.’
One definition of assumption is facts that do not require a proof or supported by empirical evidence.
The fact that an assumption in being made – is worth documenting – is evidence that somehow the success of the process is dependent on the assumption being materialized.
In my view the two words may not be synonymous but there use in project documentation can be hard to distinguish.
Hi Leo, thanks for stopping by! I agree, they are hard to distiguish, but when it comes to it, people know what they mean.
That’s exactly why I wrote this post initially. Often when looking back on a project, I noticed that when we called something an assumption it was perceived as a shallow dependency. And it’s harder to bargain on assumptions then on dependencies.
My advice is to treat them both as risks. If an assumption is worth mentioning then it’s a risk to the project likely with low probability of becoming an issue and one that has to be accepted rather than have mitigating actions taken for it.
Similar with dependencies. They will be explicit if you’re using Microsoft Project to manage the activities. If you’re forced to use a spreadsheet to plan then they should be documented as an aid to managing activities and for the sake of comms to make it obvious why a task is so important. If they need stating, the key ones should be expressed as risks – there is a risk that company A doesn’t deliver in time to start task 10. The whole project plan is a list of dependent activities.
We have enough documentation to manage and communicate to stakeholdeds as PMs without duplicating documentation. I believe that someone wanted to make the whole thing more interesting and so invented the term “RAID logs”.
Happy to receive feedback
Steve
Steve, I like the idea of treating them both as risks, certainly from the perspective of a management tool for yourself as a PM or for internal projects.
I’d be hesitant to call all dependencies or assumptions risks, certainly in a commercial context or when you’re still in negotiations because a “risk” can have a negative connotation. The word “risk” is also hard to use in terms of pointing out responsibility, for instance it’s easy to say someone is responsible for filling in a certain dependency but saying “you are responsible for not letting the result of this risk happen” doesn’t work, in a contract that may even have legal implications.
In general I describe the pre-conditions for a project in terms of assumptions or dependencies, they are intended to happen. Under the risks topic I put things that could go wrong but aren’t part of the plan or process, it’s the place where I describe things that we don’t intend to happen but can’t neglect.