The Program Office

Rev Date 14-July-2011

Table of Contents

Definitions

The organizational parts of this site have defined the team structures currently planned for the RAIN System development. Several terms from those pages are reviewed here for completeness:

Member- a business or consulting individual that has joined the project;
Customer- The U.S. Government, with possible philanthropic involvement;

	Activity	Description

1.	Launching Subproject	Causing each needed developmental activity to occur: 1) as performed by members, or 2) by direct contract if no member is performing the needed activity, or 3) by association and data-sharing with organizations performing related work (e.g., university research)
2.	Establishing the Management Culture	Defining and disciplining an overall "management culture" for the project. A separate table, below, defines some aspects of such a program culture. Each development project will have unique items in its management culture depending on the particular challenges of that project.
3.	Monitoring	Monitoring each developmental activity to ensure that project plans for each are current, that quality meets specifications and that elements of each plan are being met in terms of tasks, costs and schedule.
4.	Troubleshooting and Aid	Constantly and specifically looking for problems anywhere in the project that threaten quality, budget or scheduler performance. When potential for problems is spotted, the PO works diligently with the member or contractor to quantify the problem, find solutions and report back to the customer.
5.	Master Planning*	Maintaining an overall Master Project Plan: a juxtaposition of all of the project plans created and maintained by the satellite activities (performed by member businesses and individuals). Also, the PO will approve plans before work (and spending) are ever authorized on the project in a member organization or anywhere on the project.
6.	Data flow	Ensuring that data flows properly among the satellite activities as required by each. Included will be monitoring the quality of documentation and its timeliness to ensure that minimum standards are met and that needed data becomes available with suitable timing to support all activities that need such data.
7.	System Simulation*	Maintaining a special "System Simulation Workbench" that will 1) receive cost/performance models for each system component (as produced by members and contractors developing parts of the system); 2) integrate them into an overall system simulation and 3) operate the workbench to stimulate the system model appropriately and produce reports showing cost/performance indices. This data is needed to make system parametric decisions, define requirements and to project The RAIN System overall expected viability vis-a-vis present wildfire fighting technologies.
8.	Simulation Results Dissemination	Distributing system simulator results to the customer, team participants and to the promotional activities that support possible public display of the project and its results.
9.	PO Management	Conducting the day-by-day business activities of the PO, including accounting, attention to legal matters (e.g., patents), managing the corporate documents ledger and stock ledgers, etc.
10.	Project Promotion	Conducting all promotional activities needed to attract members and seek needed resources such as briefings to U.S. Congress staffers and principles.
11.	Contract Management	Managing all contracts between the PO and various vendors as required, including the issuing of Requests For Proposals, definitions and negotiations of Terms and Conditions, etc.
12.	Approvals: Deliverables and Payments	Contracts are typically written with milestones and intermediate deliverable items, and those management tools are often used as a basis for progress payments to vendors. The PO shall verify adequate quality and quantity of all such deliverables and approve associated progress payments, if applicable.
13.	Insurance	Maintaining appropriate insurance policies for FITERAD board members, Officers and Managers, including Product Liability insurance, as required, insurance covering corporate assets, etc.

*These activities require special "tools" that will be discussed in a separate section, below.

PO Duties

To meet the challenges of managing the RAIN System development project, the PO will assume the specific duties delineated in the table here.

	Activity	Description

