food for thought: Can an assumption ever be a deliverable?
Hi Chilly,
That's an interesting question. As my Program Manager likes to remind me 'an assumption is a risk', by that she means that any assumption that is made going into or during a project inherently contains a probability that the assumption is incorrect. As a result, if the assumption is incorrect then there will be an impact to the project. Therefore we manage our assumptions as part of our risk management process, which means we document the assumptions, assess their potential impact if they turn out to be false, and the likelihood of the assumptions being false. We also will look at ways to test our assumptions and place those in the mitigation plan.
So essentially our set of assumptions becomes a deliverable - we collect our assumptions during any planning process and highlight them to determine what, if anything, we need to do about them. I'm not sure if this is what you were thinking but it's what came to mind when I read your question.
I am not sure an assumption is a deliverable. Neither is an assumptions log really.
Deliverables are tangible things that are part of the project solution. These should be things the client values directly, not in the context of appreciating your project management mastery.
Probably the thing you are looking for here is the validation of an assumption (via your risk management processes maybe) but this isn't a deliverable either.
To understand deliverables better take a look at some definitions of the Work Breakdown Structure.
Can an assumption ever be a deliverable?
Definetly! Haven't you ever heard of Vaporware?
Tony Markos
Hi Craig,
What if you're on an early stage or feasability project? Some might consider such a project a phase in a larger project, but if there's a clear go/no go decision point at the end of the set of activities and a new team will be assembled to take on the next set of work if a go-ahead decision is made, then I would consider these projects in of themselves.
In those types of projects, you rarely have a 'solution' but rather a series of work products like a feasability analysis, environmental scan, etc. and usually a risk/assumptions log. I would consider all of these deliverables in this context. Perhaps once you move into a full-fledged build/development project the risk log becomes a project management tool, but for many early stage projects such documents are considered required to be provided to the client upon completion, and thus in my mind is a deliverable.
brought to you by enabling practitioners & organizations to achieve their goals using: