We have touched on the idea that there are explicit and implicit project deliverables in most cases. These may be due to our customer simplifying a solution or general prerequisites and best practices. Some common implicit project deliverables include documentation, test scripts, demonstrations and the like. We need to take all of these into account for our estimates and risk calculation.

A Complete List

I have found that one of the most significant contributors to bad estimation in software is missing requirements. We spend time on designing the explicit features and let the implicit ones fall through the cracks. Then those missed items pop up during the project and add a little (or a lot of time) to the schedule. These "oops" items add up and can be significant to the point of long hours or slipped dates.

You may point out that experience should reduce or eliminate these missed items. That is correct. However, it is easy to forget about these items unless we follow a detailed process in planning out the project.

Estimating Implicit Project Deliverables

The other problem with these assumed requirements is estimating them. They tend to be dependant upon the overall requirements and system complexity. My favorite examples of these are testing, documentation and general project management or meetings. Each of these items is part of almost every project. However, they are easy to estimate incorrectly due to their reliance on the project as a whole to determine size and effort.

Documentation is the easiest to evaluate. We just need to be clear about the packaging for the end solution. This should include answering the questions about the user, installation, administrator, technical and other guides. Testing and general project management (status updates, creating tasks, assigning them, and tracking progress) are often underestimated. The challenge with these is the cost per "cycle." For example, when you have weekly meetings to plan, share and discuss progress then that overhead will increase as the project timeline grows. Test cycles work in a similar fashion. When we add a partial or beta release to a project then we need to include testing impact with that estimation.

The explicit and implicit project deliverables are not hard to determine. However, we need to be intentional about including all of them in our planning. Sometimes it is best to slow down, take a deep breath, and review our plan to catch all of these critical items.

Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

Episode 214: What's your Me-Made Style?