Introduction

PDLC Background

The Product Development Lifecycle (PDLC) defines actions and materials that are required for launching new products, feature releases, enhancements, decommissioning a product, pricing changes, and small changes or configuration changes. The Banno PDLC aligns with the standard corporate PDLC framework. This ensures consistent terminology and processes across groups and for customers.

Purpose

The PDLC is not intended to be a linear process. In the early stages of defining the work, teams may move between Idea and Plan as the scope of the work is refined. As teams move from defining the work to execution, they will move between Develop, Launch, Monitor, and Support to ensure that the items required as part of the delivery of the work are completed in a timely fashion. When an item is decommissioned (may be the whole product, a feature, or a component), teams may use items from the other phases to support the retirement.

Categories

The following categories were defined for the corporate PDLC:

• New Product – brand new product being developed
• Feature Release - new functionality added to an existing product
• Enhancement - change to functionality or to technology such as cloud migration for an existing product
• Decommission/End of Life – shutting down a product or component of a product
• Pricing Change – modification to pricing for a product or component of a product
• Small Enhancement / Break-fix / Configuration Change – small change to a product or component of a product

Banno utilizes all of these to some degree:

• New Product - products that are unique and bring broad, new functionality eg Banno Business, Unified Identity Service
• Feature Release - releases that include major new features and new feature areas. Our monthly release cycle fits in this category
• Enhancement - minor changes deployed outside of the normal release cycle
• Decommission/End of Life – shutting down a product or component of a product
• Pricing Change - revision of pricing - for example the development of All-in Banno pricing
• Small Enhancement / Break-fix / Configuration Change - updates that don’t follow our standard project process – quick, small updates

Rigor

The PDLC was created with levels of rigor to provide structure for the amount of work to be completed to support the category of work being done. For reference, the corporate PDLC rigor chart is included under each stage of a project.

• Required – these items are mandatory. Teams should be able to evidence these items in the event of a review of the work. Items that are required are subject to audit and/or regulatory review.
• Evaluate – these items should be evaluated by the team based on the level of work being completed to determine if the item should be completed as part of the effort. Teams should be able to explain why or why not the decision was made to complete the item.
• Optional – these items may be completed at the discretion of the team, but are not required. Teams should review the items to determine if they should be included based on the work being performed.

Idea

For Banno, the Idea stage of the process begins with an Insight. We are constantly exposed to new project opportunities, customer needs, sales requests, and our own ideas. These are collected from numerous sources and recorded in Jira as an Insight.

When sufficient information is available to warrant a project, an Initiative should be created in Jira and the project should be prioritized in the backlog. In order to properly prioritize several of the items, below may need to be roughly completed.

Business Case

The corporate business case is used to determine the amount of rigor required for any project. For Banno, typically projects will fit into the Feature Release or the Enhancement categories. If desired, a Business Plan may be completed for larger efforts that consist of multiple projects and/or an entirely new line of work (generally we will not do this). The business case for a project is typically contained within the opening of a Product Brief.

Strategic Alignment

As part of our prioritization we evaluate a project’s strategic alignment with the following:

• Group priorities
• Team priorities
• Corporate top 20
• Customer contracts

Items that are of sufficient priority should be collected to form a possible project. Statements of strategic alignment are typically contained within the Business Case or in the opening of a Product Brief.

Risk Assessment (NEW)

Both business and technical risks should be identified and evaluated. These should be contained within a Product Brief.

Define Success Criteria

Success criteria will be used at the end of the effort to determine whether the work has been fulfilled. Having this agreement upfront minimizes questions of what is “done” at the end of a project. This should be described in the Product Brief.

Items to consider:

• How will we measure success?
• What are key metrics?
• What is done?
• What is minimum viable/marketable/lovable product?

This preliminary work helps to define if and when we should complete a project. When the priority of a project in the backlog is high enough, it should be moved to Next status and discussed in a product team priority meeting. When approved by the product team it should be added to the Roadmap agenda document. At this point the project will be evaluated for the roadmap in an exploration meeting.