1.	Planning	Planning is essential,.. plans are useless (Churchill)... Keeping plans current and vital for decisionmaking is critical, especially on a project with such diverse technologies and so many types of contributors (hardware, software, etc...)
2.	Creative Monitoring	Project plans must include items that will test progress and reveal performance is the project moves along, so that problems are detected early. This is especially true with software where the 90% syndrome* prevails without specific management technique to prevent it.
3.	Documentation	The documentation produced by each subproject enables other subprojects to interface properly into the system. Without timely, accurate and complete documentation at every level, the system cannot be built. Even though this is true of many systems, it is incredible how difficult it is for managers to get technical people to properly document their work. Managers have to make documentation a top priority and constantly stress its importance to get this done properly.
4.	Interface Control Documents (ICDs)	Although this point is a component of the previous item, ICDs especially must be kept current, accurate and disseminated throughout the organization to affect successful system integration and testing.
5.	Project Reviews	These reviews must be held at regular intervals throughout the project to facilitate early problem detection, troubleshooting, reporting to the customer (as contractually required) and for general management purposes. Performance is compared to plans, and solutions rendered when projects get in trouble. Plans are constantly updated resulting from such reviews.
6.	Openness	There must be open, candid and routine communications between those performing the work on the project and the management. Managers must employ proper psychology to ensure such openness is present at all times. This is especially important during challenging times when management depends on workers informing them of the true status of things "down in the ditch."
7.	Respect for System Engineering	The project will rely on results from a carefully developed system simulation. Managers must use data from such a simulation, respect it, and apply it for decisionmaking.
8.	Other	Other culture for the project will be imposed based on policies and procedures adopted by the management team.
9.

*The 90% syndrome is manifested when the software coder tells the manager (who, after all, cannot "see" software) that the project is 90% complete... month after month. The manger must ensure that special test software is planned and implemented, which can demonstrate clearly whether or not software packages are indeed working correctly or not.

Management Culture

The PO defines, documents, lectures and enforces a management culture on the project, as delineated in the table.

The map depicts candidate locations of 5 field offices. Each office will be staffed by one or more senior technical managers, with possible junior managers and administrative assistants.

The Central Office (CO) is shown centrally located in the U.S. for the most convenient hosting of meetings among the field office managers, CO managers and customer personnel.

PO Organization

The map figure depicts the concept of the PO organization. Two components are involved, the Field Offices (FOs) and the Central Office (CO), described next:

Field Offices

A set of field offices is formed, each in the locale of a "technology center" in the U.S. where RAIN member businesses reside. The strategic placement of these offices minimizes travel costs and inconvenience project-wide, encouraging vigorous interactions between PO personnel and the member businesses. This is seen as essential in implementing some of the key PO duties.

A separate table below specifies the duties of the field offices.

The Central Office (CO)

There is also a "Central Office" or CO which is part of the PO and will be the central coordinating facility for the PO. The CO is centrally located so that personnel from the field offices can come to the CO often for meetings and information exchange.

A separate table below specifies the duties of the Central Office.

Field Office (FO) Duties

	Activity	Description

1.	All Interfacing to Members	The FOs perform all efforts involving interfacing with the projects conducted by members on behalf of the PO. Following are detailed definitions of FO duties.
2.	Establishing the Management Culture	The separate table defining items of culture applies here too. The CO establishes these cultures through a series of written specifications that will be presented to the members and then enforced on a routine basis by the FOs.
3.	Monitoring	Monitoring will be almost exclusively the job of the FOs. On occasion the FO will host CO and possibly customer personnel at meetings in the member's shops to further communication throughout the project.
4.	Troubleshooting and Aid	The FO will perform much of this duty but will keep the CO advised and often seek help from the CO in troubleshooting and problem solving.
5.	Planning	Although the master plan is kept in the CO, the components of this plan produced by the member projects will be enforced by the FOs who will insure quality, comprehensiveness and timeliness of individual project plans that go into the master plan.
6.	Data flow	Critical project data will be kept at the CO where it will subject to configuration control. The data shall pass through FOs, and the FOs will discipline members to ensure the data meets quality standards and is timely.
7.	System Simulation	The System Simulation Workbench tool is kept at the CO and operated there. It receives individual component models from the members via the FOs, who insure the quality and timeliness of these models. Simulation results will also be disseminated to the members via the FOs, and special simulator "run" requests can be made by members through the FOs.
8.	Contract Management	The FOs will participate in contract management, as required.
9.	Approvals: Deliverables and Payments	FOs will recommend approval of deliverables and payments to the CO on behalf of the members they monitor.

Central Office (CO) Duties

	Activity	Description

