Project Methodology: What’s the Goal?

I’m struck by the number of times that people make the wrong decisions when it comes to application development as it relates to the ultimate goal.  The ultimate goal of application development is to support the business, so that the business can leverage that application to streamline processes, beat a competitor, or whatever the business need.  To that end, it seems worthwhile to deliver the best application possible.

A competing approach says that the application needs to be delivered by a certain date, regardless of the features (or failures) of the application.  Setting dates for deliverables makes sense, especially when those dates are tied to reality.  Too often though, dates are chosen without regard for the needs of the business; the dates are chosen out of thin air, using a dartboard, roulette wheel, or some other method less accurate than the aforementioned.

When due dates are chosen arbitrarily it only hurts the business.  Sure the application gets out there faster and some project manager somewhere can mark that as a completed project, but features go missing, bugs go unfixed, and the people who suffer the most are the ones who need the solution most.  That’s an important point that seems to go missing:  Business users suffer the most when arbitrary deadlines are set.  The ultimate goal, delivering a product to support the business, gets sacrified when dates are not based on reality or requirements.

Does Agile fix this?  With an agile process, more software is delivered, but that software is not necessarily better software.  And even with an agile process, deadlines are set.  However, now those deadlines are set based on even less information than other project methodologies.

Keep in mind the ultimate goal of delivering better software and supporting the business when setting deadlines.