Second, remember that the beauty of base code is that it is as complete and as thoroughly tested as possible. There's no point in having a set of base code if it's incomplete or full of bugs. It will require a lot of effort to set up initially, but it's worth the effort.
Modules that make up the base code should not have any application-specific code added to them. By its nature, the template must be capable of running as a stand-alone application in its own right. If you design the template independently of any project, you will be creating a set of base code that will work with any application. It is also important that the base code routines are loosely coupled—that is, each routine should be as self-contained as possible. Never write a base code routine that references elements external to the base code modules. Doing so would in effect prevent you from using the base code in any other project without modification. An ideal strategy would be to have the base code stored in a separate Microsoft Visual SourceSafe project, with the individual projects that use it simply linking to the base project for those modules that they need. Any updates to the base modules would need to be coded only once and the change would then be propagated to each application the next time it was built.
The way you actually construct your base code template will depend very much on where you will be using it. For example, code for an ActiveX control will differ somewhat from code in a full-blown application, which will differ again from an ActiveX DLL. Components without a user interface will probably not require items such as a full-blown message box; however, the base code template for such a component might change the message box functionality to raise some form of remote alert. Template code can be written as objects or as standard modules containing functions, methods, and properties. I advise you to build elements as simply as possible. If you do not need instancing, place your code in a standard module rather than in a class module. The key factor to building your template is to loosely couple everything. Doing this will allow you to extract functionality and reuse it for other templates you want to build.
I have already discussed the importance of your interfaces. You also might want to carefully consider your naming conventions. Because you want the interface to be as intuitive as possible, it is a good idea to use names that break the usual naming standards. For example, you might do this when subclassing existing functionality. To stick rigidly to standards might mean changing the names of procedures or parameters that are well established in the language. This is obviously counterproductive, since the whole idea of subclassing is that the programmer doesn't necessarily know that a change has taken place. Of course, the other problem is that by changing the name of the thing you are subclassing, you are no longer subclassing it!
While a large team enables you to put the code together fairly quickly, it makes standards harder to maintain. It also leaves the base code without a clearly defined owner, which makes controlling changes to the code more difficult. A small team ensures high standards of code and a clearly defined ownership. Since part of the object of base code is to abstract complex routines from the application, it also makes sense to use a high-caliber team to create the code.
The code that is created is also going to need to be tested to the highest standards. The developers who are going to use the base code rely on its integrity from day one. If they can't, they are likely to code workarounds for any bugs discovered in the base code, which can then cause problems once the base code is corrected.
Because the base code must be carefully written and extensively tested before being used in the first project, the business benefits only start to appear about a year after the project starts. Therefore, the project should probably be funded as an internal IT project that can then be recovered from the business in small chunks every time a new application is built on the base code. I cannot stress enough that having no base code will invariably result in either nonstandard code, increased development time, or both. At a time when many organizations are employing the services of third-party contractors, it is important for corporate code to conform to the defined standards of that organization. By having a base to start with, you also increase the likelihood of your standards being adhered to.