Business_Requirements_Analysis_Report_Examplepdf1Interagency

Business Requirements Analysis Report Example.pdf

Interagency Wildland Fire

Incident Information Reporting

Application

(SIT-209)

Business Requirements

Analysis Report

December 2009

Prepared for

FIRE AND AVIATION MANAGEMENT

AND PREDICTIVE SERVICES

PREPARED BY

1802 RIDGECREST DRIVE, BOISE, ID 83712

EXECUTIVE SUMMARY

OVERVIEW

The SIT-209 is an interagency wildland fire incident reporting application that captures data from the ICS- 209 form and daily fire activity reports from dispatch offices. The data collected with the SIT-209 application is also used to create the National Situation Report (IMSR) on a daily basis during the active fire season. Local GACCS, NIFC and Congress use the SIT-209 data to obtain current incident information.

Commonthread worked in collaboration with the SIT-209 project team to design and facilitate a structured analytical process, which consisted of project definition, requirements discovery, analysis and results elaboration. Through a series of interviews and moderated discussions with SIT-209 stakeholders, Commonthread gathered high-level business requirements data. The SIT-209 project team examined the data to identify a group of general business requirements along with alternatives for continued SIT-209 support. This report is the collaborative product of all of the members of the SIT-209 project team and Commonthread.

FINDINGS

The SIT-209 stakeholders identified the following key concerns:

 The ability to efficiently consolidate, summarize and compare fire incident data for analysis is critical to the core mission of SIT-209 stakeholders.

 Different agencies have different systems, different business rules and different priorities for entering fire incident data.

 Significant duplication of effort is required to maintain the same data in multiple systems, including SIT-209.

 Redundant data entries lead to inconsistencies that must be reconciled across multiple systems at considerable effort.

 Reporting capabilities for SIT-209 data are inadequate.

 The SIT-209 user interface, including access control, is cumbersome.

 SIT-209 may not be meeting the needs of a changing audience, including the general public, who require more immediate access to fire incident data.

RECOMMENDATIONS

One of the objectives for the SIT-209 Business Requirements analysis was to complete a business case to identify and provide alternatives for continuing the SIT-209 program. The business case options as identified in the Statement of Work for this project include:

1. Identify and support SIT-209 through technical refresh and life cycle renewal,

2. Incorporate SIT-209 into another application, or

3. Allow SIT-209 to go end-of-life and retire in place.

Based on interview results and the general consensus of the project team, the recommendation is that the SIT-209 application must undergo technical refresh and life cycle renewal. The basis for this recommendation is the significant value of the SIT-209 data to a widespread segment of the fire management community and the recognition that no other application is currently ready to incorporate the SIT-209 functionality.

TABLE OF CONTENTS

Executive Summary ........................................................................................................ 1 Overview ................................................................................................................................. 1 Findings .................................................................................................................................. 1 Recommendations .................................................................................................................. 1

1. Overview ................................................................................................................ 3 1.1 Project Background ....................................................................................................... 3 1.2 Project Objectives .......................................................................................................... 3 1.3 Key Assumptions and Constraints ................................................................................. 4

2. Methods ................................................................................................................. 5 2.1 Project Definition and Planning ...................................................................................... 5 2.2 Data Discovery Process ................................................................................................ 5 2.3 Validation Process ......................................................................................................... 6

3. Findings and Conclusions ...................................................................................... 7 3.1 General Findings ........................................................................................................... 7 3.2 Conclusions ................................................................................................................... 8

4. Use Cases ............................................................................................................. 9 4.1 Use Case Diagram ........................................................................................................ 9 4.2 Use Case Narratives ................................................................................................... 10

5. Business Requirements ....................................................................................... 12 5.1 List of Requirements .................................................................................................... 12 5.2 Requirements Diagram ................................................................................................ 13

6. Business Case ..................................................................................................... 14 6.1 Business Case Definition ............................................................................................. 14 6.2 List of Recommendations ............................................................................................ 14

7. Appendices .......................................................................................................... 16 7.1 Appendix A – Glossary of Terms and Acronyms .......................................................... 16 7.2 Appendix B – Project Team ......................................................................................... 17 7.3 Appendix C – Project Meeting Notes ........................................................................... 18 7.4 Appendix D – Stakeholders ......................................................................................... 23 7.5 Appendix E – Interview Analysis Category Definitions ................................................. 25 7.6 Appendix F – Stakeholder Interview Statements by Category ...................................... 26 7.7 Appendix G – Business Rules ..................................................................................... 50 7.8 Appendix H – Data Elements by Business Need ......................................................... 52 7.9 Appendix I – Crosswalk of Data Elements to SIT-209 & WFDSS ................................. 57 7.10 Appendix J – NIMS Position Paper .............................................................................. 66 7.11 Appendix K – References ............................................................................................ 73

1. OVERVIEW

1.1 PROJECT BACKGROUND

The SIT-209 is an interagency wildland fire incident reporting application that captures data from the ICS- 209 form and daily reports from dispatch offices. The data collected with the SIT-209 application is also used to create the National Situation Report (IMSR) on a daily basis. Local GACCS, NIFC and Congress use the SIT-209 data to obtain current incident information.

The SIT-209 application‘s primary mission is to provide the ability to capture data submitted on the Situation Report and ICS-209 form into a central database that support situation reporting. The SIT-209 application also provides a daily synopsis of all active wildland fire statistics through a reports function. The application title, SIT-209, reflects the combination of the two forms of data collection, the ICS-209 and the Daily Situation Report, that share a common database.

Fires that become significant (generally 100 acres in timber, 300 acres in grassland/rangeland, or where a Type 1 or a Type 2 Incident Management Team is assigned) are subject to daily reporting as required by interagency business rules. The SIT-209 system includes both Daily Situation Reports (SIT Report) and the ICS-209 Reports which are part of the National Fire and Aviation WEB Application (FAMWEB). The Incident Management Situation Report (IMSR) issued by the National Interagency Coordination Center (NICC) is generated from this information. At this time, the ICS-209 is the only common intelligence reporting form for significant incidents used by federal and state agencies. It provides a daily snapshot of fire size, fire potential, injuries and/or fatalities, structures threatened and/or destroyed; fire resources assigned, estimated cost and expected containment date.

Dispatch offices summarize the initial report information and report daily to an upper-level office GACC (Regional or Geographic Area Coordination Center). Initial report information is compiled for regions and nationally to produce Daily Situation Reports (SIT Reports), which are used to summarize the overall wildland fire situation and help determine regional, national and incident priorities and daily resource needs.

SIT-209 is a partner application within the Fire and Aviation Management (F&AM) portfolio and is hosted within the National Enterprise Support System (NESS). The Intel groups from the National and Geographic Area Coordination Centers (GACC) authorized development of the SIT-209 application.

The current version of the SIT-209 application was introduced in 1999. It has had minor modifications throughout its lifecycle. Data collected with the SIT-209 application is also collected from other applications at differing levels of incident management. Some of these applications are web-based, i.e., WFDSS, and others function only on local computer hardware, i.e. WildCAD.

In its current form, SIT-209 technically reached the end-of-life in 2007. Funding restrictions have hampered the implementation of a technical refresh to meet evolving Intelligence and wildland fire community requirements.

This SIT-209 Redesign project was requested by the Intelligence Working Group within Predictive Services. To complete this analysis, Commonthread worked closely with the SIT-209 project team (see Appendix B) that included representatives from the GACCS, NIFC and NICC.

1.2 PROJECT OBJECTIVES

This report presents the findings and conclusions of the SIT-209 Business Requirements Analysis. The charter objectives of this project were to:

 Complete a comprehensive business requirements analysis to provide the foundational information required for design of a technical refresh for SIT-209.

 Complete a business case to identify and inform alternatives for continued SIT-209 support including:

1. Identify and support SIT-209 through technical refresh and life cycle renewal,

2. Incorporate SIT-209 into another application, or

3. Allow SIT-209 to go end-of-life and retire in place.

1.3 KEY ASSUMPTIONS AND CONSTRAINTS

The SIT-209 Business Requirements Analysis was undertaken with the following assumptions and constraints:

 The SIT-209 project team is comprised of members of the stakeholder community who are knowledgeable about the SIT-209 application.

 The deliverables address and reflect the needs of key members of the SIT-209 stakeholder community. Deliverables are based on interviews that were conducted with a small group of members representing the Predictive Service Intel Group, Dispatch Center Managers and Situation Unit Leaders.

 Time and budget constraints exist. The project must end on or before December 31, 2009.

2. METHODS

2.1 PROJECT DEFINITION AND PLANNING

The Statement of Work for this project stated that there is a requirement for contractor support for requirements gathering and business case development for the SIT-209 application. Upon project initiation, Commonthread proposed a project plan to guide the discovery and elaboration phases of the business requirements analysis.

To meet the project objectives, Commonthread worked in collaboration with the SIT-209 project team to design and facilitate a process for gathering business requirements. Through a series of interviews and moderated discussions, Commonthread documented high-level business requirements. The SIT-209 project team examined the data to identify a group of general business requirements along with alternatives for continued SIT-209 support. This report is the collaborative product of all of the members of the SIT-209 project team and Commonthread.

The Intelligence Working Group authorized the SIT-209 project team to interview stakeholders representing business areas that utilize the SIT-209 System. The SIT-209 project team developed a list of stakeholders that appropriately represented the full range of business areas.

Meeting notes documented the business requirements identified by the stakeholders, and where possible, referenced the specific data now used to meet those needs as well as other information, including open questions and recommendations (see Appendix C).

2.2 DATA DISCOVERY PROCESS

2.2.1 Interviews

Commonthread interviewed stakeholders during group interview sessions, individual interviews, or by telephone. In most instances, the interview sessions focused on two or more related business areas, the collection of the ICS-209 data and daily situation reporting. These sessions were conducted from Boise, Idaho. There was also feedback provided at the Predictive Services Intel Group annual meeting on November 18, 2009 in California (see Appendix C, Section 7.3.4).

2.2.2 Interview Documentation

Interview statements were recorded and then reviewed by each interviewee. Interview statements were first analyzed in detail to determine general categories of concern (see Appendix E). Each interview statement was reviewed a second time to determine which categories applied to each statement (see Appendix F). Statements were summarized by category to arrive at a general finding for each group of statements (see Section 3.1). Conclusions were drawn from the findings (see Section 3.2).

2.2.3 Business Rules

Commonthread developed a spreadsheet of candidate business rules based on several documents provided by the SIT-209 project team (see Appendix G). These documents included:

 National Interagency Mobilization Guides

 SIT 2009 User Survey from 2008

 Simple Wildland Fire Process v4

 Complex Wildland Fire Process v4

 iRWIn Wildland Fire Incident Information/Data Flow – Current Situation and Future Situation

The candidate business rules were categorized by the Type of Rule, the Document, Process or Work Product Governed by the Rule and the Time Frame and, if available, the Delivery Date of the Work Product.

2.2.4 General Business Needs and Related SIT-209 Data Elements

The SIT-209 Project used database documentation from the National FAMWEB Systems Analysis and Documentation Project dated November 9, 2006. Members of the SIT-209 project team confirmed that the data elements identified in this prior project could be used as part of the current SIT-209 Redesign project. In addition, the Fire Occurrence Reporting Study dated February 7, 2007 was used to prepare a crosswalk between the SIT-209 data elements and the general business needs identified in this prior study. In addition to identifying the general business needs for each data element, the Data Elements by Business Need spreadsheet identifies whether the data element is considered critical (see Appendix H). This is based on an assessment of the value of the data element to general fire occurrence reporting.

2.2.5 Data Element Systems Crosswalk

The SIT-209 Project identified CAD Systems (WildCAD, Altaris CAD, Canadian CAD), WFDSS and ROSS (via ISuite) as candidate systems that might share data with the SIT-209 System. The timeframe of the business analysis did not allow a full analysis of this crosswalk. An attempt was made to discover possible relationships between the SIT-209 data elements and WFDSS (see Appendix I). The SIT-209 Redesign process should identify data elements that are common in all these systems.

2.2.6 Use Case Analysis

The current (AS IS) use cases were combined with desired (TO BE) use cases in the diagrams and narratives to present a clear relationship between the existing application use and the desired/recommended application use.

2.3 VALIDATION PROCESS

At the project milestone meeting held in Boise on December 11, 2009, the SIT-209 project team met to review, refine and validate the findings; draw conclusions; and develop recommendations. These findings, conclusions and recommendations are presented in later sections of this report.

During the review meeting, the group validated the general business requirements statements, the data element analysis, use case analysis and alternatives. Adjustments were made where necessary.

3. FINDINGS AND CONCLUSIONS

The following General Findings and Conclusions are based on the individual interview statements from SIT-209 Stakeholders.

3.1 GENERAL FINDINGS

CATEGORY NAME

CATEGORY DEFINITION

GENERAL FINDING NUMBER OF SUPPORTING STATEMENTS

Access Control Statements regarding initial user setup, daily login procedures, and access rights.

Many interviewees expressed a desire for single sign-on for FAMWEB applications, to simplify daily login procedures for users.

Audience Statements concerning the composition of the audience and how data is used and interpreted by that audience.

Some interviewees expressed concerns about 1) changes in the audience for fire data and whether the needs of those audiences are being met, and 2) the possible misinterpretation of data that is made public.

Data Capture Statements concerning duplication of data entry, ease (or difficulty) of the data entry interface, and frequency of data entry.

Interviewees generally agreed that 1) significant duplication of effort is required to maintain data in multiple systems, 2) that data entry could be simplified, and 3) that different agencies have different priorities for timeliness of data entry.

Data Integrity Statements concerning the reliability or accuracy of data, and the ability to reconcile data against other systems and/or across different timeframes.

Interviewees generally agreed that reliability or accuracy of data entries 1) vary widely from agency to agency, 2) are affected by lack of time and/or personnel constraints, 3) require significant manual effort to resolve and 4) have tangible impacts on the ability to perform the core mission, for example, fire resource allocation.

Reporting Statements that describe content, frequency and the ease (or difficulty) of creating reports.

Interviewees unanimously agreed that reporting capabilities are inadequate. The ability to create ad-hoc reports from SIT-209 has become such a critical need that efforts are being made to add this functionality in advance of (in lieu of, regardless of) a SIT-209 redesign.

System Integration

Statements regarding what systems are used by various agencies, what data is shared by these systems and the desirability of system integration.

Interviewees cited many specific examples of data redundancy and suggested that data be shared when possible. Most interviewees expressed a desire to standardize and integrate agency systems, but were not optimistic about the realization of that goal.

3.2 CONCLUSIONS

CATEGORY CONCLUSION

Access Control

Determine if there are ways to enable access to the SIT-209 application for new users that bypasses the usual need for a manager to enter an authorization. This would allow members of an Incident Team who are new to the SIT-209 System to have immediate, though temporary access.

Audience Some audience groups want more "real time" data than is available in the Daily Situation Reports. Determine if more frequent reporting of incident information is possible. There is also a concern that the sensitive nature of SIT-209 data is not well understood across the different audience groups.

Data Capture

The SIT-209 System should capture data that exists in other systems such as WildCAD, WFDSS, and ISuite. A detailed review of all relevant systems should be performed to identify data redundancy and candidate fields for automated entry.

Data Integrity

A process that reconciles data across different applications and Dispatch Centers would address inconsistencies in data and reporting time frame. It may also help if all 209 data is time-stamped at the data element level rather than at the report level to provide access to the most recent information and facilitate reporting and analysis. All 209 data that is captured should be maintained by the system and not deleted. The data can be status- flagged to identify deleted or updated data.

Reporting The SIT-209 System should support an ad-hoc reporting tool. Notes: The addition of this functionality is now being pursued using a product called Cognos.

System Integration

Applications that maintain the same or similar data should be integrated with the SIT-209 System to support retrieval of the latest and most accurate data possible. This will reduce errors that result from the keying of same data multiple times in multiple systems.

4. USE CASES

The following use case diagram and narrative provide an overview of the business requirements.

4.1 USE CASE DIAGRAM

1.0

Create Access

Rights

2.0

3.0

Maintain ICS-209

Form Data

4.0

Create Daily

Situation Report

5.0

Create Standard

SIT Reports

6.0

Generate Reports

(Ad Hoc)

7.0

Retrieve SIT-209

Data

8.0

Reconcile SIT-209

Data

Entry/

Manager

7.1

Update 209

Data Store

7.2

Retrieve 209

Data from

Data Store

AS IS TO

4.2 USE CASE NARRATIVES

USE CASE NO.

AS IS /TO BE

USE CASE ACTOR

USE CASE ACTION

BRIEF DESCRIPTION COMMENTS/FINDINGS

