I've taken to writing up a profile for any of the significant forms in an application.
The big thing that the form profile has, is a list of text fields with formulas. Any formulas that aren't simple; that are dependent on outside input; or anywhere the application owner has changed design directions.
This has proved a tremendous asset in getting the application in the field. I can switch out formulas and quickly reverse those, "Why, ah, that's not what I wanted" responses.
The profile also contains a checkbox listing optional features -- things that the application owner starts quibbling about, or that he adds during development.
Other items are picked-up during testing. If they're not simple bugs in the code, if they're requirements or concept problems, I'm also adding their relevant bits to the profile. This can get a little more complicated. But it still generates big benefits.
If you need an explanation why for managers, I believe the reason this scheme works is that ideas that pop up during development or make tiny pieces of the design complicated may not be very well thought out -- they're fuzzy. So it seems, they will need quick-changes during configuration. And the profile offers a place to make those changes.
There's a design benefit, too. Sometimes it takes a little more thought & testing to make sure all the pieces will work together, with & without some checkboxed features. The end result has to get the "once over", multiple times. That seems to bulletproof the code a lot more.
I've also discovered one downstream result: if another department wants an application "like that, except for x, y, and z", well, sometimes the features are available to be enabled or reconfigured from the profile.