1.	Launching Subprojects	This PO duty is the sole responsibility of the CO, but FOs may provide aid in finding suitable members for needed subprojects, interviewing them and rating them for the subject task(s).
2.	Establishing the Management Culture	The CO will define the culture outlined in the separate table, above, with collaboration from the FOs. The FOs will discipline the culture onto the Members.
3.	Monitoring	Direct interface with the Members will be performed by the FOs, and the results of project reviews etc. transmitted to the CO for juxtaposition to generate overall program status. However, CO personnel will "spot" attend project reviews etc. as an overall management coordinating function.
4.	Troubleshooting and Aid	When problems arise the CO and associated FO(s) work together to find solutions, possibly in conjunction with customer participation. The customer will always be kept informed of such issues by the CO as part of its normal reporting processes.
5.	Master Planning*	Keeping of the master plan is the sole responsibility of the CO, with contributing inputs from the FOs. The CO will approve plans before work (and spending) are ever authorized on the project in a member organization or anywhere on the project, and will have the final approval authority before (progress) payment requests are sent to the customer.
6.	Data flow	The CO will maintain the repository of "control documents" for the overall project under strict configuration control. All participants will have access to these documents and can "check them out" to modify them, if they have the proper (preassigned) permissions to make changes. The CO will monitor documentation quality and quantity and interface with the FOs to ensure the documents meet all requirements of the project.
7.	System Simulation*	The "System Simulation Workbench" will be maintained in CO facilities by CO personnel, and will provide a service of system-wide analysis in support of requests from the customer and members through their FOs.
8.	Simulation Results Dissemination	CO responsibility.
9.	PO Management	CO responsibility.
10.	Project Promotion	CO responsibility.
11.	Contract Management	CO responsibility.
12.	Approvals: Deliverables and Payments	FOs will apply the first level of approvals; the CO will make final approvals and recommendations to the customer(s).
13.	Insurance	CO Responsibility.

Timing Challenges

Before continuing the discussion about the recommended structure of the PO we address timing. In particular, it is essential that the PO facilities needed to perform all of the duties in the table are set up and fully operational before any other project activities (in members' shops) begin. If this were not so then there would be project activities underway without approved plans, proper technical direction and reporting, monitoring, etc. That just cannot be allowed to happen.

Throughout this site it has been indicated that many components of the RAIN system can be built from existing Intellectual Property (IP) in members' organizations and that that IP can form a basis for a sole-source government procurement of that IP with suitable interfacing /modifications as may be required.

But since the PO must be established before work begins anywhere, then the PO funding must:

be sole source too, OR,
come from members under contract (probably as an overhead expense of their contract funds), OR,
member contracts must be held up until the government finishes any competition it runs to constitute the PO. -->

Competitions are expensive, time consuming and they often lead to unsuitable contractors (that are very good at winning government contracts but not good at performing on them!)

A competition can add 18-24 months to the schedule of an activity, or more. A competitive procurement of any element of the PO can therefore be seen as disastrous!

There are a couple of ways of looking at sole-source procurements. The conventional one the government usually uses is:

1) Does the project qualify for a sole-source procurement [under the rules of the Federal Acquisition Regulations or FARs]?

But the other way to look at this is:

2) What has to be done so that the activity DOES IN FACT qualify for a sole-source procurement under the FARs?

It is the tack suggested by this second question that will be the subjects of subsequent sections, below.

The PO: Make or Buy

Considerable thought has been given to the question of whether to use a member business as the PO or to build it from scratch. The critical consideration for the PO is the quality of the managers, particularly those in the field offices: They must be the best that can be found. More on this in the section on manager qualifications.

If an existing business is selected to be the PO, then we place a layer of management (or several) between a key field-office manager and the Central Office management. Such a layer of management will make decisions (such as which personnel are selected from within their company for our project) based on what is best for their company, not necessarily what is best for the RAIN project.

And such an existing company will still have to recruit and hire people for these positions, or steal (a possibly inferior) someone from an existing project. There is no particular advantage seen in using an existing businesses' Human Resources (HR) department vs using a headhunter or other vehicle to find qualified people.

