In a cross-agency annual project, the more people take part, the more the project needs three fixed things: a meeting in the same time slot every week, a single master data sheet, and one checklist before launch and another after. In support of the Ministry of Education project, POLISH agreed these three items with the project team before work began, for both the Outdoor Education Resource Platform and the 2026 Taiwan Outdoor Education Season, and named an owner for each item.
The more people involved, the longer completion takes
The cost of coordination has research to compare against. Herbsleb and Mockus, 2003 analyzed globally distributed software development using change-management system data and a questionnaire. Work items that spanned sites took about two and a half times as long to complete as work items at a single site. The data point to a mechanism: work items that span sites involve more people, and the number of people involved correlates strongly with the calendar time needed to finish. The study centers on development teams spread across locations; what is borrowed here is the relationship between the number of people and completion time.
In a cross-agency annual project, the participants include the supervising agency, the project team and the participating units, and the POLISH side adds engineers, designers and testers. With this many people involved, each round of confirmation usually takes more calendar time. POLISH therefore fixes the cadence before work begins, so that both sides know in advance the latest time slot in which each item can be discussed face to face.
A weekly meeting in a fixed slot, with suspensions and reschedules on record
POLISH and the project team agree on one meeting each week, in the same time slot. Items that need continuing discussion between both sides, such as terms and forms, are scheduled into this slot, and project team staff take the minutes and handle follow-up. A fixed slot means neither side has to arrange a time every week, and both know when an issue can next be discussed face to face at the latest.
Schwaber and Sutherland, 2020 set out the same idea for product development in the Scrum Guide: a Sprint has a fixed length of one month or less, and the Sprint Review is a working session in which the team and key stakeholders discuss results and next steps. Scrum is a product development framework; what is taken from it here is that a fixed cadence lets stakeholders see results at regular intervals.
Herbsleb and Grinter, 1999 studied a software project spread across several locations as a case and found that integration was the hardest part, and that a break in informal communication channels amplifies coordination problems. Stable plans, processes and specifications help, while the unpredictable parts of a project call for a channel that developers can proactively open at any time. The weekly meeting corresponds to the former. For questions between meetings, POLISH collects the questions in the same discussion thread, where either side can raise a question at any time.
The meeting has a fixed procedure for suspension as well. When the project team suspends it because of an internal meeting or a briefing session, the notice goes into the discussion thread that day, with a note that the related items move to the following week. When POLISH has to reschedule at short notice, the notice is posted in the same way. If needed, the meeting moves to another day of the following week; a scheduling conflict is raised in the same thread and, once confirmed, the meeting returns to the original slot. Repeated suspensions and reschedules have all followed this method, so open items always have somewhere to go when one meeting is skipped.
- Weekly meeting in a fixed slotTerms, forms and other items under continuing discussion are scheduled into this slot
- Held as scheduledItems handled in the meeting; project team takes the minutes
- Suspended for the weekNotice posted in the thread that day, with items moved to the following week
- Needs reschedulingMoved to another day of the following week, confirmed in the same thread
Drawn from the weekly meeting practice between POLISH and the project team
One master sheet for activity and course data
The activity and course data of an annual project come from many units and are updated on a rolling basis each month. On this project, the project team maintains the data in a shared master sheet and reports each monthly update at the meeting, and POLISH imports from the master sheet. When the meeting is suspended, the report is made in the discussion thread instead. When data needs correcting, the two sides first agree whether to edit the master sheet directly or report the item individually, and POLISH handles it together with the next update of the production site.
Lee and Kim, 1999 tested 74 outsourcing relationships and found that partnership quality predicts outsourcing success, and that participation, communication, information sharing and top management support have a positive effect on partnership quality. A shared master sheet is one concrete form of information sharing, so the two sides do not each edit a separate copy. The study is relatively old; what is borrowed here is the direction in which communication and information sharing affect outsourcing success.
The division of work at the start of each month is fixed as well. The project team opens the next month's activity data, compiles the rolling updates from the participating units and uploads the result. POLISH schedules the start and completion of the work, then switches that month's activities to published and opens the month's page, so that each month's activities go live at the scheduled time. The merging, de-duplication and numbering behind the master sheet are covered in data integration for cross-agency campaigns.
Notices, terms and promotion timing before launch
Before the new platform was switched over, the POLISH project contact first listed the preparatory steps: announce that back-end editing would stop, notify of the maintenance, send an email to all venue staff and administrators, post announcements on the new and old sites and publish to social media in step, and only then go live and issue the press release. The list carried an owner and a completion check for each step, and another project coordinator confirmed the items one by one. The project team drafted the email, and POLISH adjusted it and an engineer sent it.
When a launch involves changes to the host, the host's operations contact needs to be notified early. That contact sits on the project team's side, so POLISH recommends that the project team make the notification.
On the day before launch, POLISH reminded the project team to publish an updated version of the website's terms of service and privacy policy as well, as one of the pre-launch checks. Any terms that must change in step with a new feature are handled in this check.
POLISH recommends setting the date of major public promotion after the activity rules are fully confirmed and the engineering adjustments are complete, with an animated video and an illustrated quick guide released together, so that the promotional content matches the actual functions. Once the project team agreed, POLISH began designing the promotional materials. The project team also provides an annual marketing calendar that lists, day by day, the schedule for feature development, promotional email production, social media posts, data uploads and the production launch. Items that require discussion with POLISH of the activity rules and rule wording go straight into both sides' schedules.
On the day a feature goes to the production site, the launch, the back-end list and public communication connect within the same day. POLISH supplies the matching post images in advance; that evening, after the draw, the project team checks the week's list in the back end and then publishes the social media stories and the announcement. For the platform's own practices during the campaign, see platform practices for a nationwide campaign.
Compiled from the preparatory steps for the new platform switchover and for a new feature going to the production site
Check all fixes together before notifying, and update the production site at most once a week
The project team's reported items are collected in a shared reporting list. Once every item on the list has been fixed, POLISH first runs a full check of its own, confirms that the fixes in the same round do not conflict with one another, and only then asks the project team to verify again. This arrangement reduces the project team's burden of verifying item by item. After re-verification the project team replied that there were no problems at the time; for later website updates, POLISH also asked the project team to try the new functions, and both the front end and the back end were reported successful.
After the production site went live, the POLISH project contact announced that the production site would be updated at most once a week, and added a status called “Testing complete, ready for production” to the tracking cards. Engineers make the adjustments and put the changes on the test site first; once a tester has verified the changes, the card is marked with this status; after an engineer has deployed to the production site, the card moves to Done. The testing is mainly carried out by POLISH, and the project team said this was acceptable, after which the process took effect. A fixed deployment frequency lets both sides know when updates go live, and testing and going live become two separate actions.
External materials are prepared in one batch and confirmed a week ahead
For each round's recommended posts and videos, POLISH first posts the full draft in the discussion thread. The project team checks each item against the organization's official name, contact point, time and registration method, and replies with a list of the wording that needs to change. POLISH makes the corrections the same day, the project team confirms and sets the publishing time, and posts are often scheduled in batches of one to two per week, on the day of the draft or the day after.
Afterward, POLISH provides drafts for confirmation a week ahead whenever possible, attaching the following week's three posts and videos in one go; the project team confirms the content during the week, and POLISH schedules the posts. A whole batch of posts is prepared by POLISH in one pass and sent to the project team to confirm all at once, and the project team then forwards the batch to an advisor for review at the same time, which reduces the rounds of back-and-forth post by post. How the confirmation records left in the thread are organized is covered in how to keep project communication on record.
Situations where this approach does not fit
A fixed meeting, a single master sheet and a launch checklist suit projects with many participants and continuing updates. For the situations below, a simpler arrangement is enough:
- A one-time delivery with no updates afterward: no weekly meeting is needed, and a single acceptance review at delivery is enough.
- A project with one contact and one development team: one shared list and one discussion thread cover the communication.
- A project still comparing options for requirements and scope: do the evaluation and scope confirmation first, then set the cadence.
What to prepare before starting
Before work begins, POLISH and the project team agree on the following:
- The fixed time slot for the meeting, and how a suspension or reschedule is announced.
- Who maintains the master data sheet, when it is updated each month, and where the update is reported.
- The items on the pre-launch checklist and the owner of each, including the host's operations contact to be notified and the updates to the terms of service and privacy policy.
- The date of public promotion, set after the activity rules are confirmed and the engineering adjustments are complete.
- The update frequency of the production site, and how a completed test is marked.
POLISH also convenes a one-hour project kickoff meeting with all participants before work begins. It covers the division of work, how front-end and back-end data are exchanged, and some pages of the front-end design draft; later questions go into the same discussion thread, where each member confirms attendance. In long-term operations and platform development projects, POLISH treats these items as fixed steps before work begins.
Once the participating units and the launch schedule are settled, the schedule and the list of participating units can be brought to a discussion with POLISH about the project cadence, to confirm item by item which practices apply.