R - Required     E - Evaluate     O - Optional

Plan

The initial planning work happens prior to a project being placed on the roadmap in the Idea stage. When a project is roadmapped and due to start, additional teams should be engaged. In this phase the product brief is finalized with additional information to help make a final decision in the exploration meeting.

Roadmap prioritization

A project is ready to be placed on the roadmap when an initial statement of priority and business purpose can be well articulated, the project has an Initiative, and has been discussed in a product team priority meeting.

User/Job stories

User/job stories help to define the scope of the work, who will be using it, and what needs to be accomplished when utilizing a product or feature. Completing these early will help to define the scope of the project functionality.

Build/Buy/Partner

Should we be building this? Should we be partnering with a third party? Should we be purchasing a solution? What is the risk if we do nothing? Answering these questions will help us to understand the affiliated costs, risks, and benefits of a project. Most Banno projects will result in either a build or a do nothing decision.

Deployment model

Deployment process is managed by Banno tech ops and engineering teams. The product team should evaluate if a change might be needed, but most likely we will follow our standard deployment procedure for all projects.

Architecture Assessment

Early assessment of architecture needs is critical. Architectural decisions are made by Banno tech ops. If there might be an architectural impact this team should be consulted.

Shared Service Engagement

Teams should review shared services to ensure that there is not already a solution that can meet the needs of the project. An example is how Banno utilizes ENS for sending emails.

Compliance

If the project has compliance considerations, now would be a good time to reach out to our compliance person. When in doubt, it’s better to ask than violate a regulation we don’t understand. Reach out to Todd and he’ll put you in touch with the right people.

Security Review

Check in #org-security if there are possible security implications to the project.

Operational Impact Assessment

Perform an assessment of what will be required for operational readiness in the Launch phase. Identify the work that will be required to complete the operational readiness reviews.

• Complementary areas to consider:
  • Sales
  • Marketing
  • Implementation
  • Support/Operations
  • Other inter-departmental groups
• Other items to consider:
  • Operating Agreement document
  • Product documentation to be created and/or updated
  • Communications and training
  • Mock installations
  • What is needed to support the launch
  • How will it be monitored
  • Etc.

Plan to ensure that integration partners are ready to support the deliverable from an operational perspective.

Exploration meeting

Prior to the Exploration meeting, a product brief draft should be completed. This enables us to discuss each of the items described in the Idea stage and make a decision about the viability of the project. This meeting meets the Team Assessment requirement as well as validation of the initial timeline of the corporate PDLC. After the Exploration meeting the project will be added to the roadmap.

Some projects may require engagement with the JHA Legal for contract updates, the New Product Committee, and the Pricing Committee. Most projects do not have this requirement.

R - Required     E - Evaluate     O - Optional

Develop

This stage follows the standard Banno SDLC. Post exploration meeting design, analysts, and engineers should be engaged in Discovery to prepare for regular project meetings - this is the key time to complete the Requirements/QA sheet. Some projects may be split into multiple phases with API and client project components and/or multiple milestones.

Mid-project Ops check in

Approximately halfway through the project a check in should be scheduled with Operations to discuss any updates for what might be needed to launch the feature. Review the impact assessment, and update as needed.

R - Required     E - Evaluate     O - Optional

Launch

Sales Readiness

Before a feature can be shipped and supported, it must also be ready for the sales team to demo. For Banno this happens in our Garden/Bloom environments. All features must be configured for this institution prior to launch.

It is also helpful if there are known items sales should be able to communicate to detail

• FAQs and talking points
• Common RFP questions a project might answer
• Recorded demo of the functionality

Operational Readiness & Documentation

Getting operational readiness approval from the Ops team centers on the customer-facing product collateral on the Knowledge Base, the internal-facing Ops docs (also on the Knowledge Base), and the customer-facing User Guides that the Enterprise Content Services (ECS) team writes for Help Center. These documentation needs must be completed prior to launching a new product or feature. If the docs are not yet complete, then the Ops team does not have the details necessary to support customers and ensure smooth adoption.