Thus, after such due consideration there seems to be no advantage in "buying" the PO and many disadvantages. It is essential that the project have direct access to its manager team at all times without having to go through another company's layers of decision-making.

Staffing: Where Do We Get Good Managers?

This hugely important question requires much pondering. We need direct access to these managers and much authority over their priorities and schedules. However, we have limited control on when we will have funding for these personnel, and when funding arrives there is usually enormous pressure to get underway quickly: pressure that encourages rushing the recruiting process and possibly hiring less than the best personnel for these critical functions.

The best compromise that has been found is to use management consultants for senior management: small businesses, perhaps with just one or two principals (with supporting staff including some junior managers) that this project will have direct access to. Such consultants, not being employees, can busy themselves on other projects (and stay alive) between the time that we find them and the time we can pay them for their services.

As such, these small consulting firms become member businesses just like the other team members, but with management duties within the PO. Their locations must be mapped to the locales of the other member businesses as much as practicable.

Office Organizations

As stated previously, multiple Field Offices (FOs) are distributed near technology centers in the U.S. where member projects are conducted. There is One Central Office (CO). The organizations of these offices will be discussed here.

The Field Offices (FOs)

These will be structured as provided by the consulting firms that host them and located strategically is where we find and select them. We seek small offices with small support staffs, so that the RAIN Project will be large enough to be very significant to them and therefore command their most serious attention.

The Central Office (CO)

The CO will be staffed by a small group of people that integrates the work from the field managers, provides overall System Engineering and Technical Direction steering and reports to the customer(s). -->

The CO will be the keeper and operator of the two main management tools: the master plan software and the System Simulation Workbench which are defined, below. The CO will host personnel to operate these tools and provide services to operate the tools by all project team members.

The CO will be operated under the auspices of the FITERAD Corporation, which is the holder of the RAIN System Patent (application) and the Intellectual Property (IP) licensing agreements from all project members who own IP applicable to the project.

Office Funding

The funding for the offices is discussed in a separate section.

	Activity	Description

1.	Education and Experience	Education and experience in the project management of technology development projects is the most important attribute of the PO field manager. This manager should have been top project manager on at least one significant high-technology development project such as an aircraft, weapon system, etc. Experience in the culture of government contracting will also be very important.
2	People Skills	Project managers will interface intimately with their counterparts in member businesses performing significant hardware and/or software developments on the project. They will need to earn the respect of their counterparts so that candid communications can occur (particularly when there are problems) and so the PO personnel can offer aid in problem-solving before too much money or time are spent on problems, placing the project in trouble. This manager will need to have experience in measuring people's performance and judging individuals' qualification to perform on specific project tasks.
3.	Accessibility	These managers must place high priority on the RAIN project needs and not march significantly to "other drummers" (meaning under the orders of other people with little interest in the RAIN project). This suggests that these managers must be in small, one- or two-people firms, and not working for, say, a larger systems engineering company with many projects that can demand attention from key managers on the RAIN project.
4.	Availability	The managers must be available when they are needed, but they must be able to wait for money after they are found because of the inherent delays in this project between setting up our team and getting the funding needed to proceed.
5.	Proximity	It is preferable that the managers are physically located not too far from the businesses that they will interface with, to encourage the maximum interaction/communication possible.
6.	Hardware /Software	Hardware and Software development projects require different management styles, skills and experience. Whenever possible the background of a field-office manager should apply specifically to one or the other, or both. A manager experienced in hardware development only, will generally have difficulty planning and monitoring a significant software development activity, and vice versa.
7.	Culture	It is essential that every manager in the RAIN System development program team be compatible with the project "culture" as defined in more detail in a separate table herein.

Senior Project Manager Qualifications

The table lists qualifications sought from senior project managers. These qualifications are driven by the PO duties, and timing and manager quality considerations.

Special Tools

Special tools needed by the Central Office (CO) were mentioned above. Those are addressed here.

Master Project Planning Tool

A software tool is needed to receive detailed project plans from all program activities and integrate them into the master project plan. There are some programs available that purport to perform this function (e.g., Microsoft "Project") but they have not been found satisfactory by the author in the past, particularly for a large project.

