Chapter 1. Introduction

1.1 What Are EHBs?

Electronic Handbooks (EHBs) are Internet-based tools that support the paperless documentation and management of complex distributed processes over multiple organizations following some people principles. One example of a complex distributed process over multiple organizations is Contracts/Grants Management in which Contracts/Grants are developed along the subprocesses: solicitation development, application submission, review and selection, award/contract negotiation, award/contract. administration, award/contract closeout, and post-closeout processes. Other examples of complex distributed processes over multiple organizations include the management of health episodes, automobile sales, legal cases, insurance policies, publications, credit cards, loans, public school enrollments, university. enrollments, etc.

One application are the EHBs for managing the National Aeronautics and Space Administration's (NASA) Small Business Innovative Research. (SBIR) contracts. See Figure 1.1 (a). NASA's SBIR manages two contract programs which constitute roughly 50% of all of NASA's annual. contracts. It purpose is to fund small businesses to develop technologies for NASA as well for their own commercialization. NASA's SBIR programs involve over thirty organizations distributed throughout the country in NASA's Field Centers and Headquarters. See Figure 1.1 (b). At various points in the book, we also refer the reader to other examples of EHBs applications.

Our basic approach is to wrap an organization's subprocesses in a common envelope to facilitate learning, plus intra- and inter-organization communication. See Figure 1.1 (c). The Description provides an overview of the subprocess. The Play describes the temporal flow of the subprocess with the actors. Documents describe the data used in the subprocess. Guidelines describe the roles used in the subprocess. In all four cases, there are also provided the organization's specific examples as well as links to other organization's specific examples. In addition, process libraries maintain organization's envelopes or views of the subprocesses. See Figure 1.1 (dc).

Subprocesses and their EHBs fall into five groups. Product Realization subprocesses deal directly with the development of the organization's key. products. For example, in the case of Contracts/Grants, these would. include Solicitation Development, Review and Selection, Administration. and Closeout. Product Distribution subprocesses deal directly with the. distribution of the organization's key products. For example, in the case of. Contracts/Grants, these would include Technology Transfer Guidelines. Document Development, Submission, Review and Selection, Administration and Closeout. Support subprocesses are those that aide the other subprocesses.For example, these would include Help Desk. Configuration Management, and Measurement & Analysis. Improvement. subprocesses are those that deal with improving the subprocesses and their. EHBs . For example, these would include ISO 9001:2000, CMMI-Continuous, and CMMI- Staged. Common. subprocesses are those that deal with all other the subprocesses and their. EHBs . For example, these would include Organization Subprocess Formulation, Organization Subprocess Implementation, Organization Subprocess Evaluation, and Organization Subprocess Closeout..

Figure 1.1 (a). NASA SBIR Subprocesses.

Figure 1.1 (b) . NASA SBIR Community.

Figure 1.1 (c). The basic approach is to wrap an organization's subprocesses in a common envelope to facilitate learning, plus intra- and inter-organization communication.

Figure 1.1 (d). In addition, process libraries maintain organization's envelopes or views of the subprocesses.

1.2 EHBs Is Where Shakespeare Meets Freud

Electronic Handbooks is where Shakespeare meets Freud. See Figure 1.2 (a). Subprocesses are represented as "plays" where "actors" communicate thru the Internet. Each organization puts on its own "productions". For each role, individual User EHBs guide actors thru their parts. [Shakespearean] Organizations are represented as "teams" having "multiple personalities". Subprocesses "plays" provide communication vehicles between the same team, different teams, and teams from different processes. [Freudian] We also believe that to truly understand one's universe, one must see it thru multiple "eyes". See Figure 1.2 (b). Organizations are made up of people and people principles have to be followed. See Figure 1.2 (c).

Figure 1.2 (a) Electronic Handbooks is where Shakespeare meets Freud.

Figure 1.2 (b) We also believe that to truly understand one's universe, one must see it thru multiple "eyes".

Figure 1.2 (c). People Principles.

1.3 An Overview Of This Book

Subprocesses and their EHBs are demonstrated, organized, outlined, specified, designed, built, used, revised, and improved using several web-based tools:

• Demonstration Tools introduce the concepts to a community in their terms. See Figure 1.3 (a). This is a Demonstration Tool for outlining the scope of the NASA SBIR Electronic Handbooks system.
• Process Library maintains all these tools. See Figure 1.3 (b). This is a Process Library for organizing the documentation of the NASA SBIR Electronic Handbooks system.
• Subprocess Libraries organize subprocess tools. See Figure 1.3 (c). These are Subprocess Libraries for product realization subprocesses of the NASA SBIR Electronic Handbooks system.
• View Tools show how organizations view their subprocesses. See Figure 1.3 (d). This is a View Tool for collecting the ways in which the ten NASA Field Centers view the Integrated Problem/Solution Database subprocess of the NASA SBIR Electronic Handbooks system. View Tools contain:

