One of the top misconceptions I've witnessed in IT work is that many view a software project as a discrete component. They assume that the costs are static and once a piece of software is in place, the costs end or are minimal. They will look at the cost to build and implement on Day 1 as the only cost.
This is so wrong that it befuddles me how often this mistake is made. The "long tail" of a system's life, comprising the care and maintenance of the application, is likely to be far more expensive than the cost of the initial implementation (assuming the software is useful enough to live for more than a few years).
This is especially true if the quality of the application is poor due to corner-cutting in the creation process (and given the common emphasis of deadline over quality, it happens a lot). This is why developers and project managers are often at odds. The project manager is working to a milestone and then moving to the next project, but the developer likely has to live with the completed product for a longer duration, suffering with that application's deficiencies. I've discussed this before, where such scenarios create soul-sucking and inspiration-sapping work that is menial and tactical in nature rather than strategic. Many of the people at the high end of these mistakes are not held accountable for these problems, due to the way the typical reward system's metrics work.
Change will require a major shift in metrics, and it must come from the top.
No comments:
Post a Comment