Introduction...... 4

Product Release Management for Beavers! 2 Process Overview...... 6 Trigger...... 6 Release Decision...... 6 Planning...... 7 Body of the Work...... 8 Releasing the Product...... 8 Review of the Release Effort...... 8 Roles and Responsibilities...... 9 Product Release Coordinator...... 9 Role...... 9 Responsibilities...... 9 Quality Assurance Coordinator...... 9 Role...... 9 Responsibilities...... 9 Help Desk Liaison...... 10 Role...... 10 Responsibilities...... 10 Installer Writer...... 10 Role...... 10 Responsibilities...... 10 Documentation Writer...... 10 Role...... 10 Responsibilities...... 11

Product Release Management for Beavers! 3 Introduction This book discusses how to effectively manage all aspects of the product release process. Although initially geared toward product release coordinators (PRCs), anyone interested in learning about the software release process will find it a valuable and useful guide. In addition to in-depth discussion of the software release process, the book covers many standard management, meeting, and communications techniques, which can be applied to any project. A good software release process starts with good project management practices.

A PRC is the project manager / team leader of a software release team. At MIT, each time a vendor or in-house development team releases a new version of a product MIT recommends, the software release team decides whether to release it to the MIT community. There are a number of factors involved in this decision, but once a decision is made (usually based upon an argument that the product's PRC has made), then the release process begins in earnest. At this point, the PRC takes action to organize resources, communicate plans and set expectations, and leads the team through an organized, well-structured process that culminates in either a release or a statement explaining why the software should not be released. The PRC bears a sizable responsibility in this process and consequently plays a critical role in a release’s success.

Although almost anyone can be a successful PRC with proper training and guidance, there are a few skills that make the job much easier and less frustrating. These skills include project management, organizational, time management, interpersonal, meeting planning and facilitation, communication, and lastly, leadership. If you are not strong in all of these skills, do not be discouraged. There are numerous ways to increase your expertise in these areas, such as taking professional development classes, reading books on the topics, and even putting yourself into roles where such skills are necessary and naturally developed through practice and hard-work. Most importantly, you must possess the desire to succeed as a PRC. If you want to do well and can focus on being successful, then with a little extra initiative, you can develop many of these skills along the way.

We have organized the book to first introduce the high level structure of the process and then to focus on the details of each phase of the process in chronological order. In each section, we explain the purpose of the phase, the role you play in the phase, and explain techniques that will help you skillfully accomplish your tasks in each phase. Furthermore, at the end of each section we review the materials and documents of various actual release efforts from the past. We will explain the strengths and weakness of the examples and show you the key points you need to take from them to perform your responsibilities efficiently and consistently.

This book makes the assumption that your organization has established a software release process and has dedicated the necessary resources for it to function successfully. After discussing the software release process as it has been developed at MIT, the book discusses different software release models that will help fledgling efforts get off the ground. Regardless of the

Product Release Management for Beavers! 4 model, the process discussed in this book will serve the reader well. Some interdependencies may vary, but the underlying process will not.

Before diving into this book, however, you should purchase/obtain a few items and software. Firstly, good project management software will be of significant value to you. With very little training you can learn to quickly manage a time line and a project's resources with one software package. Although you can do both with an excel spreadsheet, or even on a piece of paper, project management software such as MS Project and FastTrack make doing so easy and clear. The increased clarity and comprehensibility achieved through using these products justify their use. We use Microsoft Project in all of our examples. Secondly, you should obtain some manila folders, a 2" binder, and access to calendaring software (we use Oracle TechTime in MIT's IS&T department). You will use these items during the exercises included with each sample set.

Product Release Management for Beavers! 5 Process Overview The software release process can be thought of as having six phases as shown in figure 1.

Figure 1: The six phases of the software release process.

Obviously, this model abstracts the process a great deal, but it provides a useful tool for understanding how the release process starts, progresses, and finishes.

Trigger A trigger is an event that triggers the awareness that a release effort may be in order for a particular product. There are many different triggers, and they vary from product to product. A few typical triggers include:

 new version release of a recommended product  customer demand drives the identification and release of a new software package  technology watch catches a significant/critical update to a recommended product

Product Release Management for Beavers! 6  release of a new operating system and corresponding versions of software that run on it  managerial mandates to release a software package  introduction of a new service, such as IMAP or calendaring, that requires a software package to utilize its functionality

Release Decision