Descriptions summarize subprocesses. See Figure 1.3 (e). This is a Play Tool for describing how an organization views the NASA SBIR Contract Administration and Closeout subprocess.

Plays describe subprocess execution. See Figure 1.3 (f). This is a Play Tool for describing how an organization views the NASA SBIR Contract Administration and Closeout subprocess.

Documents describe subprocess data. See Figure 1.3 (g). This is a Document List for describing how an organization views the NASA SBIR Contract Administration and Closeout subprocess.

Guidelines describe an organization roles. See Figure 1.3 (h).. This is a Guidelines List for describing how an organization views the NASA SBIR Contract Administration and Closeout subprocess roles.

• Integration Tools facilitate subprocess document integration. See Figure 1.3 (i). This is a part of a Integration Tool for integrating all of the documents for the NASA SBIR Electronic Handbooks system.
• Electronic Handbooks (EHBs) facilitate the execution of subprocesses. See Figure 1.3 (j). This is an Electronic Handbook for an Advisor role for the NASA SBIR Contract Administration and Closeout subprocess.
• Improvement Tools facilitate overall process improvement. See Figure 1.3 (k). This is an Improvement Tool for improving the NASA SBIR Electronic Handbooks system.
• Requirements Capture Tools (RCTs) facilitate subprocess view integration. See Figure 1.3 (l). This is a Requirements Capture Tool for integrating all of the views for the NASA SBIR Contract Administration and Closeout subprocess.
• Play Development Paradigm Over Multiple Productions faclitates subprocess building and revision. See Figure 1.3 (m.

In Chapter 2, we will see how to demonstrate EHBs using Demonstration Tools. In Chapter 3, we will see how to organize subprocesses and their EHBs using a Process Library. In Chapter 4, we will see how to outline/playwright subprocesses and their EHBs using Requirements Capture Tools. In Chapter 5, we will see how organizations specify requirements using View Tools. In Chapter 6, we will see how to design, build, use, and revise subprocesses and their EHBs using Requirements Capture Tools, Document Libraries, and Checkoff Tools. In Chapter 7, we will see how to improve processes using Improvement Tools. The subprocesses described in Chapters 2 - 7 strongly interact and iterate with one another. In Chapter 8, we will examine sample subprocesses. In Chapter 9, we will conclude the book by summarizing the development process, examining assembly line processes, and reviewing the benefits of EHBs. Throughout this book, readers are pointed to Appendices A1-A7 where there are libraries of samples.

Exercises.

1. Browse around the EHBs home page http://ehbs.org/.

2. Browse around the National Aeronautics and Space Administration's (NASA) Small Business Innovation Research (SBIR) Program home page http://sbir.nasa.gov.

Figure 1.3 (a). NASA SBIR Demonstration Tool.

Figure 1.3 (b). NASA SBIR Process Library.

Figure 1.3 (c). Subprocesses in NASA SBIR Process Library.

Figure 1.3 (d). NASA SBIR Contract Contract Administration
View Tools.

Figure 1.3 (e). NASA SBIR Contract Contract Administration
and Closeout Subprocess Description.

Figure 1.3 (f). NASA SBIR Contract Contract Administration
and Closeout Subprocess Play.

Figure 1.3 (g). NASA SBIR Contract Contract Administration
and Closeout Subprocess Documents.

Figure 1.3 (h). NASA SBIR Contract Administration
Subprocess Guidelines.

Figure 1.3 (i). NASA SBIR Contract Administration Integration Tool.

Figure 1.3 (j). NASA SBIR Contract Administration
and Closeout Subprocess Advisor Electronic Handbook
(EHB).

Figure 1.3 (k). NASA SBIR ISO 9001:2000 Improvement Tool.

Figure 1.3 (l). NASA SBIR Contract Administration
and Closeout Requirements Subprocess Capture Tool (RCT).

Figure 1.3 (m). Play Development Paradigm Over Multiple Productions facilitates subprocess building and revision.

1.4 View Integration

To develop the above tools, we also recommend that you have sequential user group meetings [e.g., web-based tool + telephone] for comments on the tasks/tools. We refer to this approach as View Integration , since each user group (i.e., organizations, roles, etc.) has its views sequentially integrated into the tasks/tools. See Figure 1.4. The size of a user group may be as little as one or as many as ten. As users make suggestions, you can immediately edit the web-based (HTML) tool, reload it to the server, have the users "refresh" their browser, and then repeat the process. You should perform this interaction with different types of users (i.e., organizations, roles, etc.). After you have interacted with a number of types of user groups, you will have a better sense of the requirements. Following this, you can then have more integrated group meetings.

There are three reasons for this approach.

First, our experiences are that group dynamics can often be so intense that uncoordinated group meetings can often lead to strong dissention. This approach is akin to that used by a Family Therapist who first interviews the individuals of the family so he/she may prepare for the larger group interactions. To quote Thomas Jefferson, "The method of separate consultations prevents disagreeable collisions. While an integrated group meeting is taking place, it is important that the meeting be controlled. In particular, all participants should get to equally express their views and that the discussions not be dominated by participants with strong personalities.

Second, by individually integrating their views, you get stronger by-in on the part of the contributors. Contributors, by directly working with the developer, are more apt to feel ownership of the resultant tools and/or process. By observing, in real-time, the integration of their comments into the evolving tasks/tools, contributors also develop a stronger trust in the developer. As a result, the development of the tasks/tools becomes more a team effort as opposed to that of the developer trying to convince others of the appropriateness of his/her ideas.

Third, by integrating views of suborganizations, you facilitate the capability of suborganizations to tailor the subprocesses and their EHBs to their own specific needs. For example, by integrating NASA's Ames Research Center (ARC) view in the NASA SBIR Review and Selection subprocess, this facilitates the ARC in providing its SBIR evaluators with ARC specific guidelines for evaluating proposals. By integrating NASA's Space Science Strategic Enterprise view in the NASA SBIR Solicitation Development subprocess, this facilitates the Space Science Strategic Enterprise in providing its SBIR topic and subtopic managers with guidelines for developing topics and subtopics.

Figure 1.4. View Integration of Tools Based on User Groups (Roles).

1.5 Evolving Subprocesses and Their EHBs

There are five phases of evolution of subprocesses and their EHBs. See Figure 1.5.

Subprocess Online and Data Offline. This is where the subprocess is online but the data is offline.

Online Subprocess and Data. This is where the subprocess and the data are online but the data is passed out of the electronic system.

Integrated Online Subprocess and Data. This is where the subprocesses and the data are online and the data is passed inside of the electronic
system.

Reusable Integrated Online Subprocess and Data. This is where the subprocesses and data are integrated, online and made up of reusable
components.

Cross-Organization Reusable Integrated Subprocess and Data.This is where the subprocesses and data are integrated, online, reusable across multiple-organizations.

In all five phases, subprocesses and their EHBs are demonstrated, built and revised, executed, and improved using the same web-based tools that facilitate communication between participants. See Figures 1.3 (a) - (k).

Exercises.

1. Browse around the How Can I Apply EHBs To My Organization's Processes? link on the EHBs home page http://ehbs.org.

Figure 1.5. NASA SBIR Process Library (PL) files.

1.6 Other Applications

We highlight here some applications of EHBs.

Department of Justice's Bulletproof Vests Partnership (BVP) Program. This application supports the co-finding of the purchases of Bulletproof Vests to all policemen and women in law enforcement agencies throughout the United States and its possessions. Roles include state and local jurisdictions, law enforcement agencies, bulletproof vest manufacturers and distributers. (URL http://vests.ojp.gov/)

Justice's Local Law Enforcement Block Grants (LLEBG) Program. This application supports a program grants to state and local jurisdictions (e.g,. Maryland, Montgomery County, MD) for law enforcement agencies throughout the United States and its possessions. Roles include state and local jurisdictions, law enforcement agencies, and program managers. (URL http://www.ojp.usdoj.gov/BJA/grant/llebg_00main.html)

Federal Emergency Management Administration's US Fire Administration (USFA). This application supports a program grants to local fire departments for equipment all around the country. Roles include state and local jurisdictions, fire emergency departments, and program managers. (URL http://www.usfa.fema.gov/)

Justice's Office of State and Local Domestic Preparedness Support (OSLDPS) Program. This application supports a program grants to state and local jurisdictions for domestic preparedness for terrorist and other emergencies all around the country. Roles include state and local jurisdictions, law enforcement agencies, and program managers.(URL http://www.ojp.usdoj.gov/osldps/)

Treasury's Community Development Financial Institutions (CDFI). This application supports a program grants to state and local financial institutions for community development all around the country. Roles include state and local community development organizations, financial institutions, banking institutions, and program managers.(URL http://www.ustreas.gov/cdfi/)

Health and Human Service's Health Resources and Services Administration (HRSA). This application supports provide support grants to health professionals. Roles include state and local health agencies, physicians, nurses, hospitals, and program managers. (URL http://www.hrsa.gov/)

Interior's Property Disposal. This application supports the management of property (disposal and reuse) throughout the entire Department of Interior. Roles include department of Interior personnel, property managers, and program managers. ( URL http://www.doi.gov/ )

NASA's Earth Sciences Technology Office (ESTO) Programs This application supports a program contracts for NASA-wide earth science technology development. Roles include principal investigators, contracts specialists, contracts officers, NASA mission customers, reviewers, and program managers.(URL http://esto.gsfc.nasa.gov/)

NASA's Education Division Computer Aided Tracking System (EDCATS) This application supports NASA-wide education program tracking, reporting and analysis. Roles include education program participants, education program managers, reviewers, and NASA HQ education program managers. (URL: http://www.ojp.usdoj.gov/BJA/grant/llebg_00main.html)

NASA's Policies and Procedures (Directives). This application supports NASA-wide development of policies and procedures.. Roles include NASA associate administrators, NASA staff, NASA attorneys, NASA program managers, and NASA directives managers.(URL http://nodis.gsfc.nasa.gov/)

Federal Financial Assistance Management Improvement (FFAMI). This application supports Federal Government-wide grant program management. Roles include principal investigators, grants specialists, grants officers, reviewers, and grant program managers.(URL http://www.reisys.com/iaegc/)

Exercises.

1. Browse around some of the home pages in Other Applications link on the EHBs home page http://ehbs.org/

2. Browse around the Experiences and In The Press links on the EHBs home page http://ehbs.org/

1.7 Objectives

We describe here the four primary objectives of EHBs. In Chapter 6, we will discuss how these objectives are achieved. The objectives of EHB are to:

Facilitate paperless documentation and management of complex distributed processes. This means that we want EHBs to facilitate the labor intensive documentation effort of a complex distributed process. It also means that we want EHBs to facilitate the actual coordination and management of potentially thousands of participants partaking in the process.

Facilitate system development. By this we mean that EHBs should facilitate the following subtasks that are common in computer system development:

Requirements Capture. This deals with the querying of the system owners and users to find out what exaclty the system needs to do.
System Design. This deals with the designs of the user interface and internals of the system.
Implementation. This deals with the actual implementationand testing of the system.
Multi-Developer Coordination. This deals with the coordination of the development of the system between more than one developer.
Software Distribution. This deals with the distribution of the software on all of the computers of the users..
End-User Learning.T his deals with the teaching of users how to use the system.
System Documentation. This deals with the documentating of the system to enable others to maintain the system.
System Revisions. This deals with the revising of the systems as improvements and changes need be done.
System Reuse for Similar Processes.This deals with the reuse of programs and software for similar developments.

Facilitate integration of independently developed subsystems. By this we mean that EHBs should facilitate the integration of already existing, independently developed and potentially non-communicating subsystems of a process. It should also facilitate the eventual addition of new computer systems that will make the whole process end-to-end paperless.

Facilitate process and system improvement. By this we mean that EHBs should facilitate the improvement of the process. It also means that we want EHBs to facilitate the improvement of the system/systems used to manage the process.

In Chapter 9, we will show how all of these objectives are met in the discussion of the Benefits of EHBs.

Exercises.

1. Browse around the 4. Objectives link on the EHBs home page http://ehbs.org/.

1.8 Architecture

We describe here the three architectural perspectives to EHBs, namely, System, Security, and Participation.

System Architecture. See Figure 1.6 (a). End users and EHBs both use the Internet. The end user interacts via a World Wide Web client such as Internet Explorer, AOL, or Netscape. The EHBs system interacts through several servers: World Wide Web, Database Management System, Graphics Report, Legacy System, and Middleware. Examples of Middleware are DBGenie, Cold Fusion, and Dynamic Forms. The entire EHBs system uses Commercial Off the Shelf (COTS) components.

Security Architecture. See Figure 1.6 (b). End users and the EHBs system implement security through the Internet. The end user interacts via a user EHB through a secure password and role mechanism. The EHBs system interacts through several servers: World Wide Web, Roles, Database Management System, Encrypted Document, and an Electronic Signature System.

Participation Architecture. See Figure 1.6 (c). There are three dimensions of EHBs participation. Top-to-Bottom participation means that
EHBs involve users across all levels of process management. Coast-to-Coast participation means that EHBs involve users located across
physically separated sites. And Cradle-to-Grave participation means that EHBs involve users across all connected subprocesses. EHBs manage all participants in all processes.

Exercises.

1. Browse around the Architecture link on the EHBs home page http://ehbs.org/.

Figure 1.6 (a). System Architecture.

Figure 1.6 (b). Security Architecture.

Figure 1.6 (c). Participation Architecture.

Chapter 1. Introduction

1.1 What Are EHBs?

1.2 EHBs Is Where Shakespeare Meets Freud

1.3 An Overview Of This Book

1.4 View Integration

1.5 Evolving Subprocesses and Their EHBs

1.6 Other Applications

1.7 Objectives

1.8 Architecture

Related Reading