The problem is that usually only two of three project outcomes are considered. Let's describe them from the point of view of a software firm. It'll be helpful for future use.
The first and most visible result of a software project is the software. It is the source code passed through compiler and linker. These are project documents being processed by computer for one other computer that executes the program code. There are some variations, but the idea is clear.
The second result is the documentation for the users. We consider all the information user can get from any sources in the way other than trying to work with the software. These are user manuals and tutorials, advertisement and support, books and articles, etc. These are project documents being processed by people for other people outside the project.
Usually the project is valued as successful, if these two outcomes are good. They are important for financial results of this project, for the customers, for the market position of the firm. In many cases they are only results to be taken into account.
In case the project were the last project of the firm, this opinion were right. Of course it may be last, but it would be strange, if the management predict that the next project won't start or will be full unsuccessful.
The third outcome of the project is usually forgotten. It can be invisible for high management, for marketing or for support departments, even for the management of the project itself. Unfortunately it can be more important as two others. This is project information being processed by people and sometimes by computer for members of this project and for members of future projects.
There are many different software standards, but only a little part of them are made for the improvement of the third outcome. Most others I have seen are applied only to report to management about the presence of the development standards. Usually none of the project members accepts the third outcome as one of the project tasks. As result only a little part of the project documents is good enough to be used after end of this project. The other part is bad enough to rise a big number of problems in the following projects.
We approach to the world of Software Dragons. They are virtual software monsters. We cannot observe any material signs of them. We cannot measure them. Only one thing we can see are traces of them. These are missed deadlines, devoured resources, loss of quality and killed projects.
Software Dragons are virtual. To exist they need a material object to reflect them. The material mirror of the virtual Dragon is a project's staff. To define Dragons we must consider the developers before. Let's describe what they are doing in the manner similar to our description of developers being in the world of bugs. We'll consider the third outcome of the project.