1.0 AS IS Manager Create Access Rights

Provide access rights based on Scope and Authority that allows a person to view, add or update ICS-209 data.

Finding: Determine if temporary access could be allowed in specific situations.

2.0 AS IS All Users

Finding: Users requested the SIT-209 user interface be updated and improved to support ease of data entry and reporting.

3.0 AS IS Entry or Manager

Maintain ICS-209 form

Create or Update ICS- 209 data.

For redesign: Address issues of data redundancy across applications. Also, improve the flow of information and screens to improve the user experience.

4.0 AS IS Entry or Manager

Create Daily Situation Report

Create a report that summarizes ICS-209 data across incidents and geographic areas for specific times.

No new requirements.

5.0 AS IS Entry or Manager

Create Standard Sit Reports

Select a report from a list of standard reports available by authorization.

No new requirements.

6.0 TO BE Entry or Manager

Generate Reports

Select the type of report and the data that should be used to generate the report using a COGNOS type tool.

Finding: Provide an ad hoc report generator as part of the SIT-209 System.

7.0 TO BE Entry or Manager

Retrieve 209 Data

Retrieve and validate data from other systems for input to the 209 databases.

Finding: SIT-209 should give the user the option to populate the data from other systems such as CAD Systems, WFDSS or ISUITE.

7.1 TO BE

*This is an option only.

System User

Update 209 Data Store

Allow update of 209 data elements from systems such as WildCAD, WFDSS and ISUITE.

The option of storing data in a data store will support a smooth and seamless integration across systems.

USE CASE NO.

AS IS /TO BE

USE CASE ACTOR

USE CASE ACTION

BRIEF DESCRIPTION COMMENTS/FINDINGS

7.2 TO BE Entry or Manager

Retrieve 209 Data

Retrieve and validate data from other systems for input to the 209 databases.

Retrieving data from a data store will allow the SIT-209 user to validate incoming data as the most current and accurate available.

8.0 TO BE Entry or Manager

Reconcile SIT-209 Data

Compare SIT-209 data to the same data that is reported in another system.

Finding: SIT-209 data is often inconsistent with other systems that report fire incident information.

5. BUSINESS REQUIREMENTS

The SIT-209 project team identified the following business requirements for continued SIT-209 support:

5.1 LIST OF REQUIREMENTS

REQUIREMENT NO.

REQUIREMENT REFERENCE

1 Simplify new user access. UC 1 Create Access Rights

2 Establish Single User/Password sign-on for all FAMWEB applications.

UC 2 Login

3 Create software process to automate sharing of like data between SIT-209 and WFDSS.

UC 7 Retrieve 209 Data

4 Create software process to automate sharing of like data between SIT-209 and ROSS

UC 7 Retrieve 209 Data

5 Create software process to automate sharing of like data between SIT-209 and CAD application.

UC 7 Retrieve 209 Data

6 Build SIT-209 ad-hoc reporting tool to allow users to build custom reports.

UC 6 Generate Reports

7 Identify a common entry point for initial fire data (e.g., WFDSS) across agency boundaries

To be defined

8 Define a primary key shared by all applications (e.g., Fire ID) to link records of the same event across multiple systems.

Appendix C, Section 7.3.4 – Redesign Findings Presentation, November 18, 2009.

9 Define standard data attributes for shared data (data type, field length, etc.)

To be defined

10 Create a software process to audit shared data fields across SIT-209, WFDSS, ROSS and CAD applications and report discrepancies.

Section 3 Findings and Conclusions

11 Create a software process that supports the identified business rules.

Appendix G – Business Rules

5.2 REQUIREMENTS DIAGRAM

6. BUSINESS CASE

6.1 BUSINESS CASE DEFINITION

The following business case options were defined by the SIT-209 project team members in the SIT-209 Detailed Statement of Work between Commonthread and NWCG.

a) Identify and support SIT-209 through technical refresh and life cycle renewal,

b) Incorporate SIT-209 into another application, or

c) Allow SIT-209 to go end-of-life and retire in place.

6.2 LIST OF RECOMMENDATIONS

NO. RECOMMENDATION REFERENCES

1 The SIT-209 application must undergo technical refresh and life cycle renewal to meet existing business needs and to ensure the continued availability of critical data. This is the preferred option identified by the SIT-209 project team based on interview results and business requirements.

Appendix F – Stakeholder Interview Statements by Category

2 At this time, the SIT-209 should not be brought within another application. Candidate applications for incorporating SIT-209 functionality include WildCAD, WFDSS and ISuite. Of these three applications, the only one that is web-based is WFDSS. The WFDSS application is evolving to meet currently identified business needs and this expansion of scope cannot occur within the near future. However, WFDSS is currently receiving data from WildCAD and WFDSS staff have indicated that an exchange of data with the SIT-209 System is possible.

Appendix C, Section 7.3.4 – Redesign Findings Presentation held November 18, 2009.

Appendix I – Crosswalk of Data Elements to SIT-209 & WFDSS

3 The SIT-209 System should not be retired at this time. The value of the SIT-209 data continues to grow as the need for information increases at all levels of government and within the general public. Indeed the need for SIT-209 data is validated by the fact that the Department of Homeland Security (through FEMA) plans to integrate ICS forms within the National Incident Management System (NIMS). Note: FEMA currently has no plan to create its own incident reporting system.

http://www.fema.gov/txt/nims/nims_ics_ position_paper.txt (see Appendix J).

http://www.fema.gov/txt/nims/nims_ics_position_paper

This page is intentionally blank.

7. APPENDICES

7.1 APPENDIX A – GLOSSARY OF TERMS AND ACRONYMS

TERM DEFINITION

AMR Appropriate Management Response

BAER Burned Area Emergency Rehabilitation

BLM Department of Interior, Bureau of Land Management

CAD Computer Aided Dispatch

FEMA Federal Emergency Management Agency

FMIS Fire Management Information System

FORS Fire Occurrence Reporting System

FPA Fire Program Analysis

FWS Department of Interior, Fish and Wildlife Service

GACC Geographic Area Coordination Center

GAO Government Accountability Office

GIS Geographic Information System

GPRA Government Performance and Results Act

GPS Global Positioning System

ICS Incident Command System

ICS-209 Incident Status Summary Report

IMSR Incident Management Situation Report

IT Information Technology

MAC Multi-Agency Coordination Groups

NASF National Association of State Foresters

NIMS National Incident Management System

NPS Department of Interior, National Park Service

NWCG National Wildfire Coordinating Group

NWFEA National Wildland Fire Enterprise Architecture

ROSS Resource Ordering Status System

SME Subject Matter Expert

USFS United States Department of Agriculture, Forest Service

WFDSS Wildland Fire Decision Support System

WFIP Wildland Fire Implementation Plan

WFMI Wildland Fire Management Information System

WFSA Wildland Fire Situation Analysis

7.2 APPENDIX B – PROJECT TEAM

TEAM MEMBER TITLE

Christensen, Sue GACC Intel Coordinator, Lead of Predictive Services - Acting

Dingman, Gina GACC Intelligence Coordinator, Easter Great Basin

Ervin, Dan FAMWEB System Administrator, Fire & Aviation Management, USFS

Leonard, Charlie Intelligence Operations Coordinator, NIFC

Polutnik, Julie B. GACC Intelligence Coordinator, Northern Rockies

Risher, Bruce GACC Intelligence Coordinator, California South Operations

Vest, Keri Project Manager, Fire & Aviation Management, USFS

Willey, Marva J. GACC Intelligence Coordinator, California North Operations

Tae, Michele Consultant, Commonthread, Inc.

Barney, Jean Technical Analyst, Commonthread Inc.

7.3 APPENDIX C – PROJECT MEETING NOTES

Project meetings were held on these dates:

 August 3, 2009 - Project Kickoff

 October 1, 2009 - Project Update

 November 5, 2009 - Project Update

 November 18, 2009 - Redesign Findings Presentation (Tahoe)

 December 11, 2009 – Business Requirements Report Draft Review

Project notes follow in calendar sequence.

7.3.1 SIT-209 Kick-Off Meeting held August 3, 2009

This contract is foundational to solicit and validate user requirements mainly through user interviews, survey or other means of gathering information about the who, why and what of this application.

Meeting Attendees

Michele Tae, Dan Ervin, Keri Vest, Julie Polutnik, Sue Christensen, Trudy Fagre, Gina Dingman, Charlie Leonard, Note taker: Keri Vest

Summary of Topics Covered

 Introductions

 Review of Statement of Work

 Clarification of Expectations

 Requirements Questions

 Meeting Comments

 Dan gave history of SIT & 209 & his vision of the use of the data. Who is responsible party for the need for this information?

 SIT-209 does not exist just for NICC (misconception)(academia, research, DC).

 Much higher level of scrutiny & level of interest from USDA & DOI.

 Data requests include IMSR, direct raw data.

 Who is the business area/ sponsor (define)?

 What is the SIT-209 future?

 How might it take advantage of other applications?

 VISION: What is SIT-209--a reporting tool, or information sharing or resource tracking?

 Identify within SIT-209 what information is available from where and how we might use it. We want to validate the data, determine data sources (no redundant storing of data/effort)

 Validate the ‗only‘ interagency database for incident information (although not a system of record).

 SIT-209 committee did an informal survey. Gina has information.

 Action Item: Send survey results to Michele Tae.

 Direction to Use SIT-209? National MOB Guide (NWCG).

 Action Item: Send web link to MT for NMG (Charlie).

 The application MUST NOT STAND ALONE. Tie into another application/eliminate duplication.

 Decision: Agreed to this Process for Discovery: Michele will collect, synthesize existing information and develop some statements to present to small groups of stakeholders for them to have something to react toward rather than having a general free for all meeting which may only bring out more anecdotal information.

Stakeholders

 Need to include NIMS (possibly Vanessa Burnett), Steve Gage (FS)

 Action Item: Committee will each send MT stakeholder names

 Develop a list of proposed stakeholders at all levels of the organization that use the SIT-209 application in any capacity. This should include interagency fire directors, local, regional, national Intel users, IMT members (SITL, IC), etc.

Layout Initial Milestone Dates Toward Completion

 Three phases

 Discovery, Elaboration, Close Out

 Status meetings every 3 weeks

 Next general meeting Sept 3, 2009 @ 11:00 MDT (Keri to send meeting notice)

Determine Delivery Date(s)

 November 13, 2009 for completion of preliminary draft.

 Week of Nov 17 th National Intel Meeting at Lake Tahoe, NV.

 Will do presentation of SIT-209 redesign status.

7.3.2 SIT-209 Project Status Meeting held October 1, 2009

Meeting Attendees

Keri Vest, Charlie Leonard, Gina Dingman, Dan Ervin, Julie Polutnik and Michele Tae attended the meeting.

Discussion

 The interviews with SIT-209 project team are complete. The results were documented, reviewed and finalized.

 The Interview Findings document is being drafted. The conclusions will follow.

 At our last status meeting, we noted that the Business rules and Crosswalk from Business Needs to Data Elements could be discussed as part of the interviews. The discussion of these documents involves too much detail to do by phone.

 The interviews focused on the priorities for the redesign.

 The efforts that are currently underway such as the development of a COGNOS interface to the SIT- 209 data are considered to be part of the redesign effort.

 No meeting with the Incident Commanders is required. The phone interviews with the SITL Contacts should provide the desired information.

 The redesign business requirements will consider two possible options instead of three. The options to be addressed are AS IS and TO BE (redesign).

 Michele Tae will be on vacation from 10/6 through 10/21. The interim contact for Commonthread is Jean Barney.

Redesign Requirements

 The redesign will include the ability for the SIT-209 System to import records that contain valid data and are in the correct format, e.g. records from WildCAD or ISUITE.

 The redesign will include the update of the user interface to include common features such as drop- down menus, etc.

 The redesign will include improved navigation within the system.

 When creating a new ICS-209 form from a prior record for the same incident, the data entry person should have to confirm that each field that is carried forward is accepted without change.

Next Steps

 Conduct interviews of the SITL Contacts. Target date for completion: 11/04/09

 Obtain WildCAD and WFDSS information. Other systems?

 Draft business requirements document

 On Thursday, 11/05/09, a meeting will be held at NIFC to walk through the draft business requirements document including business rules and data elements. Those who cannot travel will use Net Meeting or other tools.

7.3.3 SIT-209 Project Status Meeting held November 5, 2009

Meeting Attendees

Michele Tae, Keri Vest, Charlie Leonard and by phone: Gina Dingman, Julie B Polutnik and Dan Ervin

Current Project Status

 Documentation for all interviews is complete. There is an ongoing effort to contact Dispatch Center staff whose names were provided by Julie B Polutnik. They were contacted and we are still trying to arrange interview times. They will not be included in the report if we cannot interview them by 11/13/2009.

 The initial draft of the Business Use Cases and the Summary of Findings and Conclusions was reviewed during the meeting. Updated versions are included with these notes.

 Other documents completed to date include: Business Rules, Crosswalk of Business Needs to Data Elements and Interview Findings by Category

 The project has two significant upcoming events: The completion of the initial draft of the SIT-209 Redesign Business Requirements report by 11/16/09 and the presentation of the findings to the Predictive Services Meeting the week of 11/16/09.

Other Comments

 There is an inherent difficulty with how the SIT-209 data is currently being used. The data is clearly a ―snapshot‖ in time for the incident. This snapshot will most always differ from ―real time‖ data due to the changing nature of incidents. Some of the downstream customers for 209 data may have an expectation that the data is close to real time. Changing these expectations is difficult. This situation cannot be remedied by any changes to the SIT-209 application based on the current business rules.

 Incident data could be reconciled over the life of an incident by comparing ICS-209 data with other systems that contain the same or similar data such as CAD Systems and WFDSS. The CAD Systems and WFDSS would send data to a SIT-209 data store. The SIT-209 Application would access the data store to update ICS-209 data or to identify inconsistencies in reporting. The SIT-209 System could also support an end-of-year reconciliation by comparing data from the Final Fire Report, SIT-209, YTD Fire Statistics, etc.

Outstanding Tasks

 Keri agreed to provide descriptive database documents for WildCAD, Altaris CAD and WFDSS to Commonthread as soon as possible, preferably before 11/13/09.

 Michele will pursue interviews with Dispatch Center staff.

 Michele will send a draft of the PowerPoint presentation to Charlie and Keri by Thursday, 11/12/09.

7.3.4 SIT-209 Redesign Findings Presentation held November 18, 2009

