Thursday, March 11, 2010

Is it true that whoever owns the JIC website owns the JIC?

Way back in 1999, during the Olympic Pipeline disaster and my first major exposure to ICS and the Joint Information Center, JIC websites were just coming into play. Incident information was primarily about feeding the reporters who fed the hungry public and everyone else. That has all changed. The internet is rapidly becoming THE way that the public gets information--and certainly has become the most significant way that key stakeholders get information about an incident. The JIC website in many ways has become the most significant means of communicating with the public, stakeholders, internal audiences and even those involved in the response.

As a member of the JIC way back in 1999, this was already an issue for me. The website used for the Olympic response was the County's website. Only one person had any access which meant that if anything were put on it, it had to go through her. And she would not respond to any requests except those that came from her boss directly. Clearly he wanted it that way, but he was neither the incident commander nor the PIO. The site was branded as the County so communication coming from that was not seen as response information directly.

I developed the PIER System after that with this problem being one of many that it would solve. It would allow access to anyone and everyone authorized as a member of the JIC. It would be "owned" by the response and fully and completely accountable only to the PIO and through the PIO, Incident Command. No one could claim control over other than the official incident organization under ICS and now NIMS rules.

In recent conversations with PIOs from major agencies--from the state to the federal level--it is clear that this incident-ownership and NIMS compliant approach to the JIC website is not clearly understood. There is an on-going battle in many if not most multi-agency responses over who owns and controls the website or websites used from the response. Agency leaders and even more, agency IT leaders, are extremely reluctant to allow anyone but their agency staff to have access to the agency's website even when it is used in a JIC.

A case in point: major wildfires in California. The US Forest Service, CalFire and local fire departments all respond depending on the real estate involved. US Forest Service has InciWeb--a Forest Service proprietary system. CalFire has its own incident website. The fire departments all have theirs. What happens when they form unified command? Who's site becomes the JIC site? Given the IT regulations around each of these, no one except the agency people can manage content on the site, no one from the JIC except agency people have access. That means one agency controls the site content and, given the extreme importance today of the JIC website, controls the information. This doesn't work.

A JIC website absolutely must be a "Switzerland" system. It must allow secure access to only authorized JIC members but it must allow access to all JIC members who have a role in managing the content. It cannot go through a single agency and be NIMS compliant in the same way that agencies cannot dictate that their PIO will serve as the response PIO anytime they are involved. They cannot do that, but they are violating NIMS which specifies that the IC has the authority to appoint the PIO and to select on the basis of qualification and experience without regard to agency or seniority.

The battle over who "owns" and therefore controls the JIC website seems to be heating up. I think that is due to the growing understanding that the incident site is the focal point for media, public, stakeholder and internal information. But whatever website you are planning to use for your JIC, you must insure that only Command through the PIO has control over its content and that to be NIMS compliant and efficient, JIC members from any agency must have full and complete control over it.

1 comment:

  1. 你可以從外表的美來評論一朵花或一隻蝴蝶,但你不能這樣來評論一個人........................................

    ReplyDelete