Enterprise IT Projects: Agile Release Planning Strategies

Enterprise IT Projects: Agile Release Planning Strategies
1
Introduction
Organizational initiatives are delivered using projects and programs. Information
Technology (IT) projects play a key role in delivering business capabilities to customers to
sustain and competitive advantage and improve operational excellence. Project sponsors and
organizational leaders plan with an end in mind to reap the value and benefit of the investments
made on multiple strategic initiatives. They always look for the planned date of product delivery
and the end date of the project completion. Project Management Institute’s structured predictive
model provides a scientific way of planning and executing projects. It is a matured model
adopted globally and practiced by millions of professionals for more than three decades. This
model's biggest drawback is a lack of flexibility and adoptability to the rapidly changing market,
technology, and customer needs.
Agile is the new trend in the industry and takes momentum in every business and functional
units within an organization and makes inroads to multiple industries. It is changing the way IT
projects are managed and delivered. Many professional organizations endorsed the agile
Manifesto declared in the year 2001. The agile framework was the best alternative to the
structured and sequential predictive method to deliver IT projects. Since then, multiple
competing frameworks have emerged to deliver products and services using agile methodologies.
In a nutshell, agile helps organizations in three ways:
1) Continuous Delivery: Instead of waiting for the final product in perfect condition,
customers get incremental product features based on their priority, urgency, and need.
2) Customer Focus: The product owner is part of the project team, collaborate to prioritize
the customer needs, and deliver desired outcomes.

2
3) Continuous Improvement: Since the outcomes are delivered incrementally at a regular
cadence, any failure in incremental features is not a final product's total failure. It is
reversible with less rework, recoverable with minimal effort, and provides multiple
opportunities to improve the delivery process and outcomes.
The agile framework provides a way of dividing large customer needs into granular
requirements, and customers get faster value based on their needs and priority. The product
owner's input is critical in prioritizing the scope items, and product releases are done using
continuous planning models. Agile release planning is complicated when multiple agile teams
work together to deliver combined capabilities, and the scope for a release span across multiple
business functions, processes, and systems. This paper presents agile release planning models for
large global organizations delivering business capabilities using IT projects.
Enterprise IT Projects
Before discussing the agile delivery model, it is good to understand different types of IT
projects in medium to large organizations. In a typical software delivery model, projects are
divided into multiple releases, and product owners play a crucial role in identifying needs and
priorities for a software release. They are also responsible for prioritizing and planning for the
releases. The releases can be categorized into four different types based on the delivery model,
impacts, and dependencies. Figure 1 shows typical enterprise release types and their
characteristics.

3
Figure 1. Enterprise Release Types
Product-Standalone and Functional-Standalone types of projects have a minimal or low
impact on an organization's dependent process, systems, or other business functions. These teams
can operate independently to deliver the best to meet the organization's strategic goals and
objectives by optimizing resources and needs. Due to the product or service's standalone nature,
the team is empowered to make the decisions. It provides an opportunity to automate and
simplify many project delivery and release processes. Integrating with the delivery process helps
to release the product faster with a less or no-touch governance model. The agile team and
product owners handle most of these release management activities. Enterprise Release
management plays minimal oversight and governance role in the release.
Product-Integrated and Functional-Integrated releases have a high level of cross-
functional, internal, and external processes and system dependencies. Any failure in the release
may impact multiple business functions, and a few may be business-critical. Failure is not an

4
option on IT projects delivering integrated business capabilities, products, and services. Many
tools are available in the market to automate the end-to-end process. However, there are practical
challenges in implementing full delivery and release automation. It is primarily due to multiple
release governance checkpoints, adhering to regulatory and policy compliance processes, and
impacting dependent project releases. The release schedule needs to be planned out by
connecting with all the stakeholders, identify the scope for upcoming and future releases. The
planned release schedule reduces the risk of business disruption and mitigates the high cost of
failure.
Expected vs. Planned Release
An organization's strategy, objectives, and alignment with various programs and projects
are the most critical factors contributing to project success. An organization’s investment could
be divided into four major categories. Run-the-business, Change-the-business, Grow-the-
business, and Transform-the-business. Depending upon the category, the budget, duration,
dependencies, exposure, and project complexity may vary. Project sponsors plan the value
realization as one of their key goals, and the “Expected Delivery Date” (EDD) is finalized based
on the strategic goals and objectives. Project sponsors consider market conditions, future
business strategy, and commitment to customers to decide the expected delivery date for the new
products, capabilities, or services.
The Product Owner provides the product vision and roadmap, which includes the
expected product release dates. It identifies the need, target customers, the value and benefit of
using the product. It also has a very high-level scope, cost, and the expected time of product
delivery. The agile delivery planning process is an activity to convert the project sponsor's
Expected Delivery Date (EDD) into the project’s Planned Delivery Date (PDD). It involves