These are the attributes needed from the master project planning tool:

Subproject plans should use a standard spreadsheet and require no special software licenses or operator training for their use. The CO will issue specifications of the preparation of these plans using standard spreadsheet technology.
A standard file format should be used to represent each subproject plan, such as the comma-separated-variable (csv) format.
The individual subproject plans must be imported into the master planning too, and combined by "leveling" to produce the master schedule.

[Resource Leveling is the process where the components of a project plan are operated on by a special algorithm to calculate the time schedule. The time schedule is a mathematical result of other parts of the plan, and it insures that resources scheduled for the project are not overextended to forecast unrealistic schedules. Automatic leveling capability in this tool is essential. It should be noted that leveling can be done in different ways. For example, with task durations fixed or resources fixed. The automatic leveling facility should have these and other options available to the user.] -->>

The master tool must produce suitable reports representing the whole project.
The master tool must be accessible by all of the separate managers, and management within the member businesses, so changes in a plan can be made and schedules recalculated in iterative fashion to solve problems. This suggests that the master tool be web-based and hosted by a web server.

More detail regarding this tool are presented here.

System Simulator Workbench

As described elsewhere on this site, the RAIN System involves many parametric trades. To address these will require system simulation, which can model each components and combine the models to reveal

performance and cost vs the selected values of the main system parameters.

Each project developing components of the RAIN system must produce a mathematical model of their component that meets the written specifications for models associated with SS Workbench.

The workbench will combine the models, stimulate the overall system model and generate reports on performance.

-->

An excellent workbench will contain optimization facilities where the simulation can be run with "parametric sweeps" to look for optimum configurations.

It is important that the SS Workbench be operational very early in the RAIN System development project so its results can have positive impact on system design. Unfortunately, it so often occurs that a system is designed and operational before the system simulation (which is supposed to help define the requirements on the system) is even available. Because of its importance, the SS Workbench needs to be found and made operational as soon as possible.

More on the System Simulation can be found here.

Models
The System Simulator will only be as good as its models. The following lists specialized tools essential to building models and performing various decision-making trade studies, all needed for management purposes in the CO:

Link	Use
Functional Simulator (FS)	Combines models from tools, below, to simulate the entire system functionally.
Aircraft Modeler	Creates dynamic models for aircraft for the FS
Wildfire Simulator	Simulates fire behavior for the FS
Fight Plan Proposer	Supports mission planning for the FS for fighting a fire based on experienced with manned fights.

General Requirements on Software Tools

The software tools outlined above are crucial to the PO function. The following general requirements are sought for these tools. Not all of these requirements will be met and there will regularly be a trade between the cost and time-duration required to acquire the tools and these requirements. Reasons for some the the requirements that might not be obvious to everybody are presented after the requirements list.

Summary

Software tools should:

be "open source" whenever possible- very important so that they can be changed/customized for particular PO needs;
be able to import and export data in a standard file format (e.g. "comma separated variable" or .CSV format) and not be restricted to manual data entry only;
be supported by a company who will enter into contracts to support and modify the software as needed by our project;
be hostable by a Linux Operating System (OS) since the Linux versions are mostly open source;
also be able to run under a Windows OS although this requirement can be waived if it is hosted by a web server and can be run over the net from a standard browser [see restrictions];
be, of course, suitably functional to satisfy the specific management needs for the tool. "Bells and whistles" of functionality ("nice" things not strictly necessary) must often be traded against other important requirements listed above.

The Argument for "Open Source" Software

Several software tools are critically important to the PO's work as discussed previously. Software is generally in two forms: 1) proprietary and 2) open source. See http://en.wikipedia.org/wiki/Open-source_software for a discussion.

Proprietary software requires the purchase of a license, usually for every "seat" (computer) using it. Also, the source code for such software is not made available under license, and the functionality of such software is therefore essentially "rigid" from the user perspective. One must adjust his or her methods, culture, operational procedures, etc. to "fit" the requirements of essential tools being used. That is not good for management purposes.

