The project versus product dilemma in Enterprise IT

[Image via Dave Spicer]

I've often run into the project-product dilemma over the last decades: a company does business by supplying products and services, which -after it's reached a certain size- can only be implemented with the help of IT. Over time, that "help" turns into "sole reliance on"

Strangely enough, these IT-implementations are project-driven, and have increasingly become so over the years. Scrum, Agile, XP: all software-developments methods of the last decade are single-mindedly focused on how to do a project faster

When the project's completed, the product is deemed to have been delivered and the project team is dismantled, with maintenance and support (to be) handed over to the standing organisation - so the business product gets delivered by an IT project, and then what?

In IT architecture, we learn that the What (conceptual level) relates to a How (logical level) and a With What (physical level). If the What is a product or service, I simply can't fully relate that to a With What being a project: that's only delivering the baby, then giving it up for adoption

I'm absolutely sure about businesses needing a very small time-to-market these days, so speedy delivery is a big plus. Yet, speedy delivery is needed all the time, not just when creating a brand-new product or service. The entirely project-focused delivery methods such as Agile and XP sacrifice documentation so they can move more quickly, which is understandable and a simple trade-off: but why don't they finish that documentation at the very, very end?
Now they deliver a car without a proper instruction manual - how would you feel about that when you're the driver and it breaks down in the middle of nowhere?

IT is not about delivering projects, IT is about sustaining business products and services which means IT is there at the moment of conception, will guarantee proper delivery, nature and nurture the child and accompany it into adolescence until it reaches maturity

Optimising project delivery is as short-sighted as it gets: no business really cares about this. Businesses care about their products and services being supported 24/7 by "an Agile IT" if you like, not by Agile projects - projects are just an IT invention and a means to the goal, not the goal itself

Application lifecycle thinking means going all the way onto fourth base, not just striking the ball as hard and fast as you can into a place where you're pretty sure there'll be no one to catch it.
Projects follow the IT business model that is wrong in so many ways: extreme focus on Sales over Delivery, and Delivery over Governance. In the middle, the user (i.e. business) gets lost.
Did you ever find or see a functional design that included all the necessary requirements but also the required error-handling, and most importantly, user-friendly messaging, for all the events in which a requirement was not met?
The project-driven approach is bad programming on a very large scale: it is entirely business-rules driven, without an eye for exceptions, and leaves those to be handled by others after delivery, based on little to no documentation

In my eyes, that is unfriendly at the least, and penny-wise pound-foolish at best. The cost of solving a problem increases with every phase of IT, from Design into Build into Run into Maintain. Doing a quicky and sacrificing proper documentation as a consequence, is adolescent and irresponsible, and extremely costly in the long run

Would you want to be the owner of a quickly produced custom-made car that has to be taken back to the original people who built it when it breaks down? So why would you want to sell such a thing to anyone?