|
||||||||||
|
Technical Committees maintain the data base of knowledge regarding their particular discipline. They create tutorials and train new members of the committee on how to do analysis in their discipline. They establish standards and guidelines for design, development, test, and evaluation of all systems in their area.
The products of a technical committee are a data base of knowledge in that particular field, documented standards, and a team of confident individuals who are qualified to participate in the Product Teams. This is an on-going effort, and will be for as long the Artemis Project continues.
For example, the Simulation Technical committee might select Ada as the computer language to be used for all simulations. They assure that everyone working on the simulations has a working knowledge of Ada or access to adequate training. They establish an overall architecture for the simulations and define guidelines for what level of simulations models are required for each application. They decide on standards such as: all our simulations will be digitial; for the spacecraft we will develop 3 levels of system models; real-time simulation is applicable to these things and non-real-time simulation is applicable to those things. The Sim Tech Comm also might have influence of the standards of quality for related commercial products -- if they say all our computer games will have an accurate starfield in the background and demonstrate this is a cost-effective approach, then by gum we'll have an accurate starfield.
Note that one of the great benefits of the Artemis Project is education. Everyone participating in the project has a chance to learn something new and exciting, and to apply those skills to a very important program. These skills are applicable well beyond the development of the lunar base, so both the individuals and everybody else on the planet will benefit from the increased skill base.
Project Teams (or Product Teams) produce the products specifically related to the Artemis Project's primary goal of establishing a permanent, self-supporting manned lunar base. They have a more hiearchical structure than the Technical Committees because they have to produce an integrated spacecraft.
The products of the project teams are designs for the spacecraft and their missions, and eventually the actual hardware. Initially, our goal is to develop conceptual designs with sufficient detail to identify and solve all the technical problems, identify costs, determine who suppliers for off-the-shelf equipment are, develop a preliminary manufacturing plan, develop a preliminary logistics plan (for getting the spaceship parts to the launch site), develop mission plans for each flight, and develop ground support plans with estimates of the required mission support facilities on Earth.
You can see these two organizational functions matrix into each other. The Technical Committees provide the expert staff for the Project Teams, and the Project Teams provide feedback to the Technical Committees. This assures a consistent, compatible design across all the spaceraft we build, and assures that lessons learned from one spacecraft are incorporated into the design of the other spacecraft.
A poignant example of what we avoid with this approach is the lithium hydroxide cannisters in the Apollo command module and lunar module. (I'm assuming you've seen the Apollo 13 movie, or read Andrew Chaikin's book.) Individually the engineers at North American and Grumman did an outstanding job on those spacecraft, but together they would have been even better.
The organizational matrix looks like the chart below. For simplicity in this memo, we've lumped everything except the reference mission into "Other Spacecraft" and then happily ignored it. However, we expect to take a look at a lot of other spacecraft before we're all done; one that comes to mind is the concept of landing a series of very lightweight spacecraft with just a camera, a nav beacon, and a transmitter. These advance explorers might weigh no more than 20 pounds each when they reach the surface, but they'll provide a wealth of information about candidate landing sites, teach us a lot about getting a spacecraft to the moon, and be lots of fun in the process.
Technical Space Flight Project Teams
Committees
Spacecraft Design Team
|
|-----------------------------|
Other Reference Mission
Spacecraft Design Team
|
---------------------------------
| | | | |
Mission LTV Hab Descent Ascent
Design Stage Vehicle
GN&C X X X X
Electrical Power X X X X X
Life Support X X X X
Thermal X X X X X
Pressure Vessels X X X
Structures & Mechanisms X X X X X
EVA Systems X X X X
Propulsion X X X X
Mission Equipment X X X X
Software X X X X X
Simulation X X X X X
Test & Verification X X X X
Manufacturing X X X X
Logistics X X X X
An 'X' indicates where members of the technical committees will be needed to participate in each project team. (Don't pick on this example too hard; the whole subject of costs and other business issues aren't represented here.) We'll need a chairman for each technical committee and a team lead for each project team.
To move the Artemis Project to the next step, we need to get each Technical Committee and Project Team functioning. Communication and planning are vital to the success of any project, but with a team literally spread out all over the globe, that's especially true for us.
Everybody needs to know what he's supposed to be doing, what everyone else is doing, and how to get it all done. Here's how we develop and share that information:
Write a Work Breakdown Structure (WBS) for the part of the project encompassing the scope of these committees. The outline of the Artemis Data Book is a good starting point for a WBS; it breaks the whole project down to the level where technical committees and project teams start.
Write a WBS dictionary. This is a short paragraph or two for each header in the WBS that defines what this work really is. It defines the products produced by the work done under a given item.
For example: Somewhere in the tree will be a WBS entry to develop propulsion systems for the sundry vehicles. The Propulsion Systems Technical Committee would participate in the project team for each spacecraft which needs rockets; specifically the Lunar Transfer Vehicle, the Descent Stage, and the Ascent Vehicle. So we'd have an entry like . . .
x.x.x.x Develop Lunar Transfer Vehicle Propulsion Systems
Develop a conceptual design for the main propulsion system and maneuvering thrusters for the Lunar Transfer Vehicle. Determine system requirements based on mission inputs from the Mission Design Project Team. Survey available off-the-shelf hardware and compare to system requirements. Select propulsion systems for the LTV and publish weight, cost, volumetric, and CAD data.
Write charters for each technical committee and project team. The charter tells what products each team will produce in sufficient detail so that everyone else can see who is producing the products they need. It lists who the suppliers are for that team (that is, who is generating information the team needs), and who their customers are (who needs the products this team is producing).
So list the things you'll need to know to make some progress on doing the tasks listed in the WBS dictionary, and as the WBS dictionary develops, see if you can figure out which other teams are producing what you need.
The first thing you'll need is a list of who is on your team and contact information for everybody. Don't forget to parcel up the work among the team, schedule IRC conferences if need be, think up ways for your team to communicate. You might write memos in the form of Coordination Sheets to keep everybody informed. We can set up a place for you to store your information on ASI domain so everybody has convenient access to it.
Develop a schedule for producing these projects. Publish the schedule, but don't worship it as if it were handed to use by Divine Providence. The reason for the schedule is to give people an idea of when they can expect the inputs they'll need so they can plan their work, and to show others what inputs you need so you can plan your work.
If your team falls behind schedule for any reason, just tell everyone else about it. We're a volunteer workforce, so we have an extra need to accommodate individuals' lives while we're doing this. If it's something that other folks can work on to fill in the gap, we'll stay on schedule. (There's really no reason why an Ada programmer can't look up stuff in a manufacturing planning handbook.) If not, we'll adjust the schedule as appropriate. This is supposed to be fun; never mind any lofty goal.
To kick-start the scheduling process, here are the top-level milestones in the briefing charts I've been using:
Feasibility Study Complete 30 Jun 1995
Conceptual Design Complete 31 Dec 1996
Preliminary Design Complete 31 Dec 1998
Spacecraft Development Complete 31 Dec 2002
First Launch 1 Jan 2003
LTV Space Trials Complete 31 Mar 2003
Second Launch 1 Apr 2003
Integration and Checkout Complete 31 May 2003
Translunar Injection 1 Jun 2003
So for the first shot at a task plan, see if it's reasonable to lay out a detailed task plan that gets a first look at costs and schedules by the end of June next year, and a pretty solid design concept done by the end of the year. It might turn out then when you start making lists of all the information you need and when you need it, your schedule won't synch with other teams' schedules. That's no big deal; we'll just work out the details.
As this goes along, if you find you're falling behind or working ahead, that list of products will tell you who you need to tell about it. If you start to feel undue pressure to get something done so that the project becomes stressful, that's a clue that you need to relax your schedule a bit. Take time to play with the kids; maybe they'll become inspired to carry on this work for generations to come!
|
|
|