A plan is an incredibly valuable tool where custom content types are concerned - especially complex ones.
Following are the main things you need to consider when creating a plan for a custom content type:
The first thing you need to do is make a list. What fields do you need on your node submisison form?
A data element is a single, unique piece of data that exists on your custom node type. It can be something like a First Name field or a Birthdate field.
Some pieces of data are things that every data object will possess. As an example, if you were creating a custom node type that collected information about a person, each person in that data set will have a First Name. Therefore a First Name field should be required.
Other pieces of data are things that not every data object will possess. Returning to our person example, some people may have a college degree whereas others may not. Requiring a College Degree field on a node submission form that will be used by a wide variety of people with different educational backgrounds is not a good idea because some people may not possess the data that should be entered in that field. If a required field is left empty, the form can not be submitted.
So, determine ahead of time what fields should be required and really consider how this applies to the entire group of data objects you will be handling.
CCK is a widely extended module. What this means is that lots of different people and organizations have created many different sub-modules that work with CCK. These sub-modules do different things such as formatting addresses, uploading files, manipulating images, etc.
Central Web Services has added many different sub-modules that can be used to help increase the usability your node types. Determine which ones you will want or need to get your job done.
Sometimes different data elements fit together in groups. A good example is an address. Somebody's address consists of a street name and number, a city, a state, and a zip code. For effective data handling reasons, each one of these items should really be a separate element, existing in what is called a "normalized" state...but they still all fit together. To group this data set together, we would use something called a fieldgroup.
The order that your data fields are presented to your content contributors (aka your data entry operators) is really important. Nothing frustrates a data entry operator more than having to tab around on a page to enter data that should really be presented in a particular sequence. Additionally, having these items out of order opens the door to potential errors and other inefficiences that you really just don't want. Determine the workflow of the page beforehand.