This temptation to fix a schedule and get to work is constant in enterprise IT. It is particularly alluring for any application tied to a SOX-compliant landscape — some governance models only allow two opportunities/year to deliver — where project durations strongly suggest themselves and time is always “a-wasting”.
Of course, as Glen Alleman reminds us here, starting with the schedule is wrong. I won’t recapitulate his post here, but I’ll borrow from his comment to another post which points out the fallacy in this kind of thinking:
[M]any…process improvement projects have failed, along with Enterprise IT, because the WHY of the effort is not established or well understood. The principles establish WHY we should be doing something. The practices of course tell us HOW.
This rush to “get working” short-circuits on of the most important functions of a WBS: stakeholder management. Properly defined deliverables and work packages aren’t simply inputs to the schedule, budget, etc. If nothing else, a WBS is the most accessible framework for a discussion with one’s stakeholders that ensures that the what of the project supports the why of the project. Wouldn’t it be a good idea to make sure that why and what are elaborated and priorities agreed upon — even at just a couple of levels — before getting down to who, when, where, and how?