|
3/13/2007 12:55:46 PM
|
|
Task Force History and Plans
|
FACADatabase Task Force History and Plans
June 15, 2006: At the June meeting of the Interagency Advisory Committee (IAC), Mr. Robert Flaak, Director of the Committee Management Secretariat, proposed that the IAC established a Task Force to address issues of concern to the FACA community regarding data collection, data management, reporting, and the ACR. To that end, Mr. Flaak provided a draft charter, proposed a working structure, and asked for IAC members interested in participating to make themselves known to the proposed chair. Mr. Flaak’s proposed draft charter is included below.
Summer and Fall, 2006: Dr. Kennett Fussell prepared a solicitation and secured funding for the initial year of a contract to first, maintain the existing FACADatabase at its current functionality level for the next few years, and second, develop a new version of the FACADatabase with current database and web technology. The initial year funding was for 250K and the eventual contract would have 4 additional option years.
September, 2006: The fall meeting of the IAC was held on 9/16/06. Members were informed of the progress of the solicitation process and invited again to consider participating on the FACADatabase Task Force. The solicitation responses were evaluated and the contract was awarded on 9/18/06. The funds for the first year include 200K for development, and the development funds for year two are anticipated to be a similar amount.
October, 2006: Dr. Fussell contacted IAC members who had either indicated an interest in participating on the Task Force themselves or who had nominated others from the FACA community from within their agency. A meeting date, time, and place were established.
|
|
3/13/2007 12:57:03 PM
|
|
October 26, 2006: Task Force Minutes.
|
October 26, 2006: Minutes.
The initial meeting of the FACADatabase Task Force was held from 10:00 am to 11:40am in
Room 4201 at the GSA Central Office Building,
1800 F Street, NW,
Washington, DC 20405
All members of the Task Force listed on the roster (separate attachment) were present either in person or by conference call except for Mr. David Cleary. Mr. Cleary was our most recent nominee from NIH, and his name was provided initially without phone number or email, so he could not be alerted or invited in advance of the meeting.
The agenda for the meeting was:
1. Meet and Greet.
2. Review the history of FACA relevant to the current system structure, functionality, and purpose over the past 10 years.
3. Revise and flesh out the draft charter relative to our goals, tasks, requirements, resources, and roles.
1. The Meet and Greet portion of the meeting established that we have a broad cross-section of the FACA community on the Task Force, with 10 agencies currently represented. Most of the members were either the CMOs from their agencies or had CMO responsibilities. There seemed to be general agreement that while the membership certainly had obvious experience and depth, the Task Force’s ability to accomplish its goals would be strengthened by having a few more DFOs and/or GFOs. The membership agreed to seek out and identify a few more such members. Only a couple of members were involved with FACA prior to the existing FACADatabase system, which will be 10 years in use at the end of FY 06’s Annual Comprehensive Review (ACR) cycle.
2. Dr. Fussell brought the group up to speed on the history of FACA in the context of the FACADatabase. This was an explanation of the current system structure, functionality, and purpose over the last 10 years.
a. The system was established and existed for the first few years to replace the paper reporting system used to generate the data for the “Annual Report” submitted over the President’s signature to Congress from 1972 through 1998.
b. The system was a minimalist venture, entirely funded by the Secretariat out of limited resources transferred from other operational accounts (mostly from an unfilled staff position), staff time, and existing staff knowledge of software and the web (mostly Dr. Fussell). The funds secured over the last ten years were translated contractually into web hosting, conceptualizing, and programming support provided almost completely by Bruce Troutman. The original structure derived from the data required on the reporting forms and the basic rules articulated in FACA, its amendments, and the GSA rule in place in 1997.
c. The system became part of the GSA Final Rule of 2001, which made it a FACA compliance requirement.
d. In 1999, as part of the “Paperwork Reduction Act”, Congress discontinued the requirement for the “Annual Report”. However, the law (FACA) continued to require an Annual Comprehensive Review (ACR), which was actually a more fundamental part of the committee tracking and management process than the summary report. Dropping the requirement for the “Annual Report” did not reduce the data reporting requirements of FACA at all. As a matter of record, Congress, including the Congressional Research Service and the Library of Congress, the White House including the Executive Office of the President, OMB, and GAO, have asked for new data collection items to be added every year since 2000. In some instances the items were always present in FACA’s data tracking requirements, but had not been previously collected, and in other instances they were wholly new and derived from the FACA community’s management needs.
e. Modules were added to the system incrementally over the years to address the management and reporting needs mentioned above. This was done in different years and at different points in time during the years, separately and together. Most new modules required “workarounds” due to the limitations of the original data design and technology, but somehow it all hung together and maintained a certain degree of connectedness and functionality. This was due in no small part to the creativity of the consultant and Secretariat staff, supported beyond the pale by the CMOs, and the patience and sufferance of the DFO community.
f. When we look ahead, we see that in the not too distant future, some major resources to the corporate knowledge and memory of the FACA community and the FACADatabase system will be moving on from government service.
g. We also see that in a similar timeframe that the software and technology upon which the FACADatabase is built will be reaching the end of its useful life.
h. The moment is also timely in that database and web development technology has just undergone a significant shift in stability, dependability, and ease of use. Fortunately, we have secured funding (approximately 400k over the next 2 years) and a supportive contract that will allow us to build a new system utilizing the more up-to-date technology.
i. We expect the new system to include the functionality of the current system while being significantly remodeled to eliminate most existing problems and limitations. The new system will be structured based on the lessons learned over the past ten years combined with a careful and in depth articulation of the anticipated needs of the FACA community for the next ten years.
j. While we, the Task Force, are defining, developing, building, and testing the new system, we, the FACA community, will be using the existing system, through the next two ACR cycles in FY 07 and FY 08. The system will be maintained in its current state, with most glitches removed, and with the user documentation complete for all parts of the system. Most of the problems of the past, beyond the design limitations, were introduced when new functionality was added in response to outside requests. We do not expect to add new functionality to the existing system from this point forward, and we expect the current ACR cycle to identify most of our remaining glitches. We expect that our next two ACRs should be relatively trouble-free in terms of the system since we will not be adding new changes.
k. We anticipate introducing the new system we will develop to the rest of the community as a finished, functional system at the beginning of FY 09. However, there is nothing sacred about that deadline. The new system will only be submitted to the certification and accreditation process when it is finished, and the new system will only be considered finished when this Task Force considers that it is clearly a functionally superior tool to the existing system.
The group commented and discussed the information above as it was introduced. Not all of the information or points above were introduced by Dr. Fussell.
3. The group did not work further during the meeting on the charter or set a time for the next meeting. Dr. Fussell asked the group to examine the charter document and to notice that it embraced a larger context than just the system.
To reiterate the draft charter:
The Task Force is established to provide the GSA Committee Management Secretariat (Secretariat) and the IAC with advice and recommendations on how best to collect, interpret, evaluate and disseminate information on Federal advisory committees. The Task Force will: a) evaluate the needs of the government wide FACA community and determine what information needs exist; b) identify necessary outputs and reporting functions needed to help Federal managers obtain the most accurate and current information on their advisory committees; and c) evaluate the existing GSA web-based FACA Database and develop recommendations on functional improvements to the system and types of output reports needed.
The very first draft was formatted differently and stated:
1) The Task Force will evaluate the needs of the government wide FACA community and determine what information needs exist;
2) Based on these needs, the Task Force will identify necessary outputs and reporting functions needed to help Federal managers obtain the most accurate and current information on their advisory committees;
3) The Task Force will evaluate the existing GSA web-based FACA Database and develop recommendations on functional improvements to the system and types of reports needed;
4) The Task Force will serve as an advisory group to GSA on development of the next generation of the FACA Database; and
5) The Task Force will evaluate the current annual comprehensive review (ACR) process and suggest improvements.
While either of the examples above is clearly an incomplete draft, they both have implications for the context and process of the ACR and they both extend the reporting needs and requirements that currently underlie the functionality of the current system.
Bruce Troutman, the winning contractor and consultant to the Task Force indicated that he would be setting up multiple web sites for the Task Force’s use. A major web site will be the user testing site for our Task Force members to use as we proceed with the development of the new system built with modern web tools and current database technology. But one of the first sites visible to the Task Force will be a Message Board to use as a message posting and idea exchange location for our work. We will be sending information on the site location out when it is available. At that time, the members of the Task Force are invited to post their expanded and detailed thoughts on the charter for our work (minimally) over the next two years. When we have finalized the charter, the message board will continue to be used as a central location to enter, list, and track our evolving ideas and requirements for the new system.
The charter is the starting point. Every member is asked to look to the charter to see what it embraces and what is missing. If you and your agency have a particular concern about the data collection process or the data collection tool and its range and breadth, the charter is the place to define that issue into or out of the process. We are all invited to take what is there and rewrite it to make it a working document to guide our efforts and meet the FACA community’s needs.
We finished the meeting with Dr. Fussell indicating that he would prepare the minutes, distribute them, and set up a time for the next meeting. It was anticipated that the next meeting would be well into November.
|
|
3/13/2007 12:58:55 PM
|
|
Task Force Member Contact Information
|
FACADatabase Task Force Membership List.
Agency Title LastName FirstName PhoneNumber Email
DoD CMO Freeman Jim 703-601-2554, x 128 jim.freeman@whs.mil
VA CMO Drake Vivian 202-273-4838 vivian.drake@va.gov
NEA CMO Plowitz-Worden, Kathy (202) 682-5691 plowitzk@arts.endow.gov
DOI CMO Norman Sharon (202) 208-4524 Sharon_Norman@ios.doi.gov
DOC CMO Anadale Linda (202) 482-7873 LAnadal1@doc.gov
TRES CMO Saumure Angel (202) 622-0078 Angel.Saumure@do.treas.gov
DHS CMO Abraham Georgia (202) 282-9150 Georgia.Abraham@dhs.gov
DOI GFO Grey Hope 703-358-2482 hope_grey@fws.gov
DOC GFO Calzada Angela 202-482-1110 angela_calzada@ita.doc.gov
SBA CMO Wood Donna 202-619-1608 donna.wood@sba.gov
TRES DFO Coston Bernie 404-338-8408 Bernie.E.Coston@irs.gov
GSA CMO Weber Maggie 202-273-3556 Maggie.Weber@gsa.gov
HHS GFO Cleary David 301-496-2123 Claryd@mail.nih.gov
GSA DO Fussell Kennett 202-273-3567 kennett.fussell@gsa.gov
Contractor Consultant Troutman Bruce 202-460-8020 bruce.troutman@fido.gov
NSF CMO Bolton Susanne 703) 292-7488 sbolton@nsf.gov
GSA ex Officio Flaak Robert 202-208-2964 robert.flaak@gsa.gov
GSA ex Officio Howton Charles 202-273-3561 charles.howton@gsa.gov
Contractor Consultant Dallis Bill
edited by kennett.fussell@gsa.gov on 5/9/2007
|
|
4/6/2007 8:46:33 AM
|
|
Search Capability
|
This was an email I received from an IRS user about a feature she would like to see in Search-KF.
Ken,
what precipitated my request was a question by a volunteer member whose term is up this year and he was interested in other gov't advisory boards. I looked at the search feature and while that could be useful if I knew what "area" I was interested in, I like the idea of a list of the committees with a link to their charter for ease of use. It would allow visitors to browse and have their interest peaked by names of committees (at least that is how my brain works).
Thanks for the prompt reply and the opportunity to comment.
Judi
Judi L. Nicholas
Taxpayer Advocacy Panel - Program Manager
Phone/VMS - (206) 220-6099
Fax - (206) 220-5760
|
|
4/20/2007 12:59:52 PM
|
|
03/14/07 Meeting Minutes
|
FACADatabase Task Force Meeting Agenda
1. Review Minutes and Contact Information.
The Task Force meeting began about 1:00 pm with the members identifying themselves on the phone and in the room. Only two members were unable to attend. Bernie Coston from the IRS added his phone information to the Membership List.
Ken Fussell asked if there were any corrections or additions to the minutes, and none were offered.
2. Review, discuss, and finalize proposed charter.
Feedback via Forum:
Ken acknowledged the task force members who had visibly utilized the online forum thus far, himself, Maggie Weber, Kathy Plowitz-Warden, Angel Saumure, David Clary and Bruce Troutman. Maggie had taken Ken’s “extended version of the task force charter” and thoroughly streamlined it. Both Angel and Kathy commented favorably on Maggie’s effort and Kathy added a few additional comments on grammar and construction. Everyone felt that the charter was pretty solid, so the group moved along to Ken’s concern that the charter required an ACR component and that a central purpose of the resulting system would be that the system support and facilitate the ACR.
ACR component:
The group clarified in discussion that its task might extend to recommending to the Director of Committee Management and the CMOs how a more flexible, less lock-step ACR be conducted. And, that, even if the group was not prepared, at the conclusion of its work, to recommend how the ACR be conducted government-wide, it remained part of the group’s charge to assure that the eventual system supported the ACR process. The ACR would have to be part of our thinking and considered for its needs and impact every step of the design and implementation process. The group moved on.
First task – Constituencies:
Ken pointed out that a component that should be included in our awareness from the very get-go was the user constituencies for the eventual system. We discussed the reality that the limited view of the constituency for the first cut of the first system imposed a constraint on the design that severely limited the eventual flexibility of the evolving system. Again, while we did not resolve what the total array of constituencies were, we did resolve to hold the issue in our awareness as we proceeded through these early months and to effectively identify an acceptable collection before we concluded the design process.
3. Review and demonstration of use of the Forum for communication and record-keeping.
Ken walked through the layout and some of the features of the Forum application.
• The RSS feature – the RSS feed works with current browsers to alert the user that a change has taken place in the application’s information. It works with IE7, which we could not demonstrate in the conference room because the computer had IE6 installed.
• Posting order – Kathy suggested that the posting order for discussion threads might be more useful if they were listed as most recent first, which reverses the order that is currently displayed. Georgia agreed. We decided to experiment with that approach.
- Requirements development
Ken explained how he envisioned the forum supporting the group in identifying the requirements. Rather than making notes about what features of the current system are useful, or what features could be discarded, or what features we should have in the new system, we could just post our ruminations to the forum. This would allow the discussions to start, develop, and perhaps even by resolved by the time we held the next meeting. We noted that David had been using the Forum for exactly that purpose during the previous week. Ken read and discussed a couple of David’s entries as examples of how the forum was going to be useful to us as a vehicle for capturing the requirements. The use of forum was for capturing the requirements was returned to many times throughout the meeting, with examples from Jim on document capture and archiving via committee website; Kathy regarding the consultation process; Maggie regarding coordination on the consultation process and regulatory development; Bruce on the use of the forum to identify the requirements and the problems, not the solutions to the problems; and Ken urging continuous use.
4. System Requirements
- Retain all the identified functionality of current system
Ken suggested that about 99% of the current system does what we want and we will be careful to avoid losing what the system currently does that we like. No objections to that opinion were voiced. The discussions used the examples already posted to elaborate on how the forum would help us. Susanne clarified how the forum permitted searching and gathering together the information and topics captured in the forum. There was some discussion dealing with the concern that the whole project was potentially so big and encompassing that it would overwhelm us unless we broke it up into manageable chunks. We discussed that and pretty much acknowledged that this was going to be a best effort based on what we already had achieved with the first version of the system and, like the first version, when we presented it to the world it would be as complete as we could make it, but there would be no reason to consider it finished and unchangeable.
- Add new requirements via Forum
As we look at the current system, when a feature we are using strikes us as important, we will note that in the forum, so that the rest of task force can interact with our observations. We will take the same approach when we notice the lack of a feature that we could use. Kathy observed that it was hard to build something without having defined what the something does or is supposed to accomplish. Ken observed that it might be more circular, we will be figuring out what we want by talking about what we want. Bruce pointed out that our development was iterative the first time around and it would be this time as well, only we will be starting with what we already have. We will put up a system and learn what else we want it to do by interacting with the system we put up, and we record our observations in the forum so we do not lose them.
Ken suggested that the process would embrace
• capturing and discussing the requirements in the forum to the extent possible and resolving some issues in meetings,
• moving the agreed upon requirements to a requirements/documentation database that would also be maintained and accessible to the task force, and
• Incorporating the requirements in the database into the continuously developing prototyped system.
The group as a whole asked for clarification on how new topics were posted to the forum and Ken demonstrated adding a new topic. We then discussed how much organization each of us has to bring to the development process. We also discussed the functionality and requirements of the RSS feed the forum has built into its design. The RSS feed can be set up to automatically alert us when new items are added to the forum. The RSS feed works automatically with the Microsoft IE 7 browser, but requires securing and installing plug ins for earlier MS browsers.
5. Demonstration of prototyping capability of new technology.
We took a look at a prototype that was built by from a revised table structure from the current system. Bruce inserted a link to the prototype into the forum. We were not suggesting that the prototype was what we wanted, but rather demonstrating how quickly something could be put together that included a lot of the functionality we were looking for. The demonstration led to further discussions of what we like in the current system and what we want in the future system. Ken and Bruce emphasized that the demo provided at this point was beyond plain vanilla; it was useless for display purposes for a specific user and was oriented to showing the new functionality we would acquire and how quickly we could produce a product.
6. Set a Time, Place, and proposed Agenda for next meeting.
We agreed that we would likely try for a meeting the week of 4/17/07.
|
|
6/7/2007 4:07:09 PM
|
|
5/9/07 Meeting Minutes (Interim)
|
FACADatabase Task Force Meeting Minutes for 05/09/07
1. Members Present.
The Task Force meeting began about 1:00 pm with the members identifying themselves on the phone and in the room. Georgia Abraham from DHS and Hope Grey from DOI were on the phone and Hope’s connection was poor. Vivian Drake From VA, Maggie Weber from GSA, Kathy Plowitz-Worden from NEA, Linda Anadale from DOC, Angel Saumure and Tonya James from TRES, Susanne Bolton NSF, David Cleary from NIH/HHS, and Ken Fussell as Task Force Chair were in the room.
2. Review and discuss thoughts regarding the stakeholders and constituencies identified as concerned with the structure, content, and reporting capabilities of the FACADatabase, ver. 3.
Ken began the discussion by asking if we were including everybody we should in our thinking. Ken listed the current constituencies of which he was aware and which include:
• The system was initially developed for Committee Management reporting purposes.
• The DFO role within agencies that have advisory committees was the first user identified since the DFO provides most of the system information.
• The GFO role was added since there are often agency sub-groups with responsibility for multiple committees.
• The CMO role for agencies and Committee Management roles were added. First, he CMOs had to validate the information at the end of the reporting periods, and then the CMOs and Committee Management tracked the consultation process and the committee life cycle within the system. This began from Committee Management’s perspective but has evolved with a greater inclusion of CMO needs and concerns.
• In the interest of openness and because FACA is focused on Public Participation in government we added the Public Access component.
• The White House was added as a user role when the WH Personnel Office expressed interest in 2001 and they continue to use the system.
• The Library of Congress refers inquiries to the database.
• The Congressional Research Service uses the system.
• The General Accountability Office is known to use the system as a starting point for some inquiries directed from Congress towards the activities of agencies.
• Congressional Staffers inquire and are directed to the database several times a year.
Georgia pointed out that the internal use by department officials within the agencies has increased significantly over the years, usually focused on committee membership and committee functions.
Angel reported that her agency uses the system for similar purposes and she directs people from the agency up to and including the secretary’s office to the system as a starting point when there are inquiries about creating new committees, urging the inquirers to determine if there are already committees established that are looking at similar concerns. If agency users can’t find what they need, then Angel’s office will do the research, but often still using the system as the basic tool and starting point.
Ken reported that DOI is using the current system for vacancy reports. Hope observed that the agency wants to use the system and is trying to use the system, but the leadership has no real confidence that their users at the DFO level keep the system up to date, so they ask people to produce a separate monthly report through other channels to compare to the information they have in the system. Generally they are unhappy with the result.
Linda and Georgia shared their methods for creating incentives to keep the records up to date.
Angel wondered aloud if was really appropriate that the Performance Measures should be visible to the public. This was batted around, with Angel pursuing the idea that perhaps it should be internal to the FACA community and others weighing in from various perspectives. Linda, Vivian, Georgia all commented. Ken noted that the discussion had moved away from constituencies and stakeholders but promised to return to Performances Measures and these issues in the Requirements review.
Susanne noted that we should not overlook universities and similar user groups from the public sector. At this point, since no other groups were being identified, Ken suggested that we wrap up the stakeholder discussion for now and return to it when anyone felt they had identified a new group that we had not already included.
3. Requirements Development:
Ken suggested that we continue the requirements development process by examining the current system page by page and role by role, identifying the requirements that had produced those pages and their current contents, keeping what was relevant, discarding what was not needed and adding whatever new requirements we identified.
We began with the Home page and Ken invited the task force to comment on their use of the Home Page and its links.
The group discussed briefly the contents of the Printed Reports 1972-1998 link, and noted that the link would be improved if it was more informative.
The same observation was made about the Case Digest Search.
The Up link and in truth the entire navigation system needs clarity. We need to experiment to find out what works for us as we set up the new system.
Some of the Task Force present felt that the Score 300 link was confusing in its purpose to anyone but the in crowd at the time of the ACR. Others thought the public had a right to know who was keeping the system up-to-date and current.
Logon will be changing in concept and location, since users may be able to logon from anywhere in the system when they have a need to edit data. We discussed the possibility of an automatic logon if the user hit the web site from their assigned workstation.
Ken mentioned the current aspects of the logon process that will be retained, i.e., the username/logon will be the user’s email address so that the user can be sent their password anytime they forget it, and the username/password combination is unique in the system and is linked to the user’s role and access rights.
Angel felt that when read-only data/results are presented to any users, it should be clear and obvious that it is read-only and not editable.
Kathy pointed out that the link names Search and Public Access can sort of mean the same thing to some people. The links are not clear.
Angel thought that it might help if Search was not on the Home page.
The group next discussed the Search link. Ken pointed out that in versions 1 and 2 the Search function was part of the public access concept and a user lost their rights when they selected Search, even if the committee found or selected was one that they owned. In version 3, on the other hand, the system will remember the logged in user’s rights, even when they invoked Search.
Vivian observed that simple, clean, un-cluttered pages were more visually pleasing.
Ken explained how clarifying information will be available to the users about each link and field via hidden tags on the page and how that process made the web page more use to blind users who were accessing the web pages using screen readers.
The group turned their attention to the Search Page and Ken explained the current functionality of the Search in Documents part of the page, i.e., it searches the text part of the committee documents stored online with the database. Ken differentiated the current search capability and the intended search capability in the revised system. With the current system the user searches for text, identifies the committee of interest from the text search, leaves the text search and then drills down to the agency and committee from the Explore Data link/button. With the planned system the user will search for text and will be presented with links to the relevant committees.
Kathy proposed a new search capability on the public’s behalf, a search of meetings by interest areas that would link to the committees. This could be provided either by a search with the appropriate parameters or by a set of reports about meetings that could be customized to get similar results. This generated a discussion by the group on how else the current and future database could be used if we collected data we do not currently collect, i.e., members by congressional district or political party. We will not be going that direction without a statutory requirement to do so. This also prompted discussions about how the system can be currently used to produce tables and schedules of proposed and planned meetings as well as a history of meetings held. Ken wrapped up this section by suggesting we would be coming back to Search with additional requirements as the system evolved.
The group moved on to a discussion of the Help feature, what we wanted Help to be, whether manuals were needed, how they should be named, etc., etc. Georgia thought that it would be more useful if the help displayed was controlled by rights of the logged in user and was context sensitive, so that an individual user was not overwhelmed by all the help possibilities for work they could not do and functionality they could not access. This discussion went on for quite a while.
|