Why Ledger went live on a Monday in October: the corporate calendar every project runs on
Finance closes the books in the first days of every month. Sales disappears in the last weeks of every quarter. The board meets six weeks after. Banks freeze in December. A field guide to the calendar a project manager can't see in the project plan.
The go-live date for Ledger, a new expense system at a 2,000-person public software company, was Monday 4 October 2027. It looks arbitrary. It wasn't. It was the only date in the quarter that dodged four separate calendars at once, and the reasoning behind it is a lesson most project management courses never teach.
Every function in a company runs on a calendar, and the calendars collide. A project manager who plans without them schedules user testing during Sales's quarter-end push, asks for next year's budget a week after the deadline, and puts a finance-system go-live in the middle of the year-end close.
First: which year are you in?
Companies plan and report on a fiscal year, which need not match the calendar year. GitLab's runs from 1 February to 31 January and is named after the year in which it ends, so FY28 runs from 1 February 2027 to 31 January 2028.
| Quarter | Months | What happens |
|---|---|---|
| Q1 | February–April | Annual plan takes effect; sales quotas and compensation plans start |
| Q2 | May–July | Major product release in May |
| Q3 | August–October | Annual planning for next year starts |
| Q4 | November–January | Year-end deals; holidays; annual planning finishes; year-end close and audit follow |
The practical rule: use the company's fiscal calendar in every plan and status report. “Ship in Q3” means August to October at GitLab, not July to September.
The rhythms, function by function
Accounting closes the books every month. A monthly close typically takes five to ten business days; a quarterly close takes longer because the results become public. During the close, accountants want nothing new: no vendor onboarding, no changes to financial systems, no surprise invoices. Year-end adds the external audit, and changes to financial systems near year-end are risky because controls have to be shown operating for the whole year.
FP&A runs the annual operating plan over three to five months before the fiscal year starts. A new project's budget is decided there. Asking for unplanned money mid-year means competing for contingency or a reforecast.
Sales lives on the quarter end. Deals cluster in the last weeks of every quarter, especially at fiscal year-end. Salespeople, solutions architects, deal desk, legal and finance are all at full stretch. GitLab's field communications team enforces a quiet period in the final two weeks of each quarter, limiting non-essential announcements to the field.
The board meets about six weeks after each quarter ends, with committee meetings two to three weeks before. Earnings follow the close and the auditors' review, with a quiet period on what the company says about performance and a trading blackout for insiders. Building the board pack occupies executives and their staff for weeks.
People teams run performance and compensation cycles, often once a year. Managers are swamped in those windows, and organizational changes are often announced just after.
Engineering releases on a train. GitLab ships monthly on the third Thursday, with a major release allowing breaking changes once a year in May. Infrastructure imposes production change locks around major holidays.
Customers have calendars too. Meridian Bank, a customer in another of the book's projects, froze all changes from 20 November to mid-January, as most banks and retailers do. The US federal government buys at its fiscal year-end, 30 September. Universities move slowly in summer.
The calendar on one page
| Q1 | Q2 | Q3 | Q4 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec | Jan | |
| Accounting close | busy | some load | some load | busy | some load | some load | busy | some load | some load | busy | some load | avoid |
| Year-end and audit | avoid | avoid | quiet | quiet | quiet | quiet | quiet | quiet | quiet | quiet | busy | busy |
| Sales quarter end | quiet | some load | busy | quiet | some load | busy | quiet | some load | busy | quiet | some load | avoid |
| Board and earnings | some load | busy | quiet | some load | busy | quiet | some load | busy | quiet | some load | busy | quiet |
| Annual plan (AOP) | quiet | quiet | quiet | quiet | quiet | quiet | quiet | some load | busy | avoid | busy | some load |
| People cycles | some load | busy | busy | some load | quiet | quiet | quiet | some load | some load | quiet | quiet | quiet |
| Releases and change locks | some load | some load | some load | busy | some load | some load | some load | some load | some load | busy | avoid | busy |
| Customer freezes (banks) | quiet | quiet | quiet | quiet | quiet | quiet | quiet | quiet | quiet | busy | avoid | busy |
The best windows for go-lives and cross-functional testing are where several bands are light at once: early in a fiscal month, mid-quarter.
The dates that constrained FY28
| Window | Function | Event | Effect on projects |
|---|---|---|---|
| Business days 1–8 of each month | Accounting | Month-end close | No finance system changes; finance experts unavailable for testing |
| Business days 1–12 after quarter end | Accounting | Quarter-end close and review | Same, stronger; avoid finance go-lives |
| Last 2 weeks of each quarter | Sales | Quarter-end push; field quiet period | No field training, surveys or pilots; deal desk and legal stretched |
| ~6 weeks after quarter end | Board | Board meeting (committees 2–3 weeks before) | Executives building board materials; slower decisions |
| Earnings date ± quiet period | Investor relations | Earnings announcement | No external statements on performance; insiders' trading blackout |
| Mar–Apr | People | Performance and compensation cycle | Managers busy; org changes follow |
| May (third Thursday) | Engineering | Major release | Deprecations and migrations land; heavy release load |
| Sep–Jan | FP&A | Annual operating plan for FY29 | Budget asks for next year due by mid-November |
| Late Nov–early Jan | Infrastructure | Production change locks around holidays | Defer risky infrastructure changes |
| Dec–Mar | Accounting, audit | Year-end close and audit | Avoid changes to SOX-relevant systems; finance unavailable |
| 20 Nov–15 Jan | Customer | Meridian change freeze | All customer cutovers before 20 November |
How the date was chosen
Ledger's decision document (written in the SPADE format: setting, people, alternatives, decision, explain) listed the constraints first. The Controller's close policy forbade go-lives in the last three or first eight business days of a fiscal quarter. The legacy tool's support ended on 31 December. Employees submit most expenses in the first week of each month. And UAT needed two clear weeks after system testing, which made late September the earliest realistic date.
| Option | For | Against |
|---|---|---|
| A · Mon 27 Sep | Earliest; most benefit | Collides with September's month-end AP close and the submission peak |
| B · Mon 4 Oct | After month-end; ~13 business days before the Q3 blackout; hypercare finishes before the Q4 close | Two days less float |
| C · Mon 8 Nov | Most float | Inside Q4's opening blackout; next window is late November, near holidays; ~$45k of benefit lost per month |
Option B won because it avoided both the month-end close and the quarter-close blackout while leaving a fallback date (18 October) inside the same window. The cutover itself ran from Friday 1 October at 18:00 UTC to Monday 4 October at 06:00 UTC, with the legacy system frozen over the weekend. That shape (go live early in a fiscal month, away from quarter boundaries, with hypercare through the next close) is a classic pattern for finance systems.
Book capacity before you need it
Ledger's UAT needed accounts payable specialists for three weeks in August. In May, Sofia Alvarez, the AP manager and Ledger's business lead, blocked that time in the AP team's calendar and moved the July close tasks that would have collided with test preparation. When a project needs a function during its busy season, book the capacity early, through the function's leader, with dates.
The calendar also belongs inside the schedule model, not in someone's head: finance blackouts as non-working periods for finance resources, change locks as constraints on deployment activities, the budget deadline as a milestone for next year's funding request. Ledger's project calendar listed every one of them, down to a Workday upgrade weekend on 11–12 September when no integration testing could run.
Rules of thumb
| System | Go-live rule |
|---|---|
| Finance systems | Early in a month; never in the last week of a quarter or during year-end close; hypercare through the first month-end |
| Sales-facing changes (CRM, quoting, territories, compensation) | Start of a quarter, or better, start of the fiscal year with the new plan; never in the last month of a quarter |
| People systems (HRIS, payroll, performance) | Avoid payroll cut-offs and review cycles; align with the cycle the system supports |
| Production infrastructure | Avoid change locks, major releases and holidays |
| Customer projects | Start from the customer's freeze windows and fiscal year |
Tricks from people who've been burned
- Ask each function's business partner: “When are you least able to help a project?” They'll answer precisely.
- Put the year's board dates, close calendar and quarter ends into your own calendar as all-day events.
- When you need an executive decision, aim for the three weeks after a board meeting, when attention is freer.
- When a customer says “after the holidays”, ask for their freeze dates in writing.
In a mature organization, the PMO keeps one integrated calendar with an owner for each type of event, checks every plan against it at each phase gate, and runs a quarterly look-ahead: which projects need which functions next quarter, and are those functions' busy windows respected?
How students practice this
Week 1, before a single project artifact: students build the FY28 corporate calendar in Google Calendar (closes, quarter ends, board dates, change locks and the customer freeze), then use it all program long. Every go-live they propose afterwards gets a collision check, and every decision document has to name the calendar constraints it respects.
Adapted from Projects, For Real, chapters 8, 19 and 64. The projects, people, vendors and numbers are the book's fictional case studies, set against GitLab's publicly documented practices. Gantt Guild is not affiliated with GitLab Inc.