5
multiple estimation levels and refinements to deliver the product closer to the project sponsor's
expected date.
Agile Release Planning
Agile delivery planning should be carried at multiple layers to ensure that the estimated
delivery aligns with expected product delivery. Since planning is an iterative process, the project
manager should allocate a few iterations dedicated to Project Planning. Figure 2 shows project
delivery components to translate product vision and roadmap into the project delivery schedule.
It starts with the product vision and roadmap, alignment with the organization’s strategic
objectives. It is further divided into high-level capabilities and features. The third level shows the
components required to build the business capabilities, products, or services. The fourth level
shows additional non-functional capabilities to meet industry standards, regulatory guidelines,
and product differentiation to gain competitive advantage.
During the initial project Planning-iterations (PI), the project team reviews all the
delivery components listed in Figure 2 to understand and uncover the customer’s implicit needs
and develop an estimated release schedule to deliver the final product. The layered planning
sessions should include cross-functional teams, project leaders, and business leaders at varying
levels to understand and agree on project scope and delivery schedule.

6
Figure 2. Project Delivery Components
Some agile project managers start product build iterations first, without spending enough
time on upfront planning sessions. Since the framework is flexible and adoptable to change, the
PM can start the project fast and course correct mistakes and changes along the way. This
approach will lead to product redesign, architecture rework, increased delivery time, increased
cost, and decreased customer satisfaction in the initial product delivery. Planning-iterations helps
to build the project team's trust, increase customer satisfaction, and gain a competitive advantage
in the marketplace.
During the project's initiation and planning stages, the project team has only a high-level
scope, expected delivery time, product roadmap, key milestones, and project cost. The First-layer
delivery planning involves expanding the high-level scope listed in the product vision into high-

7
level capabilities and its identifying impact on dependent business processes, systems, and
project portfolios. The project team also identifies tools, technologies, people, skills, and other
infra resources to deliver the final product and project. At this stage, the project team comes up
with a high-level strategy and approach to delivering the capabilities. The planning involves
choosing the right product (In-house development, SaaS, or both), the right teams (Full-time
employees, consultants, a mix of both consultants, shared resources), and team size (Number of
agile teams, team structure, team size). At the end of the first session, the project team will have
a high-level approach to deliver the scope, resources and skills, and dependent program or
project dependencies on other organization's initiatives. Also, at this point, the project team
should identify and communicate the alignment between project goals, objectives with the
organization’s strategy. These Planning-iterations should have a team that includes Project
sponsor(s), dependent functional and business owners, Enterprise Portfolio Manager (EPM),
Product owners, and business and solution architects. This team has a broader understanding of
the organization strategy, business domain, business process, technology, and systems. At the
end of the First-layer planning iterations, the project team will understand the detailed project
scope and resources to finalize the initial Estimated Delivery Date with delivery schedules. The
project manager should compare the initial Estimated Delivery Date with the project sponsors'
Expected Delivery Date and identify the gap. If the product delivery gap is high, the planned
scope, budget, and resources need to be adjusted to meet the project delivery expectations with
the project sponsors and stakeholders.

8
Figure 3. Planning Iterations and Accuracy
Once the project team knows, "What needs to be done to deliver the product," the next
Planning iterations sessions focus on "How to build the product?”. The Second-layer involves
detailing the process and technology solution and its dependencies. It needs additional product
workshops and planning sessions with the product owner, business and technical architects,
technical leads, and cross-functional teams to identify technical and process impacts and finalize
the solution to deliver the product's target state with all the committed capabilities. In this
process, the project manager needs to focus on business processes, technology, and solution.
This includes finalizing any new development tools and required training to build the product
without spending additional time once the development starts. The development and testing
team should be part of the sessions to get inputs on the various decisions to build and test the
product. At the end of this session, the project team will have a more accurate estimated date,
detailed release schedule, and delivery cadence. The second level of reconciliation and

