More harm than good has been done to software development by letting the planning dates drive the work instead of having the work drive the dates. This planning-date-driven approach causes more stress, more bad decisions, more rework, more failed projects than all other causes combined.
The power of these planning dates seems overwhelming. As a project begins, dates are set for planning purposes, since one obviously needs somewhere to start. But at some point, the date that was intended just for planning, to be adjusted down the road as needed when more is known and understood about the project scope, now magically becomes a rigid objective that requires moving heaven and earth in order to meet that planning date…or else. It is as if someone is so very addicted to dates that the first date they ever hear is imprinted deep within their soul and any change might rip them apart. Even when organizations claim to embrace new attitudes, it seems old patterns continue to return, so dates must be met.
When such propensities exist, team members may allow these corporate tendencies to influence the dates they provide. Dates are given then based on fear. Fear-based estimates are often very high. Ultimately, the team never learns how to provide a proper estimate, which means that any future estimates they provide are not realistic.
Providing these unrealistic dates cause management to use their own dates instead, based on overly optimistic hopes rather than the actual necessary amount of work, leading to further bad estimates and insupportable dates being selected. Pushing projects to meet unrealistic dates causes people to take short-cuts, which drives more non-scalable but faster-to-code options, prevents the establishment of reusable components, and results in more technical debt gathering in piles which are simply ignored. Often, instead of a follow-up enhancement, the “next phase” becomes a complete solution mulligan.
Sometimes estimates do not have a fighting chance; frequently, the scope of a solution is not well known or understood by the organization, but dates still are set early on. Understanding is more important than any date; too often we still sabotage ourselves by jumping to build solutions before any of us understand what we are working on, or before business clearly articulates what they actually need. Then in our efforts to hit a date, we end up meeting dates with insufficient solutions, or miss dates altogether and create tangled messes.
Budgeting requires fixed-sized boxes bounded within dates. Projects, solutions, deliverables of all sorts, must fit within these boxes, or else the universe will explode, or something. Perhaps it is time for an evolution. Maybe things need to start heading down a new path? Perhaps, just perhaps, resource planning and budgeting should focus on bandwidth rather than on deliverables? Instead of listing the goal as delivery of any specific solution, a more realistic goal should be X months of Y resource efforts towards this or that solution.
Consider that the specifics of the deliverables can be left more fluid at the start, then be delineated as things progress. Certainly, we need to improve our estimating skills; because ideally, in budgeting for bandwidth, we will have expectations at least at a fuzzy-level of the “amount” of work to be delivered. Over time teams will mature and start working towards better and faster delivery. Current frustrations regarding solution deliveries will be replaced by delight as more and more work starts being delivered more quickly than anticipated; but this transformation can happen only if all those involved can allow the process and the teams to mature naturally, improving their interactions and speed to deliver. The goal is to transcend the date addiction, get the team working well, as opposed to dragging out initiatives in unproductive fashions simply because the organization has shot itself in the foot trying to make a date.