Tomorrow Never Comes

The Broadway tune goes, "The sun will come out tomorrow ... it's only a day away."  The words from this optimistic jingle are often heard on IT projects that are overburdened with features and functions.  On any project of significant size the list of desired things often becomes larger than the budgeted resources or time.  Faced with limiting circumstances, the only option becomes aligning the work effort with the constraints and only doing what fits within those constraints.  The items are timeboxed, and the amount of planned work is exactly the amount of allowed work.  Some things remain in, while other features are left out.  Alternatively, responsibility for controlling a project may be ignored and the end date arrives with some things simply not completed.  Essentially, a project is timeboxed by default.  In either case, the undone items are left to be addressed in a subsequent phase, with the idea of a following phase frequently remaining an illusion.  When a function or feature is flagged as part of tomorrow's work, it is often understood by the cynics as simply a kinder way to tell users or management that such work is not going to happen at all.  Later phases may not be budgeted or even approved if initially drawn out, but the claim of linking things to the hopeful future is meant merely to provide users an easier way to swallow the bitter pill of unmet needs. 

Few IT shops these days have the fortitude to drive massive projects across multiple phases to a full-fledged completion.  Each iterative cycle may instead be derailed as too expensive so that talks of replacement, outsourcing, or third party packaged solutions arise.  Perhaps Elvis Presley was more in line with the reality of IT development when he sang, "It's now or never."  Things that cannot be done will likely remain that way.  Adding to the frustration is organizational memory loss.  Shortcuts and work-arounds initially agreed to are forgotten as originating as a shortcut.  Instead, everyone believes solid long-term choices were made.  Surprise is the organizational response when the shortcut's edges fray and expose insufficiencies leading to problems or worse circumstances.  Too often IT professionals present a soft-shoe in an attempt to make users and management believe that needed things are being addressed.  In these makeshift sales-pitches, it is not unusual to leave incorrect impressions.  While much of this misinformation is done with truly good intentions, the end result is not always as harmless as may be thought initially.  As professionals we need to do a better job of communicating bad news when such is appropriate; if something cannot be done, it needs to be stated that way, and management needs to understand what it is or is not getting. 

While not intending to sound overly apocalyptic, it must be said that more often then not, tomorrow never comes.  Even when resources are timeboxed, designers and developers need to define a diminished, yet complete and whole solution.  Everyone involved in a project needs to take a greater level of ownership to drive the components of a given project into the right shape and form to fit both in the constraining limits of people and of time.  Additionally, everyone needs to fairly represent what is truly being delivered.  IT helps no one by throwing the most critical functions into a "next release" bucket.  IT should be helping the organization sort out features labeled as mandatory versus features for the would-be-nice pile.   When future releases are tenuous, then all stakeholders should understand and agree which functions may remain unaddressed.  The challenge is to still end up with a worthwhile deliverable today.