Starting a new project

There are differing lines of thought relating to project setup and configuration, unfortunately there is not a single strategy, but there are some key principles to consider which will guide you though a methodical thought process.

The first relates to project scale. What is the overall square meterage? How many buildings make up the scheme? What is the project build cost? How many departments are there?

Let's take the fictitious example of a 20,000m2 hospital, comprised of a new main hospital building, a new separate clinical services building and a small existing building to be refurbished. The project build cost might be in the region of $100 million, lets say there are 30 departments and lets be nice and give the project a name too - Opera Hospital.

Within CodeBook we have databases, sectors, departments and floors to organize and use to order and group together our rooms. There may also be a Schedule of Accommodation (or Space Programme) to be taken into account when structuring your CodeBook project. We also have the option to assign a room category, which is yet another useful way to group related rooms but we'll come back to this later.

So how many databases will I need? Well, this depends on two other key factors, how will the Revit models be organised and how many CodeBook users will there be?

Based on our example, the Opera Hospital, the project would most likely have three Revit Architectural model files, one for the Main Hospital building, one for the Clinical Services building and one for the existing building that is going to be refurbished. You can of course have a single central model file, containing everything and that every user accesses, but from a practical model management perspective it would probably make sense to split into a series of linked model files. Perhaps you might also have a separate site model, structural model for each of the new buildings and there may also be various consultant models.

The architectural team for Opera Hospital will of course vary depending on the services being offered, resources available and programme, but it would seem reasonable to assume a team size of eight people. This would include a project director, project manager, architects, medical planners and architectural technicians and of this team you might have three staff using CodeBook on a daily basis, the project manager occasionally and perhaps even your client periodically.

One approach would be to have a single CodeBook project database with three sectors, one for the Main Hospital, Clinical Services and Existing building. Each sector would be sub-divided into departments and floors and the departments linked to the appropriate Revit model. The room category is typically used to delineate between clinical, clinical support, general support, administration etc... the beauty of room categories is that they allow you to group rooms across different departments and you can have as many or as few category types as you see fit. If you map these CodeBook fields to a Revit room parameter, you can synchronise the data to your model and build views upon them, which can be a powerful tool and provide a visual representation of your schedule of accommodation (space programme).

This arrangement would provide a good basis to start the Opera Hospital project from and by having a single database, it means that you only need setup the project properties, parameter mapping, reporting formats etc... once, rather than several times had you started off with multiple databases. It is possible to copy settings from one project database to another, but if you can avoid the extra work of coordinating multiple databases and updating them, then why wouldn't you?

Well, one potential reason is the size of the project database and another is the number of users accessing, editing, updating and reporting from it. Technically you can have any number of users working in a single project database at the same time, but from a practical perspective it sometimes makes sense to split files up to avoid the performance of the whole team being adversely affected.

Generally speaking I try to keep project database filesize under 15mb, I've found that project databases larger than this, suffer from at least one of the following:
_as an attachment, the project database is too large for some email systems
_the users may notice performance issues, i.e. how long it takes to perform a task
_users often "bump into each other", i.e. one person is synchronising, whilst another is linking rooms, or updating designed equipment, or running a report...

Databases will allow multiple users to access them simultaneously, but if one user has a room open, whilst another user synchronises the same room, whilst a third user tried to update designed equipment for the room - what do you think might happen? The likelihood is that at least one of these processes would not complete fully, or worse still the program might crash. Databases use record locking, a similar concept to Revit worksets, and this generally applies at the room level of granularity.

Through each project phase, the Opera Hospital will amalgamate more and more information, room data sheets will be completed, detailed construction information added and costing, procurement and FM data may be included towards the end of the architectural teams involvement. The usage and demand of users accessing CodeBook will change during the project lifecycle, so it is quite likely that you may start with a single project database, but this may be sub-divided once you get into the design development stage. It is also quite feasible that your client will want a single consolidated view of the project at key project milestones and upon handover, which will require you to merge back together your project database files.

Reviewing the demands of the project regularly and considering the needs of the team using CodeBook is essential to the health of your project files. In summary the sort of questions you should consider are:

1) What is the scale of the project?
2) How many users will be accessing the CodeBook files?
3) How many Revit models are there containing Revit rooms and families?
4) Will these requirements change in the next few months?

This should help you determine the best way to organise your CodeBook files, but remember files can quite easily be split and merged back together, although I wouldn't advise doing this on a regular basis. Before making a significant change to your structure, speak with other members of the project team, the BIM/model manager and take a backup so that you can revert back if needed.

I'll cover splitting and merging databases in a subsequent post, plus backups and archiving.