I want to explain why the specification must not be changed during development period to the new planning department employee.
Is there any cool document that does this?
A specification nearly always changes during development for any but the most simple of projects.
The reasons are:
As to why the spec changes have adverse effect (you can't say "must not happen" since as you can see there's plenty of reasons they do, nearly all outside of your control and many for a good reason) -
What these all amount to is of course extended (sometimes significantly) delivery date of the project and potentially increased likelihood of defects.
For the best ever example of how a minor change in the spec can create extreme problems, I have 3 letters for you:
All they did was change the spec to say "must work after year 2000".
In addition, in some situations it is indeed the case that the specification MUST not change (as opposed to "should not change without good reason"):
Prohibiting changes to the spec during development is ideal for the programmer, but it's not realistic in a real-world setting. People will always want to make changes, even when the thing is shipping out the door. It never stops. And some of those people may be signing your paycheck. The more they care, the more they think about it, and therefore the more often they want to revise the design. You have to be able to tolerate changing the design before completion, even if it means starting over.
The important thing is to clearly communicate the consequences of changes so that everyone has realistic expectations of the design process.
Changes have to be properly discussed, and the person in charge of the thing needs to have a clear understanding of what impact the changes will have on the delivery date. To get that, he has to talk to the developer. However, since an ongoing discussion of changes will inundate the developer and keep any real work from happening, the changes have to be queued and discussed at planned, infrequent intervals. That's what you hope, of course.
Ideally, you instruct people to make a note of the changes they want to make and have them bring it up in the weekly/biweekly/monthly/whatever coordination meeting. During the meeting each change request is discussed, including a discussion of the underlying modifications that will need to be made in order to implement the requested feature, and therefore the effect on the completion date. Once the "cost" of the change is established, then they can then determine whether or not to include it.
The important thing that this process introduces is the notion that each change has an associated cost, and the cost is generally higher the further along the project has progressed, since more work has to be duplicated. People who don't work in development usually have no idea how much a change will cost; the only way for them to tell is to propose it and gauge your reaction. Creating a well-defined change review process will help both them and you out.
Note that programmers tend to be either extremely optimistic about the how easy a change is to make, or extremely pessimistic about how impossible it will be to do. Try to figure out what you are by comparing your original estimates against the results, and adjust accordingly.
Perhaps it would be better to say that the specification must not change without a valid change request and process. Requesting a specification change has effects on schedule and cost, so these must be factored into the approval.
Given that there is a proper change management process, there is nothing "wrong" about changing specifications, but it is likely to be very expensive, so your customers may not be too happy. You can protect them from themselves by trying to get some good requirements and specifications up front, so that fewer changes are needed.
The best analogy I have is to compare it to building a house. The architect draws up the plans, and then comes up with an estimate, the customer then agrees (or not) to the plan. If the customer wants an extra bathroom put in then the work stops, plans have to change, a new estimate is done and the customer agrees (or not).
Writing software is no different. once the agreement has been made (after the design and estimate) then if any changes need to take place then work needs to stop to be able to make new plan, new estimate then get them approved (or not) and then the work resumes.
wherever I said or not means either the project goes on without the new changes. Of course there is always the time and materials to come up with new plans and estimate.