9
refinement validates the initial estimated delivery dates and provides an opportunity to adjust the
scope further to reach a realistic and achievable delivery date. During this session, project
owners and project managers identify additional opportunities to improve delivery schedules to
optimize customer value by improving the business process. For business and technical
architects, this session also provides an opportunity to leverage reusable business and technical
services to reduce delivery time and providing additional value to the organization. There should
be a read-out session with all the project sponsors and business stakeholders on Second-layer
session outcomes detailing the rationale behind the planned delivery dates and release schedules.
Third-layer planning sessions identify and plan for all non-functional requirements,
including usability, regulatory, policy and standards compliance, security, availability, resiliency,
and product performance requirements. These requirements may not be available in the product
scope; however, the planning process should consider all the needs and resources to make the
product usable and compliant. Some project teams do not include them in the initial planning and
add these requirements in the later stage of the project phase. Include these non-functional
requirements in the early phase of the planning will eliminate extensive rework on architecture,
design. It also guarantees product delivery on time, within budget, and ensures project success.
For example, business-critical products need to comply with Service Level Requirements
(SLA) on performance and availability to perform business transactions. Financial and human
resource applications dealing with sensitive Personally Identifiable Information needs to comply
with regulatory and other compliance standards. Some applications may need to comply with
availability requirements ranging from 99.99% to 99.999%. Performing availability testing
involves a plan to identify specialized teams, tools, and other infrastructure resources. Some of

10
the availability and resiliency testing include shutting down live applications partially or fully to
ensure that the redundant systems take over without any disruption to the business.
Further, this testing can be extended to perform the disaster recovery process if all the
live systems and data are not accessible due to natural calamities or other failures. IT projects
with multiple systems, and process dependencies need to perform end to end testing to ensure
that the final product working with dependent upstream and downstream internal and external
systems. These environments need to be set up, replicating the near-production data and software
to test and certify the product before going live. The project team needs to allocate additional
iterations or sprints to conduct special testing in a dedicated environment using specialized
resources. All these activities need to be performed in coordination with extended teams with
prior planning and communications.
Change Management is one of the essential functions to include in this planning
sessions. It is critical for the project’s success and the customer adoption. The scope of change
management activities varies based on the type of change. The change could be Greenfield,
Incremental or Transitional. A new product released to enable new business capabilities
involves educating the end user about the new feature and usability, and its benefits. This is a
Greenfield type of a change, and relatively easy to implement than training end users to
transition from a legacy to new and improved tools and process. Many years of using a specific
process and tools needs to be transitioned to the new way of working. The learning curve and
adoption is slow and change management team needs to put additional effort and time to train
and support the transition during and after the product is released. A dedicated lean team needs
to perform change management activities to communicate with the customers about the product,
provide the necessary documentation, and conduct webinars and workshops to train the end-

11
users, and provide support for any issues and failures. The change management team will
conduct focused working sessions with selected customers representing various regions, market
segments, or demographics. The agile project team need not be involved directly to this effort.
However, it needs to support the change management team by providing various artifacts, flow,
and process diagrams to the product owners to support this activity. The product owner is a
critical team member to bridge the gap between change management and agile development
teams.
The Third-layer Planning sessions identify additional needs to build and deliver the final
product. This process will also have an opportunity to identify end-to-end project scope,
additional iterations needed to make the product ready for delivery, and further review and
confirm the final Estimated Delivery Date for project completion. These Three-layer iterations
are sequential; however, the iteration can overlap if the next layer teams have enough
information to start their sessions. This approach will help the project manager reduce the total
time to complete all the three-layer iterations.
Agile Delivery Schedule
At the end of three-layer planning sessions, the project team will have more predictable
and achievable project delivery dates and schedules. Since all the sponsors and stakeholders are
part of this process, the project team gets the leadership support to move forward with the project
execution with predictable delivery dates. In the three-layer planning process, the Product
owners and project sponsors will also get visibility on risks and challenges associated with the
project delivery. The three-layer planning sessions helps build confidence and trust with the
project sponsors, product owners, and the leadership team. Once all the Planning iterations are

12
complete, the team should be prepared and ready to deliver the outcomes and value at a regular
cadence.
Figure. 4 below shows some of the release strategies and options. Build and test (BT) are
done by one or more dedicated teams focusing on delivering value to customers at a regular
cadence. The project manager will work with the product owner and the delivery team to
prioritize, groom, estimate, and commit the scope before the sprint starts. Agile ceremonies will
help the teams to streamline the process and to ensure continuous delivery without any
disruptions. The Project Manager can schedule additional Business, Process, and Technical
(BPT) sessions in parallel with the build iterations to incorporate any changes during the
delivery.
Figure 4. Agile Release Strategies
Four different strategies can be used to plan and schedule product delivery. The first
strategy is to divide the overall scope equally and plan to release the product at a regular

