09 September 2014
As a consultant, I frequently encounter projects where assumed dependencies are not in place before the beginning of the project. Sometimes, these items might not even be available for months after I am expected to finish and leave. This is especial true of anything related to data (e.g. data services, data access libraries, databases, and sample data). But, it could also be related to non-functional requirements such as authentication and logging frameworks. Despite this, even when estimates were based on these items being ready and the customer knowingly signed off on those assumptions, customers have a hard time understanding the impact to the project schedule and will often argue not to move the target release date. I am not advocating that your team should give in to these unreasonable demands. In fact, I would argue the opposite. However, whether you are waiting on dependencies that should have been completed or had planned to work in parallel from the start, I do recommend architecting your application in such a way as to minimize the damage caused by incomplete dependencies.