1.0 Title:
2.0 Purpose: This CDID is a prototype for a similarly named CDID under irap08c.
3.0 Usage
4.0 Frequency
5.0 References
5.2 US DoD Configuration management standards;
MIL-HDBK-61A(SE) Configuration Management Handbook DTD 7 Feb 2001
MIL-STD-973 (obsolete)
5.3 Software Configuration Management standards;
6.0 Responsibility
The roles and responsibilities of the users of a pm601/hri07e project site are governed by the roles and responsibilities of the HRI membership roles - and include:
- Project Owner
- Project Manager
- resource people (domain specialists, engineers, programmers, architects, etc.)
- agents
- arbitrators (and lawyers - if it gets that bad)
- investors, finance & accounting
- QA & KM resource people
All of these persons must have access to the project on a need to know basis.
7.0 Ownership
8.0 Effort
9.0 Risks
10.0 Contents - for Google Sites only - the top level pages will be:
Home Page:
This page should provide a narrative summary of the project objectives and a bit about the solution, but should not get into extended details on a technical or business level as it is directed at the person who is not familiar with the project and only wants to know "what it is"
There may be cases where this page has a marketing focus - but since this is a restricted access project development site, not a commercial, search engine crawl-able site - the puffery can be located as a set of deliverables linked via the marketing section.
note: all deliverable project artifacts should be locatable via the Contract Deliverable Requirements List (CDRL) - including hardware items, which should have accompanying soft artifacts such as Data Sheets, Specifications, drawings and Bills of Materials
Dashboard:
This section should be the KanBan section for the project and be used to quickly determine the status of the project by any team member - and especially any "hurry up" or "slow down" information that a team member needs to be aware of.
For "Agile" software projects the Dashboard typically be only a "TaskBoard" - but perhaps also a "burndown" chart.
For "waterfall" projects (most engineering projects) the Dashboard will typically be a "Tracking Gannt Chart" + perhaps an extended cash flow forecast + perhaps a Resource Allocation chart. Often these can be generated by Microsoft Project - although not by the faint-of-heart.
For engineering projects the Dashboard may (should?) include an ISEL tree (see 10.8 km05) that indicates the "dependability" of the various components and pushes alerts to the responsible signing authorities for elements that may need to change.
A similar display should identify changes in the over-burn or under-burn of hours for the aggregate or individual work orders. Thus if a resource has stopped showing up for work (for example) the person responsible for receiving the deliverables should be alerted that work isn't happening that should be. Converesly - work orders that get opened and used prematurely should also be flagged.
The Project Team
Use this area to identify and link to various project team members - existing and required. This is the "Human Resources" area of the project site and identifies both the required skill sets and the incumbents who have been contracted to fill those positions.
There are several key elements to this section which are implied by any project, but are often not visible (and the should be).
Job Descriptions:
It doesn't take a very complicated project to require a set of skills that the people who are creating the project don't have. It may be as common as bookkeeping skills or as complex as a Statistician for design of an experiment. Sometimes the same person may have both of those skills - but one shouldn't be paying that person the same rate to do both jobs.
Incumbents:
The current holder of the position (and their backup as well perhaps?) should be identified and linked. The primary elements are:
- gmail username
- link to CV/resume
Project Communications
The standard communications channels are as suggested - and vary with the content and urgency of the message being sent. It is assumed that each item member has at least one username in each - and perhaps more than one if more than one role is being filled on the project.
- general email: gmail - with the wo# as the first item in the subject line.
- skype: 2-way voice, voice conference, and 2-way video calls
- google groups
- twitter - (not used)
-
- LinkedIn (not used)
- Facebook (not used)
Project Data
This is the primary purpose of the site and consists of local data or access links to:
- the list of project files (CDRL) <typically in Google Docs>
- Design Data (Specifications, CAD files, data sheets, bills of materials, calculations)
- Integrated Logistics Systems (ILS) data (maintenance manuals, spares requirements, training manuals, ...)
- Procurement Data (purchase orders, contracts,...)
-
Quality Assurance
This includes both the standards being used and the results of any testing and inspection.
- Standards (External standards, hri07e or project CDID's, hri07e or project SIG's)
-
-- Configuration Management
Configuration Management will be a sub-section under QA in pm601 sites in an attempt to try to "keep things simple". It is a discipline all on its own, but its experts will have to swallow their pride and pretend to be part of QA for purposes of this CDID.
Software Configuration Management vs Engineering Configuration Management
The pm601’s primary role will appear to be as a portal for web access by any stakeholder in a given project to access the project data and status – but it’s primary impact will be one of Configuration Management (CM). It will model its CM processes after those of the software engineering disciplines rather than the elaborate and nearly impenetrable methods used by the US DoD, or the very costly, proprietary methods used by “full featured” CAD vendors such as AutoDesk (Vault), PTC, Dassault and Siemens.
While it is true that software structure and content is very different from an engineered object like an automobile; it is also true that every bit of metal and plastic in an automobile or the machinery that built it has a corresponding collection of data that describes the metal object – and that without that collection of data being carefully controlled, the metal/plastic object would not work. Therefore the emphasis is on making sure that the physical bits and pieces do not substantially differ from the data collection that describes them – i.e. – if you properly control the data for the object – the object should follow; provided people don’t cheat.
11.0 MetaData
12.0 File Handling Policy