13
cadence. The release could be monthly, quarterly, or after every sprint. The timeline could vary
based on the sprint cycle (1-4 weeks) and additional hardening sessions needed to deliver the
final product. The advantage is setting early expectations about the product release schedule,
value, and benefits to the customers. This release strategy will also help agile teams plan for the
release and communicate with dependent teams and a clear product roadmap, features, and
release schedules.
The second strategy is based on priority and impact on the business and customers. PO
can identify and release a group of epics and features of high value and high impact items first
and then focus on low priority items. This strategy helps the business to gain a competitive
advantage and provide benefits to customers faster. The release schedule and frequency can vary
based on the priority items in this option's scope and capacity.
Product success depends on how well and how fast customers use the product after the
release. Change Management plays a crucial role in making the customer adoption success. The
third option is to align based on customer adoption and customer success. This can be done in
phases like Crawl, Walk, Run, and Fly. Project sponsors and product owners can measure the
adoption rate and customer success to prioritize and plan the release schedules. Each and phase
will have multiple iterations based on priority and need.
The fourth option is purely based on risks and impact on the product or project success.
Risk management is a continuous process, and the identified risks need to be managed carefully
without impacting the final outcome. This option provides a way of learning from releasing low-
risk items and improve the process to take on high-risk items in the later releases. For example,
in a massive cloud migration project, the project team can identify and choose less critical
business applications to migrate first in the early releases. At the end of the first release, the

14
project teams can learn technical and process issues and improve subsequent project releases.
This option is best suited for projects that depend on new technology, new customer base, new
business process, and the impact is high and across multiple business units.
Agile Release Planning - Best Practices
Planning Iterations: Agile provides opportunities to learn from failures and improve
continually. Three Layer planning sessions will bring all stakeholders on the same page on
product vision, product roadmap, project delivery, and strategic alignment on investments. Also,
the Three Layer planning approach will flush out the Product scope (Capabilities and Features)
and Project delivery scope (Non-functional requirements). It also helps to identify implicit
product and project needs to meet the customer needs and expectations. It also gives greater
clarity on priority on various product features and sets release expectations to primary
stakeholders and schedule impact on dependent stakeholders. Figure 5 shows the importance of s
and how it impacts the project delivery.
Figure 5. Project Iterations and Project Outcomes

15
The project team, which spends upfront planning, architecture, user experience, and other
delivery scopes, can deliver high-value items in each iteration. The product will be accepted and
adopted faster, and the project team will be spending less time rework and re-redesign the
product during the development and release phase of the project. The project team which did not
have the required time spent on panning workshops still can deliver the outcomes for every
sprint. However, the team needs to do many rework and changes to meet the implicit customer
needs and expectations.
Release Metrics: Capture critical metrics associated with releases to analyze pre and post-
delivery related issues and success. The metrics will help identify deficiencies in the process,
tools, or people and improve product and project delivery.
Change Management: The goal and strategic objectives focus on faster adoption of the
customers' new product. The organization also needs to see tangible benefits by gaining a
competitive advantage in the marketplace or operational excellence. Upfront planning on change
management activities will ensure initial and sustained success and help achieve the intended
project and product value.
Summary
This paper discussed IT release planning challenges and strategies to plan and schedule
the agile release process. It also discussed the benefits of Three-layer Planning sessions to
improve product delivery and project success.

16
Kaali Dass is a leading Portfolio and Project Consultant at Wipro,
Inc. He has over 25 years of information technology experience
spanning multiple industries. He has extensive experience in
managing domestic and international projects including Cisco
Systems, and LinkedIn. He is also an Adjunct Professor at USC
Bovard College, and serves as Director of IT – Digital
Transformation and IT Security at NC PMI.
Kaali has a PhD in IT Management, an MBA in Finance, and holds
professional certifications including PMP, CISM, CSQE, ITIL, and
CSM.
His focus areas are Portfolio management, agile project
management, IT strategy and planning, enterprise architecture, data
architecture, data security, and data analytics.
He can be reached at dassconnect@gmail.com or https://www.linkedin.com/in/kaalidass

Enterprise IT Projects: Agile Release Planning Strategies

Enterprise IT Projects: Agile Release Planning Strategies

Enterprise IT Projects: Agile Release Planning Strategies

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Similar a Enterprise IT Projects: Agile Release Planning Strategies

Similar a Enterprise IT Projects: Agile Release Planning Strategies(20)

Mais de Kaali Dass PMP, PhD.

Mais de Kaali Dass PMP, PhD.(18)

Último

Último(20)

Enterprise IT Projects: Agile Release Planning Strategies