At this point the Software Release Core Team makes a decision either to go ahead with a release effort, or to stop the process. This involves weighing the benefits to the new release against the costs. Important factors to weigh are:

 size of the customer community  infrastructure dependencies  security of the proposed product or service  buy-in from key stakeholders

It is important to note that during this stage it may be necessary to solicit the opinion of various people outside of the SWRT. For example, even if the SWRT feels that it should release a product, there may be other stakeholders (computing help desk, business process owners, directors, etc) who feel strongly against the idea of releasing. Although the SWRT will decide whether to move forward with a release the majority of the time, engaging relevant stakeholders from an early point in the process will ensure that all stakeholders are aware of the release effort and will help minimize the possibility of strong pushback later in the release process.

In addition to deciding whether to release, sometimes the release team will also need to decide whether to wrap the software package in a customized installer. As a rule of thumb, only non- shrink-wrapped software that MIT distributes via the software download page is wrapped in an installer. Programs such as operating systems and application suites (Micorosoft Office, for example) are distributed as is.

Planning

The software release core team takes care of the following planning activities:

 identifies the scope of the release effort.  assign a Product Release Coordinator  obtain hardware and software resources needed for the project  identify licensing issues / requirements  decide how the software will be distributed

The Product Release Coordinator performs these planning steps (obtaining input from the relevant stake holders):

 identify roles to be filled on the Product Release Team  form the Product Release Team  establish team meeting schedule

The Product Release Team performs these planning steps:

Product Release Management for Beavers! 7  determine the release timeline  decide if a custom installer is necessary  establish a test plan  identify significant issues/dependencies the new release has with existing software, services, or products

Execution

The actual work performed by the Release Team falls into these categories:

 communication  integration  documentation  testing

Communication

Communication is all about keeping the relevant stakeholders informed of issues identified, decisions made, ongoing status. The following kinds of communication originate with the team:

 Release project underway announcement  Project notebook  meeting minutes  Follow Project Management Methodology that includes items such as a Work Breakdown Structure (WBS), Timeline, and Schedule as appropriate to the scope of the effort.  Release announcement  additional status reports if warranted  notifications to the Help Desk, and Training, and ist-web of the planned go-live date (at least 2 weeks in advance)

The Software Release Core Team is responsible for the following additional communications:

 Software Release Home Page  Software Release 9-month Outlook

Integration efforts may involve:

 crafting of configuration files  creation of custom installers

Documentation produced for a release consists of:

 Product or Service Front Door  Version Page  Getting Started and/or Installation Guide  Known Issues (if there are more than fit conveniently on the version page.)  Stock Answers  additional documentation if necessary

Product Release Management for Beavers! 8 Testing consists not only of executing the test plan, but checking in with the Help Desk, the Training group, and other relevant stakeholders to confirm there are no surprises, and that the test plan covers what needs to be covered.

Go Live

The final go-live check list consists of:

 re-confirm everyone is on board for planned go-live date affirming we are "GO"  confirm with swreq that any software to be distributed is in place  final check of published documentation  notify ist-web previously planned go-live day is ON  Release Announcement is approved and ready to send

Go-live is official when the Product or Service Front Door page is published with the Version Page linked in. At that point, the Release Announcement is sent and we are live.

Follow Through

Follow through is done at these points in time:

 immediately after go-live  in the days and weeks after go-live  at the 30-day review

Immediately after go-live, a check is made to re-confirm that all expected documentation has been published and is visible to customers. In the days and weeks after go-live the Product Release Team monitors the helpdesk feeds and escalations looking for surprises. Are there issues un-accounted for? Are there new problems? Are customers asking a lot of questions about something such that a new Stock Answer or document revision is required?

Thirty days after go-live, the Product Release Team re-convenes to:

 review surprises and propose action if there were any.  do a plus/delta on the software release project to identify aspects that worked well, what did not work well and what could be done better in the future.  perform or schedule any work identified through the follow-ups.  celebrate!

The Software Core Team follows through with Rewards and Recognition of stellar individuals or teams.

Product Release Management for Beavers! 9 Roles and Responsibilities Research and practical experience indicate that well defined roles and responsibilities play a critical role in a team’s success. A release team is no exception. The product release coordinator is responsible for forming as well as leading a release team. Because you’re on the hook to create a team that delivers a quality product in a timely fashion, it’s important to create a team that has enough people to do the work but not too many people that team members feel useless and confused about why they are on the team. Fortunately, through trial and error, the SWRT has identified the basic roles and corresponding responsibilities necessary to every release team. Occasionally, there will be times when you need more people on the release team (especially when releasing complex software like an operating system), and rarely when you will need fewer people (i.e. silent update of a minor program). By and large, however, the roles and responsibilities described below are sufficient.

