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.

It can also have other kinds of code btw. But that seems to take a correspondingly larger effort. I've experimented with LotusScript/BASIC, Javascript, and CSS snippets too. The last 2 made me wish profiles were better implemented in XPages.

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.