“We need to estimate how many people we need, how much time, and how much money. Then we’ll know when we’re running late and we can, um, do something.”
OK, assuming we are indeed running late and, as ever, “schedule is king“. WTF are our options?
- We can add more people.
- We can explicitly or (preferably) implicitly impose mandatory overtime; paid or (preferably) unpaid.
- We can reduce the project scope.
The least used option, because it’s the only one that would put management in an uncomfortable position with the customer(s), is the last one. This, in spite of the fact that it is the best option for the team’s well being over both the short and long term.
Did you ever work on a project where you thought (or knew) the schedule was pulled out of someone’s golden butt? Unlucky you, cuz Bulldozer00 never has.
In “Object-Oriented Analysis and Design with Applications“, Grady Booch bluntly states:
Unjustifiable precision—in requirements or plans—has proven to be a substantial yet subtle recurring obstacle to success. Most of the time, early precision is just plain dishonest and serves to provide a façade for more progress of more quality than actually exists. – Grady Booch
Pretty harsh, but wise, words, no? So, why do managers, directors, and executives repeatedly demand micro-granularized schedules and commitments from knowledge workers from day one throughout the life of a project?
- Because “that’s the way it has always been done“
- To maintain the illusion of control
- To flex their muscles and “hold people accountable” each time a micro-commitment is broken
When the definition of “done” for a software development project is solely based on allocated time and budget, it’s relatively easy to be perceived as successful. When the schedule and budget are exhausted: the work stops, the software is delivered/released/deployed, and victory is unequivocally declared. Whoo Hoo! As long as the software runs, regardless of its quality and usefulness, all is well – in the short run.
When the achievement of one or more difficult-to-measure, but meaningful, quality metrics is added as a third criterion to the easily measured time and budget metrics, the meaning of “done” becomes less vague and more realistic. That’s why it’s rarely done in practice.
Ya see, CLORGs and DYSCOs are full of themselves. By not measuring the things that matter for long term viability, they can stay infallibly full of themselves till the fit hits the shan.
I’d venture to say that every technology company has phrases similar to “elegant products“, “technical excellence“, “innovative solutions“, and “quality first” smartly written in its mission and/or core values statements. I’d also venture to say that “schedule is king” is not explicitly inscribed in those WORN documents.
Regardless of what is espoused in their cutesy mission and core values statements, all mediocre and underperforming corpricracies operate day-to-day as if “schedule is king” is their top priority. How many times have you heard managers say the words “quality“, “elegance“, or “excellence” when discussing or reviewing a project? Now, how many times have you heard the word “schedule” uttered by managers?
If “quality“, “elegance“, or “excellence” are never mentioned because they’re “auto-assumed” to be present in all project endeavors, then why write them down? If “meeting schedule at all costs” is really what drives day-to-day behavior in the DYSCO, then why not write it down and put it at the top of the list?
Item number 50 in “97 Things Every Programmer Should Know” is titled:
Since most schedules magically appear from the heavens without any input from below, why is there a need to learn how to estimate? If, by chance, schedule inputs ARE solicited from those who will do the work, they’re often ignored since heavenly commitments have already been made behind the scenes.