Open source software is licensed too but the cost is usually zero for it and the main constraint on its use is that it not be sold for profit, but rather continued to be distributed at no cost. Additionally, as its name implies, one receives the source code with the package and can therefore modify the software at will to meet specialized needs. That is important for management.

Open-source software packages are often managed by organizations who operate with funds from various sources (see http://en.wikipedia.org/wiki/Open-source_software#Funding) and can be hired for very reasonable amounts to make customizations to the software from time to time as may be needed by its users. When this can occur, the software can be forced to perform as needed by a project, and not the other way around where a project has to be managed to conform to the previous visions of its software tool creators.

Open source software has been dogged for many years by a lack of sufficient funding, as can be imagined. However, in spite of those obstacles, the open source community has made enormous strides in getting software tools available for many many applications, and with high quality and stability. In the opinion of the author, after considerable experience with these tools, the products of the open-source community have now evolved to the point of being totally effective and capable to support the operations of this PO.

The present management will continue to strive to use open source tools whenever practicable, and default to proprietary tools only when there are no viable open-source options available.

Restrictions on Web Hosting

This approach called by several names (e.g. "cloud computing") involves placing the software on a website to run under its server, offering its services to those who access it, usually over the internet. There are many advantages and disadvantages discussed in the wiki entitled "software as a service." If such resources become available for this project, their use will have to be weighed on a case basis by management.

However, an absolute restriction on using such a service for a critical function relates to a key objective here for open source software. The source for such functionality must obviously be available for any critical function. Otherwise its owners can simply make it disappear at any time.

The source should be possessed, or it could be held in an escrow to protect the project from losing a critical tool. Otherwise the use of such software out of the PO's control must be avoided.

Funding

How the offices are funded is the subject of this section.

It has been proposed on the website that PO funding come from the Member businesses, who in turn contract directly with the U.S. Government. This support for the PO might be included as service fees embedded in the member contract overhead structures.

The difficulty with this approach is in timing discussed previously. It is essential that the PO be fully functional (to a level of staffing appropriate for the management task at any time) BEFORE work begins in a member project. Project plans have to be developed and approved, and special tools (discussed above) in the CO need to be fully operational before management begins. But if the PO funding comes from fees paid by members from their contracts, then members must already be billing the customer before the PO receives any funding. A "Catch 22."

This consideration leads to the conclusion that at least part of the PO funding must come from its own contract, and that contract must be let months in advance of any member contracts. A hybrid would work where funding comes from both sources, but there must be some upfront funding directly from the customer to get the PO up and running. -->

It was also mentioned before, that such PO funding would have to be on a sole-source basis if any member activity is sole-source (as many are likely to be) if management is to be in place as required in time.

CO Sole-Source Justification

The key to justifying sole-source contracting with the U.S. Government is to do enough R&D to develop unique product that the Government needs. Whether or not a product is "unique enough" is a matter of subjective judgment. It will depend on the culture of the contracting agency, the personal opinion of a particular contracting officer and other factors.

At this time the author believes the CO can justify sole-source for its role in this project because:

it holds the patent (application) for the RAIN System;
it will hold multiple exclusive IP license agreements for key components of the RAIN System;
it will have exclusive license for the unique project management software that combines and levels subproject plans effectively;
it will hold an exclusive license for the System Simulation Workbench tool;
it will have the original steering mangers of the project in its employ or under contract. -->

Additional effort is ongoing to see if these justifications are adequate, or if additional resources will be needed.

Contracting Arrangements

The general plan for the RAIN project is that individual members will develop Intellectual Property (IP) under direct contract with the U.S. Government and license their own IP to the project. Newly-developed IP under government contract is normally in the public domain unless it is a modification of existing IP.

The PO's field offices can also be contracted directly by the government for their services.

However, the government may wish other arrangements, such to have the CO contract with the field offices, and possibly also with other member components of the project. Many arrangements are possible involving various administrative, accounting and insurance configurations. A final decision on this matter will have to await definitive discussions with the customer (government).