Continuous Development Process
IHE domains that operate on an annual cycle only have a single point in time for new work items each year. This means the turnaround time to publish a profile can range from 9 months to 21 months depending on where in the cycle a proposal is brought forward. At the long end, 21 months from proposal to profile is considered not responsive by some stakeholders.
An alternative continuous development cycle is proposed to evaluate new work items at any of four points distributed through the year. Instead of two 2-day selection meetings followed by three 5-day face-to-face working meetings a month or two apart, it is proposed to have four 5-day working meetings evenly spaced through the year. A portion of each meeting is devoted to planning tasks such as review and prioritizing of proposals, and the rest of the meeting would operate similar to our current technical meetings, except each work item could be in a different phase (volume 1 prep, public comment prep, TI prep).
- 1 Governance
- 2 Background
- 3 General schedule
- 4 Planning Committee Responsibilities
- 5 Dashboard
- 6 Domain Specifics
- 7 See Also
This is a specialization of the IHE Process. All the normal governance is expected, the difference is in 'when'.
As each proposal comes in, it is evaluated for suitability, and then placed in priority order in the backlog. When a current work item completes, room frees up in the schedule and a new work item is taken off of the backlog. The new work item moves through the development process. Typically each meeting would move it to the next phase (thus completing in a year once work starts), but larger or smaller work items could move faster or slower.
There is no need to change from a single annual TF publication, although that could be discussed. Supplements would be published through the year as they are ready.
Connectathon requirements would reflect the published documents as of 4 months before the event.
The goal of continuous development is to enable more flexibility and achieve better quality.
This is not to say that the former annual schedule produced poor quality, but does recognize that when the calendar is considered the top priority there is more pressure to deliver product possibly before it should be released. With a continuous development method these opportunities can be delayed by 3 months to achieve appropriate quality.
- A continuous development governance enables new work items to start at 4 times throughout the year, rather than only in the fall. This enables projects to approach IHE in a more flexible timeframe, when that project resources might be more readily available. This also enables us to react quicker to market needs.
- A continuous development governance enables smaller work items, and very large work items. It is possible to have a work item complete in as short as two meetings. The annual cycle imposes size and time limits on projects; work items need to be goldilocks sized to be accepted (not too small, not too large). We sometimes go through strange contortions of descoping features; releasing partial profiles one year, and the full profile the next year, etc. in order to meet the annual cycle needs. A continuous cycle would support work items that take anywhere from 3 to 24 (or more) months.
- We don’t hit our communities with requests to review multiple public comment documents all in the same month. Reviews would be spread out through the year. Similarly, prepping for a meeting that will be discussing work items at various stages would be a more consistent load on committee members. The publication effort peaks would be evened out.
- The annual cycle has challenges when having to work with the schedule of other organizations. This is especially true for deadlines very late or very early in the calendar year – a work item due mid-January would either have to be completed in the previous cycle (which means proposing it 18 months in advance) or started and then completed in the six weeks between profile selection and deadline.
- The annual cycle can impose compromises. We occasionally approve work items to move to the next phase when they are not yet ready because of cycle deadlines. Knowing we can hold a work item for further work over the next quarter without disrupting the cycle will result in a higher quality of work item.
Currently, if a proposal is not accepted during the work item selection, it goes away. Good proposals that are not accepted could automatically be kept in the queue for reconsideration (and proponents would have a chance to improve their pitch).
- The annual cycle means that many planning committees are active for only 3 months of the year, while technical committees are active for only 9 months. A continuous cycle would keep both committees engaged all year long.
- A continuous development governance enables a project to miss one quarterly meeting due to resource conflicts, but must not allow more than one missed quarterly meeting. The ITI/PCC/QRPH volume 1 meeting is traditionally held in Europe. This proposal would allow participants who only attend the European meeting, and those who only attend non-European meetings, to be exposed to other parts of the development cycle.
- Experience shows that it is effective, but does take much more oversite and more effort by co-chairs
- Projects will not be focused on a well-defined use-case, and thus will expand to all possible use-cases. Profiles succeed because they have a limited scope, which enables optionality to be removed, vocabulary to be chosen, and clear communications.
- Related is an open schedule will be more accepting of scope-creep
- Carefully watch the IHE Pipeline Impedance Matching as delivery of all portions of the pipeline are important, not just development of supplement
- Projects will not progress each quarter -- more than one quarter without improvement shall be automatic termination of that project
- Unclear what Connectathon will test -- well defined deadline that is strongly enforced. At least 4 months prior to connectathon.
- Moore: I think this one is easier to manage than you think.
- Moore: There are different Connectathons at different times of the year.
- Moore: I think the rule is: A profile can be tested at Connecton A that meets these two criteria:
- Profile (supplement) is published for Trial Implementation on or before registration opens for Connectathon A (not during, not after it closes).
- TPM has been engaged by the appropriate technical committee and has committed to developing test plans.
- approved Projects must submit their developed work two weeks prior to Face-to-face meeting or they will not be scheduled during that face-to-face
- approved Projects must progress. Any project that misses two face-to-face meetings in a row will be canceled
- Connectathon is based on face-to-face meeting at-least four months prior to Connectathon.
- Projects will be approved only when they have proven they have met the milestone requirements. This means no more approval by the committee pending later meeting or editing. Either it is ready or not. Else it gets ready for the next face-to-face meeting. Quality is prime!
- Scope must still be appropriate for a Profile, limited and focused; and scope must NOT expand without both Planning and Technical approval.
The committees meet quarterly. Under the annual schedule the fall meetings are two short two-day meetings. Under Continuous development governance these two meetings will be merged into one fall meeting.
On a quarterly basis
Two weeks prior to the face-to-face meeting
Deadline for approved projects to submit their current phase text so that the co-chairs can plan the agenda. Anything submitted later than this will need to be delayed to the next quarterly meeting.
- Planning committee to groom the backlog of potential new work items. This includes assuring there is available appropriate authors, and resources. This includes quality measurements of the new work item proposal text. Any new work item proposal that does not have resources or is not well documented will not be considered at this quarterly meeting, but will be allowed to improve so that it could be considered at the next meeting.
- Technical committee to groom the ongoing work items. Having the profile text ready two weeks prior to the meeting enables the community to review so that the focus on the meeting is on producing quality, not reviewing brand new text. Having the profile text available enables co-chairs to develop a reasonable agenda.
- Predict the expected publication would be, and communicate that to your publication contact (e.g. Mary). This should be optimistic (maximum) so that your publication contact can prepare.
Four timeslots each day of the face-to-face will be scheduled for specific project tasks. This enables participation by all participants. The co-chairs are enabled to give more than one timeslot to a work item, but the following tasks must be completed each face-to-face meeting based on availability of project deliverable at the two-weeks prior deadline. The face-to-face meeting should be focused on review of submitted text, and less on developing new text. Any project that has not completed their text prior to the deadline should NOT be allowed to present and develop during that face-to-face meeting.
All technical and planning responsibilities must be completed within the scheduled face-to-face, so the co-chairs must be careful to define agenda and stick to that agenda.
Part one of face-to-face meeting
- Review any Volume 1 development projects, approve as appropriate to technical solution development (Volume 2/3)
- Review any Technical Solution (Volume 2/3) projects, approval as appropriate to public comment
- Review any Public Comment resolution projects, approval as appropriate for Trial Implementation
- Review any Connectathon test plans and tools for how well they test expected requirements of the profiles
- Review any Change Proposals for ballot or integration
Part two of face-to-face meeting
- Review of Trial Implementation for promotion to Final Text
- Review of project that have stalled -- more than two quarters of no progress --
- Cancel with option to that project to promote as new work item
- Review of potential profiles to retire or deprecate
- Re-evaluate current working items for projected publication (Trial Implementation) and make visible
- Capacity assessment for following quarterly phase and Review new work items for approval as new capacity and expertise allow.
Planning Committee Responsibilities
The planning committee is still responsible for incoming new work items, prioritization of work items, capacity planning, and approval of final publication.
With the annual schedule, the planning responsibility was at the beginning of the year's planning. Concluding with the selection of new work items that are developed during the rest of the year. With continuous development governance, this will take place at the end of each quarterly meeting in preparation for the next quarterly meeting. The planning and technical committees will consider current load, and then select new work items to be picked up.
Thus the planning committee must keep a backlog of potential new work items. The planning committee must maintain this backlog prior to each quarterly meeting. This maintenance is the same maintenance as is expected prior to the Fall meeting under the annual schedule. New work items must still meet the same criteria as today.
A Monthly 2 hour call might work well to do backlog grooming, introduction of new opportunities, and evaluation of progress on items being worked on.
We anticipate the following deliverables from the Planning Meeting Face to Face
- Updated Evaluation Matrix for the new cycle, including which items require committee time during the upcoming cycle and what the expected goal is for the next cycle.
- A list of expected documents to be published or republished by the next face to face. This information should be communicated to Mary.
- A plan for the upcoming teleconferences until the next Face to Face.
Need to maintain a visible dashboard that shows progress of current work (predicted schedule, project health), and backlog of potential future work.
- Blunt use of a working group domain wiki page
- ITI is prototyping using Trello https://trello.com/
- There is a similar tool available in GitHub
- Return to ITI Planning Committee
- Return to ITI Technical Committee
- Return to IT Infrastructure domain page