Here are some practical sales/development tips and lessons learned that might help you starting up, running and finishing your projects more successfully.

Pre-sales

When preparing a product demo make sure that you have done the entire demo OUT LOUD at least once. Try to make this a rehearsal with some audience (e.g. accountmanager).
Also before going to the customer make sure you have identified the business goals of the customer.

The audience at a product demo may differ from editor to director. In such a case its a particular challenge to deliver a demo that holds the attention of the entire group.
In general the following things should be kept in mind when addressing specific roles in the audience:

Editor

• Easy of use

Marketing manager

• Launch campaigns easy AND fast
• More autonomy for marketing (less dependent on IT department)

IT manager

• Reduce load on IT department by marketing department
• Integration in existing architecture

IT developer

• An open development platform based on standards such as JAVA, XSL, XML etc.

Starting up the project

Try to be involved at the project startup.

GX does not have to play a very active role and the partner must not feel that he's been watched/inspected by 'the experts from GX'.
Inform the partner that GX is willing and able to perform a reviewing role. The partner may choose to double check with GX to see if their proposed solution truly is the most optimal in realizing the end customer's ambition.
A review like this does not have to consume a lot of time, but on the other hand may save both the partner AND GX a lot of time in the end.

Write a meeting report

After a scoping/requirements meeting with the partner/customer always write a meeting report and mail this to all attendees. This will prevent later misinterpretations, allows for early feedback, and is good for maintaining an archive.

WBD

When creating a WBD (Work Break Down), always specify exactly which functionality you are estimating the effort for. This means: don't throw everything on one big pile such as: creating WCB's. Rather specify which WCB will cost roughly what time.
Also, when finished with the WBD double check the result with an architect.

CCV's

When concluding that project specific functionality must be realized through CCV's (Closed Core Violations), firstly present the desired CCV to the architects.
Always define in as much detail as possible: what is the desired functionality, where does the customer want to achieve with it, and what do you think that should be done.
The architects may honor or decline the request.
When your request is honored please make sure that you dont communicate an availability date to the partner/customer until you have a WRITTEN approval by Professional Services that the CCV will be realised by a certain time. Otherwise the project team may assume the availability of the CCV by a certain date and plan the final project deadline accordingly.

Using email

When partners wish to email you, make sure they use developersupport@gx.nl, so that in case of your (unforeseen) absence a collegua can always continue with the latest information.

GX WebManager Configuration

• Use the same JCR database on developer PC as your eventual production environment. Production server uses MS SQL: use MS SQL yourself. Two reasons: 1) it will prevent late discovery of database specific bugs and 2) it's hard to switch once you've already filled your JCR.
• Use the same type of external DB as JCR DB (set both to MySQL, MSSQL or Oracle, not a mixture). Never use a derby DB unless it's for testing or demonstration purposes.
• Use presentation WCBs from day 1. Don't start messing with or altering the corporate style WCBs)
• Use subversion or CVS to store your code

GX WebManager Configuration setup

• Copy the settings.xml of your working GX WebManager installation in your <document & settings>/.m2 directory
• Use an absolute path to your Maven repository in your settings.xml

During the realization

• Be very careful with programming that might harm the caching/timestamp mechanism in production servers. The top 3 DON'Ts:

1. Hardcoded queries in JSPs (or basically anything that's not 1) HTML 2) JSTL 3) WebManager API calls)
2. Creating and adding your own query string parameters. This will create long and very dynamic URLs and these pages will not be cached properly. Also the SEO mechanism doesn't look very nice. Solution: try to read as many variables as possible directly from the WebManager API.
3. Mixing WebManager sessions with Java sessions

Before your first deployments

• Don't postpone your first deployment until the last possible date. Experiment with deployments by creating them and doing a test deployment. Remember to use a settings-deploy.xml of the server where the code is going to be deployed to.
• Test your WCBs on other installations to see if they have no dependencies on configuration, database or operating system.
• Check the caching settings (is Caching enabled?) and do a test with WGET to see if caching works and gives the right response times.

Before going live

• Trigger the caching mechanism by running a crawler over the site. Use WGET for example. This will render a lot of pages so they will be available in the cache.
• Dump the most important overview pages (at least the homepage) in a static file if the performance is too slow. Dump them every 10 minutes or so.
• Check if the Administrator and Developer users have secure passwords?