Notes

 Michele Tae presented an overview of the SIT-209 Business Analysis findings and conclusions at the Northstar at Tahoe Resort on November 18, 2009. The following comments were recorded following the presentation:

 We understand that the purpose of the SIT-209 is to report a snapshot in time for an incident status. Can we make 209 dynamic? Fire management has changed so there is now a need for new reporting and new performance metrics. When asked about specific performance metrics, the answer was: a way to track that Incident Management Team (IMT) decisions are tied to Land Management Plans or After Action (AA) deliberations of authority objectives. This makes reporting accomplishments down the road easier.

 It is difficult to track these performance metrics at PL 5. Often performance objectives cannot be met due to LACK of resources, which may be fallout from a decision that is out of our control like NMAC allocation, for example.

 We need better reporting when things get busy to help prioritize resource allocation (i.e. are aviation assets meeting the needs where they are located? What happens if I move them somewhere else? Probably not 209 type data today but maybe down the line—maybe it is WFDSS data.

 Change is being driven from the WFLC level. Congress wants to know what drove our decisions. Are our metrics adequate for the world we now occupy? Data is becoming increasingly important to a wider audience. We need to be looking at how to elevate visibility.

 Technology needs to serve the business case. How dynamic does the system need to be? How many times a day does NMAC meet and need the data for decisions? If we make it too cumbersome for the workforce or system support, it will gridlock.

 Eventually the NIMS 209 form will become part of the SIT-209 program. The Redesign will incorporate how we integrate with the NIMS system. All Risk options will be embedded. Therefore, WFDSS will not be the one stop data shop.

 The States do not support WFDSS as they do not support long-term fire management. They do not understand that WFDSS works for full suppression as well; it is just an option for WFDSS. It should not be hard to have States engage with WFDSS, especially if it does not cost them.

Other Findings:

 WFDSS can send data to SIT-209. WFDSS programmers coded the existing data interface that sends data to WFDSS from WildCAD. A similar interface could send data from WFDSS to SIT-209. Contact is Rob Seli, the Business Lead for WFDSS.

 ROSS can send data to SIT-209 through a data extract via COGNOS. A similar extract of resource and incident data now exists between ROSS and ISUITE. Rex Alford is the contact for ROSS.

 A single, unique incident identifier was mentioned as a barrier to interfacing with other systems. There seem to be a consensus that this issue has existed for a long time and should be resolved in the most expedient fashion so that interfaces between SIT-209 and other systems are not hampered.

 SIT-209 data is being used by SMARTFIRE. What other applications use SIT-209 data? It would be good to list them in the business case.

Issues/Questions

 Contact persons for WildCAD and Altaris CAD should be identified. We can then inquire about the feasibility of an interface with SIT-209.

 Should a mock-up of the redesigned system user interface be included as part of the business requirements? This would communicate not only added functionality but also the look and feel. It would need to be simple. A vision diagram may accomplish the same thing with less work.

7.3.5 Business Requirements Report Draft Review help December 11, 2009

Meeting Attendees: Keri Vest, Charlie Leonard, Dan Ervin, Jean Barney and Michele Tae. By phone: Marva Willey.

The topic of discussion was the review of the final draft of the SIT 209 Business Requirements Report. The following changes were identified:

1. Remove references to NWCG. Replace the NWCG logo with the logos for Predictive Services and Fire and Aviation Management.

2. Dan and Charlie sent changes to the document before the meeting. All these changes were accepted.

3. Reference to NWCG was removed from the Project Background and replaced with the Intelligence Working Group within Predictive Services.

4. Add a note to the UC Diagram to indicate that the numbers reference the table on the following page. Also, make the graphic less busy if possible. We can consider using a pattern for the AS IS use cases with a legend that identifies the AS IS and TO BE objects.

5. Make the number format for the use cases consistent from the diagram to the table.

6. Add a table to Appendix D that identifies the customers for the SIT 209 Application. Customers include Academia (Researchers), Elected Officials, e.g. Congress and State Legislatures, State Governments, the Executive Branch (White House), Department of Defense, Federal Emergency Management Agency (FEMA), U.S. Department of Interior, U.S. Department of Agriculture, Fire Planners, External Affairs.

7. Add a table to Appendix D that identifies the stakeholder groups for the SIT-209 Application.

8. Include a reference to the List of Recommendations in the Executive Summary.

9. Include the position paper for NIMS in the Appendices.

10. Change the spelling of ―Vernessa Bernett‖ to ―Vanessa Burnett‖.

11. Note: Consider adding a member of the NIMS IT Group to the SIT 209 IT Group.

12. Remove business rules that are derived from the SIT 209 Survey and the E2E_Background process flows.

13. Remove the Critical column from the Data Elements by Business Need list and include a paragraph that explains the origin of the data.

7.4 APPENDIX D – STAKEHOLDERS

7.4.1 Stakeholder Groups

Stakeholder groups are organizations with staff members that are actively involved in the SIT-209 Project, exert influence over the SIT-209 Project‘s objectives and outcomes, or may be directly affected by the SIT-209 Project execution or project completion.

GROUP ACRONYM GROUP NAME

BLM Bureau of Land Management, United States Department of the Interior

FAM Fire & Aviation Management, USDA-FS

GACC Geographic Area Coordination Centers

NIFC National Interagency Fire Center

NICC National Interagency Coordination Center

USDA-FS Forest Service, United States Department of Agriculture

7.4.2 Stakeholder Interviews

Individuals representing key stakeholder groups participated in interviews as part of the SIT-209 Project. Interview statements formed the basis for findings and conclusions presented in this report.

DATE OF INTERVIEW

INTERVIEWEE TITLE

09/15/2009 Gina Dingman GACC Intelligence Coordinator, California South Operations

09/16/2009 Dave Hart GACC Manager, Eastern Great Basin

09/16/2009 Julie Polutnik GACC Intelligence Coordinator, Northern Rockies

09/18/2009 Marva Willey GACC Intelligence Coordinator, California North Operations

09/21/2009 Dan Ervin FAMWEB System Administrator, Fire & Aviation Management, USDA-FS

09/21/2009 Charlie Leonard Intelligence Operations Coordinator, NIFC

09/25/2009 Sue Christensen GACC Intel Coordinator, Lead of Predictive Services - Acting

09/25/2009 Bruce Risher GACC Intelligence Coordinator, California South Operations

09/29/2009 Keri Vest Project Manager, Fire & Aviation Management, USDA-FS

09/30/2009 Stephanie Church Dispatch Center Manager, Boise Interagency Dispatch Center

11/24/2009 John Noneman Project Manager, Situation Unit Leader, BLM NIFC

11/24/2009 Rick Tholen Situation Unit Leader, BLM NIFC

7.4.3 Customer Groups

Customer groups are direct or indirect consumers of the information provided by the SIT-209 application. The following is not a complete list, but serves to indicate the range of federal, state and local entities, including the general public, that have a vested interested in wildland fire management.

NATIONAL, STATE AND LOCAL GOVERNMENT AGENCIES

 Federal Emergency Management Agency (FEMA)

 Military Forces: Air Force, Army, Navy, Marine Corps, National Guard, Coast Guard

 National Park Service, United States Department of the Interior (NPS)

 National Wildfire Coordinating Group (NWCG)

 State and Local Emergency Response

 State Bureau of Homeland Security

 State Department of Agriculture

 State Department of Fish and Game

 State Department of Lands

 State Parks and State Forest Management Agencies

 United States Bureau of Land Management

 United States Bureau of Reclamation

 United States Department of Agriculture (USDA)

 United States Department of Defense (DOD)

 United States Department of Homeland Security (DHS)

 United States Department of the Interior (DOI)

 United States Fish and Wildlife Service (USFW)

NATIONAL, STATE AND LOCAL ELECTED OFFICIALS

 Executive Branch (White House, State Governors, City Mayors)

 Legislative Branch (U.S. Congress, State Legislatures, City Commissioners)

GENERAL PUBLIC

 Environmental Groups

 Industry Groups (e.g., Forest Products, Livestock Grazing)

 Private Landowners

 University and College Researchers

7.5 APPENDIX E – INTERVIEW ANALYSIS CATEGORY DEFINITIONS

Interview statements were analyzed to determine common topics of concern among stakeholders.

CATEGORY NAME

CATEGORY DEFINITION

Access Control Statements regarding initial user setup, daily login procedures, and access rights.

Audience Statements concerning the composition of the audience and how data is used and interpreted by that audience.

Data Capture Statements concerning duplication of data entry, ease (or difficulty) of the data entry interface, and frequency of data entry.

Data Integrity Statements concerning the reliability or accuracy of data, and the ability to reconcile data against other systems and/or across different timeframes.

Reporting Statements that describe content, frequency and the ease (or difficulty) of creating reports.

System Integration

Statements regarding what systems are used by various agencies, what data is shared by these systems and the feasibility or desirability of system integration.

7.6 APPENDIX F – STAKEHOLDER INTERVIEW STATEMENTS BY CATEGORY

Each interview statement was analyzed to determine which categories of concern applied to that statement.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

1 Business Process: Scope and Authority define the access to the SIT-209 System. The Scope defines whether the user is Local, National or GACC. The Authority defines whether the user is PIO, Report, Entry or Manager.

2 Business Process: Once a team is brought in to manage a fire, a member of the team is given Entry access by the GACC. When the fire incident is closed, this team members‘ access to the incident is revoked.

3 Business Rule (AS IS): Users with PIO and Report Authority can only view data.

4 Business Rule (AS IS): Users with Entry or Manager authority can add, change, view or delete data.

5 Business Rule (AS IS): Users designated as Local Scope and Entry Authority can view, add or update data for the local dispatch center only.

6 Business Rule (AS IS): Users designated as National Scope and Entry Authority can view, add or update data for any dispatch center in the nation.

7 Business Rule (AS IS): Users designated as GACC Scope and Entry Authority can view, add or update data for all the dispatch centers within their GACC only.

8 Business Rule (AS IS): Users designated as PIO or Report Authority can view data as defined by their Scope, i.e. local dispatch center, dispatch centers within the GACC or all dispatch centers within the nation.

9 Business Rule (AS IS): Access is defined through the chain of command. The GACC authorizes access for the local dispatch center and NICC authorizes access for the GACC.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

10 Reporting (AS IS): The SIT-209 reports data in the Daily Situation Report.

11 Reporting (AS IS): The Daily Situation Report contains multiple pages of information.

12 Reporting (AS IS): First Page shows number of fires by agency by dispatch center and the number of human-caused fires with acres burned and the number of lightning-caused fires with acres burned.

13 Second page addresses fire resources and is not useful because it asks for prediction. GACC and National levels do not use this page.

14 Reporting (AS IS): Third page contains the Planned RX fires.

15 Reporting (AS IS): Fourth page contains general remarks.

16 Reporting (AS IS): Fifth page identifies who is ―on call‖ and the Preparedness level for the dispatch center.

17 Reporting (AS IS): Sixth page defines the priority of the incidents based on criteria such as fire resources used, acres burned; homes threatened, etc. The most critical (#1) priority is defined.

18 Reporting (AS IS): Priorities are also set at the GACC and NICC levels. This allows scarce resources to be allocated to the most critical need.

19 Reporting (AS IS): Note: The IMSR is prepared at the national level. Contact Charlie Leonard for more info.

20 SIT-209 (TO BE): Populate the SIT-209 data from other systems such as WILDCAD, CAD and/or WFDSS.

X X

21 SIT-209 (TO BE): Should explore linking WildCAD and WFDSS data to the SIT-209. Should explore a daily update of data to avoid redundant data entry.

X X

22 SIT-209 (TO BE): Carry data for an incident forward from any prior SIT-209 entries.

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

23 SIT-209 (TO BE): Add the ability to report incidents that are being managed for ecological benefit, including all relevant statistics, such as acres burned, fire resources used, etc. This allows an accurate report of the fire on the ground as part of the national SIT report and gives a more complete and accurate picture of national fire activity.

24 Is there or should there be a relationship between the Fuel and Fire Behavior Advisory and the SIT-209 System?

X X

25 Is there or should there be a relationship between the National Wildland Significant Fire Potential Outlook (WSFPO) and the SIT-209 System?

26 Is there or should there be a relationship between the 7-Day Significant Fire Potential and the SIT-209 System?

27 Which is the master system, WFDSS or WILDCAD or SIT-209?

X X X

28 Should the SIT-209 System prevent deletion of data? Background: the system now allows an authorized user to delete data, which causes problems when the delete is a mistake.

X X

29 Should the system allow a user to inactivate the data for a given reason so that this action can be reversed when needed?

X X

30 Is the access that is given to a team member for a specific fire incident only or for all fires within the dispatch center?

31 There is a current effort to link the WildCAD system with WFDSS. One of the goals is to share common data across these two programs. Roshelle Peterson can be contacted for more information.

32 Who is the audience for the information? What is the business process that the system is intended to support?

33 Should we continue to store data as a snapshot in time or should we move to a real time system? A snapshot may be fine for the WO but does not meet the needs of other audiences.

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

34 What is the impact of the implementation of the new National Fire Policy on data collection, especially for fires that are managed for resource benefit?

35 The redesign effort should not be constrained by the legacy system.

36 An accurate picture of the current fire situation is needed. Currently the data in the SIT-209 and the data in WFDSS do not match. Different people have different sources for the same data, confusing the view of the current situation.

X X X

37 WFDSS is a national web-based program that was developed by the USFS. Currently the USFS management direction is to implement the use of WFDSS on all fires. The other agencies have not yet moved in that direction.

38 Rules for use of the different tools vary by GACC. On Dave‘s GACC, all resource benefit fires are recorded on a 209.

39 It may be helpful to view the Dispatch Efficiency Study, which can be found on the USFS homepage under Efficiency.

40 Alternative One: no change – this alternative perpetuates the problems with the current system that includes redundant data entry and the associated risk of error.

41 Alternative Two: Upgrade SIT-209 System to eliminate redundant data entry wherever possible, as well as other improvements. This is the best of the three alternatives.

42 Alternative Three: Eliminate the SIT-209 and harvest the data from other systems. This is unrealistic since the need for reporting will continue to be critical.

43 Disadvantages of the SIT-209 include redundancy of data entry, bad data and history that is inaccurate.

X X

44 One of the big problems with the current situation is that the resource numbers differ from system to system. Managers compare reports from the different systems and ask why numbers do not match.

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

45 There would be value in having the data from all the different systems that track fire resources agree.

X X

46 The YTD total for the number of fires should always be accurate. When the number of fires that occur on a given day is changed, the YTD totals should adjust for that day and all subsequent days. Currently the system does not record this accurately.

47 Most SIT-209 errors or misrepresentations result from errors in data entry. The human interface is made more difficult due to multiple systems.

X X X

48 We discussed three systems that might provide data to the SIT-209: WildCAD or another CAD system, WFDSS and ROSS.

49 ROSS contains the most accurate information for resources assigned to an incident.

X X

50 Not all agencies use a CAD system or WFDSS, which makes ROSS the better choice for those incidents that use fire resources. Incidents that do not use fire resources would need to be entered in the SIT-209 directly.

51 SIT-209 should pull data from ROSS or ROSS should push it.

52 We need to identify the data that also exists in ROSS.

52 Data entry needs to be simple for the folks in the field. In California, all the agencies put data into a CAD (Computer Aided Dispatch) system, such as Altaris CAD or WILD CAD. Then data is entered into CAL FIRE and for aircraft resources only, data is entered into ROSS.

X X

53 CAD systems are starting to link to ROSS also. X

54 Large Incident Report comes from the SIT-209 data, as well as other reports.

55 With the exception of the ABCD size fires, the Fire Code is assigned to an incident in the standalone Firecode System before the SIT-209 record is created.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

56 Fires that are managed for resource benefit may not have a Fire Code and may not use resources. Whether these fires are in the SIT- 209 System is at the discretion of local or GACC management.

57 Generally, the SIT-209 data originates with the dispatch center or the ranger district by the FMO.

58 The Incident Commander Area Commander meeting is a good venue to get input from the ones who have their name on the report. They could address what management information is needed, whether what currently comes out of the system is useful, how easy the system is to use, and downstream reporting requirements.

59 Firecode is not the only system used for Incident Charge Codes. Firecode is the Federal agencies' incident fire code system. State agencies use their own systems. Additionally, the agencies (Federal and State) may have different guidance as to whether a unique Firecode should be issued for wildfires under 300 acres; such as human caused, trespass, expected reimbursement, cost share and a Type 1,2, or 3 Incident Management Team assigned.

60 Priority for the Redesign: Ease of data entry and ability to report.

X X

61 The SIT-209 System needs to be updated to be accessible for all agencies. It should be a database that is accessible from a reporting tool such as COGNOS. This is needed to respond to requests for information. The majority of people think the SIT-209 is the source for all fire info. IRWIN should provide the kind of connectivity between applications that is needed. However, by the time IRWIN is implemented it may be outdated due to technology and changes in business processes and the amount of time required for IRWIN to be funded and implemented.

X X X

63 If we make it easier to enter the data then we will get better data to report.

X X X

64 If we could harvest data and create candidate entries in SIT-209 and then push to other

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

programs.

65 The Activity Log may be a source of data for SIT-209.

66 If you know the program, working with the SIT- 209 system is not too difficult. The system is out-of-date in terms of ‗look and feel‘ and its‘ ability to produce a product that is useful to the field. Reports now seem to be for the Washington Office and are not customizable for local needs.

X X

67 Business Process (AS IS): The business process now includes every unit within the GACC entering their data every day and once a month the units validate with a monthly report to the GACC. Accurate numbers exist only at the first of the year and the first of the month.

X X X

68 Business Process (AS IS): The SIT-209 tracks the number of fires and acres at a point in time. At the end of the day, the SIT-209 is used to report activity, which is subject to change based on the real-time nature of the situation. Fire is always changing and cannot be reported accurately except through direct observation.

X X

69 Business Process (AS IS): SIT-209 does some totaling but no analysis. It is a reporting system only.

70 Business Process (AS IS): ROSS only knows what we tell it to know and is usually incomplete. There are fires that never go into ROSS. Initial Attack is done on many more fires than those that are in ROSS.

71 Business Process (AS IS): California broke the SIT-209 program last year by exceeding the number of agencies that can be entered on the data entry form. This was a nightmare for the people on the ground.

X X

72 Business Process (AS IS): Last year more explanation space on the 209 was needed to help the GACC make better decisions. There was not enough room on the form to enter all the information that was needed. For example, there were 100 fires in a single complex and the staff in the field could not input enough data

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

about each fire.

73 Business Process (AS IS): Every incident is entered into the WildCAD system, including fire reports such as campfires. Complexes are entered but only to get a fire number.

X X

74 Business Process (AS IS): Now every ignition must be entered in WFDSS. If we need to do analysis on the fire, then we use WFDSS with WildCAD inputs.

X X

75 Business Process (AS IS): In California CALFIRE folks use Altaris CAD, which talks to ROSS. Altaris CAD is a more robust tool than WILDCAD and talks to ROSS. There is a current effort to try to get WILDCAD data to ROSS data.

76 Business Process (AS IS): WildCAD is an MS ACCESS DB and does not interface well with other programs.

77 Business Process (AS IS): The GACC calls all units every night and checks on the status of the SIT Report. Sometimes numbers are just thrown into the system. There is often no time to validate the report. BAD data is sometimes perpetuated just due to time constraints.

78 Business Process (AS IS): Users have learned that if you have structures or power lines threatened, you get resources. The system can be gamed to get fire resources. Resource counts and costs are often just a guess.

79 Business Process (AS IS): The first priority of the Dispatch Center is to get resources to the incident and the CAD program identifies the resources to send based on fuel types and historic data.

80 Business Process (AS IS): In the rush of multiple incidents with all the competing priorities, dispatchers may be overwhelmed and the SIT reports have reduced priority.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

81 Business Process (AS IS): The Activity Log data is harvested from other systems; neither WildCAD nor Altaris CAD share Activity Log data.

82 Business Process (AS IS): The national level of fire management relies on ROSS to report activity but it is not complete picture of the current activity.

83 Business Process (AS IS): The information on resources is always at a point in time – snapshot. Changes are always occurring.

X X

84 The audience for the SIT-209 data from the perspective of the Intel community includes the Washington offices for DOI and USDA, the White House and Congress.

85 These audiences would like to have ―up to the minute‖ data whenever possible. No one really expects that the data is ―real time‖ since situations change rapidly.

X X

86 It is possible to submit a situation report at any time of the day and multiple reports during any one day especially when this is warranted by high-visibility incidents. The system can handle multiple daily reports but the dispatch centers seldom have the time to create more than the one required daily report.

X X

87 The numbers of fires and acres rarely agree across the different fire reporting systems. It is possible for the daily situation report to agree with WFMI and Firestat systems but it requires that the dispatch center manually reconcile the data between the different systems.

X X X

88 Charlie has provided an example of the spreadsheet he used to do this kind of reconciliation when he was at the Boise Dispatch Center. The business requirements can include a recommendation that the dispatch centers perform this kind of reconciliation.

89 Reasons why the acres don‘t agree: some GACCs place low importance on reconciliation, understaffing, lack of adequately trained personnel, disdain for intelligence gathering, initial estimated acres do not match final reported acres.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

90 One of the major goals of the redesign should be to ensure that the data that is entered in systems such as WildCAD carries over to the SIT-209 system. Note: WildCAD is primarily used in the dispatch centers located in the western states.

X X

91 There is a general direction across the agencies to standardize data whenever possible.

92 ROSS only includes non-local fire resources that are deployed to a significant incident. It does not include local resources that are initially sent to an incident. Therefore, there is not a completely accurate tracking of available fire resources. ROSS is not used in CA except for aircraft resource tracking.

X X

93 There is no ability to analyze the data in the SIT-209 system. User access to the data is through the individual fire incident and it is not possible to look across incidents except by making a request of the system administrator. The SIT-209 system needs a COGNOS-type tool for extracting and reporting data. Ideally, the extraction tool would provide tabular data that could be manipulated using capabilities of a reporting tool and/or exported to something like Excel. Currently there is no way to extract or compare the data on a field-by-field basis.

94 Redesign of the SIT-209 should eliminate duplicate data entry. IRWIN is supposed to fix this but something needs to be done now.

X X

95 Data entry needs to be easier and more automated. For example, the 209 must be submitted in sections and it is difficult to correct entries in already-submitted sections.

X X X

96 Carryover of the previous day‘s entries to the current day‘s 209 is not a good idea. People tend not to go back and update a field that has already been populated, either due to time pressure or lack of incentive.

X X

97 WildCAD is not networked so that makes data sharing difficult. In addition, it is used at the GACC level but not at the incident level. Not all Dispatch centers use WildCAD.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

98 One problem with acreage reconciliation is that the same acres are often claimed by more than one agency.

X X X

99 It is cumbersome to enter resources into ROSS because there are multiple steps needed to track each resource: create incident, add resource, reassign if necessary, etc.

100 If one Dispatch center is required to do something, others may follow suit.

101 One problem with automating the creation of the IMSR is that the IMSR content and format fluctuate at the discretion of the Fire Directors.

102 SIT-209 (TO BE): Provide ad-hoc reporting capability to facilitate data mining (already being addressed)

103 SIT-209 (TO BE): Eliminate duplicate data entry by automating data population between systems

X X X

104 SIT-209 (TO BE): Restructure database tables (esp. Resources table) to accommodate data evolution and the ability for multiple dispatch offices to report a single unit identifier.

X X X

105 SIT-209 (TO BE): Enable single sign-on to streamline user authentication

106 Ad-hoc reporting capabilities from SIT-209 will be met outside of the redesign process. A solution is already in the testing phase.

107 The proposed solution uses COGNOS as the user interface. Oracle Warehouse Building (OWB) points to the SIT-209 OLTP Server to create a data repository to satisfy COGNOS queries.

108 The proposed solution was tested successfully in the development NESS environment running on IBM pSeries 650. However, problems have been encountered in the production NESS environment where the platform is IBM pSeries 570s. The cause(s) of the problems have not been identified but a resolution is expected.

109 An alternative solution for COGNOS reporting is to eliminate the OWB layer, but this alternative has not been rolled out for testing.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

110 A ―JAD‖ application development session is scheduled for October 27th through 29th to address the ability of users to access SIT-209 data from COGNOS.

111 One shortcoming of the solution is that subsequent changes made to the SIT-209 source data are not reflected in the warehouse data (are not trapped).

X X X

112 Currently, there is no single point of entry for information on all fires. Use of the system varies depending on the individual Dispatch Center. Dispatch Centers should consistently use a single application for initial entry of fire information. (Multiple dispatch office level software solutions could be used as long as they included a process to submit completed data to the SIT-209 database.) Wildland Fire Computer Aided Dispatch (WildCAD) is the best candidate for entering location and resource information. ROSS, SIT, ICS-209 and WFDSS are not good candidates.

X X

113 Personnel must hand enter the same data into multiple systems which wastes time.

114 Personnel must hand enter the same data into multiple systems creating greater potential for inconsistencies between SIT-209, WildCAD, WFDSS, ROSS and other systems.

X X X

115 A detailed review of all relevant systems should be performed to identify data redundancy and candidate fields for automated entry.

X X

116 On the existing ICS-209 form, the user must enter fire location and then select land ownership and protection responsibility attributes separately. A GIS module could be used to populate ownership and protection attributes automatically using land unit number or location as a key. The data in this module would be updated annually (or on a to-be- determined basis). The module would eliminate data entry steps, would ensure accuracy and consistency in reporting land ownership and fire protection responsibilities, and could be used to validate a fire location, e.g., identify when a specified fire location is outside the relevant geographic area.

X X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

117 Example scenario: Use WildCAD to enter all new fire locations. The GIS module populates landowner and protection information and validates location. At end of the day, the Dispatch Center initiates a ―Submit‖ function from WildCAD to automatically populate the SIT-209 System with the number and size of new fires along with the location, owner and protection attributes. The GACC should have a window of time between the Dispatch Center Submit deadline and the SIT-209 System deadline to validate all information. Another option would be to have WildCAD send the individual fire location by lat/long and size, then the SIT-209 System would determine the ownership/protection for each fire and generate the new fire counts. This would require the SIT- 209 System be given the ownership and protection boundaries.

X X X

118 Once an incident becomes significant, a decision would need to be made whether to use WildCAD to push that fire data to the ICS-209. With the above information being supplied to the SIT-209 System, a list of active fires could be displayed when the Dispatch Center chooses to create a ―new 209‖ report. By doing this the lat/long/ownership/protection information could already exist in the ICS-209 form.

X X

119 SIT-209 actually refers to two different reports that share some of the same data tables at the application level. The SIT Report is the daily situation report with information on all fires and the ICS-209 form reports fires that are deemed significant based on size, resource requirements, response level or factor according to the judgment of the on-site response team.

120 The IMSR (Incident Management Summary Report) is subject to the preferences of the individual Incident Communication Center Manager so it may not be possible to find a widely accepted method to automate the IMSR from other sources such as SIT and ICS-209. The whole purpose of SIT-209 is to automate the creation of the IMSR. With the requirements for the IMSR changing, there is a reduced ability to automatically generate the

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

IMSR.

121 Currently SIT and ICS-209 are not being reconciled. Users only wanted to update year- to-date totals, rather than going back and adjusting individual total acres for fires. Adjusting individual totals could mean having to enter a negative number since fires are sometimes overestimated in size and then later revised when ground crews arrive.

X X

122 Number of acres for a fire is supposed to be rounded to the nearest acre. Rounding is not handled in the same way at all Dispatch centers. (Example: 1/10th acre is 0 acres or ten 1/10-acre fires reported as 1 acre?) This leads to disagreement between SIT year-to- date acres and total of ICS-209 reported acres.

123 An ICS-209 record can be deleted. X

124 The number of fires and number of acres cannot be deleted, but the values can be changed.

125 It may not be possible to automatically generate a list of 209 events based on a list of all fire events, since there is a human element involved in the decision to elevate an event to 209 status.

X X

126 Many programs have capabilities that are not being exploited because people do not know the features exist. Help requests can often be resolved by simply showing people how to do something in the program.

127 The ICS-209 is used for any significant incident that uses wildland fire resources; this includes incidents that are not fires.

128 The ICS-209 is a decision-support tool.

129 ISUITE may contain information used by SIT- 209. (Contact: Gina Bald)

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

130 FORMATA is another tool that may be used to create/edit the ICS-209 form. F&AM is currently looking into this functionality.

131 Resource allocation information is reported on the ICS-209.

132 Resource allocation information is not consistently reported on the SIT (Daily Situation Report).

X X

133 Resource information should come from ROSS or ISUITE, but snapshots in time need to be stored in ICS-209 for reporting purposes.

X X

134 The structure of the Resources table in the SIT- 209 database is not meeting ongoing needs for changes in the type of equipment and crews being used. Column names need to be generic.

X X

135 A program called CHEETAH, which looks at the life cycle of resources, needs to be able to report on resources in a consistent manner. (Contact: Tom Wardell)

136 The SIT-209 is the only interagency application that collects statistical fire information. Other applications are agency specific.

137 GACC and NICC INTEL personnel who are the primary consumers of the SIT-209 data don‘t have any authority over people entering the data, so there is no feedback loop that gives direct incentive for data entry to meet the needs of INTEL.

X X

138 In the current FAMWEB environment, users must enter authentication credentials multiple times to gain access to different applications. The usernames and passwords are often different. A single sign-on for FAMWEB would be preferable.

139 The ICS-209 form has changed over the years and currently meets our business needs.

140 There are inconsistencies in the data across WildCAD, WFDSS, SIT-209 and other related systems. While obtaining 209 data from other systems is desirable, these inconsistencies are difficult to resolve.

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

141 The SIT-209 System was created to serve the needs of the fire community with the audience defined as internal to fire management operations. Neither the SIT-209 System nor the business processes that support it should change to be more transparent to the public or other audiences.

142 The current SIT-209 form for reporting fires meets our information needs for planning and operations. This form has evolved over many years with input from users, the GACCs and fire management.

143 The deletion of the field for wildland fire use has created confusion as the manual is not updated and the field is still on the form.

X X

144 At the GACC we are responsible for a small portion of the Daily Situation Report. We enter the number of fires and the number of acres for the day and the year-to-date (YTD) totals. We must update the YTD numbers frequently in CAL Fire. The cutoff for the end of day report for the SIT-209 is 5 pm while the end of day for CalFire is midnight. The more accurate numbers for CalFire are from the prior day‘s report.

X X X

145 The field that asks for the number of planned RX fire should be removed. That field is not used at the local or GACC levels. All other tabs are important.

146 At the GACC level we do not have fire resources of our own. At the local Dispatch Center it is important to know the fire resources that are on hand for next day.

147 For the Dispatch Centers within our GACC, a report of all the fire resources at each station is faxed to the GACC every morning. This is usually more current than the report from the previous night.

148 At the GACC we occasionally need to report to the Washington Office (WO) on fire resources on hand and we use the SIT-209 reports to get this information.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

149 For years we have discussed getting data from other systems so as to avoid redundant data entry and the associated errors. This is definitely desirable but may not be realistic. The biggest problem is getting a commonality of data across all programs. For example, the incident identifier can be 3 or 4 letters. Establishing the mechanisms for different programs to talk to one another is another issue.

X X X

150 The SIT-209 System was not meant to be a management tool but an information tool. It is a summary of activity and should not be driving our decisions. The audience that is interested in this information seems to be getting bigger. For instance, some audiences look at costs as actual instead of an estimate. The audience was originally the local fire managers and the regional head of FAM. The information in the SIT-209 is not required to be a literal representation of fact.

151 The initial audience for the SIT-209 was not the public. The information needs of the public should be addressed separately. This is especially true when we consider statements of priority or risks. The public will not understand why we choose one priority over another. We need to be careful that information is not misconstrued causing alarm. The SIT-209 information is now much more visible and it was not intended to be that way. The SIT-209 meets the needs of the original audience. Any new audiences should not drive changes to the SIT-209 but have rather their needs addressed separately.

152 There is a once daily requirement to update the SIT-209 information. The SIT-209 is not usually current due to the rapid changes that occur on the ground and the time delay of reporting. This lessens the reliability of the information as a statement of the current conditions.

X X

153 InciWeb is an easier and less expensive way to provide public information. InciWeb now contains more up-to-date information and is better suited for public consumption.

154 No changes are required on the SIT-209 form.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

155 Alaska has developed reports that satisfy their reporting needs but may differ from other parts of the country.

156 The data captured on the daily 209 should represent the current situation as much as possible.

X X

157 There are frequent problems when the data is not updated daily and also when the land ownership is not separated correctly.

158 The SIT-209 login process is cumbersome. The biggest problem is the need for individuals to have their own password. Not everyone who needs to access the system is known prior to his or her need to use the system.

159 It would be great if we could pull over data from WildCAD or other such systems. This data is the most current.

X X

160 We now pull committed resources data from ROSS.

161 There is a disparity between how ROSS and the SIT-209 System enter this data, which requires that the data be checked regularly.

X X X

162 In Alaska if there are more than 17 personnel on a fire, a 209 form is required regardless of acres or type 1 or type. This has helped managers know what fire resources are committed and to justify a request to NICC for more resources.

163 The Daily Summary Report represents the current situation and may not agree with the 209s. In Alaska, we make a concerted effort to keep the SIT reports for individual fires and the daily summary in agreement. Management and ownership numbers are validated daily. We resolve discrepancies on a regular basis. There are only 11 dispatch offices statewide. Since we are smaller, we can stay more in touch.

X X X

164 Paperwork is not a priority on the fire line. The Dispatch Offices differ as to quality of reporting and this also varies based on the situation on the ground.

X X X

165 In Alaska we do our own morning SIT report. Refer to the AICC website.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

166 In Alaska we are currently considering the use of a Canadian dispatch system.

167 Alaska uses the AFS Situation Report and a Filemaker program to update the NICC report. The data used is actually from the prior day.

X X

168 The numbers on the reports often differ because they were collected at different points in time.

X X

169 Now there is much more attention paid to the SIT data than in the past. On the GACCs website, the local area websites are posted.

170 We need to meet the needs of the different audiences.

171 The SIT-209 data contains operational objectives and is intended for the fire community. There is information on this report that could be misconstrued by the public.

172 The media gets updates daily from the PIO with activity and ownership. This information comes from the Alaska SIT report for any staffed fires.

173 The ability to copy header-type data from another ICS-209 form or from another system such as WildCAD

X X

174 Have the application use more standard programming tools rather than hand-coding for program maintenance.

175 Upgrade the look and feel of the application and add tools such as GIS map displays.

176 The data on the ICS-209 is only as good as the entry person who enters it.

177 When possible, the header data on the ICS-209 form should be copied from the prior days ICS- 209 form. The entry person should key the variable, ―point in time‖ data for the incident.

178 ROSS data is not always an accurate statement of fire resources assigned to an incident. The data in ROSS should not be used for planning and should not be used to populate the 209 System.

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

179 The different systems such as ROSS, ISUITE and the SIT-209 may disagree due to the data being collected at different points in time.

X X

180 The ICS-209 form is a statement of the current situation on the incident and reflects the best available knowledge at the time.

181 ICS-209 forms must be created for significant incidents. At the discretion of the local unit the ICS-209 form can be created for other fires.

182 The Incident Commander reviews and approves the ICS-209 forms for significant incidents.

X X

183 The Daily SIT Report is initially created with ICS-209 data from the SIT-209 database. However, this report is modified by the local unit to reflect more current information and cannot necessarily be traced back to the original ICS- 209 data.

X X

184 Reconciliation of fire statistics across systems could be added as a business process. The business requirements for the redesign could describe these potential changes but they will need approval by the business managers.

X X X

185 Some of the data on the ICS-209 forms should not be available to the public and is intended for use by the fire community only.

186 WildCAD is a tool used to track the status of fire incidents and the associated fire resources especially during initial attack.

187 WildCAD contains pre-loaded data such as GIS layers, values at risk, ownership protection responsibility and fire danger ratings.

188 WildCAD is able to export a file that can be input to WFDSS.

189 Dispatch Centers want to be able to choose from among options for entering data in the SIT- 209 System. Options include importing data from other systems and entering the data if it is faster or more convenient.

X X

190 In WildCAD local resources can be assigned to each incident depending on their availability.

191 WildCAD exists as a shared database within the X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

local Dispatch Center.

192 At the discretion of the Dispatcher, information about an incident can be written to WildWeb, a website that is updated every 15 minutes and is available to Fire Managers.

X X

193 At the Boise Dispatch Center all fires that are being managed for Resource Benefit are entered into WildCAD and into the SIT-209 System.

X X

194 The kind and category of fire resources that are sent to an incident depend on availability as well as the conditions such as the fire danger rating (low, medium or high).

195 The Dispatch Center regularly communicates by phone or radio with the Duty Officer and then updates WildCAD.

X X

196 In the business process of managing a fire incident, WildCAD is the first automated tool that is used.

X X

197 WildCAD can produce reports that are pre- defined and the Dispatcher can define additional reports using SQL.

198 WildCAD tracks statistics on the fire season, response patterns, and daily shift logs including turnovers.

199 WildCAD can also track prescribed fires and non-fire resources and incidents.

200 When a fire moves to extended attack, the Dispatcher creates an incident in ROSS and requests non-local fire resources. A process improvement would be to automate the creation of an incident in ROSS using WildCAD data.

X X

201 The Dispatch Center defines and assigns the fire incident number.

X X

202 The Firecode for an incident is obtained from the Firecode system. For the USFS, the ABCD fires do not get a unique Firecode. A Firecode is needed to fund expenditures for an incident.

X X

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

203 At the Boise Dispatch Center the Dispatcher creates an incident in WFDSS, although it is possible to export an incident record from WildCAD. In many cases it is easier to re-enter the data due to the nature of the export process. Other Dispatch Centers may perform this process differently.

X X

204 The Dispatch Center obtains the latitude and longitude of the fire from WildCAD and then enters it in WFDSS. Determining the correct Lat/Long can be cumbersome.

X X X

205 Fire managers use WFDSS to define the course of action for an incident.

206 WFDSS is a strategic system, not tactical.

207 WFDSS contains pre-defined data such as Landfire GIS layers, land and fire management objectives, etc.

208 The WildCAD record that can be imported to WFDSS contains the Fire Name, the Incident Number and the Lat/Long.

X X

209 Once the WFDSS run is complete for an incident, the Dispatch Center is notified to coordinate the update of other related databases.

X X X

210 In WFDSS, the Incident Commander can look at the fire behavior analysis for an incident.

X X

211 The timeframe for completing the ICS-209 form for a fire is set by the GACC.

212 While it would be useful to be able to export an incident record from WildCAD to the 209 System, the Dispatcher wants to make that choice manually.

X X

213 It would be helpful to have the option to export data from WildCAD for the Daily SIT Report but only when an incident is complete. This could include data such as initial acres and final acres.

X X X

214 Some of the 209 data could come from WFDSS, such as values at risk.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

215 The Final Fire Report contains the data from WildCAD, WFDSS and Firestat for the USFS and 1202 for DOI. The Dispatch Center is responsible for making sure that all the databases contain the same data for the same incident.

X X X X

216 Periodically, weekly or sooner, a manual reconciliation occurs for the data in all the systems that are used for incident information.

X X

217 In the past the audience for the SIT209 data was only fire management staff usually at NIFC. The audience now has broadened to include the media and segments of the public.

218 The SIT209 data is open to a lot of interpretation. The way the data is entered may be interpreted differently when it is reported to the public. Information may be weighted differently than was originally intended.

219 Incident Commanders take the 209 very seriously. There is a concerted effort to make the data complete and accurate.

220 Rick has not experienced a duplication of data entry for 209 data with other systems. With the exception of a fire in California where a separate spreadsheet was required.

221 Rick has not been required to update WFDSS. Perimeter data is usually posted to an FTP site.

222 The SIT-209 System is definitely old technology. The current system needs to be more user friendly, easier to navigate, etc. It is easy to get lost when going between pages.

223 WFDSS and the SIT-209 have different objectives. WFDSS works with management strategy. The 209 reports current status on a daily basis provides information for PIOs and for management of fire resources. It is not a tool for the local fire manager.

X X

224 A link between the 209 System and WFDSS might be useful to exchange data.

STATEMENT NUMBER

INTERVIEW STATEMENT

A C

C E

S S

C O

N T

R O

A U

D IE

N C

D A

T A

C A

P T

U R

D A

T A

IN T

E G

R IT

R E

P O

R T

IN G

S Y

S T

E M

IN T

E G

R A

T IO

225 There definitely needs to be better business rules. With fields such as Structure Threatened, the number is easily repeated throughout the duration of the fire. This number should actually change. As we change how we evaluate fire management, we will likely move from chains of fire line constructed to the reduction of structures threatened. This would make accurate reporting much more important.

X X X

226 Now data is put in text boxes and it is difficult to access discreet information. This is especially true with the requirements for multiple management objectives on a fire.

227 SIT-209 needs to be nimble because it will continue to change over time.

228 There is an occasional problem with entering data on the 209 form. When filling out the form, if the user returns to a prior page to make changes, when the form is saved, the changes are lost. This usually happens at the worst time and seems to be an intermittent problem.

229 It would be possible to manually pull desired data from ISuite, and then make 209 updates as needed. ISuite contains the local Incident Action Plan that includes the medical and communication plans as well as resource counts, cost and objectives for the day.

230 There is a need for common business rules for each data element, especially for fields such as Structures Threatened.

231 There needs to be a different form for fire complexes.

232 SIT-209 needs to adapt to changes in management policy.

TOTALS 17 18 71 65 57 99

7.7 APPENDIX G – BUSINESS RULES

RULE NO.

TYPE OF RULE

RULE DEFINITION TIME FRAME

SOURCE DOCUMENT PAGE NO.

1 Policy The ICS-209 is submitted by the agency that has protection responsibility for the incident regardless of who administers the land.

2009 National Interagency Mobilization Guide

2 Policy If the protection agency is non-federal and chooses not to meet federal reporting standards, then the federal agency, which has administrative jurisdiction, will submit the ICS-209.

2009 National Interagency Mobilization Guide

3 Guide GACC will ensure that its dispatch centers have submitted complete and accurate ICS-209 reports at the times specified in its Mobilization Guide.

As specified in the GACC Mobilization Guide

2009 National Interagency Mobilization Guide

4 Policy An ICS-209 will be submitted daily when an incident exceeds 100 acres in timber fuel types (aka Large Fire), until incident is contained.

Daily until Containment

2009 National Interagency Mobilization Guide

5 Policy An ICS-209 will be submitted daily when an incident exceeds 300 acres in grass or brush fuel types (aka Large Fire), until incident is contained.

Daily until Containment

2009 National Interagency Mobilization Guide

6 Policy An ICS-209 will be submitted for wildfires managed for resource or ecological benefit when the event becomes a Large Fire, where confine/contain or monitor is the strategy employed.

Not specified, except when size or Stage threshold reached

2009 National Interagency Mobilization Guide

7 Policy An ICS-209 will be submitted daily when a Type 1 Interagency Incident Management Team (IMT) is assigned until incident is contained.

Daily until Containment

2009 National Interagency Mobilization Guide

8 Policy An ICS-209 will be submitted daily when a Type 2 Interagency Incident Management Team (IMT) is assigned until incident is contained.

Daily until Containment

2009 National Interagency Mobilization Guide

9 Policy An ICS-209 will be submitted when a resource benefit, confine/contain, Wildland Fire Use incident reaches 1,000 acres in size after it was initially reported. (Rule does not apply to incidents with teams assigned.)

When 1000- acre threshold is reached

2009 National Interagency Mobilization Guide

RULE NO.

TYPE OF RULE

RULE DEFINITION TIME FRAME

SOURCE DOCUMENT PAGE NO.

10 Policy An ICS-209 will be submitted every time an incident doubles in size after initially reaching 1,000 acres in size. (Rule does not apply to incidents with teams assigned.)

Every time size doubles

2009 National Interagency Mobilization Guide

11 Policy An ICS-209 shall be submitted when a wildland fire managed for resource or ecological benefit moves from Stage I to Stage II as defined in the Wildland Fire Implementation Plan (WFIP).

When Incident moves from Stage I to II

2009 National Interagency Mobilization Guide

12 Guide Incidents within a complex should be aggregated and included on one (1) ICS-209.

2009 National Interagency Mobilization Guide

13 Guide Individual large incidents within a complex should be listed in the Remarks section along with acreage and percent contained.

2009 National Interagency Mobilization Guide

7.8 APPENDIX H – DATA ELEMENTS BY BUSINESS NEED

The Fire Occurrence Reporting System (FORS) Business Needs Analysis prepared for the National Fire and Aviation Executive Board in February 2007 identified these data elements.

DATA ELEMENT GENERAL BUSINESS NEED

A n a

ly z e d

a ta

f o r

fi re

p la

n n

in g a

n d

re s e a rc

A n a

ly z e f ir e

c o s ts

A s s e s s F

ir e M

a n a g

e m

e n t

S tr

a te

g y

D e te

rm in

e t re

n d s i n h

is to

ri c f ir e e

ff e c ts

D e te

rm in

e i m

p a c t

a n d e

ff e c t o f a f

ir e

D e te

rm in

e r

e q u

ir e m

e n ts

f o r

p re

v e n ti o n

e d u c a ti o n

D e te

rm in

e t h e

q u

a n ti ty

a n

d q

u a

lit y o

e m

is s io

n s

Q u a n ti fy

w o rk

lo a d

R e s p o n

d t o i n fo

rm a ti o

n r

e q

u e s ts

a n d

d a ta

c a

lls

R e s p o n

d t o

r e p o rt

in g r

e q u

ir e m

e n

S u p

p o rt

f o r

B A

E R

e ff

o rt

S u p

p o rt

r e a

l ti m

e d

e c is

io n m

a k in

Acres at Discovery X

Acres at Initial Response X

Acres Burned - Burn Out X

Acres Burned by State and Owner X X X X X X X X X

Acres Protected by Agency X

Actual Area of Activity X

Actual Level of IA Activity X X X

Administrative - Approved/Authorized By X

Administrative - Report Entered By X

Administrative - Reported By X X

Bug Kill Acres X

Detection Type X

Fatalities X

FBPS Fuel Model X X X X X X X X X

Fire Cause Code - General X X X X X

Fire Cause Code - Specific X X X X X X X X X X

Fire Cause Code - Description X X X

Fire Code X X

DATA ELEMENT GENERAL BUSINESS NEED

A n a

ly z e d

a ta

f o r

fi re

p la

n n

in g a

n d

re s e a rc

A n a

ly z e f ir e

c o s ts

A s s e s s F

ir e M

a n a g

e m

e n t

S tr

a te

g y

D e te

rm in

e t re

n d s i n h

is to

ri c f ir e e

ff e c ts

D e te

rm in

e i m

p a c t

a n d e

ff e c t o f a f

ir e

D e te

rm in

e r

e q u

ir e m

e n ts

f o r

p re

v e n ti o n

e d u c a ti o n

D e te

rm in

e t h e

q u

a n ti ty

a n

d q

u a

lit y o

e m

is s io

n s

Q u a n ti fy

w o rk

lo a d

R e s p o n

d t o i n fo

rm a ti o

n r

e q

u e s ts

a n d

d a ta

c a

lls

R e s p o n

d t o

r e p o rt

in g r

e q u

ir e m

e n

S u p

p o rt

f o r

B A

E R

e ff

o rt

S u p

p o rt

r e a

l ti m

e d

e c is

io n m

a k in

Fire Consultation X

Fire Containment Date/Time X X X X X X X X

Fire Control Date/Time X X X X X

Fire Cost - Agency X X X X X

Fire Cost Agency - Date Estimated X X X X

Fire Cost Agency - Date Final X X X

Fire Cost Agency - Estimate X X X X

Fire Cost Agency - Final X X X X

Fire Danger Rating (BI or ERC) X X X X

Fire Discovery Date/Time X X X X X X X

Fire Identifier - Unique X X X X X X X X X X X

Fire Initial Response Date/Time X X X X X X X

Fire Intensity Level X X X X X X

Fire Land Type X X X X X X X X

Fire Name X X X X X X X

Fire Out Date/Time X X X X X X X X

Fire Perimeter Shapefile X X X X X X

Fire Perimeter Shapefile - Burn Severity X X X X X X X

Fire Perimeter Shapefile - Daily Acres Burned

X X X X X X

Fire Reporting Agency X X X X X

Fire Resource Day X X X X X

Fire Resource Fatality Count X X X X

DATA ELEMENT GENERAL BUSINESS NEED

A n a

ly z e d

a ta

f o r

fi re

p la

n n

in g a

n d

re s e a rc

A n a

ly z e f ir e

c o s ts

A s s e s s F

ir e M

a n a g

e m

e n t

S tr

a te

g y

D e te

rm in

e t re

n d s i n h

is to

ri c f ir e e

ff e c ts

D e te

rm in

e i m

p a c t

a n d e

ff e c t o f a f

ir e

D e te

rm in

e r

e q u

ir e m

e n ts

f o r

p re

v e n ti o n

e d u c a ti o n

D e te

rm in

e t h e

q u

a n ti ty

a n

d q

u a

lit y o

e m

is s io

n s

Q u a n ti fy

w o rk

lo a d

R e s p o n

d t o i n fo

rm a ti o

n r

e q

u e s ts

a n d

d a ta

c a

lls

R e s p o n

d t o

r e p o rt

in g r

e q u

ir e m

e n

S u p

p o rt

f o r

B A

E R

e ff

o rt

S u p

p o rt

r e a

l ti m

e d

e c is

io n m

a k in

Fire Resource Kind, Category X X X X X

Fire Resource Owner X X X X X

Fire Resource Quantity X X X X X

Fire Resource Severity Request Indicator

X X

Fire Response Objectives Met X X

Fire Severity Level X X X

Fire Size - Daily X X X X X X X X X

Fire size - Final Acres Burned X X

Fire Size - Total Acres Within Perimeter Protected by Agency

Fire Size Class X X X X X X

Fire Type Change Date/Time X

Fire Type Code - Description X X X X X X X X X X X X

Fire line Intensity X

FRCC - Post Fire X X X X X

FRCC - Pre Fire X X X X X

Fuel Load X X X X X

Fuel Type X X

Homes Lost X X X X

Homes Threatened X X X X X X

IA Control Percent X X X X X X X X X

Incident Complexity Type X X X

Initial Fire Response Objective Met X

DATA ELEMENT GENERAL BUSINESS NEED

A n a

ly z e d

a ta

f o r

fi re

p la

n n

in g a

n d

re s e a rc

A n a

ly z e f ir e

c o s ts

A s s e s s F

ir e M

a n a g

e m

e n t

S tr

a te

g y

D e te

rm in

e t re

n d s i n h

is to

ri c f ir e e

ff e c ts

D e te

rm in

e i m

p a c t

a n d e

ff e c t o f a f

ir e

D e te

rm in

e r

e q u

ir e m

e n ts

f o r

p re

v e n ti o n

e d u c a ti o n

D e te

rm in

e t h e

q u

a n ti ty

a n

d q

u a

lit y o

e m

is s io

n s

Q u a n ti fy

w o rk

lo a d

R e s p o n

d t o i n fo

rm a ti o

n r

e q

u e s ts

a n d

d a ta

c a

lls

R e s p o n

d t o

r e p o rt

in g r

e q u

ir e m

e n

S u p

p o rt

f o r

B A

E R

e ff

o rt

S u p

p o rt

r e a

l ti m

e d

e c is

io n m

a k in

Initial Fire Strategy X X X X X X

Injuries X X X

Length of Fire Seasons X

NFDRS Fuel Model X X X X

NFPORS Treatment ID X X

Number of Starts X

Other Structures Lost X X X X

Other Structures Threatened X X X X X X

Ownership Within Perimeter X X X X X X X

Pile or Broadcast X

Planned Date of Ignition X

Planned Number of Acres Burned X

Point of Origin - County X X X X

Point of Origin Accuracy X X X X X X X X X X X

Point of Origin Aspect X X X X X X

Point of Origin Data Collection Method X X

Point of Origin Datum X X X X X X X X X X X

Point of Origin Elevation X X X X X X

Point of Origin Land Owner X X X X X X X X

Point of Origin Latitude X X X X X X X X X X X

Point of Origin Longitude X X X X X X X X X X X

Point of Origin Slope X X X X X X

Point of Origin State X X X X X

DATA ELEMENT GENERAL BUSINESS NEED

A n a

ly z e d

a ta

f o r

fi re

p la

n n

in g a

n d

re s e a rc

A n a

ly z e f ir e

c o s ts

A s s e s s F

ir e M

a n a g

e m

e n t

S tr

a te

g y

D e te

rm in

e t re

n d s i n h

is to

ri c f ir e e

ff e c ts

D e te

rm in

e i m

p a c t

a n d e

ff e c t o f a f

ir e

D e te

rm in

e r

e q u

ir e m

e n ts

f o r

p re

v e n ti o n

e d u c a ti o n

D e te

rm in

e t h e

q u

a n ti ty

a n

d q

u a

lit y o

e m

is s io

n s

Q u a n ti fy

w o rk

lo a d

R e s p o n

d t o i n fo

rm a ti o

n r

e q

u e s ts

a n d

d a ta

c a

lls

R e s p o n

d t o

r e p o rt

in g r

e q u

ir e m

e n

S u p

p o rt

f o r

B A

E R

e ff

o rt

S u p

p o rt

r e a

l ti m

e d

e c is

io n m

a k in

Potential for Loss X

Protection Type X

Rate of Spread X X X

Reimbursable Indicator X

Responsible Agency Unit Identifier X X X X X X

Retardant Used Indicator X

Shift To Fire Strategy X X X X X X

Spread Direction X X

Strategy Escape or Fire Type Change X X X

Strategy Shift Reason X X X X X X

Time Zone X

Value of Structures Threatened X X X X

Vegetation Classification Scheme Code X

Vegetation Classification Type Identifier X

Weather Station ID - Primary X X X X X

Weather Station ID - Secondary X X X X X

WUI Indicator X X X X X X X X

7.9 APPENDIX I – CROSSWALK OF DATA ELEMENTS TO SIT-209 & WFDSS

The field names on the ICS-209 paper form were compared to the field names in the SIT-209 and WFDSS databases to determine a possible correspondence between data fields. An in-depth technical analysis of both the SIT-209 and WFDSS applications is required to verify this crosswalk.

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Administrative – Approved- Authorized By

Approved By Who approved the report

IMSR_209_INCIDENTS, APPROVED_BY

INCIDENT_TRAIL, USER_NAME

Administrative - Report Entered By

Prepared By Who prepared the report

IMSR_209_INCIDENTS, PREPARED_BY

INCIDENT_TRAIL, USER_NAME

Administrative - Reported By

Sent By Who sent the report

IMSR_209_INCIDENTS, SENT_FROM

INCIDENT_TRAIL, USER_NAME

Fatalities Fatalities Fatalities for the entire incident

IMSR_209_INCIDENTS, FATALITIES

Fire Code or Fire Cause Code

Cause (h)uman, (l)ightning, (u)nder investigation, (n)/a

IMSR_209_INCIDENTS, CAUSE

INCIDENT_CAUSE, ID

Fire Containment Date/Time

Expected Containment Date and Time

Expected Containment date and time

IMSR_209_INCIDENTS, EXP_CONTAIN

INCIDENT_HISTORY, CONTAINMENT_DAT E

Fire Control Date/Time

Declared Controlled Date and Time

The date and time when the incident was declared controlled.

IMSR_209_INCIDENTS, CONTROLLED_DATE

INCIDENT_HISTORY, CONTAINMENT_DAT E

Fire Cost - Agency Costs to Date Total cost to date IMSR_209_INCIDENTS, COSTS_TO_DATE

INCIDENT_PUBLISHE D_DECISION, ESTIMATED_COST

Fire Discovery Date/Time

Start Date and Time

Incident start date and time.

IMSR_209_INCIDENTS, START_DATE

INCIDENT_HISTORY, START_DATE

Fire Identifier - Unique

Incident Number

Incident number - usually protection unit and number

IMSR_209_INCIDENTS, INCIDENT_NUMBER

INCIDENT_HISTORY, WFDSS_ID

Fire Intensity Level Observed Fire Behavior

Observed Fire Behavior (blank for non-fire events)

IMSR_209_INCIDENTS, OBS_FIRE_BEHAV

Fire Land Type Short Location Description

Short Location Description (in relation to the nearest town)

IMSR_209_INCIDENTS, LOCATION

Fire Name Incident Name Name assigned to the incident

IMSR_209_INCIDENTS, INCIDENT_NAME

INCIDENT_HISTORY, NAME

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Fire Resource Kind, Category and Fire Resource Quantity

Critical Resource Needs 12 Hours

Critical resource needs up to 3 lines separated by "-/".

IMSR_209_INCIDENTS, CRITICAL_RES

MGMT_ACTION_PT, RESOURCES

Fire Resource Kind, Category and Fire Resource Quantity

Critical Resource Needs 24 Hours

Critical resource needs up to 3 lines separated by "-/".

IMSR_209_INCIDENTS, CRITICAL_RES

MGMT_ACTION_PT, RESOURCES

Fire Resource Kind, Category and Fire Resource Quantity

Critical Resource Needs 48 Hours

Critical resource needs up to 3 lines separated by "-/".

IMSR_209_INCIDENTS, CRITICAL_RES

MGMT_ACTION_PT, RESOURCES

Fire Resource Kind, Category and Fire Resource Quantity

Critical Resource Needs 72 Hours

Critical resource needs up to 3 lines separated by "-/".

IMSR_209_INCIDENTS, CRITICAL_RES

MGMT_ACTION_PT, RESOURCES

Fire Resource Kind, Category and Fire Resource Quantity

Resource CRW1 SR

Type 1 Crew (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_CREW_1

Fire Resource Kind, Category and Fire Resource Quantity

Resource CRW1 ST

Type 1 Crew (Strike Team)

IMSR_209_INCIDENT_R ESOURCES, ST_CREW_1

Fire Resource Kind, Category and Fire Resource Quantity

Resource CRW2 SR

Type 2 Crew (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_CREW_2

Fire Resource Kind, Category and Fire Resource Quantity

Resource CRW2 ST

Type 2 Crew (Strike Team)

IMSR_209_INCIDENT_R ESOURCES, ST_CREW_2

Fire Resource Kind, Category and Fire Resource Quantity

Resource HEL1 SR

Type 1 Helicopter (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_HELICOPTER_1

Fire Resource Kind, Category and Fire Resource Quantity

Resource HEL2 SR

Type 2 Helicopter (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_HELICOPTER_2

Fire Resource Kind, Category and Fire Resource Quantity

Resource HEL3 SR

Type 3 Helicopter (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_HELICOPTER_3

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Fire Resource Kind, Category and Fire Resource Quantity

Resource ENGS SR

Engines (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_ENGINES

Fire Resource Kind, Category and Fire Resource Quantity

Resource ENGS ST

Engines IMSR_209_INCIDENT_R ESOURCES, ST_ENGINES

Fire Resource Kind, Category and Fire Resource Quantity

Resource DOZR SR

Dozers (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_DOZER

Fire Resource Kind, Category and Fire Resource Quantity

Resource DOZR ST

Dozers (Strike Team)

IMSR_209_INCIDENT_R ESOURCES, ST_DOZER

Fire Resource Kind, Category and Fire Resource Quantity

Resource WTDR SR

Water Tenders (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_WATER_TENDER

Fire Resource Kind, Category and Fire Resource Quantity

Resource OVHD SR

Overhead (Single Resource)

IMSR_209_INCIDENT_R ESOURCES, SR_OVERHEAD

Fire Resource Kind, Category and Fire Resource Quantity

Resource Camp Crews

Camp Crews IMSR_209_INCIDENT_R ESOURCES, CAMP_CREW

Fire Resource Kind, Category and Fire Resource Quantity

Total Personnel Total Personnel in the incident

IMSR_209_INCIDENT_R ESOURCES, TOTAL_PERSONNEL

Fire Size - Daily Size Area involved IMSR_209_INCIDENTS, AREA

LANDFIRE_MAPZON ES, ACRES

Fire Size - Daily Area Involved Descriptive size of the area (acres, hectares, square kilometers)

IMSR_209_INCIDENTS, AREA_MEASUREMENT

LANDFIRE_MAPZON ES, ACRES

Fire Type Code / Desc

Incident Kind IMSR_209_INCIDENTS, TYPE_INC

INCIDENT_HISTORY, PURPOSE

Fuel Type Fuels/Materials Involved

Fuels/Materials Involved...for example litter and understory, and logging slash

IMSR_209_INCIDENTS, FUELS

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Homes Lost Residence Destroyed (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type destroyed

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / DESTROYED

Homes Threatened Residence Threatened (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type threatened

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / THREATENED

IA Control Percent Percent Contained or MMA

Percent contained or Maximum Manageable Area (MMA) value. (P)ercent or (M)MA flag for P_CONTAIN value.

IMSR_209_INCIDENTS, P_CONTAIN / PERCENT_MMA

Initial Fire Strategy Actions Planned

Planned Actions for the next operational period

IMSR_209_INCIDENTS, PLANNED_ACTIONS

Initial Fire Strategy Growth Potential

Growth Potential of the incident (high, etc.)

IMSR_209_INCIDENTS, GROWTH_POTENTIAL

Initial Fire Strategy Terrain Difficulty

Difficulty of the terrain (extreme, etc.)

IMSR_209_INCIDENTS, TERRAIN

Initial Fire Strategy Projected Strategy Success Date

Likelihood that containment/contro l targets will be met, given the current resources and suppression/contro l strategy

IMSR_209_INCIDENTS, TARGETS_MET

Injuries Injuries this Reporting Period

Injuries since last ICS-209 report

IMSR_209_INCIDENTS, INJURIES

Injuries Injuries to Date Total injuries caused by the incident

IMSR_209_INCIDENTS, INJURIES_TO_DATE

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Other Structures Lost

Commercial Property Destroyed (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type destroyed

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / DESTROYED

Other Structures Lost

Outbuilding/Oth er Destroyed (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type destroyed

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / DESTROYED

Other Structures Threatened

Commercial Property Threatened (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type threatened

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / THREATENED

Other Structures Threatened

Outbuilding/Oth er Threatened (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type threatened

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / THREATENED

Point of Origin - County

County County the incident is located in

IMSR_209_INCIDENTS, COUNTY

JURISDICTION_GIS, COUNTY

Point of Origin Land Owner

Ownership The state of the unit that has ownership of where the incident started. The unit id of the unit that has ownership of where the incident started.

IMSR_209_INCIDENTS, OWNERSHIP_STATE / OWNERSHIP_UNITID

INCIDENT_OWNER, OWNER_ID

Point of Origin Latitude

Latitude Latitude in decimal degrees where the incident originated

IMSR_209_INCIDENTS, LATITUDE

INCIDENT_HISTORY, LATITUDE

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Point of Origin Longitude

Longitude Longitude in decimal degrees where the incident originated

IMSR_209_INCIDENTS, LONGITUDE

INCIDENT_HISTORY, LONGITUDE

Point of Origin State

State Unit state for the unit that has protection responsibility for where the incident started.

IMSR_209_INCIDENTS, UN_USTATE

JURISDICTION_GIS, STATE

Potential for Loss Communities Threatened 12 Hours

Communities/Critic al Infrastructure threatened within 12-hour time frame

IMSR_209_INCIDENTS, COMMUNITIES_THREA TENED_12

Potential for Loss Communities Threatened 24 Hours

Communities/Critic al Infrastructure threatened within 24-hour time frame

IMSR_209_INCIDENTS, COMMUNITIES_THREA TENED_24

Potential for Loss Communities Threatened 48 Hours

Communities/Critic al Infrastructure threatened within 48-hour time frame

IMSR_209_INCIDENTS, COMMUNITIES_THREA TENED_48

Potential for Loss Communities Threatened 72 Hours

Communities/Critic al Infrastructure threatened within 72-hour time frame

IMSR_209_INCIDENTS, COMMUNITIES_THREA TENED_72

Strategy Escape or Fire Type Change

Evacuations in Progress

(Y/N) if there is an evacuation in progress

IMSR_209_INCIDENTS, EVACUATION_IN_PRO GRESS

Strategy Escape or Fire Type Change

No Evacuations Imminent

(Y/N) if there are no imminent evacuations

IMSR_209_INCIDENTS, NO_EVACUATION

Strategy Escape or Fire Type Change

Potential Future Threat

(Y/N) if there is a potential future evacuation threat

IMSR_209_INCIDENTS, POTENTIAL

Strategy Escape or Fire Type Change

No Likely Threat

(Y/N) if evacuations are not likely

IMSR_209_INCIDENTS, NO_LIKELY

Strategy Shift Level

Significant Events

Significant Events IMSR_209_INCIDENTS, SIG_EVENT

Value of Structures Threatened

Values at Risk 12 Hours

Not Used? , SCI, HOUSING_VALUE

Value of Structures Threatened

Values at Risk 24 Hours

Not Used? , SCI, HOUSING_VALUE

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Value of Structures Threatened

Values at Risk 48 Hours

Not Used? , SCI, HOUSING_VALUE

Value of Structures Threatened

Values at Risk 72 Hours

Not Used? , SCI, HOUSING_VALUE

Date Report Date not including the time

IMSR_209_INCIDENTS, REPORT_DATE

INCIDENT_HISTORY, CREATION_DATE

Time Military time of report including minutes

IMSR_209_INCIDENTS, HOUR

Initial Status Status flag for the 209: I for Initial, U for Update, F for Final

IMSR_209_INCIDENTS, STATUS

Update Status Status flag for the 209: I for Initial, U for Update, F for Final

IMSR_209_INCIDENTS, STATUS

Final Status Status flag for the 209:I for Initial, U for Update, F for Final

IMSR_209_INCIDENTS, STATUS

Incident Commander

Incident Commander Name

IMSR_209_INCIDENTS, IC_NAME

IMT Type type of incident management team assigned (1, 2, 3, or FUMT for Fire Use Management Team)

IMSR_209_INCIDENTS, IMT_TYPE

Unit Unit id for the unit that has protection responsibility for where the incident started.

IMSR_209_INCIDENTS, UN_UNITID

INCIDENT_FMU, UNIT_ID

Line to Build Number of chains, miles, or feet of line still to be completed (for wildland fire incidents)

IMSR_209_INCIDENTS, LINE_TO_BUILD

Residence Damaged (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / DAMAGED

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

structures of the above type damaged

Commercial Property Damaged (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type damaged

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / DAMAGED

Outbuilding/Oth er Damaged (#)

Type of Structure (Residence, Commercial, Outbuilding) Number of structures of the above type damaged

IMSR_209_INCIDENT_S TRUCTURES, STRUCTURE TYPE / DAMAGED

Major Problems Major problems and concerns (control problems, social/political/econ omic concerns or impacts, etc.) - relate critical resource needs identified

IMSR_209_INCIDENTS, MAJOR_PROBLEMS

Wind Direction Current wind direction

IMSR_209_INCIDENTS, C_WIND_DIRECTION

WINDS, WIND_DIRECTION

Wind Speed Current wind speed

IMSR_209_INCIDENTS, C_WIND_SPEED

WINDS, WIND_SPEED

Peak Gusts Not Used? , WINDS, GUST_SPEED

Maximum Temperature

Current temperature

IMSR_209_INCIDENTS, C_TEMP

WEATHER, MAX_TEMPERATURE

Minimum Relative Humidity

Current relative humidity

IMSR_209_INCIDENTS, C_RH

WEATHER, MIN_HUMIDITY

Forecast Wind Speed

Forecasted wind speed (tomorrow)

IMSR_209_INCIDENTS, F_WIND_SPEED

Forecast Wind Direction

Forecasted wind direction (tomorrow)

IMSR_209_INCIDENTS, F_WIND_DIRECTION

DATA ELEMENT FIELD NAME ON ICS-209

FORM

DEFINITION SIT-209 DATABASE (TABLE NAME, FIELD

NAME)

WFDSS DATABASE (TABLE NAME, FIELD

NAME)

Forecast Temperature

Forecasted temperature (tomorrow)

IMSR_209_INCIDENTS, F_TEMP

Forecast Relative Humidity

Forecasted relative humidity (tomorrow)

IMSR_209_INCIDENTS, F_RH

Estimated Control Date and Time

Estimated date and time the incident will be controlled.

IMSR_209_INCIDENTS, EST_CONTROL

INCIDENT_HISTORY, CONTAINMENT_DAT E

Projected Final Size

Estimated final size of the incident

IMSR_209_INCIDENTS, EST_FINAL_AREA

SCI_ACRES, ACRES_BURNED

Estimated Final Cost

Estimated final costs involved in the incident

IMSR_209_INCIDENTS, EST_FINAL_COSTS

INCIDENT_PUBLISHE D_DECISION, ESTIMATED_COST

Projected Demobilization Start Date

Projected Demobilization start date and time.

IMSR_209_INCIDENTS, DEMOBE_START

Remarks Remarks: (General details about the incident)

IMSR_209_INCIDENTS, REMARKS

INCIDENT_TRAIL, COMMENTS

Cooperating Agencies

Cooperating and Assisting Agencies not listed in the resources section.

IMSR_209_INCIDENTS, COOP_AGENCIES

UNIT, AGENCY_ID

Sent To Who the report was sent to

IMSR_209_INCIDENTS, SENT_TO

INCIDENT_TRAIL, USER_NAME

Sent Date The date and time the form was submitted.

IMSR_209_INCIDENTS, SENT_DATE

INCIDENT_TRAIL, AUDIT_DATE

7.10 APPENDIX J – NIMS POSITION PAPER

The implementation of NIMS ICS is expected to affect the SIT-209 application. The following white paper was obtained from the FEMA web site link http://www.fema.gov/txt/nims/nims_ics_position_paper.txt.

NIMS and the Incident Command System

The way this nation prepares for and responds to domestic incidents is about to change. It won't be an abrupt change; best practices that have been developed over the years are part of this new comprehensive national approach to incident management known as the National Incident Management System (NIMS). But it will change – and for the better. Developed by the Department of Homeland Security and issued in March 2004, the NIMS will enable responders at all jurisdictional levels and across all disciplines to work together more effectively and efficiently. Beginning in FY 2006, federal funding for state, local and tribal preparedness grants will be tied to compliance with the NIMS.

One of the most important 'best practices' that has been incorporated into the NIMS is the Incident Command System (ICS), a standard, on-scene, all-hazards incident management system already in use by firefighters, hazardous materials teams, rescuers and emergency medical teams. The ICS has been established by the NIMS as the standardized incident organizational structure for the management of all incidents.

Although many agencies now use various forms of ICS, there is considerable uncertainty about NIMS ICS and the impact it will have on systems and processes currently in place. These are important questions because one of the FY 2005 requirements for implementing NIMS is "institutionalizing the use of ICS, across the entire response system."

This paper is intended to provide an historical perspective on the development of ICS, explain how NIMS ICS works, describe how it is different from previous systems, and discuss the future of NIMS ICS training.

Background

In Homeland Security Presidential Directive-5 (HSPD-5), President Bush called on the Secretary of Homeland Security to develop a national incident management system to provide a consistent nationwide approach for federal, state, tribal and local governments to work together to prepare for, prevent, respond to and recover from domestic incidents, regardless of cause, size or complexity.

On March 1, 2004, after close collaboration with state and local government officials and representatives from a wide range of public safety organizations, Homeland Security issued the NIMS. It incorporates many existing best practices into a comprehensive national approach to domestic incident management, applicable at all jurisdictional levels and across all functional disciplines.

The NIMS represents a core set of doctrine, principles, terminology, and organizational processes to enable effective, efficient and collaborative incident management at all levels. To provide the framework for interoperability and compatibility, the NIMS is based on a balance between flexibility and standardization. The recommendations of the National Commission on Terrorist Attacks Upon the United States (the "9/11 Commission") further highlight the importance of ICS. The Commission's recent report recommends national adoption of the ICS to enhance command, control and communications capabilities.

The History of Incident Command System

The concept of ICS was developed more than thirty years ago, in the aftermath of a devastating wildfire in California. During 13 days in 1970, 16 lives were lost, 700 structures were destroyed and over one-half million acres burned. The overall cost and loss associated with these fires totaled $18 million per day. Although all of the responding agencies cooperated to the best of their ability, numerous problems with communication and coordination hampered their effectiveness. As a result, the Congress mandated that the U.S. Forest Service design a system that would "make a quantum jump in the capabilities of Southern California wildland fire protection agencies to effectively coordinate interagency action and to allocate suppression resources in dynamic, multiple-fire situations."

http://www.fema.gov/txt/nims/nims_ics_position_paper

The California Department of Forestry and Fire Protection, the Governor's Office of Emergency Services; the Los Angeles, Ventura and Santa Barbara County Fire Departments; and the Los Angeles City Fire Department joined with the U.S. Forest Service to develop the system. This system became known as FIRESCOPE (FIrefighting RESources of California Organized for Potential Emergencies).

In 1973, the first "FIRESCOPE Technical Team" was established to guide the research and development design. Two major components came out of this work, the ICS and the Multi- Agency Coordination System (MACS). The FIRESCOPE ICS is primarily a command and control system delineating job responsibilities and organizational structure for the purpose of managing day-to-day operations for all types of emergency incidents.

By the mid-seventies, the FIRESCOPE agencies had formally agreed upon on ICS common terminology and procedures and conducted limited field-testing of ICS. By 1980, parts of ICS had been used successfully on several major wildland and urban fire incidents. It was formally adopted by the Los Angeles Fire Department, the California Department of Forestry and Fire Protection (CDF), the Governor's Office of Emergency Services (OES), and endorsed by the State Board of Fire Services.

Also during the 1970s, the National Wildfire Coordinating Group (NWCG) was chartered to coordinate fire management programs of the various participating federal and state agencies. By 1980, FIRESCOPE ICS training was under development. Recognizing that in addition to the local users for which it was designed, the FIRESCOPE training could satisfy the needs of other state and federal agencies, the NWCG conducted an analysis of FIRESCOPE ICS for possible national application.

By 1981, ICS was widely used throughout Southern California by the major fire agencies. In addition, the use of ICS in response to non-fire incidents was increasing. Although FIRESCOPE ICS was originally developed to assist in the response to wildland fires, it was quickly recognized as a system that could help public safety responders provide effective and coordinated incident management for a wide range of situations, including floods, hazardous materials accidents, earthquakes and aircraft crashes. It was flexible enough to manage catastrophic incidents involving thousands of emergency response and management personnel. By introducing relatively minor terminology, organizational and procedural modifications to FIRESCOPE ICS, the NIIMS ICS became adaptable to an all-hazards environment.

While tactically each type of incident may be handled somewhat differently, the overall incident management approach still utilizes the major functions of the Incident Command System. The FIRESCOPE board of directors and the NWCG recommended national application of ICS. In 1982, all FIRESCOPE ICS documentation was revised and adopted as the National Interagency Incident Management System (NIIMS). In the years since FIRESCOPE and the NIIMS were blended, the FIRESCOPE agencies and the NWCG have worked together to update and maintain the Incident Command System Operational System Description (ICS 120-1). This document would later serve as the basis for the NIMS ICS.

Variations on the Theme

In the early 1970s, the Phoenix Fire Department developed the Fire Ground Command System (FGC). The concepts of FGC were similar to FIRESCOPE ICS but there were differences in terminology and in organizational structure. The FGC system was developed for structural firefighting and was designed for operations of 25 or fewer companies.

There were several efforts to "blend" the various incident command systems. One early effort was in 1987 when the National Fire Protection Association (NFPA) undertook the development of NFPA 1561, then called Standard on Fire Department Incident Management System. The NFPA committee quickly recognized that the majority of the incident command systems in existence at the time were similar. The differences among the systems were mostly due to variations in terminology for similar components. That NFPA standard, later revised to its present title: Standard on Emergency Services Incident Management, provides for organizations to adopt or modify existing systems to suit local requirements or preferences as long as they meet specific performance measurements.

Recognizing the continuing challenges occurring in the fire service in applying a common approach to incident command, the National Fire Service Incident Management System (IMS) Consortium was created in 1990. Its purpose was to evaluate an approach to developing a single command system. The consortium consisted of many individual fire service leaders, representatives of most major fire service

organizations and representatives of federal, state and local agencies, including FIRESCOPE and the Phoenix Fire Department. One of the significant outcomes of the consortium's work was an agreement on the need to develop operational protocols within ICS, so that fire and rescue personnel would be able to apply the ICS as one common system.

In 1993, the IMS consortium completed its first document: Model Procedures Guide for Structural Firefighting. As a result, FIRESCOPE incorporated the model procedures, thereby enhancing its organizational structure with operational protocols. These changes enabled the nation's fire and rescue personnel to apply the ICS effectively regardless of what region of the country they were assigned to work. The National Fire Academy (NFA), having already adopted the FIRESCOPE ICS in 1980, incorporated this material into its training curriculum as well.

National Incident Management System

The NIMS provides a consistent, flexible and adjustable national framework within which government and private entities at all levels can work together to manage domestic incidents, regardless of their cause, size, location or complexity. This flexibility applies across all phases of incident management: prevention, preparedness, response, recovery and mitigation.

The NIMS provides a set of standardized organizational structures – including the ICS, Multi-Agency Coordination Systems and public information systems – as well as requirements for processes, procedures and systems to improve interoperability among jurisdictions and disciplines in various areas.

Homeland Security recognizes that the overwhelming majority of emergency incidents are handled on a daily basis by a single jurisdiction at the local level. However, the challenges we face as a nation are far greater than the capabilities of any one community or state, but no greater than the sum of all of us working together.

There will be instances in which successful domestic incident management operations depend on the involvement of emergency responders from multiple jurisdictions, as well as personnel and equipment from other states and the federal government. These instances require effective and efficient coordination across a broad spectrum of organizations and activities.

The success of the operations will depend on the ability to mobilize and effectively utilize multiple outside resources. These resources must come together in an organizational framework that is understood by everyone and must utilize a common plan, as specified through a process of incident action planning. This will only be possible if we unite, plan, exercise and respond using a common National Incident Management System.

When Homeland Security released the NIMS on March 1, 2004, Secretary Tom Ridge and Under Secretary Brown specifically highlighted compliance with the ICS as being possible fairly quickly. They recognized that in some cities, the fire and police departments have worked together using ICS for years. In other places, only the fire department used ICS. Although law enforcement, public works and public health were aware of the concept, they regarded ICS as a fire service system. The NIMS ends this discrepancy because HSPD-5 requires state and local adoption of NIMS as a condition for receiving federal preparedness funding. While ICS was first pioneered by the fire service, it is, at its core, a management system designed to integrate resources to effectively attack a common problem. This system is not exclusive to one discipline or one set of circumstances; its hallmark is its flexibility to accommodate all circumstances. Some purists may claim that a particular application of ICS is not consistent with the NIMS. Yet, we need not approach ICS with the same mathematical precision used by an engineer. We are changing the culture of organizations and first responders at all levels of government. As long as implementation of ICS is consistent with the basic principles expressed in the NIMS, we will have made significant progress. Further refinements can be achieved over time based on experience with its use.

What is NIMS ICS?

With the exception of the way the intelligence function is handled, the principles and concepts of NIMS ICS are the same as the FIRESCOPE and NIIMS ICS.

ICS Management Characteristics

ICS is based on proven management tools that contribute to the strength and efficiency of the overall system. The following ICS management characteristics are taught by DHS in its ICS training programs:

 Common Terminology

 Modular Organization

 Management by Objectives

 Reliance on an Incident Action Plan

 Manageable Span of Control

 Pre-designated Incident Mobilization Center Locations & Facilities

 Comprehensive Resource Management

 Integrated Communications

 Establishment and Transfer of Command

 Chain of Command and Unity of Command

 Unified Command

 Accountability of Resources and Personnel

 Deployment

 Information and Intelligence Management.

ICS Command Staff

Command comprises the Incident Commander (IC) and Command Staff. Command staff positions are established to assign responsibility for key activities not specifically identified in the General Staff functional elements. These positions may include the Public Information Officer (PIO), Safety Officer (SO), and the Liaison Officer (LNO), in additional to various others, as required and assigned by the IC.

Unified Command (UC)

Unified Command (UC) is an important element in multi-jurisdictional or multi-agency domestic incident management. It provides guidelines to enable agencies with different legal, geographic, and functional responsibilities to coordinate, plan, and interact effectively. As a team, the Unified Command overcomes much of the inefficiency and duplication of effort that can occur when agencies from different functional and geographic jurisdictions, or agencies at different levels of government, operate without a common system or organizational framework. The primary difference between the single command structure and the UC structure is that in a single command structure, the IC is solely responsible for establishing incident management objectives and strategies. In a UC structure, the individuals designated by their jurisdictional authorities jointly determine objectives, plans, and priorities and work together to execute them.

General Staff

The General Staff includes incident management personnel who represent the major functional elements of the ICS, including the Operations Section Chief, Planning Section Chief, Logistics Section Chief, and Finance/Administration Section Chief. Command Staff and General Staff must continually interact and share vital information and estimates of the current and future situation and develop recommended courses of action for consideration by the IC.

Incident Action Plan (IAP)

The IAP includes the overall incident objectives and strategies established by the IC or UC. The Planning Section is responsible for developing and documenting the IAP. In the case of UC, the IAP must adequately address the overall incident objectives, mission, operational assignments, and policy needs of each jurisdictional agency. This planning process is accomplished with productive interaction between jurisdictions, functional agencies, and private organizations. The IAP also addresses tactical objectives

and support activities for one operational period, generally 12 to 24 hours. The IAP also contains provisions for continuous incorporation of "lessons learned" as identified by the Incident Safety Officer or incident management personnel as activities progress.

Area Command

Area Command is activated only if necessary, depending on the complexity of the incident and span-of- control considerations. An area command is established either to oversee the management of multiple incidents that are being handled by separate ICS organizations or to oversee the management of a very large incident that involves multiple ICS organizations. It is important to note that Area Command does not have operational responsibilities. For incidents under its authority, the Area Command:

 Sets overall agency incident-related priorities;

 Allocates critical resources according to established priorities;

 Ensures that incidents are managed properly;

 Ensures effective communications;

 Ensures that incident management objectives are met and do not conflict with each other or with agency policies;

 Identifies critical resource needs and reports them to the Emergency Operations Center(s);

 Ensures that short-term emergency recovery is coordinated to assist in the transition to full recovery operations; and

 Provides for personnel accountability and a safe operating environment.

The Difference between NIMS ICS and FIRESCOPE/NIIMS ICS

The ICS organization has five major functions, including command, operations, planning, logistics, and finance and administration. In the NIMS ICS, a potential sixth functional area to cover the intelligence function can be established for gathering and sharing incident related information and intelligence.

The Information and Intelligence function provides analysis and sharing of information and intelligence during an incident. Intelligence can include national security or classified information but also can include operational information such as risk assessments, medical intelligence, weather information, structural designs of buildings and toxic contaminant levels. Traditionally, information and intelligence functions are located in the Planning Section. In exceptional situations, however, the IC may need to assign this role to other parts of the ICS organization. Under the NIMS ICS, the intelligence and information function may be assigned in one of the following ways:

 Within the Command Staff;

 As a unit within the Planning Section;

 As a branch within the Operations Section; or

 As a separate General Staff Section.

ICS as Taught by Homeland Security

One of the first steps for becoming compliant with the NIMS requires states and local governments to institutionalize the use of ICS (as taught by Homeland Security) across the entire response system. This means that ICS training must be consistent with the concepts, principles and characteristics of the ICS training offered by the various DHS training entities. ICS training courses need not be taught by a DHS employee or at a DHS facility, although they can be. Organizations that are developing ICS training courses should be sure to review their materials and revise them if they are not consistent with DHS concepts and principles.

Available NIMS ICS Training

DHS, through its many training bodies, makes ICS training available. ICS training developed by the Federal Emergency Management Agency (FEMA) includes:

 ICS-100, Introduction to ICS

 ICS-200, Basic ICS

 ICS-300, Intermediate ICS

 ICS-400, Advanced ICS

To participate in FEMA's ICS training, contact the state emergency management training office. The Emergency Management Institute (EMI) and the National Fire Academy (NFA) also offer ICS Train-the- Trainer classes at their Emmitsburg, Md., facility. A variety of other ICS training programs are available. The NIMS Integration Center is working with federal and state training providers to ensure that their ICS course offerings are consistent with the NIMS.

Responders who have already been trained in ICS do not need retraining if their previous training is consistent with DHS standards. Since NIMS ICS is based on FIRESCOPE and NIIMS, any training developed or provided by FIRESCOPE and NIIMS is consistent with NIMS ICS.

The Future of NIMS ICS Training

Over time, the NIMS Integration Center will continues to define the critical components of NIMS ICS, and training providers should update their courses accordingly. With so many training bodies and companies offering ICS training, it will be impossible in the near term for the Center to certify each training program as "NIMS ICS compliant." But, the Center will provide NIMS ICS training and make the training materials available to others who offer ICS training.

More specific ICS modules, such as those developed by FIRESCOPE to facilitate the use of ICS in situations other than wildland fires, should be reviewed and updated to become additional components of NIMS ICS training. The FIRESCOPE ICS modules include Multi-Casualty, Hazardous Materials, High- rise, Wildland/Urban Interface, and Urban Search and Rescue applications. As groups like the NWCG and FIRESCOPE update their ICS training modules, the NIMS Integration Center will be an active participant. Those ICS modules can form the basis for a suite of ICS training materials in which responders from all disciplines and at all levels of government can learn how to fit into the ICS structure and how to work with other responders.

Updates and revisions to existing ICS training modules should include the modifications necessary to allow for multiple methods of delivery. To ensure that all responders adopt and use ICS, we must provide ICS training in numerous ways. Classroom instruction, field training, independent study and distance learning are all valuable training methods. The more materials and options that the Center and its partners, the training providers, can provide, the more responders will be trained to use ICS. ICS training also should encourage and support integrated training opportunities, where law enforcement, fire, public health, emergency medical, emergency management, and public works personnel from a jurisdiction are trained together on using ICS. While the response disciplines may need specific tools and training to understand how they fit into the ICS structure, everyone should learn the same incident command system.

Conclusions

Throughout the transition to the National Incident Management System, it is important to remember why we have the NIMS and why ICS is a critical piece of the incident management system. Most incidents are local, but when we're faced with the worst-case scenario, such as Sept.11, 2001, all responding agencies must be able to interface and work together. The NIMS, and in particular, the ICS component, allow that to happen, but only if the foundation has been laid at the local level. If local jurisdictions adopt a variation of ICS that cannot grow or is not applicable to other disciplines, the critical interface between responding agencies and jurisdictions cannot occur when the response expands.

It is important that everyone understand that with the establishment of the NIMS, there is only one ICS. As agencies adopt the principles and concepts of ICS as established in the NIMS, the incident command system can expand to meet the needs of the response, regardless of the size or number of responders. The key to both NIMS and ICS is a balance between standardization and flexibility.

The NIMS Integration Center (NIC) is working towards a common understanding and application of the ICS. As the office established to manage and oversee the entire NIMS, the Center will continue its

collaboration with stakeholders at all levels of government and across all response disciplines. The initial staff is detailed from other parts of DHS, including FEMA, the Office for Domestic Preparedness (ODP) and the Science and Technology (S&T) Directorate. As the NIMS Integration Center continues to grow it will evolve into robust, fully integrated center that will incorporate additional DHS employees, interagency detailees and liaisons, as well as state, tribal and local government representatives.

The NIMS document is available on www.fema.gov/nims.HSPD-5 states that: "Beginning in Fiscal Year 2005, Federal departments and agencies shall make adoption of the NIMS a requirement, to the extent permitted by law, for providing Federal preparedness assistance through grants, contracts, or other activities. The Secretary shall develop standards and guidelines for determining whether a State or local entity has adopted the NIMS."

The NIC has developed a NIMS web page to provide updated information and resources to assist with NIMS implementation. The web page can be found at: www.fema.gov/nims. From this page, you can also email your NIMS related questions to the NIMS Integration Center (NIMS-Integration- [email protected]). A NIMS Awareness Course is also available through the NIMS web page.

Nov. 23, 2004

7.11 APPENDIX K – REFERENCES

1. Federal Wildland Fire Policy, 1995; Policy Update, 2001

2. National Interagency Statistics Information Project Report, 1998

3. National Fire Plan, 2000

4. Coarse Assessment of Federal Wildland Fire Occurrence Data–A report for the National Wildfire Coordinating Group by CEFA, 2002

5. NASF Resolution on National Fire Reporting, 2002

6. Fire Statistics Task Group Final Report, 2003

7. Predictive Services White Paper – Integrated Fire Statistics Data Needs, 2003

8. Reporting Fire Statistics by State, Local, and Tribal Fire Organizations– A White Paper to Focus the Issue for the Short Term, 2003

9. Fire Occurrence Reporting System Charter, 2005

10. Report of the eGov Disaster Management Task Group to the National Fire and Aviation Executive Board, 2006

11. Draft version of USFS Individual Wildland Fire Report, officially adopted for use in FY2007, 2006

12. FWS-FMIS Data Call spreadsheet, 2006

13. NFIRS Version 5.0 Design Documentation Manual, 2006

Astha Jain Rameshkumar

Arshdeep Kaur Sahl

Gurnit Singh

Simrat Kaur

BUSI 2133 Organization Theory and Design 11/11 (20F-C-BC-5B)

Amr Shokry

29 November 2020

Introduction:

Sephora is a French worldwide retailer of beauty as well as personal care products. It was first launched in Paris in 1970. The company main headquarter is in Paris, France. Sephora sells products with its own private label and features around 3000 different brands which include skin care, fragrance, cosmetic, body, nail color, hair care and beauty tools (Fast Company, 2020). The Sephora Company is owned by luxury conglomerate LVMH as of 1997. The company has 2,600 stores in 36 nations. It allows testing of the products at store so that customers can choose the product at their best. Also, there are numbers of videos on their website which helps people to know about the brand, tech how to use products and tells which product suits best according to the skin type and skin problems. This why Sephora is gaining heights in market and is also evolved in one of the most powerful beauty chains in the world. The Sephora brand targeted on large segment of the customers and created the product for all skin tones and for the foundations they created light-as-air formulas that can be layered on the skin by designing in a unique way. The products of Sephora are lightweight and natural to use. That is why they attract customer from all around the world (Sephora, n.d.).

Mintzberg ‘s organizational Design:

We apply Mintzberg ‘s organizational 5 basic parts on Sephora company like in Top management include the mission and goal of company like the whole team make Sephora gold standard for makeup expertise and in store customer experience. To achieve this goal they do a lot of struggle such as team members are selected with great care because of the team spirit now. Sephora creates its own identity in the world of beauty [Shokry, 2020].

Middle management including operating core is directly involved in the production activities of products and services. Faculty staffs Operating support staff involves planning, designing, and making changes to operating core [Shokry, 2020].

The team overseas store systems and communications, digital tools and workload planning, all with a goal of helping our in store teams deliver the best possible experience to our clients. Task management is responsible for build up the communication with the objective of driving overall company objectives within our tone of voice .this role sets processes and guidelines in place to ensure communications are clear, concise and provide the right information to achieve the goals of our company [Shokry, 2020].

Mission:

Sephora’s mission statement is “we believe beauty is for each person to define and ours to celebrate. Together, we support and encourage bold choices in beauty—and in life. Our purpose is to inspire fearlessness.” Experience of Sephora is valued by how the customer is gaining from the company. The mission of Sephora is to implement the critical activities to attract customers. The following components are drawn from this mission statement:

1. Celebrating and supporting beauty together

2. Inspire fearlessness

3. Improvement of life

Sephora tries to give customers a broad variety of beauty products so as the customers have many options. The company acknowledges the importance of aesthetic appeal in the overall completeness of a person. Sephora achieves this by getting all the products to be simplified to meet their needs (“Mission Statement”, n.d.).

Sephora has built a name where the customers know that it is known for its interactive platform. It helps people to pick products based on their type and their choice. In fact, it has a community section that shows the epitome of the concerted efforts to advance beauty of the company. By doing this, Sephora helps people to show off their radiant shelves (“Mission Statement”, n.d.).

Vision:

Sephora’s vision is to make sure that the customer has the best experience with the products, an aspect it has been unequaled in this niche (“Vision”, n.d.).

Values:

“Sephora’s values include:

1. Passion

2. Innovation

3. Expertise

4. Balance

5. Initiative

6. Teamwork

7. Respect for all” (“Core values”, n.d.)

The first and the second value emphasize the company on the need for absolute commitment in whatever they do and third and fourth component emphasize maintaining a balance in all activities and applying top skills. By combining with independence, working together and respect for all is the success of Sephora (“Core values”, n.d.).

Strategy goals:

The current marketing strategy of Sephora is to focus on in-store and online store experiences. It also promotes brand involvement through web, social and mobile platforms. is they gather from their customers by their habit of shopping and then improve the functioning accordingly. To influence their sales, Sephora uses data to build confidence of the customer (Ogino, n.d.).

Porter’s competitive strategy:

After the analysis of Sephora, it indicates that the company operates a combination of Low-cost leadership and a Differentiation strategy. They sell their products in a broad range by keeping their price low and making changes to their products or services. For example, they had introduced different types of distribution channels- App store and internet. Their webpage was formed in the year 1999 that made limitless shopping opportunities for consumers. They have earned new customers from the success of their online store. It was supported by the importance of customer reviews, information about different elements, offers of products, and assistance from a specialist. They had a consistent name among women customers, but lately, they introduced a new campaign for male customers with the new brand- Lacoste men. For the comparison between other companies, Sephora had able to provide a premium quality service which made an impact on their competitors. They have also concentrated on the in-store location by putting the same amount of concern into their brand and having a reputation within the industry. In 2015, they announced two programs on their website about product information.

They have the most significant attribute which is the transactional function. They contact buyers by offering different products to satisfy them. They always make a deal for consumers by having a marketing strategy in mind. They had manufactured goods on the client’s needs and gives advice for customer skin (Tongyuwang, 2013).

Stakeholders of Sephora:

· Customers

Customers play a significant role by being the stakeholder of the organization. In Sephora, the customers expects the high quality of beauty products and services as these products would be applied on face, skin, hair and all the other parts of the body. So they must be extra careful while manufacturing these products. Also, the employees in the store must provide proper guidance to the customers as people may have allergies from different things and so all the ingredients must be carefully mentioned (Shokry, 2020).

· Employees:

Employees also play an important role by being the stakeholder of the organization. Every employee expects to be treated equally with others in terms of salary, their workload and many other factors. The employees must look after the customers properly with whatever their concern is and they must also report to their supervisors at the end of the end (Shokry, 2020).

· Owners and Stockholders:

Owners and Stockholders expect to earn financial return as they are the ones who are financially investing in Sephora (Shokry, 2020).

Type of Organizational Structure:

Organization structure defines the hierarchy of an organization and determines the way of information flow within. Sephora has functional division because of lack of horizontal linkage. Seeing the structure and working of a beauty and cosmetic company, Sephora is following up a centralized approach for its effective functions in the market. It is having a centralized and mechanistic structure following a hierarchy of corporate, management, assistant management, beauty advisors and sales associated in lowest level [Shokry, 2020]. The employees of Sephora are entitled and vested into vast culture. Employees and the business partners of Sephora is all about educating the clients and providing best customer service to our customers possible. A centralized approach of making decisions is followed where the main and primary decisions for company‘s main activities are taken by corporate and directors of first level. All the functional decisions are then going down with limited power of control and authority to manage and subordinates thereby. This means managers are few and subordinates working under them are more because of limited power. They use vertical communication because tasks are rigidly defined. In vertical communications, all the coordinate activities are done between the top and the bottom of the organization. Sephora is a traditional organization in which few teams and task forces and centralized decision making, vertical communication and reporting system [Shokry, 2020].

General Environment:

The General Environment of an organization alludes to a scope of forces or factors outside a company that may impact the operation and performance of a business. The effect of these dimensions is less direct when compared to a firm’s task environment. All the aspects of the general environment are considered by the managers so as to control, lead, organize and plan the operations of the organization. The general environment for Sephora would be the health minister closing the on campus classes for the students due to COVID 19. This thing will not affect the Sephora brand as they have no direct relation with the closure o schools (Utges, 2020).

Task Environment:

Task Environment straightforwardly influences the organization from achieving business objectives. It helps in recognizing the environmental factors liable for the achievement of the organization. Factors responsible for Task Environment are distributors, suppliers, customers and competitors. The task environment of Sephora was the all the shopping centres and stores were closed for a limited time due to COVID 19. Sephora faced a loss as the stores were closed and this impacted them financially (Utges, 2020).

Interorganizational Relationships:

Their inter-organizational relationship is cooperative which makes their company more efficient in the quality of service. They have an institutionalism type that puts attention on the desirability, structures, managing existence, and norms of their shareholders (Shokry, 2020).

Manufacturing and Service Technologies:

Sephora sells both skin care and beauty products and provides services to customers by helping the select the products based on their skin type and also sometimes they apply the makeup on customers. This helps customers in knowing about the product and product quality in a better way. This also helps them in know if the product suits on them personally. Sephora is the mix of both manufacturing and service organisation as they are manufacturing their own brand products as well as supply the other brands products (beauty and skincare) which are a way of servicing. Sephora offers a varied and wide range of products that meets everyone’s individual needs. Many of the products available at Sephora store are free of animal derived ingredients and natural ingredients (Shokry, 2020).

Core Technology:

The Core technology is the transformation procedure to deliver goods and services. They have focused on the digital transformation to become the number one in the beauty industry. “Digital and innovation have always been part of Sephora” (MARY BETH LAUGHTON). They concentrated on their customer needs and wants because, in order to be successful as a retailer, it is a requirement to provide the best services to their customers. They offer many types of tech alternatives to allow consumers for doing their shopping easily. Also, in the year 2015 Sephora innovation lab introduced and a team of administrators appointed from the product development, marketing had launch new contributions and technology for shopping in the store and online (Rayome, 2018).

It’s about directness for new ideas that require creating the right solutions which make something special and customer is unaware of. Sephora virtual artist, it is an AR tool that allows a customer to try different types of shades and other products sold at Sephora. It is a good example of their company because it has given assistance in real customer needs (Mckinnon, 2020).

Core technology: -

Core technology of Sephora is to manufacture as well as stock the products

Non-Core Technology: -

Non-core technology of the company is human resource, accounting, marketing, IT and many more departments.

Social Capital Activity:

There are many social capital activities that the Sephora organization is involved in. Firstly they welcome their customers very happily and warmly. Secondly, they help the customers in choosing the best product according to their skin type and according to their affordability. For example, whenever we go to Sephora, they are always ready to guide us in choosing the right makeup as well as skin care products according to skin type. Moreover, they even make their customers happy by giving them gifts on their birthdays. Furthermore Sephora provides free make up to the consumers after their purchasing from them. For example, one of our group members went to Sephora to buy blush and foundation on before party. After purchasing the product she asked for makeup to them. Then the Sephora professional put a beautiful makeup on her face for free (Jacobsen & Barnes, 2017).

Conclusion:

So, to conclude, we have briefly described about the different analysis of Sephora in this project.

References:

Jacobsen, S., & Barnes, N. G. (2017). On Being Social: How Social Identity Impacts Social Commerce for the Millennial Shopper. International Journal of Management Science and Business Administration.

“Mission Statement, Vision, Core values”. (n.d.). SEPHORA MISSION STATEMENT ANALYSIS. Retrieved November 28, 2020, from https://mission-statement.com/sephora/

Ogino, S. (n.d.). The “Makeup” Of Sephora’s Marketing Strategy. Retrieved November 15, 2020, from https://www.annexcloud.com/blog/the-makeup-of-sephoras-marketing-strategy/

Rayome, A. (2018). How Sephora is leveraging AR and AI to transform retail and help customers buy cosmetics. Tech Republic.

Sephora. (n.d.). About Sephora. Retrieved November 14, 2020, from https://www.sephora.com/beauty/about-us

Shokry, S. (2020). Interorganizational Relation.

Shokry, S. (2020). Services And Manufacturing Technologies.

Shokry, S. (2020). Stakeholders of Sephora.

Shokry, S. (2020). Type of Organizational Structure.

Tongyuwang, (October 31, 2013). Retrieved from https://tongyuwang.wordpress.com/2013/10/31/sephora-successful-distribution-2/

Utges, G. (2020, May 13). What is the difference between task environment and general environment? Retrieved November 28, 2020, from https://askinglot.com/what-is-the-difference-between-task-environment-and-general-environment

blog6

Business Requirements Analysis Report Example.pdf

Get help from top-rated tutors in any subject.