You have just 52 weekends in a year!

Summary

If your organisation performs core system changes away from business days, you can reserve a complete year's weekends with little trouble. So when planning, allowance must be made if data migrations (or other changes...) impact your application.

Actions

Outline planned weekend events for the next six to twelve months
Pencil in plans for the following six to twelve months - reserve time for known regulatory changes, end-of-year and published blackout periods
Firm up the plan for the immediate three months - confirm and publicise within your team / business
Work through the plans for the next twelve to eighteen months in three month blocks until the plan is firm - publicise the confirmed plan within your team / business
Examine development leadtimes for your application and confirm their alignment with your planning horizon - publicise your leadtimes to assist your team's / business' planning
Examine the upstream and downstream applications' leadtimes and understand their relationship to your planning timeframe - discuss your relative leadtimes with these applications to promote an understanding of your interdependence
Each quarter firm up the next 3 months and pencil in the draft events at the plan's end (12 to 24 months out) - confirm and publicise
Understand the 'change workload' level for users and operational staff - use this to confirm the human suitability of your change programme

A year's plan for an application

For your application, a year's weekends could be reserved (generically) in the following manner:

6 weekends for software releases: Changes to your base application that bring enhanced functionality or conformity to regulatory requirements.
6 weekends for software release 'backup weekends': These weekends are reserved in case the software is not ready for release, or the primary release fails and is backed out. These weekends represent insurance for the software releases.
3 weekends for a financial end-of-year: If your application contains financial amounts, the auditors (or finance department) may disallow application changes for a period before and after the financial end-of-year. This reduces the risk to the financial results.
4 to 6 weekends of (summer) holiday blackout: This blackout prevents changes being performed when (summer) holidays reduce the support and management staff available. The ability to recover from and manage major operational problems is diminished during these times.
2 weekends reserved for major public holidays: These holidays could include Easter, Thanksgiving, independence days (e.g. July 4th), and other important national / regional holidays. These reservations are for similar reasons to the (summer) holiday blackout.
2 to 4 weekends for major marketing events: When new products are released, or marketing campaigns are performed, all systems need to be fully operational. If systems are broken due to recently upgraded software or recently migrated data your business' ability to respond to market demands will be impacted. By making these reservations, you ensure recent changes do not disable systems just when they are needed most.

Total: 23 to 27 weekend reservations

This leaves 25 to 29 weekends (i.e. the remainder of 52 weeks) available. Your reservations may vary if you release software more often, or if your application is impacted by the software releases of other upstream or downstream applications. As well, these reservations do not include situations where end-of-month weekends are disqualified for reasons of financial risk. As always, your mileage will vary based on your specific circumstances.

In the example above, a maximum of 12 to 14 weekends per year are left available for data migrations. This allows each data migration to have a 'backup' weekend available if the primary weekend cannot fully complete. If these backup weekends are not available, the 'sunk' cost / effort / benefit expended for staff training, communications and other interdependent activities could be lost or sharply diminished.

Staffing Implications

Whilst the operational staff supporting your application do not change, the staff performing the 'reserved weekend' activities will. For example, the software development team is likely to be different to the data migration team. This situation can impact your support staff due to:

Requirements for additional staff: to cover regular support tasks plus additional weekend workload
The risk of support staff burn-out: due to their application changing 'every weekend'
System stability: the capacity of staff to address issues as they arise
Problem resolution: problems may be due to software releases, data migrations or an unfortunate combination of both
Review and learning activities: staff supporting an application may be reasonably expected to participate in the review of upcoming software releases - understand new functions, confirm design appropriateness, and understand / agree to deployment plans.

Impact of external applications

In addition to change in your own application, upstream and downstream applications may require reservations that impact you as well. These impacts may include changes to your interfaces (or the manner in which they are called), the population of existing fields, or new transactions across an existing interface. Like your own software releases, their releases may not be successful and require backout and re-release.

Development Leadtimes

The development leadtime determines when a planned release's scope must be locked in (or at least firmly agreed). This is related to an application's development capacity (number of days or dollars available), the size of the ideas developed, and the speed an idea can be turned into an implemented change. Due to their complexity, larger ideas can take longer to go through the development process. If there is sufficient development capacity, a percentage of a release can be reserved for 'unexpected' development - e.g. responses to a competitor, remediation of a large production defect.

Where the idea's scope impacts multiple applications, your own plus those upstream or downstream of yours, it is important to identify which application has the longest leadtime This allows the idea's impacts to be confirmed for that application first, and progressively for the remainder with shorter leadtimes. All impacted applications can then develop to a common implementation point.

Applying symmetry, applications upstream or downstream may impact your application as well. They may have leadtimes shorter or longer than your application's, and may need you to reserve weekends in your planning period.

It is important to understand whether your application's leadtimes are generally longer than your interfacing applications (and so you require them to notify you early in their release planning), or are shorter (requiring you to inform others of specific date commitments).

Central point of review - distributed control by application

The staff (including management) that support an application understand its operation the best. They understand the impacts of a change and will be the ones to fix any problems. For this reason, the responsibility for planning and administering the changes that will impact an application must be controlled by its management and senior operational staff.

Avoiding too narrow a focus and providing an external review of planned change (i.e. bringing light into dark places), a centralised and knowledgeable review of planned changes is desirable. This review can be broken into two parts. The initial review of changes that are months away - this is the review where 'politics' is most likely to be on display (as competing interests attempt to get their plans in place) and decisions will be required between competing ideas. Closer to their implementation, additional review points will validate each change's readiness to progress, and will approve (or reject) that progression.

Publication of the release plan is desirable and provides one 'point of truth' where committed reservations (and their details) can be easily discovered.

Information captured for a 'weekend' event

The following list includes details desirable for each weekend reservation (or for any other planned change):

Applications impacted: This includes any affected upstream and downstream applications, the degree of impact, and the interdependency of the applications (e.g. what must happen first / last / after)
Date / time of change: This allows support staff to plan other work with these impacts in mind. As well, operational staff can confirm that specific system outages are planned and not a cause for alarm.
Nature of impact: What is planned during the weekend? Is it considered a minor or major change?
Backup / Backout plans: Details of the plan if things go badly. This would also need to include the expected elapsed time and impacts of a backout.
Notification plan / Points of contact: Who will be notified of ongoing status? How can others contact the weekend team to inform them of unexpected impacts, or obtain current status?
GO / NOGO decision point and the decision makers: When will the weekend's decision point be reached? Who will decide to progress or backout? Are there interim points that decisions may be made?

Tags: Migration, Conversion