When you start a project, big or small (or large or grand), you base your plan on a set of assumptions, such as
– how productive developers will be
– how many sessions will be needed with users
– how difficult some of the functional areas will be (sometimes this results in t-shirt sizing of areas of code, as in S, M, L, XL etc)
– what day rates you're going to pay
-how long it will take to stand up an environment
– how many interfaces will be needed
– what data quality will look like
And so on
A smart team publishes those assumptions … and then tracks their validity.
If the project starts to drift – in cost of time or some other variable – it makes sense to recheck those assumptions, because if one or more turn out to be wrong, the affect can ripple through many areas of the plan.
All too often assumptions are like risks, written down once and forgotten about. Until it's too late.
