Good information on the Indicident Command System from
http://herbertcole.wordpress.com/2011/06/27/ics-simplified shows how simple, yet robust, it really is.

Some quick thoughts on the use the Incident Command System (ICS) and the benefits of viewing ICS as a functional system as opposed to an organizational system.
Recently I was teaching the ICS module to a new group of CERT recruits in our community. As the class progressed through the evening I was made aware that several of the students were, or had previously been first responders. It also became very apparent that they had no understanding of ICS in practical application, and were taught previously that ICS was an organizational construct designed to maintain command and control utilizing existing organizational and political structures. This position was counter to the teaching of the evening and required that a new perspective and way of presenting the material be implemented. Instead of plugging names and positions into an organizational chart, which is what many view the ICS structure as, I suggested we look at the purpose for the ICS and than build upon that without consideration of existing political, and organizational hierarchy.
In reorienting the class, a new definition of what the Incident Command System "is" was proffered. The Incident Command System is a "functional" system that supports incident goals and objectives in an organic and flexible manner. The key to this new definition is rooted in the term "functional". As a I set about to redrawing the the ICS schematic on the board, one student quickly noted that the structure was identical to what we had previously been discussing. I explained that while it looked that way, we would be approaching the system differently this time. Instead of focusing on the organizational method of Incident Commander and Section Chiefs, we would instead focus on the primary functions necessary to support the goals and objectives of the incident.
First we need to identify what it takes to support the goals and objectives in addressing an incident. To this end we identify the following:
People that DO stuff in support of goals and objectivesPeople that GET stuff in support of goals and objectivesPeople that COLLECT, ANALYZE and PLAN stuff in support of goals and objectivesPeople that take care of CLERICAL stuff in support of goals and objectivesPeople that LEAD and MANAGE all of the functions necessary to support the goals and objectives.

Once the functional support components have been identified we can assign them to a formal ICS Section based on functional objective.
Function and Corresponding ICS Section:
Do Stuff = OperationsCollect, Analyze, and Plan Stuff = Planning & IntelligenceGet Stuff = LogisticsClerical Stuff = Administration & FinanceLead & Manage = Incident Command

With the formal ICS structure established, it is time to clarify roles and responsibility's of each functional component. The easiest way to do this is to begin with how the ICS is implemented. As stated previously, ICS is an ORGANIC system, meaning that it expands and contracts as needed in support of the incident goals and objectives. As an ORGANIC system, ICS is FLEXIBLE.  Remember, ICS is not a rigid organizational hierarchy. It may be that in the early stages of an incident there will be resource constraints that require one person to oversee multiple functional areas.
INCIDENT COMMAND (Leadership & Command Function): The seed to ICS implementation begins with ONE person, the Incident Commander.  The Incident Commander is responsible for the following:
Initial scene stabilizationEstablishing initial goals and objectivesSets priorities and defines the ICS functions necessary to respond to the incidentAssigns Deputies and Section Chiefs as needed
PLANNING & INTEL SECTION (Collect, Analyze, and Plan Stuff Function): The Planning and Intelligence section is responsible for collecting information, analyzing information, and creating plans and maintaining current incident status (inclusive of resource usage and allocation status). Staging and check-in of personnel is typically included as a function of the Planning and Intelligence Section, therefore it should be the first section established by the Incident Commander.
LOGISTICS SECTION (Get Stuff Function): The Logistics Section supports the overall material resource needs of the ICS. As the ICS evolves and an Incident Action Plan (IAP) begins to take shape, Logistics will be called upon to provide the material support necessary to meet the goals and objectives of the incident response. Logistics support may include:
Food and WaterShelterMedical SuppliesSpecialized EquipmentTransportationCommunicationsIT and Networking
OPERATIONS SECTION (Do Stuff Function): The Operations Section is where the primary incident response activities occur. These activities are typically carried out by Public Safety (Fire, EMS, Law Enforcement, etc…) and specialized volunteer groups (CERT, MRC, County Search and Rescue, etc…). Operations may be broken down further by functional duties and geographic responsibilities.
Remember, the key to ICS is Flexibility and it's Organic ability to grow and shrink as needed. Use what you need, nothing more, nothing less. Delineation of Branch, Division, etc… within the ICS should only be done in furtherance of meeting the goals and objectives outlined in the Incident Action Plan (IAP). If you don't need them, don't use them.
ADMINISTRATIVE AND FINANCE SECTION (Clerical Stuff Function): The Administrative and Finance Section is responsible for Records Management, Payroll, and the overall incident budget. When the operations section has long been put to bed, the Admin/Finance Section will still be sorting out paperwork, bills due, payroll issues, etc…. This is the section that will be looked to for incident review and audit materials so it is important that all ICS sections understand that …"If you didn't write it down, it didn't happen."
Putting it All Together
When implementing the Incident Command System (ICS), follow the functional steps necessary to meet the goals and objectives first established by the Incident Commander. Typical ICS development should follow a basic pattern, but is always FLEXIBLE and ORGANIC so as to meet the specific needs of an incident.
ICS is dependent upon many skilled individuals that can fill a variety of functional roles. There should be no one person that fills a role continuously or as a permanently pre-assigned position. In ICS Egos need not apply. ICS is Ego Neutral. When Egos and personalities begin to take precedence over the functional position, your ICS will fail. This is why it is important that you have multiple individuals capable of filling any of the necessary ICS functions.
In the end, ICS is not rocket science. It is a very useful tool that can be used by anyone who understands the basic functional requirements necessary for establishing goals and objectives to meet the operational needs of an incident. ICS can be complex or it can be simple, but when confronted with the confusion of managing multiple responsibilities just remember the following:
People that Lead & Manage StuffPeople that Collect, Analyze, & Plan StuffPeople that Get StuffPeople that Do StuffPeople responsible for Clerical Stuff
Remember that each function begins with "People", not a specific individual. Any person trained in ICS should be able to fill any functionally needed position. ICS is your friend. Use it, and over time it will become your best friend in time of need.