Product Release Coordinator

Role The product release coordinator (PRC) is the project team leader of the release project.

Responsibilities  draft a business case (if one is needed)  create a project plan  form the release team; allocation of resources  schedule and organize meetings  draft and send communications  maintain a project notebook  quality assurance  train support providers (HD)

Quality Assurance Coordinator

Role In large scope release projects, the Product Release Coordinator can manage these aspects. The Quality Assurance Coordinator in conjunction with the project manager or PRC, heads the testing efforts for the product.

Responsibilities  create test plan and matrix  test product according to test plan and matrix  coordinate activities and act as a point of contact for external testers  ensure that the test cluster has appropriate versions of the product installed and ready for testing  summarizes test results  identifies issues that may warrant a stock answer

Product Release Management for Beavers! 10 Platform Coordinator

Responsibilities

 resource for platform-specific issues.  may or may not be on the Release Project team depending on the platform impact of the Project.  acts as an escalation point for platform specific software issues.  works with Product Release Coordinator to develop test standards and procedures for the platform.  validates supported software and MIT installers on each new version of the operating system.  acts as technical resource for installer writers to resolve problems

Help Desk Liaison

Role The Help Desk Liaison (HDL) ensures that the computing help desk has a voice on the release team. The HDL maintains an open line of communication between the help desk and the release team and coordinates testing, review, and training activities between the two teams.

Responsibilities  distributes beta installers to the rest of the help desk  solicits input into key decisions from the help desk  informs the help desk of key decisions and important issues  coordinates “dog and pony” shows of the product before the release  informs the team about help desk activities that may impact the release effort  alerts the help desk via e-mail two weeks before a product is scheduled to be released  shares documentation created during the release project with the help desk (typically by sending links to the documentation via e-mail)  creates and maintains case sets for the product after it’s released  compiles case set data for 30 day review  solicits feedback from help desk members about the product for the 30 day review

Installer Writer

Role The Installer Writer (IW) writes installers that customize software products to work properly in the MIT environment. The IW participates in a release project under two conditions. First, the SWRT or release team determines to wrap the product in an installer. Second, the SWRT or release team is trying to determine whether to wrap the product in an installer. In the second case, the IW may serve more of a consulting role by helping the team determine how his participation can add value to the release project.

Responsibilities  assists release teams in determining the value, if any, of wrapping the product in an installer  writes installers and publishes betas in a web accessible location, and notifies the relevant release teams of updates  collaborates with the documentation writer to draft readmes included with installers

Product Release Management for Beavers! 11  emails [email protected] necessary information to publishes final product to the software download page  communicates with other development teams (such as the Macintosh or Windows development teams and the Win.mit.edu teams) about the teams efforts and searches for synergies  works with the Platform Coordinators to identify bugs or issues with the installer

Documentation Liaison

The Documentation Writer (DW) writes most of the documentation the release team produces.

Responsibilities

 keeps training and publications team up-to-date on progress  works with the QAC to draft stock answers  inventories all IS&T documentation related to the product and the class of product (i.e. e- mail, web browsing, etc) and identifies which documents need to be updated  compiles a list of all documents that need to be updated or created  drafts new version specific documents: installation instructions, known issues, settings configuration, etc.  collaborates with the Production team [email protected] to publish the final versions of all the documents

Training Liaison

Depending upon the release project, the team determines if training is currently being provided and/or will training be provided for a new software package.

Responsibilities

 works with the team and relays information back to training team.  tests new software  develop new training curriculum

Product Release Management for Beavers! 12 FAQ

How do I escalate bugs?

How do I obtain testers?

What tools can I use for PM?

How can I get help using PM tools?

How do I obtain permissions to product directory and to mail list?

Should I use a wiki?

What mechanism is in place to document bugs?

Product Release Management for Beavers! 13 Parking lot items: Create 1 page executive summary List PM tools; can use MS project, Omniplan, Fasttrack, etc Templates for release project underway, release announcement, etc. Accountability and sign off (testing, hd readiness, pubs, training) Should swrt use confluence/jira as a standard? What are the caveats? - out of google’s range (indexing) - what kind of support is provided for confluence? Next step for team: Schedule a Confluence/Jira QS for SWRT

Product Release Management for Beavers! 14