
| Entry Title | Business Plan Developer |
| Submitted by: | SI International, Inc. |
| Contact Name: | Janet Cichelli, Craig Marion |
| Phone: | 240-778-1223 (Janet); 240-778-1200 (Craig) |
| E-mail: | Janet.Cichelli@si-intl.com; Craig.Marion@si-intl.com |
| Address: | 2099 Gaither Road, Third
Floor Rockville, MD 20850 |
| Logo: |
![]() |
|
|
|
| Purpose: |
Beginning in 1999, the National Park Service (NPS) began to develop
business plans for individual parks to demonstrate their contributions,
growth, and needs. These business plans were then used in various ways
to communicate how much money is needed to run a park and to attract
investors to support park activities.
In the first three years of the program, plans were created during the summer by interns recruited from some of the leading university M.B.A. and public policy programs. Roughly two interns were assigned to each of a dozen parks each summer. After a week of training and with continued assistance from the Office of the Comptroller, these interns worked onsite with each park’s superintendent, managers and division chiefs to create plans appropriate for each park. Under the intern-based system, NPS could only generate 12-13 business plans per year for approximately 380 park units. Since interns were available only during the summer, the plans were being developed when the parks were busiest, rather than in the off-season. A much more beneficial solution would be to enable park personnel to create these plans themselves in the off-season. But how could they be equipped with the skills? |
|
|
|
| Solution: | SI
International examined and analyzed the workflow the NPS used to build
plans and differentiated
(1) the process used to create a business plan from (2) the data that needed
to be collected and (3) the elements of the plan that needed to be
built. It then proceeded to design and build two software applications, one
for collecting data and a second for constructing the plan, and to embed
them within an EPSS that would guide and coach its users, the plan
developers, through their work. The EPSS would also provide plan
developers with all of the materials required to do the work.
An examination of the work process showed that it could be divided into five phases. Because each of the phases involved many tasks, they were grouped into activities. This three-level hierarchy ensures that plan developers are always presented with a small number of tasks within a clear context.
Most of the tasks in the first phase of the process, Getting Started, and many of the tasks in subsequent phases do not involve the use of either of the two software applications. These tasks are presented as steps within the EPSS in their proper sequence. Supporting materials as well as tips, examples, and pitfalls are presented whenever they were appropriate.
In the second phase of the process, Collecting Information, plan developers assemble the numerical data and other information on which the plan is based. Information collection is centered around the creation of a "detail sheet" -- a term carried over from the manual process -- for each function ("program" in park language) conducted at the park. The software application that SI International developed to manage this information, structure its collection and input, and perform the appropriate calculations on the assembled data to determine its meaning is called the Detail Sheet Manager.
In an early step in the process, plan developers determine who in the park can provide the information needed for each sheet. During the Collecting Information phase they make appointments with these people and either fill out the sheet online with them or fill out a paper form the system generates that is customized for each function. If they use paper forms, they input the information into the Detail Sheet Manager afterwards. Both of the applications within the EPSS (the Detail Sheet Manager and the Business Plan Editor, which will be explained below) were developed according to the principles of Performance-Centered Design. Within each application, everything the performer needs to do is laid out clearly in step-by-step fashion, and guidance and answers to anticipated questions are provided at point of need. Because the applications are integrated into the EPSS, the instructional information that appears within the application is task-appropriate. Plan builders may visit a single page within an application several times. Each time they do, they receive the appropriate guidance for the task they are performing.
After information is input into the Detail Sheet Manager, the application generates reports so that the information can be reviewed and signed off on by the appropriate park personnel. Lists of completed (and incomplete) activities are provided to help the plan developers finalize the data collection. Throughout the process, the Data Sheet Manager performs calculations on the assembled data and generates a set of charts and graphs that show its meaning. A summary financial statement resembling a profit and loss statement is also created. When the data collection is complete, the charts, graphs, and financial statement are ready for analysis and incorporation into the plan.
The individual creating the plan then proceeds to the Analyzing Information phase. This is the beginning of the writing of the actual business plan. It is done in the second application integrated into the EPSS, the Business Plan Editor.
Using the Business Plan Editor, the plan developer shifts from collecting data to interpreting it. Each chart and graph is a data map that illuminates an aspect of the park's operations, accomplishments, or needs. As the system has the plan developer focus on each one, it explains its meaning and coaches him or her through writing an appropriate description. Examples are presented for each item. They are supplemented with "extended guidance," which includes detailed instructions and recommendations, for complex areas.
Most of the writing of the actual plan is done in the Analyzing Information phase. The next phase, Determining Priorities and Strategies, guides the plan developer through conducting sessions with park personnel in which priorities are established and decisions are made. In the final phase, Producing Your Plan, this information is entered into the plan and the plan developer composes additional paragraphs to complete the text needed for the business plan. Finally, at the push of a button, the Business Plan Developer creates the actual business plan. The Business Plan Editor inserts the appropriate text next to its corresponding chart or graph in a Microsoft Word document designed to receive the information and display it with the proper formatting. The finished plan is then complete except for graphics, which are added to the final document at specific points where placeholders have been inserted.
|
|
|
|
| Classification: | How would you classify your
PCD Solution? Check one: Traditional EPSS - external or extrinsic "EPSS" solutions with designs rooted primarily in learning or reference Performance-centered workflow solution - any PCD solution with a focus on directly supporting business processes (aka workflow). (Innovative technology is also used.) PCD makeover - solutions that replace existing user interfaces with ones that exhibit attribute and behaviors of performance-centered systems Embedded/ intrinsic PCD solution - performer-centered solutions that are strictly embedded in the task context and focus on task completion - not learning - without breaking the task context or flow PCD featuring innovative technology - any performance-centered solution that features technology other than just a user interface to enable or enhance performance. Other category (describe): |
|
|
|
| Further details: (Optional) | |
| 1. Supports performers through best practice processes. | |
|
Business plans created through the Business Plan Developer adhere
strictly to NPS best practices in both their form and their content. They collect
appropriate data in all of the appropriate areas and address precisely
the issues that the NPS has determined to be pertinent.
Previously, although interns were provided with models and instructed on best practices, they often followed their individual instincts and deviated from addressing the issues identified by the NPS. The Business Plan Developer automates tasks where possible and appropriate. It also guides performers through all of the necessary tasks in their proper sequence, and it synthesizes stored data and presents it to performers in new contexts when they view charts and graphs to write their actual plans. |
|
|
2. Establishes, or aids in establishing, goals. |
|
| The Business Plan Developer is structured to enable inexperienced individuals to create uniform business plans. It provides a clear, proven, and authorized methodology to achieve this goal, and guides, coaches, and supports its users' efforts towards achieving this goal. | |
|
3. Minimizes terminology translation or interpretation. |
|
| Although some accounting language is used in the plans, technical
language is held to an minimum. When it is used, its meaning is always
explained to the performer, who is not expected to have an accounting
or financial analysis background. The two applications central to the system are both designed to be performance-centered and use no technical language. Factors that contribute to difficulty in use, such as cognitive load, are kept to a minimum. All instructions are conversational in tone and incorporate terminology commonly used in the National Park Service. |
|
|
4. Provides access to supporting and learning resources. |
|
|
Support resources (such as detailed instructions, checklists, sample
letters, etc.) are both presented in their context of need and available on a single Resources Page so that any
performer can get to any
resource quickly and easily. The two applications that are integrated into the EPSS are also available independently so that more experienced performers, or those in the middle of a process, can access them without going through specific steps. |
|
|
5. Focuses on task(s), processes, and the natural flow of work. |
|
|
The Business Plan Developer was built upon a detailed task analysis that
refined the process developed by the NPS and clarified best
practices.
It is task-centric. Performers don't need to know anything about the task model and sequencing in advance to successfully perform the work. They can simply follow the guidance, a step at a time. (The system does, however, present a conceptual overview of the process early in the Introduction phase, so that performers will have a mental model of what they're doing.) Data input, retrieval, and manipulation are always presented within the task context rather than as the primary focus of the system. As they follow the guidance, performers are taken to the appropriate screen within the two applications and given instructions on using the screen to perform a particular task. When the same screen is used to perform multiple tasks, the performer is given the set of instructions that pertain to the relevant task. When the process has been completed, the system generates its deliverable, a business plan, automatically -- literally at the touch of a button. |
|
|
6. Reduces or eliminates the need for training/learning. |
|
| The previous manual process, directed at interns, required five days of training. The NPS found that they could orient and train park personnel to use the new system in a single day. When they continued to use interns, however, they maintained the original five days of training. They did this not because five days of training continued to be necessary to learn the new procedures, but because training served the ancillary purpose of building teams, camaraderie, and relationships with the NPS staff. | |
|
7. Supports performance FIRST, and learning only as a secondary consequence of doing. |
|
| The entire system is performance-focused. The individual creating the business plan learns about business plans entirely by creating one. After going through the process of collecting data and being guided through explaining its meaning, however, the individual will attain a grasp of the financial and performance parameters of his or her park that could be an asset both to the individual and to the park. | |
|
8. Stretches the PCD/EPSS paradigm. |
|
|
The Business Plan Developer stretches the EPSS/PCD paradigm in three ways. First, it illustrates the value of developing separate performance-centered applications for different complex functions and embedding them within and integrating them into a comprehensive EPSS. Second, it pioneers new connections between the EPSS/PCD paradigm and large data repositories. And third, it shows how new levels of software usability and performance centeredness can be achieved by integrating the skills of instructional systems designers (ISDs) and information technologists (ITs). From the front end, the Business Plan Developer guides and coaches performers through a complete work process. The first of its five phases barely uses its two applications (one for assembling data and the other for creating the plan). Rather, it steps novices through necessary organizational activities, team building, and laying groundwork with park personnel. In subsequent phases, performers are introduced to the two applications within the context of researching and building a plan. Use of the applications is woven into the work flow, and performers are taken into and out of the applications as needed. From the back end, the two applications interact with large Oracle databases that store both park financial data and the components of the individual business plans. Business Plan Developer users, while working entirely through an easy-to-use front end with intrinsic assistance, actually populate and use larger and more sophisticated databases than most EPSSs attempt to work with. Beyond their standpoint, however, their use of the system makes an additional contribution. As data from many parks accumulates, opportunities for querying against it will be recognized and new possibilities for the analysis of data across parks will arise. The Business Plan Developer, therefore, will provide the data for future inter-park studies. From a development standpoint, the system illustrates the value of coordinating the efforts of ISDs, who laid out the process in the proper detail and wrote explanations that performers would find clear and helpful, with those of ITs, who developed the sophisticated data modeling the system was built upon and used the appropriate technology (Microsoft .NET) to interact with the Oracle databases. By themselves, the ISDs would have been able to clarify and guide users through the processes, and to provide them with supporting materials, but the automation they would have been able to provide would have been much more limited and less sophisticated. By themselves, the ITs would have been able to design two easy-to-use applications, but they would not have addressed supporting performers through the entire work process, and both the work process and the two applications would have required substantial training. In this project, the contributions of both sets of professionals were enhanced through teamwork and a common vision in ways that ultimately benefited performers. |
|
|
|
|
| Prior State: (Required for all In-Production entries) |
Prior to the Business Plan Developer, the creation of business plans was
a manual process involving standard forms, tools such as Excel and Word,
and the time and expertise of professional consultants. One software
application had previously been developed that served as the basis for
the Summary Financial Statement. This application was not used by
consultants, however. They were trained and assisted in working
with the data in Excel.
Plans that were manually constructed by consultants were often very attractive since professional graphic designers were brought into the process to polish them. They were not, however, uniform. Consequently, the government agencies that needed to evaluate one against another to make allocation determinations would often have a difficult time in locating particular information and making comparisons on particular points. Because of the uniformity resulting from the automated process, these comparisons are now much easier. |
|
|
|
| User Profile: (Required for all In-Production entries) |
Many
park employees have bachelor degrees in education, the biological sciences, history, or
recreation. Administrative and business knowledge and experience
vary.
The original skill set used to select interns to build plans included:
While all of these skills would still be desirable, the Business Plan Developer was designed to enable park personnel without training in quantitative analysis to create business plans. The factor in the original list that would be most important to individuals assigned to this task would be strong communication skills. While the gathering and analysis of quantitative information has been automated, the explanations of this information and the writing of other sections of the plan depend on the performer's skill with words. |
|
|
|
| Results: (Required for all In-Production entries) |
While the Business Plan Developer was designed to enable untrained and inexperienced park personnel to develop business plans for their parks in the off season, this has not yet occurred. Initial efforts in this direction proceeded as planned. The NPS was pleased to find that only one day of training and explanation was necessary rather than the five required for the manual process, and the tool garnered positive feedback. An unanticipated obstacle, however, presented itself. It turned out that building a plan required most of the time of the staff person who managed the project, and in each case this staffing requirement proved more than the parks could afford at their current staffing levels. The plans were not completed. Consequently, the NPS decided to suspend its effort to have park personnel build plans and continue with its original approach of using interns to create plans over the summer. The Business Plan Developer currently provides clarity, structure, resources, and automation to about twenty-five interns a year in a dozen parks (about the same number who participated in the original manual process). It is perceived to be a significant improvement over the manual processes by NPS personnel involved with the creation of business plans prior to its development. Currently, 100% of the plans initiated are completed each summer, while before the Business Plan Developer was used approximately 70% were completed on time. Most significantly, use of the Business Plan Developer has speeded up the data collection process and enabled the interns to focus more on developing financial strategies and priorities for their parks. San Juan National Historical Site reported last year, for example, that it saved $140,000 in a year by implementing the strategy developed in its plan. The NPS cites the improvement in the quality of park priority and strategy determination (phase four of the Business Plan Developer) as an important achievement resulting from the use of the tool. Most of the evaluation efforts by the NPS and its supporting organizations have focused not on the tool, but on the value of the plans themselves. The National Park Conservation Association, which funded the development of the Business Plan Developer, published findings stating that “Park managers are beginning to use the results of the business plans to explain the park status quo to Congress, park visitors, gateway communities, and potential donors. Internally, business plans are being used to reconfigure and refine the budget information that flows between Washington, D.C., and the parks themselves.” The Business Plan Developer plays a significant role in this process even though this role differs from the original conception. Plans are now quicker and easier to build, more uniform, and of a higher quality than ever before. Consolidating data in a common database and in a standard format has laid the groundwork for queries to be performed that were never possible before. And who knows? if economic circumstances improve and the value of the plans (and the database) becomes more broadly recognized, the Business Plan Developer may yet be used as it was originally intended. |
| Other Evidence: | |