Click here to view a larger image.

EIDX Main Development Process

Narrative

• New process reviewed and approved for trial usage
• Allows for fast-track development projects
• Allows EIDX to process minor changes rapidly
• Allows for adopting deliverables for trial use/piloting without going through full balloting process
• Many of these steps may be accomplished informally through quick review and consensus.
• The process is meant to be flexible, and consistent with the fact that EIDX produces recommendations and guidelines, not standards, and that most resources are volunteer resources.

1.  Proposer submits project proposal to core team.  Core team is made of representatives from all subcommittees. 

1.1.  The proposal may be formal or informal.  Informal means include e-mail exchanges, telephone conferences, and discussion with mutual agreement during a conference or meeting.

2.  Core team reviews proposal (in person, via e-mail exchange, or whatever).   Composition of core team:  BPS, GSS, and TECH chairs, vice-chairs, board liaisons.  In addition, key task group leaders may be asked to participate in the review.

2.1.  If the entire core team is not present for a meeting or phone conference, the members who are present may review the proposal and make a decision.  Ultimately, the entire core team will have a chance to evaluate the need for the project by way of conference agenda reviews and/or subcommittee status reports. 

2.2.  In general, a project is automatically justified if it fits within the EIDX Business Process Framework and/or the Technical Architecture Recommendations, and there is a willing volunteer to lead the project.

2.2.1  If a member volunteers to lead a task group and his/her company agrees to their participation, it means the company sees value in the project, and this is sufficient justification for moving ahead with the project.

2.3.  If the core team rejects the proposal, it is sent back to the proposer for revision.

          2.4.  If the proposer revises the proposal, he/she resubmits to core team.  Return to Step 2 above.

2.5.  If the proposer takes no action, the project dies.

3.  If the core team approves the proposal, it is submitted to all three subcommittees. 

4.  Each subcommittee team evaluates and makes one of three decisions (refer to individual BPS, TECH and GSS subcommittee flows):

4.1.  There are no changes to the subcommittee's deliverables.  The subcommittee reports back to the core team that no action is required (return to main process).

4.2.  No project is required (for that subcommittee).  The changes to the subcommittee's deliverables are minor and/or non-controversial.  The team authorizes the proposer to just go ahead and make the change and submit draft documentation.  If subcommittee approves draft documentation, return to main process.

4.3.  A project is needed.  The project follows the subcommittee-specific process.  If subcommittee approves draft documentation, return to main process.

5.  The net result may be that all three subcommittees require a full project for their deliverables.  This may be structured as three separate projects or as one combined project.  If separate, projects may run concurrently or sequentially, depending on the what works best.

5.1.  If all three subcommittees report back that no changes/no new deliverables are required, the proposal is referred back to the proposer for revision.

5.2.  If one or more subcommittees have new or changed deliverables, completed documentation is submitted to the core team.

6.   Core team reviews documentation.

6.1.  If documentation is not approved, it is sent back to the proposer for revision. 

6.1.1.  The project may have to be referred back to the subcommittee if it needs a lot of rework.  The subcommittee team determines where in the process the project should go back to, or if project should be put on hold, discontinued, etc.

6.1.2.  If the proposer revises the documentation, he/she resubmits to core team.   Return to Step 6 above.

6.1.3.  If the proposer takes no action, the project dies.

7.  If the documentation is approved, core team reviews to determine if a ballot is required.

7.1.  If balloting is required balloting process is followed.

7.2.  Ballot may not be required if all changes are minor and/or non-controversial.  Ballot may also not be required if decision is made to a provisional or draft document.  Go to Step 10.

7.3.  Before making a decision about whether to ballot or not, Core team may take straw poll of membership via e-mail and allow for short feedback period.  If there are no objections, Core team may determine that no ballot is required.

7.4.  Proposer, Subcommittee and/or Core Team may recommend that publication automatically be designated as draft or provisional (see Step 10) and not go through ballot process immediately.  This might be a case where EIDX wants to get something out on the table for trial usage, piloting, etc. and is not ready yet to put it forward for approval as a standard or guideline.

8.  At the end of the balloting process, a ballot review is conducted.  This may be a separate session dedicated to the project, or done as part of a subcommittee general session, depending on the complexity of the ballot, number of ballot comments, etc.

8.1.  If the ballot is not approved, it is referred back to the proposer for revision and resolution of ballot comments.

8.2.  The project may have to be referred back to the subcommittee if it needs a lot of rework.  The subcommittee team determines where in the process the project should go back to, or if project should be put on hold, discontinued, etc.

8.3.  If the proposer revises the documentation, he/she resubmits to core team.   Return to Step 6 above.

8.4.  If the proposer takes no action, the project dies.

9.  If the ballot is approved, the proposer makes any changes/final updates arising out of ballot comments, proofreading, etc., and submits final documents to core team.

10.  Core team indicates publication designation to be used.

11.  Go to publication process.