Standardizing File Names/Locations

• For links to be effective, we have to be able to count on files keeping the same name and being in a particular folder.

• This does not have to be in the same folder for everything, but each file should reside in a particular place that does not change on a shared drive. Whenever a file moves or changes names, all links to that file must be modified.

• If many of us are generating are own web pages with links to common files, we need assurance that these links will maintain there validity. It is not enough to inform people when changes occur. Pages simply should not be moved or renamed once it is decided where they will reside. The overhead of keeping links current should be the chief concern in making such changes.

• Individuals and teams should be free to link to any files that are useful in the performance of their tasks. However, the html files that are generated should also be treated as important parts of the organizations information and should be made available to others that might benefit from using them. We don't want to restrict the freedom of individuals to organize information in any way that serves them; rather we want people to be aware that if they are going to spend the time to do this organization, where possible they should consider doing it in a manner that is useful to others as well.

Configuration Management Considerations and Suggestions

• Each resource(file) generated should be submitted along with a brief description to a centralized data management function to make sure it receives a unique name and is put in a folder that is appropriate.

• Each resource(file) should have an IPT assigned to it as the owner. Any changes to the resource(file) should be processed through that owner. The owner should be responsible for ensuring that the resource(file) is the latest version.

• There should be at least two levels of configuration management. The first should be at the individual IPT (or working team) level. The second should be at the Systems Engineering IPT (or organization) level.
  

• Common reference documents that apply to multiple teams should be managed at the organization level by a data management team. Data management should be responsible for ensuring that the document is always the latest available from the originator, and that previous versions of the document are archived and readily available if needed.
  

• When new / revised documents arrive, an announcement should be sent to each IPT, not to every individual so that each IPT can determine the relevance of the document to that IPT and inform the particular members that need to review, or otherwise be aware of the information in the document.
  
  
• Shotgunning documents to multiple people wastes a lot of time if the individuals that receive the documents don't have a need to know the information. Empower the IPTs to decide how best to employ their resources and distribute information.
  
  
• Often a sequential review is better than a parallel one, since individuals can add to the comments of others.
  
  
• The person (or IPT for that matter) that generates a document, is not necessarily the best candidate for ownership of the document. In general, it should be a systems engineering call as to which IPT should be assigned ownership responsibility.
  
  
• With few exceptions, ownership of shared documents should not be assigned to specific individuals ... except perhaps by the IPTs themselves. Even then, there should be a primary and secondary owner to eliminate reliance on any one individual.
  
  
• Common files should be kept in read-only directories. The owners of the files should be the only ones authorized to change them. Even then, depending on the file, there may need to be some involvement from configuration management to approve changes.

Replicating Working Directories on Shared Drives

• Presently, we have at least three shared drives where information should be replicated.
  
• The N: drive for the Air Force [this is the G: drive for Aerospace]
• The S: drive at Aerospace
• The S: drive at NIC

This ensures that all organizations supporting CWI have access to common information. Further, all Air Force and Aerospace personnel supporting CW have access to either the N:/G: drive and/or the Aerospace S: drive.

• We need to implement data management procedures that ensure that this common environment is kept current at all three locations.

Establishing Standard Interfaces at the Working Level

• Working level interfaces should be treated in the same manner that we treat the interfaces of the AF SCN. Interface control documents should define the agreements that various individuals develop between one another and that various teams develop between one another. The standard plug should be agreed to file names and formats where particular products, information, or requests for services can be found/deposited. This may also include agreements as to performance expectations for various services.
  
  
• These interfaces may be very simple to very complex depending on how the various individuals or teams need to function to get their jobs done effectively.
  
  
• In general, simple interfaces are preferred. We want to be careful not to overly constrain the freedom of individuals and teams to organize and express information in more effective ways.