The cost for new development can often be easily justified. If a new function is needed, staffing a team to create such functionality and supporting data structures can be quantified and voted up or down by those controlling resources. Money can be found to build those things that move the organization forward; often, the expense may be covered by savings or increased revenue derived from providing the new services.
However, there is a less glamorous side to this development coin, known as ongoing maintenance, or to use a more agile term, sustainment. Organizations would very much like to believe that once a project completes, then all work ends. Not a dime more will ever need to be spent on the solution. Maintenance is a mythological beast that will not harm them. In fact, for many executives, the simple purchasing of a tool is the desired extent of monetary investment. Often maintenance is ignored under the mistaken perspective that any maintenance costs are small and not noticeable. Sadly, such completeness is rarely the case. Even projects that can verify without question that everything requested was faithfully delivered cannot achieve such closure. Issues may arise related to circumstances not previously considered. Or simple questions may occur so that even those simple questions may require research and time to answer-aka resources, money.
There is a further correlation, where the more things are built the more maintenance work becomes necessary. Minimizing maintenance costs, while a good goal, is often a goal ignored during development. Many organizations circumvent lowered maintenance costs by jettisoning any attempts at documentation from a project early on in the process. The hope is that not doing documentation can save precious development time. Money saved in development is the only focus, leaving long-term costs overlooked. While it is not unusual for leaders of a development team to believe that any documentation is of little value, anyone who has walked into an organization and been told to support some application without any document can tell you that many hours, days, and weeks are indeed lost in efforts to understand the true intentions of things, the actual business rules versus the implemented code. This anti-documentation circumstance often results in developers' careers being curtailed (or made, depending on their individual perspective) by becoming "the only one" who understands one thing or another and must effectively remain devoted to just that thing as time moves on.
Another aspect that can increase or reduce the necessary amount of documentation, relates to the level of conformity in the artifacts developed across an organization. Doing things "the same" time after time assists people in becoming familiar with systems and in how to deal with issues. Having developers implement "out-of-the-box" approaches increases how much additional details need to be explained via documentation. Therefore, the more often unusual approaches are used, likely the greater the level of necessary documentation.
Diminishing maintenance costs is a fine balancing act that may be unique to each organization. Enabling agile development approaches is a good thing. However, there is a need for consistency and conformity that must be held to as well. Therefore, it is the duty of every IT organization to determine how much and what types of documentation are useful in helping people learn and support systems. Then, this documentation must be standardized and required for every development effort to always provide that agreed upon level of detail.
Additionally, remember that the documentation side of things is not always a task of love. Ensure that all documents truly are reviewed for clarity and accuracy; bad documentation can be its own monster, causing confusion.