Working with documentation stakeholders

Product managers should work with the following stakeholders to ensure that required documentation has been reviewed, approved, and published:

• Product collateral: ECS (Skylar Monsees and/or Tali Utz) and our Knowledge Base TPM (Wes Iliff, on the Go-to-Market team)
• User guides for Help Center: Leaning on product managers as primary subject matter experts (SMEs), Skylar Monsees and Tali Utz from the ECS team write the Banno User Guides that are published on Help Center. In general, they will need access and necessary permissions / entitlements, etc. to test features on all environments affected — Online, Mobile, Banno Admin, and (if applicable) other JH products that customers must directly configure.
• Ops docs: While product managers provide an initial draft of the Ops doc, ensuring that the doc is accurate and complete typically requires assistance from engineers, analysts, and the Operations team. When the Ops doc is complete, the product manager should work with Implementation or Support leads to test the configuration process on Garden, Dev Bank, Episys, or the appropriate environment (if there are special circumstances).

Important The current process for looping in documentation stakeholders is a manual lift. Using the #org-documentation Slack channel, product managers should facilitate communication, any meetings, and documentation reviews (whether conducted asynchronously or in a meeting) with the GTM team, ECS team, and the Knowledge Base TPM. … Note that the GTM team is working with the ECS team, Product leadership, and Operations leadership to finalize an improved, Jira-based workflow for creating Required Documentation tickets that will get routed to the appropriate stakeholders. Product leadership, Operations leadership, and team GTM are also collaborating to determine the best time and approach to cover Content Kickoff needs — i.e. during one of the bi-monthly Ops Readiness meetings or, if necessary, during a separate meeting.

Handoff Meeting

Prior to shipping a feature, a handoff meeting should be scheduled with Operations, sales, marketing, education. This meeting consists of:

• Discussion of the problem/solution
• Demo of the functionality on Garden or Optimus.
• Communicate any known issues
• Walk through ops doc and answer any questions
• Go through communication plan: Banno Statement, one-off email, etc
• What’s the implementation cycle/timeline

Launch Plan & Communication

When shipping a feature, the feature description should be completed in the release notes, Banno Statement, and any other channels where appropriate. For most features this will be sufficient.

R - Required     E - Evaluate     O - Optional

Monitor

Banno tech-ops handles monitoring for our production and UAT systems.

Review ROI / Usage / Client adoption

After shipping new functionality it’s a good idea to evaluate adoption, return on investment, and any metrics described in project plans. This can be done shortly after initial launch and then repeated in the future. Tracking this type of adoption ensures new work is delivering anticipated value.

Track Defects

Defects are logged in team Jira boards and via customer issues from the Support and Implementation teams.

Collect Client Feedback

Client feedback is crucial for determining if value has been provided and what should be included in future improvements. Banno tracks via IdeaLab, customer cases from Support, and our Advisory Board.

R - Required     E - Evaluate     O - Optional

Support

Bug Fixes

Although there are many ways a bug can be found and reported, it will ultimately come back to the backlog and require analysis, refinement, and planning. Some bugs are handled purely on engineering backlogs. Some require larger efforts and will be prioritized in the product backlog.

Operational Readiness

In this stage operational readiness consists primarily of answering questions and ensuring documentation is accurate for long-term support by operational teams and sales.

R - Required     E - Evaluate     O - Optional

End of Life

Considerations for a product’s End of Life should be made early on in order to ease the transition for stakeholders. When possible, consider end of life as a part of the full lifecycle even though it may not happen for many years. There is a corporate sunset process that should be followed when making the determination to stop supporting a product.

Customer Impact Analysis and Strategy

It is important to understand who is using the product or component and what the impact of sunsetting it will do to them. Are there alternatives that can meet the need? What JHA product/service replaces the one being decommissioned?

The remainder of the EOL process should follow the stages described in the corporate PDLC:

• Stakeholder communication
• Technical debt cleanup
• New product committee engagement
• Legal engagement
• Client communication

R - Required     E - Evaluate     O - Optional