Assess Your IT Financial Management Maturity Effectively

Influence your organization’s strategic direction.

Analyst Perspective

Make better informed data-driven business decisions.

Technology has been evolving throughout the years, increasing complexity and investments, while putting more stress on operations and people involved. As an IT leader, you are now entrusted to run your outfit as a business, sit at the executive table as a true partner, and be involved in making decisions that best suit your organization. Therefore, you have an obligation to fulfill the needs of your end customers and live up to their expectations, which is not an easy task.

IT financial management (ITFM) helps you generate value to your organization’s clientele by bringing necessary trade-offs to light, while driving effective dialogues with your business partners and leadership team.

This research will focus on Info-Tech’s approach to ITFM maturity, aiming for a state of continuous improvement, where an organization can learn and grow as it adapts to change. As the ITFM practice matures, IT and business leaders will be able to better understand one another and together make better business decisions, driven by data.

This client advisory presentation and accompanying tool seek to support IT leaders and ITFM practitioners in evaluating and improving their current maturity. It will help document both current and target states as well as prioritize focus areas for improvement.

Bilal Alberto Saab Research Director, IT Financial Management Info-Tech Research Group

Executive Summary

The value of ITFM is undermined

ITFM is often discarded and not given enough importance and relevance due to the operational nature of IT, and the specialized skillset of its people, leading to several problems and challenges, such as:

• Unfamiliarity: Lack of knowledge and understanding related to ITFM maturity.
• Shortsightedness: Randomly reacting to changing circumstances.
• Exchange: Inability to consistently drive dialogues.
• Perception: IT is perceived as a cost center instead of a trustworthy strategic partner.

Constructive dialogues with business partners are not the norm

Business-driven conversations around financials (spending, cost, revenue) are a rarity in IT due to several factors, including:

• Foundation: Weak governance, inadequate skillset, and less than perfect processes and tools.
• Data: Lack of adequate taxonomy/data model, alongside inaccurate data leading to poor reporting and insights.
• Language: Lack of a common vocabulary across the organization.
• Organization culture: No alignment, alongside minimal communication and collaboration between IT and business partners.

Follow Info-Tech’s approach to move up the ITFM maturity ladder

Mature your ITFM practice by activating the means to make informed business decisions.

Info-Tech’s methodology helps you move the dial by focusing on three maturity focus areas:

• Build an ITFM Foundation
• Manage and Monitor IT Spending
• Bridge the Language Barrier

Info-Tech Insight

Influence your organization’s strategic direction by maturing your ITFM practice.

What is ITFM?

ITFM is not just about finance.

• ITFM has evolved from traditional budgeting, accounting, and cost optimization; however, it is much more than those activities alone.
• It starts with understanding the financial implications of technology by adopting different perspectives to become adept in communicating with various stakeholders, including finance, business partners, IT managers, and your CEO.
• Armed with this knowledge, ITFM helps you address a variety of questions, such as:
  • How are technology funds being spent?
  • Which projects is IT prioritizing and why?
  • What are the resources needed to speed IT delivery?
  • What’s the value of IT within the organization?
• ITFM’s main objective is thus to improve decision-making capabilities by facilitating communication between IT leaders and stakeholders, while enabling a customer focus attitude throughout the organization.

“ITFM embeds technology in financial management practices. Through cost, demand, and value, ITFM brings technology and business together, forging the necessary relationships and starting the right conversations to enable the best decisions for the organization.”
– Monica Braun, Research Director, Info-Tech Research Group

Your challenge

IT leaders struggle to articulate and communicate business value.

• IT spending is often questioned by different stakeholders, such as business partners and various IT business units. These questions, usually resulting from shifts in business needs, may revolve around investments, expenditures, services, and speed to market, among others. While IT may have an idea about its spending habits, aligning it to the business strategy may prove difficult.
• IT staff often does not have access to, or knowledge of, the business model and its intricacies. In an operational environment, the focus tends to be on technical issues rather than overall value.
• People tend to fear what they do not know. Some business managers may not be comfortable with technology. They do not recognize the implications and ramifications of certain implementations or understand the related terminology, which puts a strain on any conversation.

“Value is not the numbers you visualize on a chart, it’s the dialogue this data generates with your business partners and leadership team.”
– Dave Kish, Practice Lead, Info-Tech Research Group

Technology is constantly evolving

Increasing IT spending and decision-making complexity.

Common obstacles

IT leaders are not able to have constructive dialogues with their stakeholders.

• The way IT funds are spent has changed significantly, moving from the purchase of discrete hardware and software tools to implementing data lakes, cloud solutions, the metaverse and blockchain. This implies larger investments and more critical decisions. Conversations around interoperability, integration, and service-based solutions that focus more on big-picture architecture than day-to-day operations have become the norm.
• Speed to market is now a survival criterion for most organizations, requiring IT to shift rapidly based on changing priorities and customer expectations. This leads to the need for greater financial oversight, with the CFO as the gatekeeper. Today’s IT leaders need to possess both business and financial management savvy to justify their spending with various stakeholders.
• Any IT budget increase is tied to expectations of greater value. Hence, the compelling demands for IT to prove its worth to the business. Promoting value comes in two ways: 1) objectively, based on data, KPIs, and return on investment; and 2) subjectively, based on stakeholder satisfaction, alongside relationships. Building trust, credibility, and confidence can go a long way.

In a technology-driven world, advances come at a price. With greater spending required, more complex and difficult conversations arise.

Constructive dialogues are key

You don’t know what you don’t know.

• IT, being historically focused on operations, has become a hub for technically savvy personnel. On the downside, technology departments are often alien to business, causing problems such as:
  • IT staff have no knowledge of the business model and lack customer focus.
  • Business is not comfortable with technology and related jargon.
• The lack of two-way communication and business alignment is hence an important ramification. If the business does not understand technology, and IT does not speak in business terms, where does that lead us?
• Poor data quality and governance practices, alongside overly manual processes can only exasperate the situation.

IT Spending Survey

79% of respondents believe that decisions taking too long to make is either a significant or somewhat of a challenge (Flexera 2022 Tech Spend Pulse; N=501).

81% of respondents believe that ensuring spend efficiency (avoiding waste) is either a challenge or somewhat of a challenge (Flexera 2022 Tech Spend Pulse; N=501).

ITFM is trailing behind

IT leaders must learn to speak business.

In today’s world, where organizations are driving customer experience through technology investments, having a seat at the table means IT leaders must be well versed in business language and practice, including solid financial management skills.

However, IT staff across all industries aren’t very confident in how well IT is doing in managing its finances. This becomes evident after looking at three core processes:

• Demonstrating IT’s value to the business.
• Accounting of costs and budgets.
• Optimizing costs to gain the best return on investment.

Recent data from 4,137 respondents to Info-Tech’s IT Management & Governance Diagnostic shows that while most IT staff feel that these three financial management processes are important, notably fewer feel that IT management is effective at executing on them.

IT leadership’s capabilities around fundamental cost data capture appear to be lagging, not to mention the essential value-added capabilities around optimizing costs and demonstrating IT’s contribution to business value.

Source: Info-Tech Research Group, IT Management & Governance Diagnostic, 2023.

Info-Tech’s approach

We take a holistic approach to ITFM and support you throughout your maturity journey.

The Info-Tech difference:

• Info-Tech has a methodology and set of tools that will help assess your ITFM maturity and take the first step in developing an improvement plan. We have identified three maturity focus areas:
  • Build an ITFM Foundation
  • Manage and Monitor IT Spending
  • Bridge the Language Barrier
• No matter where you currently stand in your ITFM practice, there is always room for improvement. Hence, a maturity assessment should be viewed as a self-improvement tool, which is only valuable if you are willing to act on it.

Note: See Appendix A for maturity level definitions and descriptions.

Climb the maturity ladder

By growing along three maturity focus areas.

Info-Tech identified three maturity focus areas, each containing three levers.

Identify where you stand across the nine maturity levers, detect the gaps, and determine your priorities as a first step to develop an improvement plan.

Note: See Appendix B for maturity level definitions and descriptions per lever.

Key project deliverables

Each step of this activity is accompanied by supporting deliverables to help you accomplish your goals.

IT Financial Management Maturity Assessment Report Template

IT Financial Management Maturity Assessment Tool

Measure the value of this activity

Reach your 12-month maturity target.

• Determine your 12-month maturity target, identify your gaps, and set your priorities.
• Use the ITFM maturity assessment to kickstart your improvement plan by developing actionable initiatives.
• Implement your initiatives and monitor your progress to reach your 12-month target.

Build your improvement plan and implement your initiatives to move the dial and climb the maturity ladder.

Info-Tech offers various levels of support to best suit your needs

Step 1

Prepare for the ITFM maturity assessment

Content Overview

1. Identify your stakeholders
2. Set the context
3. Determine the methodology
4. Identify assessment takers

This step involves the following participants:

• CIO/IT director
• CFO/finance director
• IT finance lead
• IT audit lead
• Other IT management

1. Prepare to take the ITFM maturity assessment

3 hours

Input: Understanding your context, objectives, and methodology

Output: ITFM maturity assessment stakeholders and their objectives, ITFM maturity assessment methodology, ITFM maturity assessment takers

Materials: 1a. Prepare for Assessment tab in the ITFM Maturity Assessment Tool

Participants: CIO/IT director, CFO/finance director, IT finance lead, IT audit lead, Other IT management

1. Identify your stakeholders and document it in the ITFM Maturity Assessment Tool (see next slides). We recommend having representatives from different business units across the organization, most notably IT, IT finance, finance, and IT audit.
2. Set the context with your stakeholders and document it in the ITFM Maturity Assessment Tool. Discuss the reason behind taking the ITFM maturity assessment among the various stakeholders. Why do each of your stakeholders want to take the assessment? What are their main objectives? What would they like to achieve?
3. Determine the methodology and document it in the ITFM Maturity Assessment Tool. Discuss how you want to go about taking the assessment with your stakeholders. Do you want to have representatives from each business unit take the assessment individually, then share and discuss their findings? Do you prefer forming a working group with representatives from each business unit and go through the assessment together? Or does any of your stakeholders have a different suggestion? You will have to consider the effort, skillset, and knowledge required.
4. Identify the assessment takers and document it in the ITFM Maturity Assessment Tool. Determine who will be taking the assessment (specific names of stakeholders). Consider their availability, knowledge, and skills.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Document your stakeholders, objectives, and methodology

Excel Workbook: ITFM Maturity Assessment Tool – Prepare for Assessment worksheet

Refer to the example and guidelines below on how to document stakeholders, objectives, and methodology (table range: columns B to G and rows 8 to 15).

Review the following in the Excel workbook as per guidelines:

1. Navigate to the 1a. Prepare for Assessment tab.
2. Enter the full names and job titles of the ITFM maturity assessment stakeholders.
3. Document the maturity assessment objective of each of your stakeholders.
4. Document the agreed-upon methodology.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Document your assessment takers

Excel Workbook: ITFM Maturity Assessment Tool – Prepare for Assessment worksheet

Refer to the example and guidelines below on how to document assessment takers (table range: columns B to E and rows 18 to 25).

Review the following in the Excel workbook as per guidelines:

1. Navigate to the 1a. Prepare for Assessment tab.
2. Enter the full name of each assessment taker, along with the job title of the stakeholder they are representing.

Download the IT Financial Management Maturity Assessment Tool

Step 2

Take the ITFM maturity assessment

Content Overview

1. Complete the survey
2. Review your assessment results
3. Determine your priorities

This step involves the following participants:

• CIO/IT director
• CFO/finance director
• IT finance lead
• IT audit lead
• Other IT management

2. Take the ITFM maturity assessment

3 hours

Input: Understanding of your ITFM current state and 12-month target state, ITFM maturity assessment results

Output: ITFM current- and target-state maturity levels, average scores, and variance, ITFM current- and target-state average scores, variance, and priority by maturity focus area and maturity lever

Materials: 1b. Glossary, 2a. Assess ITFM Foundation, 2b. Assess Mngt. & Monitoring, 2c. Assess Language, and 3. Assessment Summary tabs in the ITFM Maturity Assessment Tool

Participants: CIO/IT director, CFO/finance director, IT finance lead, IT audit lead, Other IT management

1. Complete the survey: select the current and target state of each statement – refer to the glossary as needed for definitions of key terms – in the ITFM Maturity Assessment Tool (see next slides). There are three tabs (one per maturity focus area) with three tables each (nine maturity levers). Review and discuss statements with all assessment takers: consider variations, differing opinions, and reach an agreement on each statement inputs.
2. Review assessment results: navigate to the Assessment Summary tab in the ITFM maturity assessment tool (see next slides) to view your results. Review and discuss with all assessment takers: consider any shocking output and adjust survey input if necessary.
3. Determine your priorities: decide on the priority (Low/Medium/High) by maturity focus area and/or maturity lever. Rank your maturity focus area priorities from 1 to 3 and your maturity lever priorities from 1 to 9. Consider the feasibility in terms of timeframe, effort, and skillset required, positive and negative impacts on business and technology, likelihood of failure, and necessary approvals. Document your priorities in the ITFM maturity assessment tool (see next slides).
   Review and discuss priorities with all assessment takers: consider variations, differing opinions, and reach an agreement on each priority.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Complete the survey

Excel workbook: ITFM Maturity Assessment Tool – Survey worksheets

Refer to the example and guidelines below on how to complete the survey.

Review the following in the Excel workbook as per guidelines:

1. Navigate to the survey tabs: 2a. Assess ITFM Foundation, 2b. Assess Management and Monitoring, and 2c. Assess Language.
2. Select the appropriate current and target maturity levels.
3. Add any notes or comments per ITFM maturity statement where necessary or helpful.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Review your overall result

Excel Workbook: ITFM Maturity Assessment Tool – Assessment Summary worksheet

Refer to the example and guidelines below on how to review your results.

Review the following in the Excel workbook as per guidelines:

1. Navigate to tab 3. Assessment Summary.
2. Review your overall current state and target state result along with the corresponding variance.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Set your priorities

Excel Workbook: ITFM Maturity Assessment Tool – Assessment Summary worksheet

Refer to the example and guidelines below on how to review your results per maturity focus area and maturity lever, then prioritize accordingly.

Review the following in the Excel workbook as per guidelines:

1. Navigate to tab 3. Assessment Summary.
2. Review your current-state and target-state result along with the corresponding variance per maturity focus area and maturity lever.
3. Select the appropriate priority for each maturity focus area and maturity lever.
4. Enter a unique rank for each maturity focus area (1 to 3).
5. Enter a unique rank for each maturity lever (1 to 9).

Download the IT Financial Management Maturity Assessment Tool

Step 3

Communicate your ITFM maturity results

Content Overview

1. Review your assessment charts
2. Customize the assessment report
3. Communicate your results

This step involves the following participants:

• CIO/IT director
• CFO/finance director
• IT finance lead
• IT audit lead
• Other IT management

3. Communicate your ITFM maturity results

3 hours

Input: ITFM maturity assessment results

Output: Customized ITFM maturity assessment report

Materials: 3. Assessment Summary tab in the ITFM Maturity Assessment Tool, ITFM Maturity Assessment Report Template

Participants: CIO/IT director, CFO/finance director, IT finance lead, IT audit lead, Other IT management

1. Review assessment charts: navigate to the Assessment Summary tab in the ITFM Maturity Assessment Tool (see next slides) to view your results and related charts.
2. Edit the report template: complete the template based on your results and priorities to develop your customized ITFM maturity assessment report (see next slide).
3. Communicate results: communicate and deliberate the assessment results with assessment takers at a first stage, and with your stakeholders at a second stage. The objective is to agree on next steps, including developing an improvement plan.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Review assessment charts

Excel Workbook: ITFM Maturity Assessment Tool – Assessment Summary worksheet

Refer to the example below on charts depicting different views of the maturity assessment results across the three focus areas and nine levers.

From the Excel workbook, after completing your potential initiatives and filling all related entries in the Outline Initiatives tab:

1. Navigate to tab 3. Assessment Summary.
2. Review each of the charts.
3. Navigate back to the survey tabs to examine, drill down, and amend individual entries as you deem necessary.

Download the IT Financial Management Maturity Assessment Tool

TEMPLATE & EXAMPLE

Customize your report

PowerPoint presentation: ITFM Maturity Assessment Report Template

Refer to the example below on slides depicting different views of the maturity assessment results across the three maturity focus areas and nine maturity levers.

Slide 6: Edit levels based on your assessment results. Copy and paste the appropriate maturity level definition and description from slide 4.

Slide 7: Copy related charts from the assessment summary tab in the Excel workbook and remove the chart title. You can use the “Outer Offset: Bottom” shadow under shape effects on the chart.

Slide 8: Copy related charts from the assessment summary tab in the Excel workbook and remove the chart title and legend. You can use the “Outer Offset: Center” shadow under shape effects on the chart.

From the ITFM Maturity Assessment Report Template:

1. Edit the report based on your results found in the assessment summary tab of the Excel workbook (see previous slide).
2. Review slides 6 to 8 and bring necessary adjustments.

Download the IT Financial Management Maturity Assessment Report Template

Make informed business decisions

Take a holistic approach to ITFM.

• A thorough understanding of your technology spending in relation to business needs and drivers is essential to make informed decisions. As a trusted partner, you cannot have effective conversations around budgets and cost optimization without a solid foundation.
• It is important to realize that ITFM is not a one-time exercise, but a continuous, sustainable process to educate (teach, mentor, and train), increase transparency, and assign responsibility.
• Move up the ITFM maturity ladder by improving across three maturity focus areas:
  • Build an ITFM Foundation
  • Manage and Monitor IT Spending
  • Bridge the Language Barrier

What’s Next?

Communicate your maturity results with stakeholders and develop an actionable ITFM improvement plan.

And remember, having informed discussions with your business partners and stakeholders, where technology helps propel your organization forward, is priceless!

IT Financial Management Team

	Dave Kish Practice Lead, ITFM Practice Info-Tech Research Group
	Jennifer Perrier Principal Research Director, ITFM Practice Info-Tech Research Group
	Angie Reynolds Principal Research Director, ITFM Practice Info-Tech Research Group
	Monica Braun Research Director, ITFM Practice Info-Tech Research Group
	Rex Ding Research Specialist, ITFM Practice Info-Tech Research Group
	Aman Kumari Research Specialist, ITFM Practice Info-Tech Research Group

Research Contributors and Experts

	Amy Byalick Vice President, IT Finance Info-Tech Research Group	Amy Byalick is an IT Finance practitioner with 15 years of experience supporting CIOs and IT leaders elevating the IT financial storytelling and unlocking insights. Amy is currently working at Johnson Controls as the VP, IT Finance, previously working at PepsiCo, AmerisourceBergen, and Jacobs.
	Carol Carr Technical Counselor, Executive Services Info-Tech Research Group
	Scott Fairholm Executive Counselor, Executive Services Info-Tech Research Group
	Gokul Rajan Executive Counselor, Executive Services Info-Tech Research Group
	Allison Kinnaird Practice Lead, Infrastructure & Operations Info-Tech Research Group
	Isabelle Hertanto Practice Lead, Security & Privacy Info-Tech Research Group

Related Info-Tech Research

	Achieve IT Spending Transparency Mature your ITFM practice by activating the means to make informed business decisions.
	Build Your IT Cost Optimization Roadmap Develop an IT cost optimization strategy based on your specific circumstances and timeline.

Bibliography

Eby, Kate. “The Complete Guide to Organizational Maturity: Models, Levels, and Assessments.” Smartsheet, 8 June 2022. Web.

“Financial Management Maturity Model.” National Audit Office, n.d. Accessed 28 Apr. 2023.

“ITFM/TBM Program Maturity Guide.” Nicus Software, n.d. Accessed 28 Apr. 2023.

Jouravlev, Roman. "Service Financial Management: ITIL 4 Practice Guide." Axelos, 2020.

McCarthy, Seamus. “Financial Management Maturity Model: A Good Practice Guide.” Office of the Comptroller & Auditor General, 26 June 2018. Web.

“Principles for Effective Risk Data Aggregation and Risk Reporting.“ Bank for International Settlements, Jan. 2013. Web.

“Role & Influence of the Technology Decision-Maker 2022.” Foundry, 2022. Web.

Stackpole, Beth. “State of the CIO, 2022: Focus turns to IT fundamentals.” CIO, 21 March 2022. Web.

“Tech Spend Pulse.” Flexera, 2022. Web.

Appendix A

Definition and Description
Per Maturity Level

ITFM maturity levels and definitions

Appendix B

Maturity Level Definitions and Descriptions
Per Lever

Establish your ITFM team

Maturity focus area: Build an ITFM foundation.

Set up your governance structure

Maturity focus area: Build an ITFM foundation

Adopt ITFM processes and tools

Maturity focus area: Build an ITFM foundation.

Standardize your taxonomy and data model

Maturity focus area: Manage and monitor IT spending.

Identify, gather, and prepare your data

Maturity focus area: Manage and monitor IT spending.

Analyze your findings and develop your reports

Maturity focus area: Manage and monitor IT spending.

Communicate your IT spending

Maturity focus area: Bridge the language barrier.

Educate the masses

Maturity focus area: Bridge the language barrier.

Influence your organization’s culture

Maturity focus area: Bridge the language barrier.

Manage Requirements in an Agile Environment

Agile and requirements management are complementary, not competitors

Analyst's Perspective

The temptation when moving to Agile is to deemphasize good requirements practices in favor of perceived speed. If you're not delivering on the needs of the business then you have failed, regardless of how fast you've gone.

Delivery in Agile doesn't mean you stop needing solid business analysis. In fact, it's even more critical, to ensure your products and projects are adding value. With the rise of Agile, the role of the business analyst has been misunderstood.

As a result, we often throw out the analysis with the bathwater, thinking we'll be just fine without analysis, documentation, and deliberate action, as the speed and dexterity of Agile is enough.

Consequently, what we get is wasted time, money, and effort, with solutions that fail to deliver value, or need to be re-worked to get it right.

The best organizations find balance between these two forces, to align, and gain the benefits of both Agile and business analysis, working in tandem to manage requirements that bring solutions that are "just right".

Vincent Mirabelli
Principal Research Director, Applications Delivery and Management
Info-Tech Research Group

EXECUTIVE BRIEF

Executive Summary

Your Challenge

The process of navigating from waterfall to Agile can be incredibly challenging. And even more problematic; how do you operate your requirements management practices once there? Since there traditionally isn't a role for a business analyst; the traditional keeper of requirements. it isn't like switching on a light.

You likely find yourself struggling to deliver high quality solutions and requirements in Agile. This is a challenge for many organizations, regardless of how long they've leveraged Agile.

But you aren't here for assurances. You're here for answers and help.

Common Obstacles

many organizations and teams face is that there are so busy doing Agile that they fail to be Agile.

Agile was supposed to be the saving grace of project delivery but is misguided in taking the short-term view of "going quickly" at the expense of important elements, such as team formation and interaction, stakeholder engagement and communication, the timing and sequencing of analysis work, decision-making, documentation, and dealing with change.

The idea that good requirements just happen because you have user stories is wrong. So, requirements remain superficial, as you "can iterate later"…but sometimes later never comes, or doesn't come fast enough.

Organizations need to be very deliberate when aligning their Agile and requirements management practices. The work is the same. How the work is done is what changes.

Info-Tech's Approach

Infotech's advice? Why choose? Why have to pick between traditional waterfall and Agile delivery? If Agile without analysis is a recipe for disaster, Agile with analysis is the solution. And how can you leverage the Info-Tech approach to align your Agile and requirements management efforts into a powerful combination?

Manage Requirements in an Agile Environment is your guide.

Use the contents and exercises of this blueprint to gain a shared understanding of the two disciplines, to find your balance in your approach, to define your thresholds, and ultimately, to prepare for new ways of working.

Info-Tech Insight

Agile and requirements management are complementary, not competitors.

The temptation when moving to Agile is to deemphasize good requirements practices in favor of perceived speed. If you're not delivering on the needs of the business, then you have failed, regardless of how fast you've gone.

Insight summary

Overarching insight

Agile and requirements management are complementary, not competitors.

The temptation when moving to Agile is to deemphasize good requirements practices in favor of perceived speed. If you're not delivering on the needs of the business, then you have failed, regardless of how fast you've gone

Phase 1 insight

• The purpose of requirements in waterfall is for approval. The purpose in Agile is for knowledge management, as Agile has no memory.
• When it comes to the Agile manifesto, "over" does not mean "instead of".
• In Agile, the what of business analysis does doesn't change. What does change is the how and when that work happens.

Phase 2 insight

• Understand your uncertainties; it's a great way to decide what level of Agile (if any) is needed.
• Finding your "Goldilocks" zone will take time. Be patient.

Phase 3 insight

• Right-size your governance, based on team dynamics and project complexity. A good referee knows when to step in, and when to let the game flow.
• Agile creates a social contract amongst the team, and with their leaders and organization.
• Documentation needs to be valuable. Do what is acceptable and necessary to move work to future steps. Not documenting also comes with a cost, but one you pay in the future. And that bill will come due, with interest (aka, technical debt, operational inefficiencies, etc.).
• A lack of acceptable documentation makes it more difficult to have agility. You're constantly revalidating your current state (processes, practices and structure) and re-arguing decisions already made. This slows you down more than maintaining documentation ever would.

Phase 4 insight

• Making Agile predictable is hard, because people are not predictable; people are prone to chaos.

There have been many challenges with waterfall delivery

It turns out waterfall is not that great at reducing risk and ensuring value delivery after all

• Lack of flexibility
• Difficulty in measuring progress
• Difficulties with scope creep
• Limited stakeholder involvement
• Long feedback loops

48%
Had project deadlines more than double

85%
Exceeded their original budget by at least 20%

25%
At least doubled their original budget

Source: PPM Express.

Agile was meant to address the shortcomings of waterfall

The wait for solutions was too long for our business partners. The idea of investing significant time, money, and resources upfront, building an exhaustive and complete vision of the desired state, and then waiting months or even years to get that solution, became unpalatable for them. And rightfully so. Once we cast a light on the pains, it became difficult to stay with the status quo. Given that organizations evolve at a rapid pace, what was a pain at the beginning of an initiative may not be so even 6 months later.

Agile became the answer.

Since its' first appearance nearly 20 years ago, Agile has become the methodology of choice for a many of organizations. According to the 15th Annual State of Agile report, Agile adoption within software development teams increased from 37% in 2020 to 86% in 2021.

Adopting Agile led to challenges with requirements

Requirements analysis, design maturity, and management are critical for a successful Agile transformation.

"One of the largest sources of failure we have seen on large projects is an immature Agile implementation in the context of poorly defined requirements."
– "Large Scale IT Projects – From Nightmare to Value Creation"

"Requirements maturity is more important to project outcomes than methodology."
– "Business Analysis Benchmark: Full Report"

"Mature Agile practices spend 28% of their time on analysis and design."
– "Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings"

"There exists a Requirements Premium… organizations using poor practices spent 62% more on similarly sized projects than organizations using the best requirements practices."
– "The Business Case for Agile Business Analysis" - Requirements Engineering Magazine

Strong stakeholder satisfaction with requirements results in higher satisfaction in other areas

N= 324 small organizations from Info-Tech Research Group's CIO Business Vision diagnostic.

Note: High satisfaction was classified as organizations with a score greater or equal to eight and low satisfaction was every organization that scored below eight on the same questions.

Info-Tech's Agile requirements framework

Agile requirements are a balancing act

Collaboration

Many subject matter experts are necessary to create accurate requirements, but their time is limited too.

Communication

Stakeholders should be kept informed throughout the requirements gathering process, but you need to get the right information to the right people.

Documentation

Recording, organizing, and presenting requirements are essential, but excessive documentation will slow time to delivery.

Control

Establishing control points in your requirements gathering process can help confirm, verify, and approve requirements accurately, but stage gates limit delivery.

What changes for the business analyst?

In Agile, the what of business analysis does not change.

What does change is the how and when that work happens.

Business analysts need to focus on six key elements when managing requirements in Agile.

• Team formation and interaction
• Stakeholder engagement and communication
• The timing and sequencing of their work
• Decision-making
• Documentation
• Dealing with change

Where does the business analysis function fit on an Agile team?

Team formation is key, as Agile is a team sport

A business analyst in an Agile team typically interacts with several different roles, including:

• The product owner,
• The Sponsor or Executive
• The development team,
• Other stakeholders such as customers, end-users, and subject matter experts
• The Design team,
• Security,
• Testing,
• Deployment.

How we do our requirements work will change

• Team formation and interaction
• Stakeholder engagement and communication
• The timing and sequencing of their work
• Decision-making
• Documentation
• Dealing with change

As a result, you'll need to focus on;

• Emphasizing flexibility
• Enabling continuous delivery
• Enhancing collaboration and communication
• Developing a user-centered approach

Get stakeholders on board with Agile requirements

1. Stakeholder feedback and management support are key components of a successful Agile Requirements.
2. Stakeholders can see a project's progression and provide critical feedback about its success at critical milestones.
3. Management helps teams succeed by trusting them to complete projects with business value at top of mind and by removing impediments that are inhibiting their productivity.
4. Agile will bring a new mindset and significant numbers of people, process, and technology changes that stakeholders and management may not be accustomed to. Working through these issues in requirements management enables a smoother rollout.
5. Management will play a key role in ensuring long-term Agile requirements success and ultimately rolling it out to the rest of the organization.
6. The value of leadership involvement has not changed even though responsibilities will. The day-to-day involvement in projects will change but continual feedback will ultimately dictate the success or failure of a project.

Measuring your success

Tracking metrics and measuring your progress

As you implement the actions from this Blueprint, you should see measurable improvements in;

• Team and stakeholder satisfaction
• Requirements quality
• Documentation cost

Without sacrificing time to delivery

Info-Tech's methodology for Agile requirements

Blueprint tools and templates

Key deliverable:

Agile Requirements Playbook

A practical playbook for aligning your teams and articulating the guidelines for managing your requirements in Agile

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Documentation Calculator

A tool to help you answer the question: What is the right level of Agile requirements documentation for my organization?

Agile Requirements Assessment

Establishes your current maturity level, defines your target state, and supports planning to get there.

Agile Requirements Workbook

Supporting tools and templates in advancing your Agile requirements practice, to be used with the Agile Requirements Blueprint and Playbook.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks used throughout all four options

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Guided Implementation

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is 10 calls over the course of 4 to 6 months.

Framing Agile and Business Analysis

Phase 1

Framing Agile and Business Analysis

This phase will walk you through the following activities:

• EXERCISE: What do Agile and requirements mean in your organization?
• ASSESSMENT: Agile requirements assessment
• KEY DELIVERABLE: Agile Requirements Playbook

This phase involves the following participants:

• Business analyst and project team
• Stakeholders
• Sponsor/Executive

Managing Requirements in an Agile Environment

Step 1.1

Understand the benefits and limitations of Agile and business analysis

Activities

1.1.1 Define what Agile and business analysis mean in your organization

This step involves the following participants:

• Business analyst and project team
• Sponsor/Executive

Outcomes of this step

• Recognize the benefits and detriments of both Agile and business analysis

Framing Agile and Business Analysis

There have been many challenges with waterfall delivery

It turns out waterfall is not that great at reducing risk and ensuring value delivery after all

• Lack of flexibility
• Difficulty in measuring progress
• Difficulties with scope creep
• Limited stakeholder involvement
• Long feedback loops

48%
Had project deadlines more than double

85%
Exceeded their original budget by at least 20%

25%
At least doubled their original budget

Source: PPM Express.

Business analysis had a clear home in waterfall

Business analysts had historically been aligned to specific lines of business, in support of their partners in their respective domains. Somewhere along the way, the function was moved to IT. Conceptually this made sense, in that it allowed BAs to provide technical solutions to complex business problems. This had the unintended result of lost domain knowledge, and connection to the business.

It all starts with the business. IT enables business goals. The closer you can get to the business, the better.

Business analysts were the main drivers of helping to define the business requirements, or needs, and then decompose those into solution requirements, to develop the best option to solve those problems, or address those needs. And the case for good analysis was clear. The later a poor requirement was caught, the more expensive it was to fix. And if requirements were poor, there was no way to know until much later in the project lifecycle, when the cost to correct them was exponentially higher, to the tune of 10-100x the initial cost.

Adapted from PPM Express. "Why Projects Fail: Business Analysis is the Key".

Agile was meant to address the shortcomings of waterfall

The wait for solutions was too long for our business partners. The idea of investing significant time, money, and resources upfront, building an exhaustive and complete vision of the desired state, and then waiting months or even years to get that solution became unpalatable for them. And rightfully so. Once we cast a light on the pains, it became difficult to stand pat in the current state. And besides, organizations evolve at a rapid pace. What was a pain at the beginning of an initiative may not be so even six months later.

Agile became the answer.

Since its first appearance nearly 20 years ago, Agile has become the methodology of choice for a huge swathe of organizations. According to the 15th Annual State of Agile report, Agile adoption within software development teams increased from 37% in 2020 to 86% in 2021.

To say that's significant is an understatement.

The four core values of Agile helped shift focus

According to the Agile manifesto, "We value. . ."

"…while there is value in the items on the right, we value the items on the left more."

Source: Agilemanifesto, 2001

Agile has made significant inroads in IT and beyond

94% of respondents report using Agile practices in their organization

according to Digital.AI's "The 15th State of Agile Report"

That same report notes a steady expansion of Agile outside of IT, as other areas of the organization seek to benefit from increased agility and responsiveness, including Human Resources, Finance and Marketing.

While it addressed some problems…

"Agile projects are 37% faster to market than [the] industry average"

(Requirements Engineering Magazine, 2017)

• Business requirements documents are massive and unreadable
• Waterfall erects barriers and bottlenecks between the business and the development team
• It's hard to define the solution at the outset of a project
• There's a long turnaround between requirements work and solution delivery
• Locking in requirements dictates an often-inflexible solution. And the costs to make changes tend to add up.

…Implementing Agile led to other challenges

Adopting Agile led to challenges with requirements

Requirements analysis, design maturity, and management are critical for a successful Agile transformation.

"One of the largest sources of failure we have seen on large projects is an immature Agile implementation in the context of poorly defined requirements."
– BCG, 2015

"Requirements maturity is more important to project outcomes than methodology."
– IAG Consulting, 2009.

"Mature Agile practices spend 28% of their time on analysis and design."
– InfoQ, 2017."

"There exists a Requirements Premium… organizations using poor practices spent 62% more on similarly sized projects than organizations using the best requirements practices."
– Requirements Engineering Magazine, 2017

Strong stakeholder satisfaction with requirements results in higher satisfaction in other areas

N= 324 small organizations from Info-Tech Research Group's CIO Business Vision diagnostic.

Note: High satisfaction was classified as organizations with a score greater or equal to eight and low satisfaction was every organization that scored below eight on the same questions.

Agile is being misinterpreted as an opportunity to bypass planning and analysis activities

Agile is a highly effective tool.

This isn't about discarding Agile. It is being used for things completely outside of what was originally intended. When developing products or code, it is in its element. However, outside of that realm, its being used to bypass business analysis activities, which help define the true customer and business need.

Business analysts were forced to adapt and shift focus. Overnight they morphed into product owners, or no longer had a place on the team. Requirements and analysis took a backseat.

The result?

Increased rework, decreased stakeholder satisfaction, and a lot of wasted money and effort.

"Too often, the process of two-week sprints becomes the thing, and the team never gets the time and space to step back and obsess over what is truly needed to delight customers."
Harvard Business Review, 9 April 2021.

Info-Tech Insight

Requirements in Agile are the same, but the purpose of requirements changes.

• The purpose of requirements in waterfall is for stakeholder approval.
• The purpose of requirements in Agile is knowledge management; to maintain a record of the current state.

Many have misinterpreted the spirit of Agile and waterfall

The stated principles of waterfall say nothing of how work is to be linear.

Source: Royce, Dr. Winston W., 1970.

For more on Agile methodology, check out Info-Tech's Agile Research Centre

How did the pendulum swing so far?

Shorter cycles of work made requirements management more difficult. But the answer isn't to stop doing it.

Organizations went from engaging business stakeholders up front, and then not until solution delivery, to forcing those partners to give up their resources to the project. From taking years to deliver a massive solution (which may or may not even still fit the need) to delivering in rapid cycles called sprints.

This tug-of-war is costing organizations significant time, money, and effort.

Your approach to requirements management needs to be centered. We can start to make that shift by better aligning our Agile and business analysis practices. Outside of the product space, Agile needs to be combined with other disciplines (Harvard Business Review, 2021) to be effective.

Agility is important. Though it is not a replacement for approach or strategy (RCG Global Services, 2022). In Agile, team constraints are leveraged because of time. There is a failure to develop new capabilities to address the business needs Harvard Business Review, 2021).

Agility needs analysis.

Agile requirements are a balancing act

Collaboration

Many subject matter experts are necessary to create accurate requirements, but their time is limited too.

Communication

Stakeholders should be kept informed throughout the requirements gathering process, but you need to get the right information to the right people.

Documentation

Recording, organizing, and presenting requirements are essential, but excessive documentation will slow time to delivery.

Control

Establishing control points in your requirements gathering process can help confirm, verify, and approve requirements accurately, but stage gates limit delivery.

Start by defining what the terms mean in your organization

We do this because there isn't even agreement by the experts on what the terms "Agile" and "business analysis" mean, so let's establish a definition within the context of your organization.

1.1.1 What do Agile and business analysis mean in your organization?

Estimated time: 30 Minutes

1. Explore the motivations behind the need for aligning Agile with business analysis. Are there any current challenges related to outputs, outcomes, quality? How can the team and organization align the two more effectively for the purposes of requirements management?
2. Gather the appropriate stakeholders to discuss their definition of the terms "Agile" and "business analysis" It can be related to their experience, practice, or things they've read or heard.
3. Brainstorm and document all shared thoughts and perspectives.
4. Synthesize those thoughts and perspectives into a shared definition of each term, of a sentence or two.
5. Revisit this definition as needed, and as your Agile requirements efforts evolve.

Input

• Challenges and experiences/perspectives related to Agile and business requirements

Output

• A shared definition of Agile and business analysis, to help guide alignment on Agile requirements management

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Build your Agile Requirements Playbook

Keep the outcomes of this blueprint in a single document

Share at the beginning of a new project, as part of team member onboarding, and revisit as your practice matures.

Your Agile Requirements Playbook will include

• Your shared definition of Agile and business analysis for your organization
• The Agile Requirements Maturity Assessment
• A Methodology Selection Matrix
• Agile requirements RACI
• A defined Agile requirements process
• Documentation Calculator
• Your Requirements Repository Information
• Capability Gap List (from current to target state)
• Target State Improvement Roadmap and Action Plan

Step 1.2

Align Agile and Business Analysis Within Your Organization

Activities

1.2.1 Assess your Agile requirements maturity

This step involves the following participants:

• Business Analyst and Project Team
• Stakeholders
• Sponsor/Executive

Outcomes of this step

• Complete the Agile Requirements Maturity Assessment to establish your current and target states

Framing Agile and Business Analysis

Consider the question: "Why Agile?"

What is the driving force behind that decision?

There are many reasons to leverage the power of Agile within your organization, and specifically as part of your requirements management efforts. And it shouldn't just be to improve productivity. That's only one aspect.
Begin by asking, "Why Agile?" Are you looking to improve:

• Time to market
• Team engagement
• Product quality
• Customer satisfaction
• Stakeholder engagement
• Employee satisfaction
• Consistency in delivery of value
• Predictably of your releases

Or a combination of the above?

Info-Tech Insight

Project delivery methodologies aren't either/or. You don't have to be 100% waterfall or 100% Agile. Select the right approach for your project, product, or service.

In the end, your business partners don't want projects delivered faster, they want value faster!

For more on understanding Agile, check out the Implement Agile Practices That Work Blueprint

Responses to a 2019 KPMG survey:

13% said that their top management fully supports Agile transformation.

76% of organizations did not agree that their organization supports Agile culture.

62% of top management believe Agile has no implications for them.

What changes for the business analyst?

Business analysts need to focus on six key elements when managing requirements in Agile.

• Team formation and interaction
• Stakeholder engagement and communication
• The timing and sequencing of their work
• Decision-making
• Documentation
• Dealing with change

In Agile, the what of business analysis does not change.

What does change is the how and when that work happens.

1.2.1 Assess your Agile requirements maturity

1.2.1 Assess your Agile requirements maturity

Estimated time: 30 Minutes

1. Using the Agile Requirements Maturity Assessment, gather all appropriate stakeholders, and discuss and score the current state of your practice. Scoring can be done by:
1. Consensus: Generally better with a smaller group, where the group agrees the score and documents the result
2. Average: Have everyone score individually, and aggregate the results into an average, which is then entered.
3. Weighted Average: As above, but weight the individual scores by individual or line of business to get a weighted average.
2. When current state is complete, revisit to establish target state (or hold as a separate session) using the same scoring approach as in current state.
1. Recognize that there is a cost to maturity, so don't default to the highest score by default.
2. Resist the urge at this early stage to generate ideas to navigate from current to target state. We will re-visit this exercise in Phase 4, once we've defined other pieces of our process and practice.

Input

• Participant knowledge and experience

Output

• A current and target state assessment of your Agile requirements practice

Materials

• Agile Requirements Maturity Assessment

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Tailoring Your Approach

Phase 2

This phase will walk you through the following activities:

• Selecting the appropriate delivery methodology
• Managing your requirements backlog
• Tracing from business need to user story

This phase involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Managing Requirements in an Agile Environment

Step 2.1

Confirm the Best-fit Approach for Delivery

Activities

2.1.1 Confirm your methodology

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• A review of potential delivery methodologies to select the appropriate, best-fit approach to your projects

Confirming you're using the best approach doesn't have be tricky

Selecting the right approach (or confirming you're on the right track) is easier when you assess two key inputs to your project; your level of certainty about the solution, and the level of complexity among the different variables and inputs to your project, such as team experience and training, the number of impacted stakeholders or context. lines of business, and the organizational

Solution certainty refers to the level of understanding of the problem and the solution at the start of the project. In projects with high solution certainty, the requirements and solutions are well defined, and the project scope is clear. In contrast, projects with low solution certainty have vague or changing requirements, and the solutions are not well understood.

Project complexity refers to the level of complexity of the project, including the number of stakeholders, the number of deliverables, and the level of technical complexity. In projects with high complexity, there are many stakeholders with different priorities, many deliverables, and high technical complexity. In contrast, projects with low complexity have fewer stakeholders, fewer deliverables, and lower technical complexity.

"Agile is a fantastic approach when you have no clue how you're going to solve a problem"

• Ryan Folster, Consulting Services Manager, Business Analysis, Dimension Data

Use Info-Tech's methodology selection matrix

Waterfall methodology is best suited for projects with high solution certainty and high complexity. This is because the waterfall model follows a linear and sequential approach, where each phase of the project is completed before moving on to the next. This makes it ideal for projects where the requirements and solutions are well-defined, and the project scope is clear.

On the other hand, Agile methodology is best suited for projects with low solution certainty. Agile follows an iterative and incremental approach, where the requirements and solutions are detailed and refined throughout the project. This makes it ideal for projects where the requirements and solutions are vague or changing.

Note that there are other models that exist for determining which path to take, should this approach not fit within your organization.

Use info-tech's-methodology-selection-matrix

Adapted from The Chaos Report, 2015 (The Standish Group)

Download the Agile Requirements Workbook

2.1.1 Confirm your methodology

Estimated time: 30 Minutes

1. Using the Agile Requirements Workbook, find the tab labelled "Methodology Assessment" and answer the questions to establish your complexity and certainty scores, where;

1 = Strongly disagree
2 = Disagree
3 = Neutral
4 = Agree
5 = Strongly agree.

2. In the same workbook, plot the results in the grid on the tab labelled "Methodology Matrix".
3. Projects falling into Green are good fits for Agile. Yellow are viable. And Red may not be a great fit for Agile.
4. Note: Ultimately, the choice of methodology is yours. Recognize there may be additional challenges when a project is too complex, or uncertainty is high.

Input

• Current project complexity and solution certainty

Output

• A clear choice of delivery methodology

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Step 2.2

Manage Your Requirements Backlog

Activities

2.2.1 Create your user stories

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• Understand how to convert requirements into user stories, which populate the Requirements Backlog.

Tailoring Your Approach

There is a hierarchy to requirements

	Higher-level statements of the goals, objectives, or needs of the enterprise. Business requirements focus on the needs of the organization, and not the stakeholders within it.	Defines
		Intended benefits and outcomes
	Statements of the needs of a particular stakeholder or class of stakeholders, and how that stakeholder will interact with a solution.	Why it is needed, and by who
	Describes the characteristics of a solution that meets business requirements and stakeholder requirements. Functional describes the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations. Non-functional represents constraints on the ultimate solution and tends to be less negotiable.	What is needed, and how its going to be achieved

Connect the dots with a traceability matrix

Business requirements describe what a company needs in order to achieve its goals and objectives. Solution requirements describe how those needs will be met. User stories are a way to express the functionality that a solution will provide from the perspective of an end user.

A traceability matrix helps clearly connect and maintain your requirements.

To connect business requirements to solution requirements, you can start by identifying the specific needs that the business has and then determining how those needs can be met through technology or other solutions; or what the solution needs to do to meet the business need. So, if the business requirement is to increase online sales, a solution requirement might include implementing a shopping cart feature on your company website.

Once you have identified the solution requirements, you can then use those to create user stories. A user story describes a specific piece of functionality that the solution will provide from the perspective of a user.

For example, "As a customer, I want to be able to add items to my shopping cart so that I can purchase them." This user story is directly tied to the solution requirement of implementing a shopping cart feature.

Tracing from User Story back up to Business Requirement is essential in ensuring your solutions support your organization's strategic vison and objectives.

Download the Info-Tech Requirements Traceability Matrix

Improve the quality of your solution requirements

A solution requirement is a statement that clearly outlines the functional capability that the business needs from a system or application.

For more on developing high quality requirements, check out the Improve Requirements Gathering Blueprint

Prioritize your requirements

When everything is a priority, nothing is a priority.

Prioritization is the process of ranking each requirement based on its importance to project success. Each requirement should be assigned a priority level. The delivery team will use these priority levels to ensure efforts are targeted toward the proper requirements as well as to plan features available on each release. Use the MoSCoW Model of Prioritization to effectively order your requirements.

The MoSCoW Model of Prioritization

The MoSCoW model was introduced by Dai Clegg of Oracle UK in 1994

(Source: ProductPlan).

Base your prioritization on the right set of criteria

Info-Tech Insight

It is easier to prioritize requirements if they have already been collapsed, resolved, and rewritten. There is no point in prioritizing every requirement that is elicited up front when some of them will eventually be eliminated.

Manage solution requirements in a Product backlog

What is a backlog?

Agile teams are familiar with the use of a Sprint Backlog, but in Requirements Management, a Product Backlog is a more appropriate choice.

A product backlog and a Sprint backlog are similar in that they are both lists of items that need to be completed in order to deliver a product or project, but there are some key differences between the two.

A product backlog is a list of all the features, user stories, and requirements that are needed for a product or project. It is typically created and maintained by the business analyst or product owner and is used to prioritize and guide the development of the product.

A Sprint backlog, on the other hand, is a list of items specifically for an upcoming sprint, which is an iteration of work in Scrum. The Sprint backlog is created by the development team and is used to plan and guide the work that will be done during the sprint. The items in the Sprint backlog are typically taken from the product backlog and are prioritized based on their importance and readiness.

For more on building effective product backlogs, visit Deliver on Your Digital Product Vision

A backlog stores and organizes requirements at various stages

Your backlog must give you a holistic understanding of demand for change in the product.

A well-formed backlog can be thought of as a DEEP backlog

Detailed appropriately: Requirements are broken down and refined as necessary

Emergent: The backlog grows and evolves over time as requirements are added and removed.

Estimated: The effort to deliver a requirement is estimated at each tier.

Prioritized: A requirement's value and priority are determined at each tier.

Adapted from Essential Scrum

Ensure requests and requirements are ready for development

Clearly define what it means for a requirement, change, or maintenance request to be ready for development.

This will help ensure the value and scope of each functionality and change are clear and well understood by both developers and stakeholders before the start of the sprint. The definition of ready should be two-fold: ready for the backlog, and ready for coding.

1. Create a checklist that indicates when a requirement or request is ready for the development backlog. Consider the following questions:
1. Is the requirement or request in the correct format?
2. Does the desired functionality or change have significant business value?
3. Can the requirement or request be reasonably completed within defined release timelines under the current context?
4. Does the development team agree with the budget and points estimates?
5. Is there an understanding of what the requirement or request means from the stakeholder or user perspective?
2. Create a checklist that indicates when a requirement or request is ready for development. Consider the following questions:
1. Have the requirements and requests been prioritized in the backlog?
2. Has the team sufficiently collaborated on how the desired functionality or change can be completed?
3. Do the tasks in each requirement or request contain sufficient detail and direction to begin development?
4. Can the requirement or request be broken down into smaller pieces?

Converting solution requirements into user stories

Define the user

Who will be interacting with the product or feature being developed? This will help to focus the user story on the user's needs and goals.

Create the story

Create the user story using the following template: "As a [user], I want [feature] so that [benefit]."
This helps articulate the user's need and the value that the requirement will provide.

Decompose

User stories are typically too large to be implemented in a single sprint, so they should be broken down into smaller, more manageable tasks.

Prioritize

User stories are typically too large to be implemented in a single sprint, so they should be broken down into smaller, more manageable tasks.

2.2.1 Create your user stories

Estimated time: 60 Minutes

1. Gather the project team and relevant stakeholders. Have access to your current list of solution requirements.
2. Leverage the approach on previous slide "Converting Solution Requirements into User Stories" to generate a collection of user stories.

NOTE: There is not a 1:1 relationship between requirements and user stories.
It is possible that a single requirement will have multiple user stories, and similarly, that a single user story will apply to multiple solution requirements.

Input

• Requirements
• Use Case Template

Output

• A collection of user stories

Materials

• Current Requirements

Participants

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Use the INVEST model to create good user stories

At this point your requirements should be high-level stories. The goal is to refine your backlog items, so they are . . .

Independent: Ideally your user stories can be built in any order (i.e. independent from each other). This allows you to prioritize based on value and not get caught up in sequencing and prerequisites. Negotiable: As per the Agile principle, collaboration over contracts. Your user stories are meant to facilitate collaboration between the developer and the business. Therefore, they should be built to allow negotiation between all parties. Valuable: A user story needs to state the value so it can be effectively prioritized, but also so developers know what they are building. Estimable: As opposed to higher-level approximation given to epics, user stories need more accuracy in their estimates in order to, again, be effectively prioritized, but also so teams can know what can fit into a sprint or release plans. Small: User stories should be small enough for a number of them to fit into a sprint. However, team size and velocity will impact how many can be completed. A general guideline is that your teams should be able to deliver multiple stories in a sprint. Testable: Your stories need to be testable, which means they must have defined acceptance criteria and any related test cases as defined in your product quality standards. Source: Agile For All

Defining Your Requirements Thresholds

Phase 3

Defining Your Requirements Thresholds

This phase will walk you through the following activities:

• Assigning roles and responsibilities optional (Tool: RACI)
• Define your Agile requirements process
• Calculate the cost of your documentation (Tool: Documentation Calculator)
• Define your backlog refinement plan

This phase involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Managing Requirements in an Agile Environment

Step 3.1

Define Project Roles and Responsibilities

Activities

3.1.1 Define your Agile requirements RACI (optional)

3.1.2 Define your Agile requirements process

Defining Your Requirements Thresholds

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• A defined register of roles and responsibilities, along with a defined process for how Agile requirements work is to be done.

Defining Your Requirements Thresholds

Where does the BA function fit on an Agile team?

Team formation is key, as Agile is a team sport

A business analyst in an Agile team typically interacts with several different roles, including the product owner, development team, and many other stakeholders throughout the organization.

• The product owner, to set the priorities and direction of the project, and to gather requirements and ensure they are being met. Often, but not always, the BA and product owner are the same individual.
• The development team, to provide clear and concise requirements that they can use to build and test the product.
• Other stakeholders, such as customers, end-users, and subject matter experts to gather their requirements, feedback and validate the solution.
  • Design, to ensure that the product meets user needs. They may provide feedback and ensure that the design is aligned with requirements.
  • Security, to ensure that the solution meets all necessary security requirements and to identify potential risks and appropriate use of controls.
  • Testing, to ensure that the solution is thoroughly tested before it is deployed. They may create test cases or user scenarios that validate that everything is working as intended.
  • Deployment, to ensure that the necessary preparations have been made, including testing, security, and user acceptance.

Additionally, during the sprint retrospectives, the team will review their performance and find ways to improve for the next sprint. As a team member, the business analyst helps to identify areas where the team could improve how they are working with requirements and understand how the team can improve communication with stakeholders.

3.1.1 (Optional) Define Your Agile Requirements RACI

Estimated Time: 60 Minutes

1. Identify the project deliverables: The first step is to understand the project deliverables and the tasks that are required to complete them. This will help you to identify the different roles and responsibilities that need to be assigned.
2. Define the roles and responsibilities: Identify the different roles that will be involved in the project and their associated responsibilities. These roles may include project manager, product owner, development team, stakeholders, and any other relevant parties.
3. Assign RACI roles: Assign a RACI role to each of the identified tasks. The RACI roles are:
1. Responsible: the person or team who is responsible for completing the task
2. Accountable: the person who is accountable for the task being completed on time and to the required standard
3. Consulted: the people or teams who need to be consulted to ensure the task is completed successfully
4. Informed: the people or teams who need to be informed of the task's progress and outcome
4. Create the RACI chart: Use the information gathered in the previous steps to create a matrix or chart that shows the tasks, the roles, and the RACI roles assigned to each task.
5. Review and refine: Review the RACI chart with the project team and stakeholders to ensure that it accurately reflects the roles and responsibilities of everyone involved. Make any necessary revisions and ensure that all parties understand their roles and responsibilities.
6. Communicate and implement: Communicate the RACI chart to all relevant parties and ensure that it is used as a reference throughout the project. This will help to ensure that everyone understands their role and that tasks are completed on time and to the required standard.

Input

• A list of required tasks and activities
• A list of stakeholders

Output

• A list of defined roles and responsibilities for your project

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

A Case Study in Team Formation

Industry: Anonymous Organization in the Energy sector
Source: Interview

Challenge

Agile teams were struggling to deliver within a defined sprint, as there were consistent delays in requirements meeting the definition of ready for development. As such, sprints were often delayed, or key requirements were descoped and deferred to a future sprint.

During a given two-week sprint cycle, the business analyst assigned to the team would be working along multiple horizons, completing elicitation, analysis, and validation, while concurrently supporting the sprint and dealing with stakeholder changes.

Solution

As a part of addressing this ongoing pain, a pilot program was run to add a second business analyst to the team.

The intent was, as one is engaged preparing requirements through elicitation, analysis, and validation for a future sprint, the second is supporting the current sprint cycle, and gaining insights from stakeholders to refine the requirements backlog.

Essentially, these two were leap-frogging each other in time. At all times, one BA was focused on the present, and one on the future.

Result

A happier team, more satisfied stakeholders, and consistent delivery of features and functions by the Agile teams. The pilot team outperformed all other Agile teams in the organization, and the "2 BA" approach was made the new standard.

Understanding the Agile requirements process

Shorter cycles make effective requirements management more necessary, not less

Short development cycles can make requirements management more difficult because they often result in a higher rate of change to the requirements. In a shorter timeframe, there is less time to gather and verify requirements, leading to a higher likelihood of poor or incomplete requirements. Additionally, there may be more pressure to make decisions quickly, which can lead to less thorough analysis and validation of requirements. This can make it more challenging to ensure that the final solution meets the needs of the stakeholders.
When planning your requirements cycles, it's important to consider;

• Your sprint logistics (how long?)
• Your release plan (at the end of every sprint, monthly, quarterly?)
• How the backlog will be managed (as tickets, on a visual medium, such as a Kanban board?)
• How will you manage communication?
• How will you monitor progress?
• How will future sprint planning happen?

Info-Tech's Agile requirements framework

	Sprint N(-1)	Sprint N	Sprint N(+1)
Changes from waterfall to Agile	Gathering and documenting requirements: Requirements are discovered and refined throughout the project, rather than being gathered and documented up front. This can be difficult for business analysts who are used to working in a waterfall environment where all requirements are gathered and documented before development begins. Prioritization of requirements: Requirements are prioritized based on their value to the customer and the team's ability to deliver them. This can be difficult for business analysts who are used to prioritizing requirements based on the client's needs or their own understanding of what is important.	Defining acceptance criteria: Acceptance criteria are defined for each user story to ensure that the team understands what needs to be delivered. Business analysts need to understand how to write effective acceptance criteria and how to use them to ensure that the team delivers what the customer needs. Supporting Testing and QA: The business analyst plays a role in ensuring that testing (and test cases) are completed and of proper quality, as defined in the requirements.	Managing changing requirements: It is expected that requirements will change throughout the project. Business analysts need to be able to adapt quickly to changing requirements and ensure that the team is aware of the changes and how they will impact the project. Collaboration with stakeholders: Requirements are gathered from a variety of stakeholders, including customers, users, and team members. Business analysts need to be able to work effectively with all stakeholders to gather and refine requirements and ensure that the team is building the right product.

3.1.2 Define your Agile requirements process

Estimated time: 60 Minutes

1. Gather all relevant stakeholders to discuss and define your process for requirements management.
2. Have a team member facilitate the session to define the process. The sample in the Agile Requirements Workbook can be used optionally as a starting point. You can also use any existing processes and procedures as a baseline.
3. Gain agreement on the process from all involved stakeholders.
4. Revisit the process periodically to review its performance and make adjustments as needed.

NOTE: The process is intended to be at a high enough level to leave space and flexibility for team members to adapt and adjust, but at a sufficient depth that everyone understands the process and workflows. In other words, the process will be both flexible and rigid, and the two are not mutually exclusive.

Input

• Project team and RACI
• Existing Process (if available)

Output

• A process for Agile requirements that is flexible yet rigid

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Establish the right level of governance and decision-making

Establishing the right level of governance and decision making is important in Agile requirements because there is a cost to decision making, as time plays an important factor. Even the failure to decide can have significant impacts.

Good governance and decision-making practices can help to minimize risks, ensure that requirements are well understood and managed, and that project progress is tracked and reported effectively.

In Agile environments, this often involves establishing clear roles and responsibilities, implementing effective communication and collaboration practices, and ensuring that decision-making processes are efficient and effective.

Good requirements management practices can help to ensure that projects are aligned with organizational goals and strategy, that stakeholders' needs are understood and addressed, and that deliverables are of high quality and meet the needs of the business.

By ensuring that governance and decision-making is effective, organizations can improve the chances of project success, and deliver value to the business. Risks and costs can be mitigated by staying small and nimble.

Check out Make Your IT Governance Adaptable

Develop an adaptive governance process

Maturing governance is a journey

Organizations should look to progress in their governance stages. Ad-hoc and controlled governance tends to be slow, expensive, and a poor fit for modern practices.

The goal as you progress through your stages is to delegate governance and empower teams to make optimal decisions in real-time, knowing that they are aligned with the understood best interests of the organization.

Automate governance for optimal velocity, while mitigating risks and driving value.

This puts your organization in the best position to be adaptive and able to react effectively to volatility and uncertainty.

Five key principles for building an adaptive governance framework

Delegate and empower

Decision making must be delegated down within the organization, and all resources must be empowered and supported to make effective decisions.

Define outcomes

Outcomes and goals must be clearly articulated and understood across the organization to ensure decisions are in line and stay within reasonable boundaries.

Make risk- informed decisions

Integrated risk information must be available with sufficient data to support decision making and design approaches at all levels of the organization.

Embed / automate

Governance standards and activities need to be embedded in processes and practices. Optimal governance reduces its manual footprint while remaining viable. This also allows for more dynamic adaptation.

Establish standards and behavior

Standards and policies need to be defined as the foundation for embedding governance practices organizationally. These guardrails will create boundaries to reinforce delegated decision making.

Sufficient decision-making power should be given to your Agile teams

Push the decision-making process down to your pilot teams.

• Bring your business stakeholders and subject matter experts together to identify the potential high-level risks.
• Bring your business stakeholders and subject matter experts together to identify the potential high-level risks.
• Discuss with the business the level of risk they are willing to accept.
• Define the level of authority project teams have in making critical decisions.

"Push the decision making down as far as possible, down to the point where sprint teams completely coordinate all the integration, development, and design. What I push up the management chain is risk taking. [Management] decides what level of risk they are willing to take and [they] demonstrate that by the amount of decision making you push down."
– Senior Manager, Canadian P&C Insurance Company, Info-Tech Interview

Step 3.2

Define Your Level of Acceptable Documentation

Activities

3.2.1 Calculate the cost of documentation

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Outcomes of this step

• Quantified cost of documentation produced for your Agile project.

Defining Your Requirements Thresholds

Right-size Your Documentation

Why do we need it, and what purpose does it serve?

Before creating any documentation, consider why; why are you creating documentation, and what purpose is it expected to serve?
Is it:

• … to gain approval?
• … to facilitate decision-making?
• .. to allow the team to think through a challenge or compare solution options?

Next, consider what level of documentation would be acceptable and 'enough' for your stakeholders. Recognize that 'enough' will depend on your stakeholder's personal definition and perspective.
There may also be considerations for maintaining documentation for the purposes of compliance, and auditability in some contexts and industries.
The point is not to eliminate all documentation, but rather, to question why we're producing it, so that we can create just enough to deliver value.

"What does the next person need to do their work well, to gain or create a shared understanding?"
- Filip Hendrickx, Innovating BA and Founder, altershape

Documentation comes at a cost

We need to quantify the cost of documentation, against the expected benefit

All things take time, and that would imply that all things have an inherent cost. We often don't think in these terms, as it's just the work we do, and costs are only associated with activities requiring additional capital expenditure. Documentation of requirements can come at a cost in terms of time and resources. Creating and maintaining detailed documentation requires effort from project team members, which could be spent on other aspects of the project such as development or testing. Additionally, there may be costs associated with storing and distributing the documentation.

When creating documentation, we are making a decision. There is an opportunity cost of investing time to create, and concurrently, not working on other activities. Documentation of requirements can come at a cost in terms of time and resources. Creating and maintaining detailed documentation requires effort from project team members, which could be spent on other aspects of the project such as development or testing. Additionally, there may be costs associated with storing and distributing the documentation.

In order to make better informed decisions about the types, quantity and even quality of the documentation we are producing, we need to capture that data. To ensure we are receiving good value for our documentation, we should compare the expected costs to the expected benefits of a sprint or project.

3.2.1 Calculate the cost of documentation

Estimated time: as needed

1. Use this tool to quantify the cost of creating and maintaining current state documentation for your Agile requirements team. It provides an indication, via the Documentation Cost Index, of when your project is documenting excessively, relative to the expected benefits of the sprint or project.
2. In Step 1, enter the hourly rate for the person (or persons) completing the business analysis function for your Agile team. NB: This does not have to be a person with the title of business analyst. If there are multiple people fulfilling this role, enter the average rate (if their rates are same or similar) or a weighted average (if there is a significant range in the hourly rate)
3. In Step 2, enter the expected benefit (in $) for the sprint or project.
4. In Step 3, enter the total number of hours spent on each task/activity during the sprint or project. Use blank spaces as needed to add tasks and activities not listed.
5. In Step 4, you'll find the Documentation Cost Index, which compares your total documentation cost to the expected benefits. The cell will show green when the value is < 0.8, yellow between 0.8 and 1, and red when >1.
6. Use the information to plan future sprints and documentation needs, identify opportunities for improvement in your requirements practice, and find balance in "just enough" documentation.

Input

• Project team and RACI
• Existing Process (if available)

Output

• A process for Agile requirements that is flexible yet rigid

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Lack of documentation also comes at a cost

Lack of documentation can bring costs to Agile projects in a few different ways.

• Onboarding new team members
• Improving efficiency
• Knowledge management
• Auditing and compliance
• Project visibility
• Maintaining code

Info-Tech Insight

Re-using deliverables (documentation, process, product, etc.) is important in maintaining the velocity of work. If you find yourself constantly recreating your current state documentation at the start of a project, it's hard to deliver with agility.

Step 3.3

Manage Requirements as an Asset

Activities

3.3.1 Discuss your current perspectives on requirements as assets

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Outcomes of this step

• Awareness of the value in, and tactics for enabling effective management of requirements as assets

Defining Your Requirements Thresholds

What do we mean by "assets"?

And when do requirements become assets?

In order to delivery with agility, you need to maximize the re-usability of artifacts. These artifacts could take the form of current state documentation, user stories, test cases, and yes, even requirements for re-use.
Think of it like a library for understanding where your organization is today. Understanding the people, processes, and technology, in one convenient location. These artifacts become assets when we choose to retain them, rather than discard them at the end of a project, when we think they'll no longer be needed.
And just like finding a single book in a vast library, we need to ensure our assets can be found when we need them. And this means making them searchable.
We can do this by establishing criteria for requirements and artifact reuse;

• What business need and benefit is it aligned to?
• What metadata needs to be attached, related to source, status, subject, author, permissions, type, etc.?
• Where will it be stored for ease of retrieval?

Info-Tech Insight

When writing requirements for products or services, write them for the need first, and not simply for what is changing.

The benefits of managing requirements as assets

Retention of knowledge in a knowledge base that allows the team to retain current business requirements, process documentation, business rules, and any other relevant information.
A clearly defined scope to reduce stakeholder, business, and compliance conflicts.
Impact analysis of changes to the current organizational assets.

Source: Requirement Engineering Magazine, 2017.

A case study in creating an asset repository

Industry: Anonymous Organization in the Government sector
Source: Interview

Challenge

A large government organization faced a challenge with managing requirements, processes, and project artifacts with any consistency.

Historically, their documentation was lacking, with multiple versions existing in email sent folders and manila folders no one could find. Confirming the current state at any given time meant the heavy lift of re-documenting and validating, so that effort was avoided for an excessive period.

Then there was a request for audit and compliance, to review their existing documentation practices. With nothing concrete to show, drastic recommendations were made to ensure this practice would end.

Solution

A small but effective team was created to compile and (if not available) document all existing project and product documentation, including processes, requirements, artifacts, business cases, etc.

A single repository was built and demonstrated to key stakeholders to ensure it would satisfy the needs of the audit and compliance group.

Result

A single source of truth for the organization, which was;

• Accessible (view access to the entire organization).
• Transparent (anyone could see and understand the process and requirements as intended).
• A baseline for continuous improvement, as it was clear what the one defined "best way" was.
• Current, where no one retained current documentation outside of this library.

3.3.1 Discuss your current perspectives on requirements as assets

Estimated time: 30 Minutes

1. Gather all relevant stakeholder to share perspectives on the use of requirements as assets, historically in the organization.
2. Have a team member facilitate the session. It is optional to document the findings.
3. After looking at the historical use of requirements as assets, discuss the potential uses, benefits, and drawbacks of managing as assets in the target state.

Input

• Participant knowledge and experience

Output

• A shared perspective and history on requirements as assets

Materials

• A method for data capture (optional)

Participants

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Apply changes to baseline documentation

Baseline + Release Changes = New Baseline

• Start from baseline documentation dramatically to reduce cost and risk
• Treat all scope as changes to baseline requirements
• Sum of changes in the release scope
• Sum of changes and original baseline becomes the new baseline
• May take additional time and effort to maintain accurate baseline

What is the right tool?

While an Excel spreadsheet is great to start off, its limitations will become apparent as your product delivery process becomes more complex. Look at these solutions to continue your journey in managing your Agile requirements:

Step 3.4

Define Your Requirements Change Management Plan

Activities

3.4.1 Triage your requirements

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Relevant Stakeholders

Outcomes of this step

• An approach for determining the appropriate level of governance over changes to requirements.

Expect and embrace change

In Agile development, change is expected and embraced. Instead of trying to rigidly follow a plan that may become outdated, Agile teams focus on regularly reassessing their priorities and adapting their plans accordingly. This means that the requirements can change often, and it's important for the team to have a process in place for managing these changes.

A common approach to managing change in Agile is to use a technique called "backlog refinement." Where previously we populated our backlog with requirements to get them ready for development and deployment, this involves regularly reviewing and updating the list of work to be done. The team will prioritize the items on the evolving backlog, and the prioritized items will be worked on during the next sprint. This allows the team to quickly respond to changes in requirements and stay focused on the most important work.

Another key aspect of managing change in Agile is effective communication. The team should have regular meetings, such as daily stand-up meetings or weekly sprint planning meetings, to discuss any changes in requirements and ensure that everyone is on the same page.

Best practices in change and backlog refinement

Communicate

Clearly communicate your change process, criteria, and any techniques, tools, and templates that are part of your approach.

Understand impacts/risks

Maintain consistent control and communication and ensure that an impact assessment is completed. This is key to managing risks.

Leverage tools

Leverage tools when you have them available. This could be a Requirements Management system, a defect/change log, or even by turning on "track changes" in your documents.

Cross-reference

For every change, define the source of the change, the reason for the change, key dates for decisions, and any supporting documentation.

Communicate the reason, and stay on message throughout the change

Leaders of successful change spend considerable time developing a powerful change message: a compelling narrative that articulates the desired end state and makes the change concrete and meaningful to staff. They create the change vision with staff to build ownership and commitment.

• The change message should:
• Explain why the change is needed.
• Summarize the things that will stay the same.
• Highlight the things that will be left behind.
• Emphasize the things that are being changed.
• Explain how the change will be implemented.
• Address how the change will affect the various roles in the organization.
• Discuss staff's role in making the change successful.

The five elements of communicating the reason for the change:

How to make the management of changes more effective

Key decisions and considerations

How will changes to requirements be codified?
How will intake happen?

• What is the submission process?
• Who has approval to submit?
• What information is needed to submit a request?

How will potential changes be triaged and evaluated?

• What criteria will be used to assess the impact and urgency of the potential change?
• How will you treat material and non-material changes?

What is the review and approval process?

• How will acceptance or rejection status be communicated to the submitter?

3.4.1 Triage Your requirements

If there's no material impact, update and move on

Material changes require oversight and approval

Planning Your Next Steps

Phase 4

Planning Your Next Steps

This phase will walk you through the following activities:

• Completing Your Agile Requirements Playbook
• EXERCISE: Capability Gap List

This phase involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Managing Requirements in an Agile Environment

Step 4.1

Preparing New Ways of Working

Activities

4.1.1 Define your communication plan

Planning Your Next Steps

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• Recognize the changes required on the team and within the broader organization, to bring stakeholders on board.

How we do requirements work will change

Change within the team, and in the broader organization

How to build an effective blend Agile and requirements management

Within the team

• Meetings should happen as needed
• Handoffs should be clear and concise
• Interactions should add value
• Stand-ups should similarly add value, and shouldn't be for status updates

Within the organization

• PMO inclusion, to ensure alignment across the organization
• Business/Operating areas, to recognize what they are committing to for time, resources, etc.
• Finance, for how your project or product is funded
• Governance and oversight, to ensure velocity is maintained

"Whether in an Agile environment or not, collaboration and relationships are still required and important…how you collaborate, communicate, and how you build relationships are key."
- Paula Bell, CEO, Paula A. Bell Consulting

Get stakeholders on board with Agile requirements

1. Stakeholder feedback and management support are key components of successful Agile requirements.
2. Stakeholders can see a project's progression and provide critical feedback about its success at critical milestones.
3. Management helps teams succeed by trusting them to complete projects with business value at top of mind and by removing impediments that are inhibiting their productivity.
4. Agile will bring a new mindset and significant amounts of people, process, and technology changes that stakeholders and management may not be accustomed to. Working through these issues in requirements management enables a smoother rollout.
5. Management will play a key role in ensuring long-term Agile requirements success and ultimately rolling it out to the rest of the organization.
6. The value of leadership involvement has not changed even though responsibilities will. The day-to-day involvement in projects will change but continual feedback will ultimately dictate the success or failure of a project.

4.1.1 Define your communication plan

Estimated time: 60 Minutes

1. Gather all relevant stakeholder to create a communication plan for project or product stakeholders.
2. Have a team member facilitate the session.
3. Identify
4. ;
1. Each stakeholder
2. The nature of information they are interested in
3. The channel or medium best to communicate with them
4. The frequency of communication
5. (Optional) Consider validating the results with the stakeholders, if not present.
6. Document the results in the Agile Requirements Workbook and include in Agile Requirements Playbook.
7. Revisit as needed, whether at the beginning of a new initiative, or over time, to ensure the content is still valid.

Input

• Participant knowledge and experience

Output

• A plan for communicating with stakeholders

Materials

• Agile Requirements Workbook

Participants

• Business Analyst(s)
• Project Team

Step 4.2

Develop a Roadmap for Next Steps

Activities

4.2.1 Develop your Agile requirements action plan

4.2.2 Prioritize with now, next, later

This step involves the following participants:

• Business Analyst(s)
• Project Team
• Sponsor/Executive
• Relevant Stakeholders

Outcomes of this step

• A comprehensive and prioritized list of opportunities and improvements to be made to mature the Agile requirements practice.

Planning Your Next Steps

Identify opportunities to improve and close gaps

Maturing at multiple levels

With a mindset of continuous improvement, there is always some way we can get better.

As you mature your Agile requirements practice, recognize that those gaps for improvement can come from multiple levels, from the organizational down to the individual.

Each level will bring challenges and opportunities.

The organization

• Organizational culture
• Organizational behavior
• Political will
• Unsupportive stakeholders

The team

• Current ways of working
• Team standards, norms and values

The individual

• Practitioner skills
• Practitioner experience
• Level of training received

Make sure your organization is ready to transition to Agile requirements management

	Learning: Agile is a radical change in how people work and think. Structured, facilitated learning is required throughout the transformation to help leaders and practitioners go from doing Agile to being Agile.
	Automation: While Agile is tool-agnostic at its roots, Agile work management tools and DevOps inspired SDLC tools that have become a key part of Agile practices.
	Integrated Teams: While temporary project teams can get some benefits from Agile, standing, self-organizing teams that cross business, delivery, and operations are essential to gain the full benefits of Agile.
	Metrics and Governance: Successful Agile implementations require the disciplined use of delivery and operations metrics that support governance focused on developing better teams.
	Culture: Agile teams believe that value is best created by standing, self-organizing cross-functional teams who deliver sustainably in frequent, short increments supported by leaders who coach them through challenges.

Info-Tech Insight

Agile gaps may only have a short-term, perceived benefit. For example, coding without a team mindset can allow for maximum speed to market for a seasoned developer. Post-deployment maintenance initiatives, however, often lock the single developer as no one else understands the rationale for the decisions that were made.

4.2.1 Develop your Agile requirements action plan

Estimated time: 60 Minutes

1. Gather all relevant stakeholder to create a road map and action plan for requirements management.
2. Have a team member facilitate the session using the results of the Agile Requirements Maturity Assessment.
3. Identify gaps from current to future state and brainstorm possible actions that can be taken to address those gaps. Resist the urge to analyze or discuss the feasibility of each idea at this stage. The intent is idea generation.
4. When the group has exhausted all ideas, the facilitator should group like ideas together, with support from participants. Discuss any ideas that are unclear or ambiguous.
5. Document the results in the Agile Requirements Workbook.

Note: the feasibility and timing of the ideas will happen in the following "Now, Next, Later" exercise.

Prioritize your roadmap

Taking steps to mature your Agile requirements practice.

The "Now, Next, Later" technique is a method for prioritizing and planning improvements or tasks. This involves breaking down a list of tasks or improvements into three categories: "Now" tasks are those that must be completed immediately. These tasks are usually urgent or critical, and they must be completed to keep the project or organization running smoothly. "Next" tasks are those that should be completed soon. These tasks are not as critical as "now" tasks, but they are still important and should be tackled relatively soon. "Later" tasks are those that can be completed later. These tasks are less critical and can be deferred without causing major problems. By using this technique, you can prioritize and plan the most important tasks first, while also allowing for flexibility and the ability to adjust plans as necessary. This process also helps you get a clear picture on what needs to be done first and what can be done later. This way you can work on the most important things first, and keep track of what you need to do next, for keeping the development/improvement process smooth and efficient.

Monitor your progress

Monitoring progress is important in achieving your target state. Be deliberate with your actions, to continue to mature your Agile requirements practice.

As you navigate toward your target state, continue to monitor your progress, your successes, and your challenges. As your Agile requirements practice matures, you should see improvements in the stated metrics below.

Establish a cadence to review these metrics, as well as how you are progressing on your roadmap, against the plan.

This is not about adding work, but rather, about ensuring you're heading in the right direction; finding the balance in your Agile requirements practice.

Appendix

Research Contributors and Experts

Emal Bariali
Business Architect & Business Analyst
Bariali Consulting

Emal Bariali is a Senior Business Analyst and Business Architect with 17 years of experience, executing nearly 20 projects. He has experience in both waterfall and Agile methodologies and has delivered solutions in a variety of forms, including custom builds and turnkey projects. He holds a Master's degree in Information Systems from the University of Toronto, a Bachelor's degree in Information Technology from York University, and a post-diploma in Software & Database Development from Seneca College.

Paula Bell
Paula A. Bell Consulting, LLC

Paula Bell is the CEO of Paula A Bell Consulting, LLC. She is a Business Analyst, Leadership and Career Development coach, consultant, speaker, and author with 21+ years of experience in corporate America in project roles including business analyst, requirements manager, business initiatives manager, business process quality manager, technical writer, project manager, developer, test lead, and implementation lead. Paula has experience in a variety of industries including media, courts, manufacturing, and financial. Paula has led multiple highly-visible multi-million-dollar technology and business projects to create solutions to transform businesses as either a consultant, senior business analyst, or manager.

Currently she is Director of Operations for Bridging the Gap, where she oversees the entire operation and their main flagship certification program.

Ryan Folster
Consulting Services Manager, Business Analysis
Dimension Data

Ryan Folster is a Business Analyst Lead and Product Professional from Johannesburg, South Africa. His strong focus on innovation and his involvement in the business analysis community have seen Ryan develop professionally from a small company, serving a small number of users, to large multi-national organizations. Having merged into business analysis through the business domain, Ryan has developed a firm grounding and provides context to the methodologies applied to clients and projects he is working on. Ryan has gained exposure to the Human Resources, Asset Management, and Financial Services sectors, working on projects that span from Enterprise Line of Business Software to BI and Compliance.

Ryan is also heavily involved in the local chapter of IIBA®; having previously served as the chapter president, he currently serves as a non-executive board member. Ryan is passionate about the role a Business Analyst plays within an organization and is a firm believer that the role will develop further in the future and become a crucial aspect of any successful business.

Filip Hendrickx
Innovating BA, Visiting Professor @ VUB
altershape

Filip loves bridging business analysis and innovation and mixes both in his work as speaker, trainer, coach, and consultant.

As co-founder of the BA & Beyond Conference and IIBA Brussels Chapter president, Filip helps support the BA profession and grow the BA community in and around Belgium. For these activities, Filip received the 2022 IIBA® EMEA Region Volunteer of the Year Award.

Together with Ian Richards, Filip is the author ofBrainy Glue, a business novel on business analysis, innovation and change. Filip is also co-author of the BCS book Digital Product Management and Cycles, a book, method and toolkit enabling faster innovation.

Fabricio Laguna
Professional Speaker, Consultant, and Trainer
TheBrazilianBA.com

Fabrício Laguna, aka The Brazilian BA, is the main reference on business analysis in Brazil. Author and producer of videos, articles, classes, lectures, and playful content, he can explain complex things in a simple and easy-to-understand way. IIBA Brazil Chapter president between 2012-2022. CBAP, AAC, CPOA, PMP, MBA. Consultant and instructor for more than 25 years working with business analysis, methodology, solution development, systems analysis, project management, business architecture, and systems architecture. His online courses are approved by students from 65 countries.

Ryland Leyton
Business Analyst and Agile Coach
Independent Consultant

Ryland Leyton, CBAP, PMP, CSM, is an avid Agile advocate and coach, business analyst, author, speaker, and educator. He has worked in the technology sector since 1998, starting off with database and web programming, gradually moving through project management and finding his passion in the BA and Agile fields. He has been a core team member of the IIBA Extension to the BABOK and the IIBA Agile Analysis Certification. Ryland has written popular books on agility, business analysis, and career. He can be reached at www.RylandLeyton.com.

Steve Jones
Supervisor, Market Support Business Analysis
ISO New England

Steve is a passionate analyst and BA manager with more than 20 years of experience in improving processes, services and software, working across all areas of software development lifecycle, business change and business analysis. He rejoices in solving complex business problems and increasing process reproducibility and compliance through the application of business analysis tools and techniques.

Steve is currently serving as VP of Education for IIBA Hartford. He is a CBAP, certified SAFe Product Owner/Product Manager, Six Sigma Green Belt, and holds an MS in Information Management and Communications.

Angela Wick
Founder
BA-Squared and BA-Cube

Founder of BA-Squared and BA-Cube.com, Angela is passionate about teaching practical, modern product ownership and BA skills. With over 20 years' experience she takes BA skills to the next level and into the future!
Angela is also a LinkedIn Learning instructor on Agile product ownership and business analysis, an IC-Agile Authorized Trainer, Product Owner and BA highly-rated trainer, highly-rated speaker, sought-after workshop facilitator, and contributor to many industry publications, including:

• IIBA BABOK v3 Core Team, leading author on the BABOK v3
• Expert Reviewer, IIBA Agile Extension to the BABOK
• PMI BA Practice Guide – Expert Reviewer
• PMI Requirements Management Practice Guide – Expert Reviewer
• IIBA Competency Model – Lead Author and Team Lead, V1, V2, and V3.

Rachael Wilterdink
Principal Consultant
Infotech Enterprises

Rachael Wilterdink is a Principal Consultant with Infotech Enterprises. With over 25 years of IT experience, she holds multiple business analysis and Agile certifications. As a consultant, Rachael has served clients in the financial, retail, manufacturing, healthcare, government, non-profit, and insurance industries. Giving back to the professional community, Ms. Wilterdink served on the boards of her local IIBA® and PMI® chapters. As a passionate public speaker, Rachael presents various topics at conferences and user groups across the country and the world. Rachael is also the author of the popular eBook "40 Agile Transformation Pain Points (and how to avoid or manage them)."

Bibliography

"2021 Business Agility Report: Rising to the Challenge." Business Agility, 2021. Accessed 13 June 2022.
Axure. "The Pitfalls of Agile and How We Got Here". Axure. Accessed 14 November 2022.
Beck, Kent, et al. "Manifesto for Agile Software Development." Agilemanifesto. 2001.
Brock, Jon, et al. "Large-Scale IT Projects: From Nightmare to Value Creation." BCG, 25 May 2015.
Bryar, Colin and Bill Carr. "Have We Taken Agile Too Far?" Harvard Business Review, 9 April 2021. Accessed 11 November, 2022.
Clarke, Thomas. "When Agile Isn't Responsive to Business Goals" RCG Global Services, Accessed 14 November 2022.
Digital.ai "The 15th State of Agile Report". Digital.ai. Accessed 21 November 2022.
Hackshall, Robin. "Product Backlog Refinement." Scrum Alliance. 9 Oct. 2014.
Hartman, Bob. "New to Agile? INVEST in good user stories." Agile For All.
IAG Consulting. "Business Analysis Benchmark: Full Report." IAG Consulting, 2009.
Karlsson, Johan. "Backlog Grooming: Must-Know Tips for High-Value Products." Perforce. 18 May 2018
KPMG. Agile Transformation (2019 Survey on Agility). KPMG. Accessed November 29.
Laguna, Fabricio "REQM guidance matrix: A framework to drive requirements management", Requirements Engineering Magazine. 12 September 2017. Accessed 10 November 2022.
Miller, G. J. (2013). Agile problems, challenges, & failures. Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.
Product Management: MoSCoW Prioritization." ProductPlan, n.d. Web.
Podeswa, Howard "The Business Case for Agile Business Analysis" Requirements Engineering Magazine. 21 February 2017. Accessed 7 November 2022.
PPM Express. "Why Projects Fail: Business Analysis is the Key". PPM Express. Accessed 16 November 2022.
Reifer, Donald J. "Quantitative Analysis of Agile Methods Study: Twelve Major Findings." InfoQ, 6 February, 2017.
Royce, Dr. Winston W. "Managing the Development of Large Software Systems." Scf.usc.edu. 1970. (royce1970.pdf (usc.edu))
Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Pearson Education. 2012.
Singer, Michael. "15+ Surprising Agile Statistics: Everything You Need To Know About Agile Management". Enterprise Apps Today. 22 August 2022.
The Standish Group. The Chaos Report, 2015. The Standish Group.

Where do I go next?

Improve Requirements Gathering

Back to basics: great products are built on great requirements.

Make the Case for Product Delivery

Align your organization on the practices to deliver what matters most.

Requirements for Small and Medium Enterprises

Right-size the guidelines of your requirements gathering process.

Implement Agile Practices that Work

Improve collaboration and transparency with the business to minimize project failure.

Create an Agile-Friendly Gating and Governance Model

Use Info-Tech's Agile Gating Framework as a guide to gating your Agile projects following a "trust but verify" approach.

Make Your IT Governance Adaptable

Governance isn't optional, so keep it simple and make it flexible.

Deliver on Your Digital Product Vision

Build a product vision your organization can take from strategy through execution.

Microsoft Teams Cookbook

Recipes for best practices and use cases for Microsoft Teams.

Table of contents

Executive Brief

Section 1: Teams for IT

Section 2: Teams for End Users

Executive Summary

Situation

Remote work calls for leveraging your Office 365 license to utilize Teams – but IT is unsure about best practices for governance and permissions.

Without a framework or plan for governing the rollout of Teams, IT risks overlooking secure use of Teams, the phenomenon of “teams sprawl,” and not realizing how Teams integrates with Office 365 more broadly.

Complication

Teams needs to be rolled out quickly, but IT has few resources to help train end users with Teams best practices.

With teams, channels, chats, meetings, and live events to choose from, end users may get frustrated with lack of guidance on how to use Teams’ many capabilities.

Resolution

Use Info-Tech’s Microsoft Teams Cookbook to successfully implement and utilize Teams. This cookbook includes recipes for:

• IT best practices concerning governance of the creation process and Teams rollout.
• End-user best practices for Teams functionality and common use cases.

Key Insights

Teams is not a standalone app

Successful utilization of Teams occurs when conceived in the broader context of how it integrates with Office 365. Understanding how information flows between Teams, SharePoint Online, and OneDrive for Business, for instance, will aid governance with permissions, information storage, and file sharing.

IT should paint the first picture for team creation

No initial governance for team creation can lead to “teams sprawl.” While Teams was built to allow end users’ creativity to flow in creating teams and channels, this can create problems with a cluttered interface and keeping track of information. To prevent end-user dissatisfaction here, IT’s initial Teams rollout should offer a basic structure for end users to work with first, limiting early teams sprawl.

The Teams admin center can only take you so far with permissions

Knowing how Teams integrates with other Office 365 apps will help with rolling out sensitivity labels to protect important information being accidentally shared in Teams. Of course, technology only does so much – proper processes to train and hold people accountable for their actions with data sharing must be implemented, too.

Related Info-Tech Research

Establish a Communication and Collaboration System Strategy

Don’t waste your time deploying yet another collaboration tool that won’t get used.

Modernize Communication and Collaboration Infrastructure

Your legacy telephony infrastructure is dragging you down – modern communications and collaboration technology will dramatically improve productivity.

Migrate to Office 365 Now

One small step to cloud, one big leap to Office 365. The key is to look before you leap.

Section 1: Teams for IT

Governance best practices and use cases for IT

From determining prerequisites to engaging end users.

IT fundamentals

• Creation process
• Teams rollout

Use cases

• Retain and search for legal/regulatory compliance
• Add an external user to a team
• Delete/archive a team

Overview: Creation process

IT needs to be prepared to manage other dependent services when rolling out Teams. See the figure below for how Teams integrates with these other Office 365 applications.

Which Microsoft 365 license do I need to access Teams?

• Microsoft 365 Business Essentials
• Microsoft 365 Business Premium
• Office 365 Enterprise, E1, E3, or E5
• Office 365 Enterprise E4 (if purchased prior to its retirement)

Please note: To appeal to the majority of Info-Tech’s members, this blueprint refers to Teams in the context of Office 365 Enterprise licenses.

Assign admin roles

You will already have at least one global administrator from setting up Office 365.

Global administrators have almost unlimited access to settings and most of the data within the software, so Microsoft recommends having only two to four IT and business owners responsible for data and security.

Info-Tech Best Practice

Configure multifactor authentication for your dedicated Office 365 global administrator accounts and set up two-step verification.

Once you have organized your global administrators, you can designate your other administrators with “just-enough” access for managing Teams. There are four administrator roles:

Prepare the network

There are three prerequisites before Teams can be rolled out:

• UDP ports 3478 through 3481 are opened.
• You have a verified domain for Office 365.
• Office 365 has been rolled out, including Exchange Online and SharePoint Online.

Microsoft then recommends the following checklist to optimize your Teams utilization:

• Optimize calls and performance using the Call Quality Dashboard.
• Assess network requirements in the Network Planner in the Teams admin center.
• Ensure all computers running Teams client can resolve external DNS queries.
• Check adequate public IP addresses are assigned to the NAT pools to prevent port exhaustion.
• Route to local or regional Microsoft data centers.
• Whitelist all Office 365 URLs to move through security layers, especially IDS/IPS.
• Split tunnel Teams traffic so it bypasses your organization’s VPN.

Info-Tech Best Practice

For online support and walkthroughs, utilize Advisor for Teams. This assistant can be found in the Teams admin center.

Team Creation

You can create and manage Teams through the Teams PowerShell module and the Teams admin center. Only the global administrator and Teams service administrator have full administrative capabilities in this center.

Governance over team creation intends to prevent “teams sprawl” – the phenomenon whereby end users create team upon team without guidance. This creates a disorganized interface, with issues over finding the correct team and sharing the right information.

Prevent teams sprawl by painting the first picture for end users:

1. Decide what kind of team grouping would best fit your organization: by department or by project.
2. Start with a small number of teams before letting end users’ creativity take over. This will prevent initial death by notifications and support adoption.
3. Add people or groups to these teams. Assign multiple owners for each team in case people move around at the start of rollout or someone leaves the organization.
4. Each team has a general channel that cannot be removed. Use it for sharing an overview of the team’s goals, onboarding, and announcements.

Info-Tech Best Practice

For smaller organizations that are project-driven, organize teams by projects. For larger organizations with established, siloed departments, organize by department; projects within departments can become channels.

Integrations with SharePoint Online

Teams does not integrate with SharePoint Server.

Governance of Teams is important because of how tightly it integrates with other Office 365 apps, including SharePoint Online.

A poor rollout of Teams will have ramifications in SharePoint. A good rollout will optimize these apps for the organization.

Teams and SharePoint integrate in the following ways:

• Each team created in Teams automatically generates a SharePoint team site behind it. All documents and chat shared through a team are stored in that team’s SharePoint document library.
• As such, all files shared through Teams are subject to SharePoint permissions.
• Existing SharePoint folders can be tied to a team without needing to create a new one.
• If governance over resource sharing in Teams is poor, information can get lost, duplicated, or cluttered throughout both Teams and SharePoint.

Info-Tech Best Practice

End users should be encouraged to integrate their teams and channels with existing SharePoint folders and, where no folder exists, to create one in SharePoint first before then attaching a team to it.

Permissions

Within the Teams admin center, the global or Teams service administrator can manage Teams policies.

Typical Teams policies requiring governance include:

• The extent end users can discover or create private teams or channels
• Messaging policies
• Third-party app use

Chosen policies can be either applied globally or assigned to specific users.

Info-Tech Best Practice

If organizations need to share sensitive information within the bounds of a certain group, private channels help protect this data. However, inviting users into that channel will enable them to see all shared history.

External and guest access

Within the security and compliance center, the global or Teams service administrator can set external and guest access.

External access (federation) – turned on by default.

• Lets you find, call, and chat with users in other domains. External users will have no access to the organization’s teams or team resources.

Guest access – turned off by default.

• Lets you add individual users with their own email address. You do this when you want external users to access teams and team resources. Approved guests will be added to the organization’s active directory.

If guest access is enabled, it is subject to Azure AD and Office 365 licensing and service limits. Guests will have no access to the following, which cannot be changed:

• OneDrive for Business
• An organization’s calendar/meetings
• PSTN
• Organization’s hierarchical chart
• The ability to create, revise, or browse a team
• Upload files to one-on-one chat

Info-Tech Best Practice

Within the security and compliance center, you can allow users to add sensitivity labels to their teams that can prevent external and guest access.

Expiration and archiving

To reduce the number of unused teams and channels, or delete information permanently, the global or Teams service administrator can implement an Office 365 group expiration and archiving policy through the Teams admin center.

If a team has an expiration policy applied to it, the team owner will receive a notification for team renewal 30 days, 15 days, and 1 day before the expiry date. They can renew their team at any point within this time.

• To prevent accidental deletion, auto-renewal is enabled for a team. If the team owner is unable to manually respond, any team that has one channel visit from a team member before expiry is automatically renewed.
• A deleted Office 365 group is retained for 30 days and can be restored at any point within this time.

Alternatively, teams and their channels (including private) can be archived. This will mean that all activity for the team ceases. However, you can still add, remove, and update roles of the members.

Retention and data loss prevention

Retention policies can be created and managed in the Microsoft 365 Compliance Center or the security and compliance center PowerShell cmdlets. This can be applied globally or to specific users.

By default, information shared through Teams is retained forever.

However, setting up retention policies ensures data is retained for a specified time regardless of what happens to that data within Teams (e.g. user deletes).

Info-Tech Best Practice

To prevent external or guest users accessing and deleting sensitive data, Teams is able to block this content when shared by internal users. Ensure this is configured appropriately in your organization:

• For guest access in teams and channels
• For external access in meetings and chat

Please note the following limitations of Teams’ retention and data loss prevention:

• Organization-wide retention policies will need to be manually inputted into Teams. This is because Teams requires a retention policy that is independent of other workloads.
• As of May 2020, retention policies apply to all information in Teams except private channel messages. Files shared in private channels, though, are subject to retention policies.
• Teams does not support advanced retention settings, such as a policy that pertains to specific keywords or sensitive information.
• It will take three to seven days to permanently delete expired messages.

Teams telephony

Teams has built-in functionality to call any team member within the organization through VoIP.

However, Teams does not automatically connect to the PSTN, meaning that calling or receiving calls from external users is not immediately possible.

Bridging VoIP calls with the PSTN through Teams is available as an add-on that can be attached to an E3 license or as part of an E5 license.

There are two options to enable this capability:

• Enable Phone System. This allows for call control and PBX capabilities in Office 365.
• Use direct routing. You can use an existing PSTN connection via a Session Border Controller that links with Teams (Amaxra).

Steps to implement Teams telephony:

1. Ensure Phone System and required (non-Microsoft-related) services are available in your country or region.
2. Purchase and assign Phone System and Calling Plan licenses. If Calling Plans are not available in your country or region, Microsoft recommends using Direct Routing.
3. Get phone numbers and/or service numbers. There are three ways to do this:
   • Get new numbers through the Teams admin center.
   • If you cannot get new numbers through the Teams admin center, you can request new numbers from Microsoft directly.
   • Port or transfer existing numbers. To do this, you need to send Microsoft a letter of authorization, giving them permission to request and transfer existing numbers on your behalf.
4. To enable service numbers, including toll-free numbers, Microsoft recommends setting up Communications Credits for your Calling Plans and Audio Conferencing.

Overview: Teams rollout

1. From Skype (and Slack) to Teams
2. Gain stakeholder purchase
3. Employ a phased deployment
4. Engage end users

Skype for Business is being retired; Microsoft offers a range of transitions to Teams.

Combine the best transition mode with Info-Tech’s adoption best practices to successfully onboard and socialize Teams.

From Skype to Teams

Skype for Business Online will be retired on July 31, 2021. Choose from the options below to see which transition mode is right for your organization.

Skype for Business On-Premises will be retired in 2024. To upgrade to Teams, first configure hybrid connectivity to Skype for Business Online.

Islands mode (default)

• Skype for Business and Teams coexist while Teams is rolled out.
• Recommended for phased rollouts or when Teams is ready to use for chat, calling, and meetings.
• Interoperability is limited. Teams and Skype for Business only transfer information if an internal Teams user sends communications to an external Skype for Business user.

Teams only mode (final)

• All capabilities are enabled in Teams and Skype for Business is disabled.
• Recommended when end users are ready to switch fully to Teams.
• End users may retain Skype for Business to join meetings with non-upgraded or external parties. However, this communication is only initiated from the Skype for Business external user.

Collaboration first mode

• Skype for Business and Teams coexist, but only Teams’ collaboration capabilities are enabled. Teams communications capabilities are turned off.
• Recommended to leverage Skype for Business communications yet utilize Teams for collaboration.

Meetings first mode

• Skype for Business and Teams coexist, but only Teams’ meetings capabilities are enabled.
• Recommended for organizations that want to leverage their Skype for Business On-Premises’ Enterprise Voice capability but want to benefit from Teams’ meetings through VoIP.

From Slack to Teams

The more that’s left behind in Slack, the easier the transition. As a prerequisite, pull together the following information:

• Usage statistics of Slack workspaces and channels
• What apps end users utilize in Slack
• What message history you want to export
• A list of users whose Slack accounts can map on to required Microsoft accounts

Test content migration

Your Slack service plan will determine what you can and can’t migrate. By default, public channels content can be exported. However, private channels may not be exportable, and a third-party app is needed to migrate Direct Messages.

Files migration

Once you have set up your teams and channels in Teams, you can programmatically copy files from Slack into the target Teams channel.

Apps migration

Once you have a list of apps and their configurations used in Slack’s workspaces, you can search in Teams’ app store to see if they’re available for Teams.

User identity migration

Slack user identities may not map onto a Microsoft account. This will cause migration issues, such as problems with exporting text content posted by that user.

Info-Tech Best Practice

Avoid data-handling violations. Determine what privacy and compliance regulations (if any) apply to the handling, storage, and processing of data during this migration.

Gain stakeholder purchase

Change management is a challenging aspect of implementing a new collaboration tool. Creating a communication and adoption plan is crucial to achieving universal buy-in for Teams.

To start, define SMART objectives and create a goals cascade.

Sample list of stakeholder-specific benefits from improving collaboration

Use these activities to define what pain points stakeholders face and how Teams can directly mitigate those pain points.

Employ a phased deployment

Info-Tech Best Practice

Deploy Teams over a series of phases. As such, if you are already using Skype for Business, choose one of the coexistence phases to start.

1. Identify and pilot Teams with early adopters that will become your champions. These champions should be formally trained, be encouraged to help and train their colleagues, and be positively reinforced for their efforts.
2. Iron out bugs identified with the pilot group and train middle management. Enterprise collaboration tool adoption is strongly correlated with leadership adoption.
   1. Top-level management
      Control and direct overall organization.
   2. Middle management
      Execute top-level management’s plans in accordance with organization’s norms.
   3. First-level management
      Execute day-to-day activities.
3. Use Info-Tech’s one-pager marketing template to advertise the new tool to stakeholders. Highlight how the new tool addresses specific pain points. Address questions stemming from fear and uncertainty to avoid employees’ embarrassment or their rejection of the tool.

1. Extend the pilot to other departments and continue this process for the whole organization.

(Source: Rationalize Your Collaboration Tools (coming soon), Tools:GANTT Chart and Marketing Materials, Activities: 3.2A – 3.2B)

Info-Tech Insight

Be in control of setting and maintaining expectations. Aligning expectations with reality and the needs of employees will lower onboarding resistance.

Engage end users

Short-term best practices

Launch day:

• Hold a “lunch and learn” targeted training session to walk end users through common use cases.
• Open a booth or virtual session (through Teams!) and have tool representatives available to answer questions.
• Create a game to get users exploring the new tool – from scavenger hunts to bingo.

Launch week:

• Offer incentives for using the tool and helping others, including small gift cards.
• Publicize achievements if departments hit adoption milestones.

Long-term best practices

• Make available additional training past launch week. End users should keep learning new features to improve familiarity.
• Distribute frequent training clips, slowly exposing end users to more complex ways of utilizing Teams.
• Continue to positively reinforce and recognize those who use Teams well. This could be celebrating those that help others use the tool, how active certain users are, and attendance at learning events.

Info-Tech Best Practice

Microsoft has a range of training support that can be utilized. From instructor-led training to “Coffee in the Cloud” sessions, leverage all the support you can.

Use case #1: Retain and search data for legal/regulatory compliance

Scenario:

Your organization requires you to retain data and documents for a certain period of time; however, after this period, your organization wishes to delete or archive the data instead of maintaining it indefinitely. Within the timeframe of the retention policy, the admin may be asked to retrieve information that has been requested through a legal channel.

Purpose:

• Maintain compliance with the legal and regulatory standards to which the organization is subject.

Jobs:

• Ensure the data is retained for the approved time period.
• Ensure the policy applies to all relevant data and users.

Solution: Retention Policies

• Ensure that your organization has an Office 365 E3 or higher license.
• Set the desired retention policy through the Security & Compliance Center or PowerShell by deciding which teams, channels, chats, and users the policies will apply to and what will happen once the retention period ends.
• Ensure that matching retention policies are applied to SharePoint and OneDrive, since this is where files shared in Teams are stored.
• Be aware that Teams retention policies cannot be applied to messages in private channels.

Solution: e-Discovery

• If legally necessary, place users or Teams on legal hold in order to retain data that would be otherwise deleted by your organization’s retention policies.
• Perform e-discovery on Teams messages, files, and summaries of meetings and calls through the Security & Compliance Center.
• See Microsoft’s chart on the next slide for what is e-discoverable.

Content subject to e-discovery

E-discovery does not capture audio messages and read receipts in MS Teams.

Since files shared in private channels are stored separately from the rest of a team, follow Microsoft’s directions for how to include private channels in e-discovery. (Source: “Conduct an eDiscovery investigation of content in Microsoft Teams,” Microsoft, 2020.)

Use case #2: Add external person to a team

Scenario:

A team in your organization needs to work in an ongoing way with someone external to the company. This user needs access to the relevant team’s work environment, but they should not be privy to the goings-on in the other parts of the organization.

Jobs:

This external person needs to be able to:

• Attend meetings
• Join calls
• Chat with individual team members
• View and collaborate on the team’s files

Solution:

• If necessary, set a data loss prevention policy to prevent your users from sharing certain types of information or files with external users present in your organization’s Teams chats and public channels.
• Ensure that your Microsoft license includes DLP protection. However:
  • DLP cannot be applied to private channel messages.
  • DLP cannot block messages from external Skype for Business users nor external users who are not in “Teams only” mode.
• Ensure that you have a team set up for the project that you wish the external user to join. The external user will be able to see all the channels in this team, unless you create a private channel they are restricted from.
• Complete Microsoft’s “Guest Access Checklist” to enable guest access in Teams, if it isn’t already enabled.
• As admin, give the external user guest access through the Teams admin center or Azure AD B2B collaboration. (If given permission, team owners can also add guests through the Teams client).
• Decide whether to set a policy to monitor and audit external user activity.

Use case #3: Delete/archive a team

Scenario:

In order to avoid teams sprawl, organizations may want IT to periodically delete or archive unused teams within the Teams client in order to improve the user interface.

Alternately, if you are using a project-based approach to organizing Teams, you may wish to formalize a process to archive a team once the project is complete.

Delete:

• Determine if the team owner anticipates the team will need to be restored one day.
• Ensure that deletion does not contradict the organization’s retention policy.
• If not, proceed with deletion. Find the team in the Teams admin center and delete.
• Restore a deleted team within 30 days of its initial deletion through PowerShell.

Archive:

• Determine if the team owner anticipates the team will need to be restored one day.
• Find the relevant team in the Teams admin center and change its status to “Archived.”
• Restore the archived team if the workspace becomes relevant once again.

Info-Tech Best Practice

Remind end users that they can hide teams or channels they do not wish to see in their Teams interface. Knowing a team can be hidden may impact a team owner’s decision to delete it.

Section 2: Teams for End Users

Best practices for utilizing teams, channels, chat, meetings, and live events

From Teams how-tos to common use cases for end users.

End user basics

• Teams, channels, and chat
• Meetings and live events

Common use cases: Workspaces

• WS#1: Departments
• WS#2: A cross-functional committee
• WS#3: An innovation day event
• WS#4: A non-work-related social event
• WS#5: A project team with a defined end time

Common use cases: Meetings

• M#1: Job interview with an external candidate
• M#2: Quarterly board meeting
• M#3: Weekly recurring team meeting
• M#4: Morning stand-up/scrum
• M#5: Phone call between two people

Overview: Teams, channels, and chat

Teams

• Team: A workspace for a group of collaborative individuals.
  • Public channel: A focused area where all members of a team can meet, communicate, and share ideas and content.
  • Private channel: Like a public channel but restricted to a subset of team members, defined by channel owner.

Chat

• Chat: Two or more users collected into a common conversation thread.

For any Microsoft Teams newcomer, the differences between teams, channels, and chat can be confusing.

Use Microsoft’s figure (left) to see how these three mediums differ in their role and function.

Best practices: Workspaces 1/2

When does a Group Chat become a Channel?

• When it’s appropriate for the conversation to have a gallery – an audience of members who may not be actively participating in the discussion.
• When control over who joins the conversation needs to be centrally governed and not left up to anyone in the discussion.
• When the discussion will persist over a longer time period.
• When the number of participants approaches 100.

When does a Channel become a Team?

• When a team approaches 30 private channels, many of those private channels are likely candidates to become their own team.
• When the channel membership needs to extend beyond the boundary of the team membership.

Best practices: Workspaces 2/2

When does a Team become a Channel?

• When a team’s purpose for existing can logically be subsumed by another team that has a larger scope.

When does a Channel become a Group Chat?

• When a conversation within a channel between select users does not pertain to that channel’s scope (or any other existing channel), they should move the conversation to a group chat.
• However, this is until that group chat desires to form a channel of its own.

Create a new team

Team owner: The person who creates the team. It is possible for the team owner to then invite other members of the team to become co-owners to distribute administrative responsibilities.

Team members: People who have accepted their invitation to be a part of the team.

NB: Your organization can control who has permission to set up a team. If you can’t set a up a team, contact your IT department.

Create a new team

Decide from these two options:

• Building a team from scratch, which will create a new group with no prior history imported (steps 4.1–4.3).
• Creating a team from an existing group in Office 365, including an already existing team (steps 4.4–4.6).

NB: You cannot create a team from an existing group if:

• That group has 5,000 members or more.
• That group is in Yammer.

Decide if you want you new team from scratch to be private or public. If you set up a private team, any internal or external user you invite into the team will have access to all team history and files shared.

'.">

Create a new team

Decide from these two options:

• Building a team from scratch, which will create a new group with no prior history imported (steps 4.1–4.3).
• Creating a team from an existing group in Office 365, including an already existing team (steps 4.4–4.6).

NB: You cannot create a team from an existing group if:

• That group has 5,000 members or more.
• That group is in Yammer.

Configure your new team settings, including privacy, apps, tabs, and members.

'.">

Create a new channel

	On the right-hand side of the team name, click “More options.” Then, from the drop-down menu, click “Add channel.”	Name your channel, give a description, and set your channel’s privacy.
	To manage subsequent permissions, on the right-hand side of the channel name, click “More options.” Then, from the drop-down menu, click “Manage channel.”	Adding and removing members from channels: Only members in a team can see that team’s channels. Setting channel privacy as “standard” means that the channel can be accessed by anyone in a team. Unless privacy settings for a channel are set as “private” (from which the channel creator can choose who can be in that channel), there is no current way to remove members from channels. It will be up to the end user to decide which channels they want to hide.

Link team/channel to SharePoint folder

Need to find the SharePoint URL? ', 'Click to access the folder's SharePoint URL.'">

Create a chat

Overview: Meetings and live events

Teams Meetings: Real-time communication and collaboration between a group, limited to 250 people.

Teams Live Events: designed for presentations and webinars to a large audience of up to 10,000 people, in which attendees watch rather than interact.

Depending on the use case, end users will have to determine whether they need to hold a meeting or a live event.

Use Microsoft’s table (left) to see what license your organization needs to perform meetings and live events.

Best practices: Meetings

When should an Ad Hoc Call become a Scheduled Meeting?

• When the participants need time to prepare content for the call.
• When an answer is not required immediately.
• When bringing a group of people together requires logistical organizing.

When should a Scheduled Meeting become an Ad Hoc Call?

• When the participants can meet on short notice.
• When a topic under discussion requires creating alignment quickly.

When should a Live Event be created?

• When the expected attendance exceeds 250 people.
• If the event does not require collaboration and is mostly a presenter conveying information.

Create a scheduled meeting

Create an ad hoc meeting

Tip: Use existing channels to host the chatrooms for your online meetings

When you host a meeting online with Microsoft Teams, there will always be a chatroom associated with the meeting. While this is a great place for meeting participants to interact, there is one particular downside.

Problem: The never-ending chat. Often the activity in these chatrooms can persist long after the meeting. The chatroom itself becomes, unofficially, a channel. When end users can’t keep up with the deluge of communication, the tools have failed them.

Solution: Adding an existing channel to the meeting. This ensures that discussion activity is already hosted in the appropriate venue for the group, during and after the meeting. Furthermore, it provides non-attendees with a means to catch up on the discussion they have missed.

In section two of this cookbook, we will often refer to this tactic.

Don’t have a channel for the chat session of your online meeting? Perhaps you should!

If your meeting is with a group of individuals that will be collaborating frequently, they may need a workspace that persists beyond the meeting.

Guests can still attend the meeting, but they can’t chat!

If there are attendees in your meeting that do not have access to the channel you select to host the chat, they will not see the chat discussion nor have any ability to use this function.

This may be appropriate in some cases – for example, a vendor providing a briefing as part of a regular team meeting.

However, if there are attendees outside the channel membership that need to see the meeting chat, consider another channel or simply default to not assigning one.

Meeting settings explained

Show device settings. For settings concerning audio, video, and whether viewing is private.

Show meeting notes. Use to take notes throughout the meeting. The notes will stay attached to this event.

Show meeting details. Find meeting information for: a dial-in number, conference ID, and link to join.

Enter full screen.

Show background effects. Choose from a range of video backgrounds to hide/blur your location.

Turn on the captions (preview). Turn on live speech-to-text captions.

Keypad. For dialing a number within the meeting (when enabled as an add-on with E3 or as part of E5).

Start recording. Recorded and saved using Microsoft Stream.

End meeting.

Turn off incoming video. To save network bandwidth, you can decline receiving attendee’s video.

Click “More options” to access the meetings settings.

Screen share. In the tool tray, select “Share” to share your screen. Select particular applications if you only want to share certain information; otherwise, you can share your whole desktop.

System audio share. To share your device’s audio while screen sharing, checkbox the “Include system audio” option upon clicking “Share.”

If you didn’t click that option at the start but now want to share audio during screen share, click the “Include systems audio” option in the tool tray along the top of the screen.

Give/take control of screen share. To give control, click “Give control” in the tool tray along the top of the screen when sharing content. Choose from the drop-down who you would like to give control to. In the same spot, click “Take back control” when required.

To request control, click “Request control” in the same space when viewing someone sharing their content. Click “Release control” once finished.

Start whiteboarding

1. You’ll first need to enable Microsoft Whiteboard in the Microsoft 365 admin center. Ask your relevant admin to do so if Whiteboard is not already enabled.
2. Once enabled, click “Share” in a meeting. This feature only appears if you have 3+ participants in the meeting.
3. Under the “Whiteboard” section in the bottom right, click “Microsoft Whiteboard.”
4. Click the pen icons to the right of the screen to begin sketching.

NB: Anonymous, federated, or guest users are currently not supported to start, view, or ink a whiteboard in a Teams meeting.

Will the whiteboard session be recorded if the meeting is being recorded?

No. However, the final whiteboard will be available to all meeting attendees after the meeting, under “Board Gallery” in the Microsoft Whiteboard app. Attendees can then continue to work on the whiteboard after the meeting has ended.

Create a live event

As the organizer, you can invite other people to the event who will be the “producers” or “presenters.” Producers: Control the live event stream, including being able to start and stop the event, share their own and others’ video, share desktop or window, and select layout. Presenters: Present audio, video, or a screen.

Live event settings explained

When you join the live event as a producer/presenter, nothing will be immediately broadcast. You’ll be in a pre-live state. Decide what content to share and in what order. Along the bottom of the screen, you can share your video and audio, share your screen, and mute incoming attendees. Once your content is ready to share along the bottom of the screen, add it to the screen on the left, in order of viewing. This is your queue – your “Pre-live” state. Then, click “Send now.” This content will now move to the right-hand screen, ready for broadcasting. Once you’re ready to broadcast, click “Start.” Your state will change from “Pre-live” to “Live.” Along the top right of the app will be a tools bar.

Workspace #1: Departments

Scenario: Most of your organization’s communication and collaboration occurs within its pre-existing departmental divisions.

Conventional communication channels:

• Oral communication: Employees work in proximity to each other and communicate in person, by phone, in department meetings
• Email: Department-wide announcements
• Memos: Typically posted/circulated in mailboxes

Solution: Determine the best way to organize your organization’s departments in Teams based on its size and your requirements to keep information private between departments.

Option A:

• Create a team for the organization/division.
• Create channels for each department. Remember that all members of a team can view all public channels created in that team and the default General channel.
• Create private channels if you wish to have a channel that only select members of that team can see. Remember that private channels have some limitations in functionality.

Option B:

• Create a new team for each department.
• Create channels within this team for projects or topics that are recurring workflows for the department members. Only department members can view the content of these channels.

Option C:

• Post departmental memos and announcements in the General channel.
• Use “Meet now” in channels for ad hoc meetings. For regular department meetings, create a recurring Teams calendar event for the specific department channel (Option A) or the General channel (Option B). Remember that all members of a team can join a public channel meeting.

Workspace #2: A cross-functional committee

Scenario: Your organization has struck a committee composed of members from different departments. The rest of the organization should not have access to the work done in the committee.

Purpose: To analyze a particular organizational challenge and produce a plan or report; to confidentially develop or carry out a series of processes that affect the whole organization.

Jobs: Committee members must be able to:

• Attend private meetings.
• Share files confidentially.

Solution:

Ingredients:

• Private team

Construction:

• Create a new private team for the cross-functional committee.
• Add only committee members to the team.
• Create channels based on the topics likely to be the focal point of the committee work.
• Decide how you will use the mandatory General channel. If the committee is small and the work limited in scope, this channel may be the main communication space. If the committee is larger or the work more complex, use the General channel for announcements and move discussions to new topic-related channels.
• Schedule recurring committee meetings in the Teams calendar. Add the relevant channel to the meeting invite to keep the meeting chat attached to this team and channel (as meeting organizer, put your name in the meeting invite notes, as the channel will show as the organizer in the Outlook invite).
• Remember that all members of this team will have access to these meetings and be able to view that they are occurring.

Workspace #3: An innovation day event

Scenario: The organization holds a yearly innovation day event in which employees form small groups and work on a defined, short-term problem or project.

Purpose: To develop innovative solutions and ideas.

Jobs:

• Convene small groups.
• Work toward time-sensitive goals.
• Communicate synchronously.
• Share files.

Solution:

Ingredients:

• Public team
• Channel tabs
• Whiteboard
• Planner

Construction:

• Create a team for the innovation day event.
• Add channels for each project working group.
• Communicate to participants the schedule for the day and their assigned channel.
• Use the General channel for announcements and instructions throughout the day. Ensure someone moderates the General channel for participants’ questions.
• Pre-populate the channel tabs with files the participants need to work with. To add a scrum board, refer to M#4 (Morning stand-up/Scrum) in this slide deck.
• For breakouts, instruct participants to use the “meet now” feature in their channel and how to use the Whiteboard during these meetings.
• Arrange to have your IT admin archive the team after a certain point so the material is still viewable but not editable.

Workspace #4: A non-work-related social event

Scenario: Employees within the organization wish to organize social events around shared interests: board game clubs, book clubs, TV show discussion groups, trivia nights, etc.

Purpose: To encourage cohesion among coworkers and boost morale.

Jobs:

• Schedule the event.
• Invite participants.
• Prepare the activity.
• Host and moderate the discussion.

Solution:

Ingredients:

• Public team
• Private channels
• Screen-sharing

Construction:

• Create a public team for the social event so that interested people can find and join it.
• Example: Trivia Night
  • Schedule the event in the Teams calendar.
  • Publish the link to the Trivia Night team where other employees will see it.
  • Create private channels for each trivia team so they cannot see the other competitors’ discussions. Add yourself to each private channel so you can see their answers.
  • As the host, begin a meeting in the General channel. Pose the trivia questions live or present the questions on PowerPoint via screen-sharing.
  • Ask each team to post its answers to its private channel.
• To avoid teams sprawl, ask your IT admin to set a deletion policy for the team, as long as this request does not contradict your organization’s policies on data retention. If the team becomes moribund, it can be set to auto-delete after a certain period of time.

Workspace #5: A project team with a defined end time

Scenario: Within a department/workplace team, employees are assigned to projects with defined end times, after which they will be assigned to a new project.

Purpose: To complete project-based work that fulfills business needs.

Jobs:

• Oral communication with team members.
• Synchronous and asynchronous work on project files.
• The ability to attend scheduled meetings and ad hoc meetings.
• The ability to access shared resources related to the project.

Solution:

If your working group already has its own team within Teams:

• Create a new public or private channel for the project. Remember that some functionality is not available in private channels (such as Microsoft Planner).
• Use the channel for the project team’s meetings (scheduled in Teams calendar or through Meet Now).
• Add a tab that links to the team’s project folder in SharePoint.

If your workplace team does not already have its own team in Teams:

• Determine if there is a natural fit for this project as a new channel in an existing team. Remember that all team members will be able to see the channel if it is public and that all relevant project members need to belong to the Team to participate in the channel.
• If necessary, create a new team for the project. Add the project members.
• Create channels based on the type of work that comprises the project.
• Use the channel for the project team’s meetings (scheduled in Teams calendar or through Meet Now)
• Add a tab to link to the team’s project folder in SharePoint.

Info-tech Best Practice

Hide the channel after the project concludes to de-clutter your Teams user interface.

Meeting #1: Job interview with external candidate

Scenario: The organization must interview a slate of candidates to fill an open position.

Purpose:

• Select the most qualified candidate for the job.

Jobs:

• Create a meeting, ensuring the candidate and other attendees know when and where the meeting will happen.
• Ensure the meeting is secure to protect confidential information.
• Ensure the meeting is accessible, allowing the candidate to present themselves through audio and/or visual means.
• Create a professional environment for the meeting to take place.
• Engender a space for the candidate to share their CV, research, or other relevant file.
• The interview must be transcribed and recorded.

Solution:

Ingredients:

• Private Teams meeting
• Screen-sharing
• Microsoft Stream

Construction:

• Create a Teams meeting, inviting the candidate with their email, alongside other internal attendees. The Teams meeting invite will auto-generate a link to the meeting itself.
• The host can control who joins the meeting through settings for the “lobby.”
• Through the Teams meeting, the attendees will be able to use the voice and video chat functionality.
• All attendees can opt to blur their backgrounds to maintain a professional online presence.
• The candidate can share their screen, either specific applications or their whole desktop, during the Teams meeting.
• A Teams meeting can be recorded and transcribed through Stream. After the meeting, the transcript can be searched, edited, and shared

NB: The external candidate does not need the Teams application. Through the meeting invite, the external candidate will join via a web browser.

Meeting #2: Quarterly board meeting

Scenario: Every quarter, the organization holds its regular board meeting.

Purpose: To discuss agenda items and determine the company’s future direction.

Jobs:

• Attendance and minutes must be taken.
• Votes must be recorded.
• In-camera sessions must occur.
• External experts must be included.

• Follow-up items must be assigned.
• Reports must be submitted.

Solution:

Ingredients:

• Teams calendar invite
• Planner; Forms
• Private channel
• Microsoft Stream

Construction:

• Guest Invite: Invites can be sent to any non-domain-joined email address to join a private, invitation-only channel within the team controlled by the board chair.
• SharePoint & Flow: Documents are emailed to the Team addresses, which kicks off an MS Flow routine to collect review notes.
• Planner: Any board member can assign tasks to any employee.
• Forms/Add-On: Chair puts down the form of the question and individual votes are tracked.
• Teams cloud meeting recording: Recording available through Stream. Manual edits can be made to VTT caption file. Greater than acceptable transcription error rate.
• Meeting Log: Real-time attendance is viewable but a point-in-time record needs admin access.

NB: The external guests do not need the Teams application. Through the meeting invite, the guests will join via a web browser.

Meeting #3: Weekly team meeting

Scenario: A team meets for a weekly recurring meeting. The meeting is facilitated by the team lead (or manager) who addresses through agenda items and invites participation from the attendees.

Purpose: The purpose of the meeting is to:

• Share information verbally
• Present content visually
• Achieve consensus
• Build team morale

Jobs: The facilitator must:

• Determine participants
• Book room
• Book meeting in calendar

Solution:

Ingredients:

• Meeting Place: A channel in Microsoft Teams (must be public) where all members of the meeting make up the entirety of the audience.
• Calendar Recurrence: A meeting is booked through Teams and appears in all participants’ Outlook calendar.
• Collaboration Space: Participants join the meeting through video or audio and can share screens and contribute text, images, and links to the meeting chat.

Construction:

• Ensure your team already has a channel created for it. If not, create one in the appropriate team.
• Create the meeting using the calendar view within Microsoft Teams:
  • Set the meeting’s name, attendees, time, and recurrence.
  • Add the team channel that serves as the most appropriate workplace for the meeting. (Any discussion in the meeting chat will be posted to this channel.)

NB: Create the meeting in the Teams calendar, not Outlook, or you will not be able to add the Teams channel. As meeting organizer, put your name in the meeting invite notes, as the channel will show as the organizer in the Outlook invite.

Meeting #4: Morning stand-up/scrum

Scenario: Each morning, at 9am, members of the team meet online.

Purpose: After some pleasantries, the team discusses what tasks they each plan to complete in the day.

Jobs: The team leader (or scrum master) must:

• Place all tasks on a scrum board, each represented by a sticky note denoting the task name and owner.
• Move the sticky notes through the columns, adjusting assignments as needed.
• Sort tasks into the following columns: “Not Started,” “In Progress,” and “Done.”

Solution:

Ingredients:

• Meeting Place: A channel in Microsoft Teams (must be public) where all members of the meeting make up the entirety of the audience.
• Scrum Board: A tab within that channel where a persistent scrum board has been created and is visible to all team members.

Meeting Place Construction:

• Create the meeting using the calendar view in Teams.
• Set the meeting’s name, attendees, time, and work-week daily recurrence (see left).
• Add the channel that is the most appropriate workplace for the meeting. Any meeting chat will be posted to this channel rather than a separate chat.

Scrum Board Construction:

• Add a tab to the channel using Microsoft Planner as the app. (You can use other task management apps such as Trello, but the identity integration of first-party Office 365 tools may be less hassle.)
• Create a new (or import an existing) Plan to the channel. This will be used as the focal point.

Meeting #5: Weekly team meeting

Scenario: An audio-only conversation that could be a regularly scheduled event but is more often conducted on an ad-hoc basis.

Purpose: To quickly share information, achieve consensus, or clarify misunderstandings.

Jobs:

• Dial recipient
• See missed calls
• Leave/check voicemail
• Create speed-dial list
• Conference call

Solution:

Ingredients:

• Audio call begun through Teams chat.

Construction:

• Voice over IP calls between users in the same MS Teams tenant can begin in multiple ways:
  • A call can be initiated through any appearance of a user’s profile picture: hover over user’s profile photo in the Chat list and select the phone icon.
  • Enter your last chat with a user and click phone icon in upper-right corner.
  • Go to the Calls section and type the name in the “Make a call” text entry form.
• Voicemail: Voicemail, missed calls, and call history are available in the Calls section.
• Speed dial: Speed dial lists can be created in the Calls section.
• Conference call: Other users can be added to an ongoing call.

NB: Microsoft Teams can be configured to provide an organization’s telephony for external calls, but this requires an E5 license. Additional audio-conferencing licenses are required to call in to a Teams meeting over a phone.

Bibliography 1/4

Section 1: Teams for IT › Creation Process

Overview: Creation process

• “How do I get access to Microsoft Teams?” Microsoft, n.d., support.office.com/en-us/article/how-do-i-get-access-to-microsoft-teams-fc7f1634-abd3-4f26-a597-9df16e4ca65b. Accessed 11 May 2020.
• “Logical architecture for Microsoft Teams and related services.” Microsoft, 6 Mar. 2020, docs.microsoft.com/en-us/microsoftteams/teams-architecture-solutions-posters. Accessed 9 May 2020.
• “Plan for governance in Teams.” Microsoft, 10 Aug. 2018, docs.microsoft.com/en-us/MicrosoftTeams/plan-teams-governance. Accessed 30 Apr. 2020.

Assign admin roles

• “Use Microsoft Teams administrator roles to manage Teams.” Microsoft, 19 Sep. 2018, docs.microsoft.com/en-us/microsoftteams/using-admin-roles. Accessed 9 May 2020.

Prepare the network

• “Prepare your organization's network for Microsoft Teams.” Microsoft, 28 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/prepare-network. Accessed 9 May 2020.

Team creation

• “Best practices for organizing teams in Microsoft Teams.” Microsoft, 13 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/best-practices-organizing. Accessed 9 May 2020.
• “Create your first teams and channels in Microsoft Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/get-started-with-teams-create-your-first-teams-and-channels. Accessed 9 May 2020.

Integrations with SharePoint Online

• “Configure Teams with three tiers of protection.” Microsoft, 7 May 2020, docs.microsoft.com/en-us/microsoft-365/solutions/configure-teams-three-tiers-protection?view=o365-worldwide. Accessed 9 May 2020.
• “File collaboration in SharePoint with Microsoft 365.” Microsoft, 21 Apr. 2020, docs.microsoft.com/en-us/sharepoint/deploy-file-collaboration. Accessed 9 May 2020.

Permissions

• “Manage app permission policies in Microsoft Teams.” Microsoft, 21 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/teams-app-permission-policies. Accessed 9 May 2020.
• “Manage messaging policies in Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/messaging-policies-in-teams. Accessed 30 Apr. 2020.
• “Sensitivity labels for Microsoft Teams.” Microsoft, 22 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/sensitivity-labels. Accessed 9 May 2020.

Bibliography 2/4

Section 1: Teams for IT › Creation Process (cont'd.)

External and guest access

• “Add a guest to Teams.” Microsoft, 22 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/add-guests. Accessed 30 Apr. 2020.
• “Communicate with users from other organizations in Microsoft Teams.” Microsoft, 22 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/communicate-with-users-from-other-organizations. Accessed 30 Apr. 2020.
• “Guest access in Microsoft Teams.” Microsoft, 22 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/guest-access. Accessed 9 May 2020.
• “Manage external access in Microsoft Teams.” Microsoft, 22 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/manage-external-access. Accessed 9 May 2020.
• “Microsoft Teams guest access checklist.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/guest-access-checklist. Accessed 30 Apr. 2020.
• “Turn on or turn off guest access to Microsoft Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/set-up-guests. Accessed 9 May 2020.
• “What the guest experience is like.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/guest-experience. Accessed 4 May 2020.

Expiration and archiving

• “Archive or delete a team in Microsoft Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/archive-or-delete-a-team?view=o365-worldwide. Accessed 29 Apr. 2020.
• “Microsoft 365 group expiration policy.” Microsoft, 6 May 2020, docs.microsoft.com/en-us/microsoft-365/admin/create-groups/office-365-groups-expiration-policy?view=o365-worldwide. Accessed 9 May 2020.
• “Team expiration and renewal in Microsoft Teams.” Microsoft, 6 Feb. 2020, docs.microsoft.com/en-us/microsoftteams/team-expiration-renewal. Accessed 9 May 2020.

Retention and data loss prevention

• “Data loss prevention and Microsoft Teams.” Microsoft, 21 Apr. 2020, docs.microsoft.com/en-us/microsoft-365/compliance/dlp-microsoft-teams?view=o365-worldwide. Accessed 9 May 2020.
• “Retention policies in Microsoft Teams.” Microsoft, 5 May 2020, docs.microsoft.com/en-us/microsoftteams/retention-policies. Accessed 9 May 2020.

Teams telephony

• “Here's what you get with Phone System in Office 365.” Microsoft, 26 Feb. 2020, docs.microsoft.com/en-us/microsoftteams/here-s-what-you-get-with-phone-system. Accessed 9 May 2020.
• O’Donnell, J.P. “The killer feature in Microsoft Teams your business should be using.” Amaxra, n.d., www.amaxra.com/blog/the-killer-feature-in-microsoft-teams-your-business-should-be-using. Accessed 4 May 2020.
• “Set up Phone System in your organization.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/deploy-audio-conferencing-teams-landing-page. Accessed 4 May. 2020.
• “What is Phone System in Office 365?” Microsoft, 29 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/what-is-phone-system-in-office-365. Accessed 9 May 2020.

Bibliography 3/4

Section 1: Teams for IT › Teams Rollout

From Skype to Teams

• “FAQ — Upgrading from Skype for Business to Microsoft Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/faq-journey. Accessed 9 May 2020.
• “Teams and Skype interoperability.” Microsoft, 21 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/teams-skype-interop. Accessed 9 May 2020.
• “Understand Microsoft Teams and Skype for Business coexistence and interoperability.” Microsoft, 3 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/teams-and-skypeforbusiness-coexistence-and-interoperability. Accessed 9 May 2020.

From Slack to Teams

• “Migrate from Slack to Microsoft Teams.” Microsoft, 14 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/migrate-slack-to-teams. Accessed 9 May 2020.

Teams adoption

• “365 adoption guide” Microsoft, 22 Jan. 2020, query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWqTOD. Accessed 9 May 2020.

Section 1: Teams for IT › Use Cases

• Acharya, Ansuman. “Microsoft Teams launches eDiscovery for calling and meetings.” Microsoft Tech Community, 2 Jul. 2018, techcommunity.microsoft.com/t5/microsoft-teams-blog/microsoft-teams-launches-ediscovery-for-calling-and-meetings/ba-p/210947. Accessed 30 Apr. 2020.
• “Conduct an eDiscovery investigation of content in Microsoft Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/ediscovery-investigation?view=o365-worldwide#overview, Accessed 29 Apr. 2020.
• “Teams cloud meeting recording: Compliance and eDiscovery for meeting recordings.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/cloud-recording#compliance-and-ediscovery-for-meeting-recordings. Accessed 29 Apr. 2020.

Bibliography 4/4

Section 2: Teams for End Users › Teams, Channels, Chat

• “Limits and specifications for Microsoft Teams.” Microsoft, 29 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/limits-specifications-teams. Accessed 4 May 2020.
• “Location of data in Microsoft Teams.” Microsoft, 27 Apr. 2020, docs.microsoft.com/en-us/MicrosoftTeams/location-of-data-in-teams. Accessed 4 May 2020.
• “Manage the Whiteboard in Microsoft Teams.” Microsoft, 1 Oct. 2019, docs.microsoft.com/en-us/microsoftteams/manage-whiteboard. Accessed 9 May 2020.
• [Microsoft Teams admin documentation.] Microsoft, n.d., docs.microsoft.com/en-us/MicrosoftTeams/teams-overview. Accessed 29 Apr. 2020.
• “Overview of teams and channels in Microsoft Teams.” Microsoft, 9 Mar. 2020, docs.microsoft.com/en-us/MicrosoftTeams/teams-channels-overview. Accessed 4 May 2020.
• “Private channels in Microsoft Teams.” Microsoft, 24 Feb. 2020, docs.microsoft.com/en-us/MicrosoftTeams/private-channels. Accessed 30 Apr. 2020.

Section 2: Teams for End Users › Meetings and Live Events

• “Admin quick start – Meetings and live events in Microsoft Teams.” Microsoft, 7 Apr. 2020, docs.microsoft.com/en-us/microsoftteams/quick-start-meetings-live-events. Accessed 21 Apr. 2020.
• “Get started with Microsoft Teams live events.” Microsoft, n.d., support.office.com/en-us/article/get-started-with-microsoft-teams-live-events-d077fec2-a058-483e-9ab5-1494afda578a#bkmk_roles. Accessed 29 Apr. 2020.
• “Schedule a Teams live event.” Microsoft, n.d., support.microsoft.com/en-us/office/schedule-a-teams-live-event-7a9ce97c-e1cd-470f-acaf-e6dfc179a0e2. Accessed 29 Apr. 2020.
• “Search the audit log for events in Microsoft Teams.” Microsoft, 12 Mar. 2018, docs.microsoft.com/en-us/microsoftteams/audit-log-events?view=o365-worldwide. Accessed 30 Apr. 2020.

Section 2: Teams for End Users › Use Cases

• “Understand calling in Microsoft Teams.” Microsoft, n.d., docs.microsoft.com/en-us/microsoftteams/tutorial-calling-in-teams. Accessed 9 May 2020.

Implement Hardware Asset Management

Build IT services value on the foundation of a proactive asset management program.

ANALYST PERSPECTIVE

IT asset data impacts the entire organization. It’s time to harness that potential.

"Asset management is like exercise: everyone is aware of the benefits, but many struggle to get started because the process seems daunting. Others fail to recognize the integrative potential that asset management offers once an effective program has been implemented.

A proper hardware asset management (HAM) program will allow your organization to cut spending, eliminate wasteful hardware, and improve your organizational security. More data will lead to better business decision-making across the organization.

As your program matures and your data gathering and utility improves, other areas of your organization will experience similar improvements. The true value of asset management comes from improved IT services built upon the foundation of a proactive asset management program." - Sandi Conrad, Practice Lead, Infrastructure & Operations Info-Tech Research Group

Our understanding of the problem

This Research Is Designed For:

• Asset Managers and Service Delivery Managers tasked with developing an asset management program who need a quick start.
• CIOs and CFOs who want to reduce or improve budgeting of hardware lifecycle costs.
• Information Security Officers who need to mitigate the risk of sensitive data loss due to insecure assets.

This Research Will Help You:

• Develop a hardware asset management (HAM) standard operating procedure (SOP) that documents:
  • Process roles and responsibilities.
  • Data classification scheme.
  • Procurement standards, processes, and workflows for hardware assets.
  • Hardware deployment policies, processes, and workflows.
  • Processes and workflows for hardware asset security and disposal.
• Identify requirements for an IT asset management (ITAM) solution to help generate a shortlist.
• Develop a hardware asset management implementation roadmap.
• Draft a communication plan for the initiative.

Executive summary

Situation

• Executives are aware of the numerous benefits asset management offers, but many organizations lack a defined ITAM program and especially a HAM program.
• Efforts to implement HAM are stalled because organizations cannot establish and maintain defined processes and policies.

Complication

• Organizations often implement an asset management program as a one- off project and let it stagnate, but asset management needs to be a dynamic, continually involving process to succeed.
• Organizations often fail to dedicate adequate resources to the HAM process, leading to unfinished processes and inconsistent standards.
• Hardware asset management programs yield a large amount of useful data. Unfortunately, this data is often underused. Departments within IT become data siloes, preventing effective use of the data.

Resolution

• As the IT environment continues to change, it is important to establish consistency in the standards around IT asset management.
• A current state assessment of your HAM program will shed light on the steps needed to safeguard your processes.
• Define the assets that will need to be managed to inform the scope of the ITAM program before defining processes.
• Build and involve an ITAM team in the process from the beginning to help embed the change.
• Define standard policies, processes, and procedures for each stage of the hardware asset lifecycle, from procurement through to disposal.
• Pace yourself; a staged implementation will make your ITAM program a success.

Info-Tech Insight

1. HAM is more than just tracking inventory. A mature asset management program provides data for proactive planning and decision making to reduce operating costs and mitigate risk.
2. ITAM is not just IT. IT leaders need to collaborate with Finance, Procurement, Security, and other business units to make informed decisions and create value across the enterprise.
3. Treat HAM like a process, not a project. HAM is a dynamic process that must react and adapt to the needs of the business.

Implement HAM to reduce and manage costs, gain efficiencies, and ensure regulatory compliance

Save & Manage Money

• Companies with effective HAM practices achieve cost savings through redeployment, reduction of lost or stolen equipment, power management, and on-time lease returns.
• The right HAM system will enable more accurate planning and budgeting by business units.

Improve Contract Management

• Real-time asset tracking to vendor terms and conditions allows for more effective negotiation.

Inform Technology Refresh

• HAM provides accurate information on hardware capacity and compatibility to inform upgrade and capacity planning

Gain Service Efficiencies

• Integrating the hardware lifecycle with the service desk will enable efficiencies through Install/Moves/Adds/Changes (IMAC) processes, for larger organizations.

Meet Regulatory Requirements

• You can’t secure organizational assets if you don’t know where they are! Meet governance and privacy laws by knowing asset location and that data is secure.

Prevent Risk

• Ensure data is properly destroyed through disposal processes, track lost and stolen hardware, and monitor hardware to quickly identify and isolate vulnerabilities.

HAM is more than just inventory; 92% of organizations say that it helps them provide better customer support

Hardware asset management (HAM) provides a framework for managing equipment throughout its entire lifecycle. HAM is more than just keeping an inventory; it focuses on knowing where the product is, what costs are associated with it, and how to ensure auditable disposition according to best options and local environmental laws.

Implementing a HAM practice enables integration of data and enhancement of many other IT services such as financial reporting, service management, green IT, and data and asset security.

Cost savings and efficiency gains will vary based on the organization’s starting state and what measures are implemented, but most organizations who implement HAM benefit from it. As organizations increase in size, they will find the greatest gains operationally by becoming more efficient at handling assets and identifying costs associated with them.

A 2015 survey by HDI of 342 technical support professionals found that 92% say that HAM has helped their teams provide better support to customers on hardware-related issues. Seventy-seven percent have improved customer satisfaction through managing hardware assets. (HDI, 2015)

HAM delivers cost savings beyond only the procurementstage

HAM cost savings aren’t necessarily realized through the procurement process or reduced purchase price of assets, but rather through the cost of managing the assets.

HAM delivers cost savings in several ways:

• Use a discovery tool to identify assets that may be retired, redeployed, or reused to cut or reallocate their costs.
• Enforce power management policies to reduce energy consumption as well as costs associated with wasted energy.
• Enforce policies to lock down unauthorized devices and ensure that confidential information isn’t lost (and you don’t have to waste money recovering lost data).
• Know the location of all your assets and which are connected to the network to ensure patches are up to date and avoid costly security risks and unplanned downtime.
• Scan assets to identify and remediate vulnerabilities that can cause expensive security attacks.
• Improve vendor and contract management to identify areas of hardware savings.

The ROI for HAM is significant and measurable

1. Weigh the return against the annual cost of investing in an ITAM solution to calculate the ROI.
2. Don’t forget about the intangible benefits that are more difficult to quantify but still significant, such as increased visibility into hardware, more accurate IT planning and budgeting, improved service delivery, and streamlined operations.

Avoid these common barriers to ITAM success

Organizations that struggle to implement ITAM successfully usually fall victim to these barriers:

Organizational resistance to change

Senior-level sponsorship, engagement, and communication is necessary to achieve the desired outcomes of ITAM; without it, ITAM implementations stall and fail or lack the necessary resources to deliver the value.

Lack of dedicated resources

ITAM often becomes an added responsibility for resources who already have other full-time responsibilities, which can quickly cause the program to lose focus. Increase the chance of success through dedicated resources.

Focus on tool over process

Many organizations buy a tool thinking it will do most of the work for them, but without supporting processes to define ITAM, the data within the tool can become unreliable.

Choosing a tool or process that doesn’t scale

Some organizations are able to track assets through manual discovery, but as their network and user base grows, this quickly becomes impossible. Choose a tool and build processes that will support the organization as it grows.

Using data only to respond to an audit without understanding root causes

Often, organizations implement ITAM only to the extent necessary to achieve compliance for audits, but without investigating the underlying causes of non-compliance and thus not solving the real problems.

To help you make quick progress, Info-Tech Research Group parses hardware asset management into essential processes

Focus on hardware asset lifecycle management essentials:

IT Asset Procurement:

• Define procurement standards for new hardware along with related warranties and support options.
• Develop processes and workflows for purchasing and work out financial implications to inform budgeting later.

IT Asset Intake and Deployment:

• Define policies, processes, and workflows for hardware and receiving, inventory, and tracking practices.
• Develop processes and workflows for managing imaging, change and moves, and large-scale rollouts.

IT Asset Security and Maintenance:

• Develop processes, policies, and workflows for asset tracking and security.
• Maintain contracts and agreements.

IT Asset Disposal or Recovery:

• Manage the employee termination and equipment recovery cycle.
• Securely wipe and dispose of assets that have reached retirement stage.

Follow Info-Tech’s methodology to build a plan to implement hardware asset management

Asset management is a key piece of Info-Tech's COBIT- inspired IT Management and Governance Framework

Cisco IT reduced costs by upwards of $50 million through implementing ITAM

CASE STUDY

Industry IT

Source Cisco Systems, Inc.

Cisco Systems, Inc.

Cisco Systems, Inc. is the largest networking company in the world. Headquartered in San Jose, California, the company employees over 70,000 people.

Asset Management

As is typical with technology companies, Cisco boasted a proactive work environment that encouraged individualism amongst employees. Unfortunately, this high degree of freedom combined with the rapid mobilization of PCs and other devices created numerous headaches for asset tracking. At its peak, spending on hardware alone exceeded $100 million per year.

Results

Through a comprehensive ITAM implementation, the new asset management program at Cisco has been a resounding success. While employees did have to adjust to new rules, the process as a whole has been streamlined and user-satisfaction levels have risen. Centralized purchasing and a smaller number of hardware platforms have allowed Cisco to cut its hardware spend in half, according to Mark Edmondson, manager of IT services expenses for Cisco Finance.

This case study continues in phase 1

Info-Tech delivers: Use our tools and templates to accelerate your project to completion

HAM Standard Operating Procedures (SOP)

HAM Maturity Assessment

Non-Standard Hardware Request Form

HAM Visio Process Workflows

HAM Policy Templates

HAM Budgeting Tool

HAM Communication Plan

HAM Implementation Roadmap Tool

Measured value for Guided Implementations (GIs)

Engaging in GIs doesn’t just offer valuable project advice, it also results in significant cost savings.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation overview

Workshop overview

Contact your account representative or email Workshops@InfoTech.comfor more information.

Phase 1

Lay Foundations

Implement Hardware Asset Management

A centralized procurement process helped cut Cisco’s hardware spend in half

CASE STUDY

Industry IT

Source Cisco Systems, Inc.

Challenge

Cisco Systems’ hardware spend was out of control. Peaking at $100 million per year, the technology giant needed to standardize procurement processes in its highly individualized work environment.

Users had a variety of demands related to hardware and network availability. As a result, data was spread out amongst multiple databases and was managed by different teams.

Solution

The IT team at Cisco set out to solve their hardware-spend problem using a phased project approach.

The first major step was to identify and use the data available within various departments and databases. The heavily siloed nature of these databases was a major roadblock for the asset management program.

This information had to be centralized, then consolidated and correlated into a meaningful format.

Results

The centralized tracking system allowed a single point of contact (POC) for the entire lifecycle of a PC. This also created a centralized source of information about all the PC assets at the company.

This reduced the number of PCs that were unaccounted for, reducing the chance that Cisco IT would overspend based on its hardware needs.

There were still a few limitations to address following the first step in the project, which will be described in more detail further on in this blueprint.

This case study continues in phase 2

Step 1.1: Assess current state and plan scope

Phase 1: Assess & Plan

1.1 Assess current state & plan scope

1.2 Build team & define metrics

This step will walk you through the following activities:

1.1.1 Complete MGD (optional)

1.1.2 Outline hardware asset management challenges

1.1.3 Conduct HAM maturity assessment

1.1.4 Classify hardware assets to define scope of the program

This step involves the following participants:

• CIO/CFO
• IT Director
• Asset Manager
• Purchasing
• Service Desk Manager
• Security (optional)
• Operations (optional)

Step Outcomes

• Understand key challenges related to hardware asset management within your organization to inform program development.
• Evaluate current maturity level of hardware asset management components and overall program to determine starting point.
• Define scope for the ITAM program including list of hardware to track as assets.

Complete the Management & Governance Diagnostic (MGD) to weigh the effectiveness of ITAM against other services

1.1.1 Optional Diagnostic

The MGD helps you get the data you need to confirm the importance of improving the effectiveness of your asset management program.

The MGD allows you to understand the landscape of all IT processes, including asset management. Evaluate all team members’ perceptions of each process’ importance and effectiveness.

Use the results to understand the urgency to change asset management and its relevant impact on the organization.

Establish process owners and hold team members accountable for process improvement initiatives to ensure successful implementation and realize the benefits from more effective processes.

To book a diagnostic, or get a copy of our questions to inform your own survey, visit Info-Tech’s Benchmarking Tools, contact your account manager, or call toll-free 1-888-670-8889 (US) or 1-844-618-3192 (CAN).

Sketch out challenges related to hardware asset management to shape the direction of the project

Common HAM Challenges

Processes and Policies:

• Existing asset management practices are labor intensive and time consuming
• Manual spreadsheets are used, making collaboration and automation difficult
• Lack of HAM policies and standard operating procedures
• Asset management data is not centralized
• Lack of clarity on roles and responsibilities for ITAM functions
• End users don’t understand the value of asset management

Tracking:

• Assets move across multiple locations and are difficult to track
• Hardware asset data comes from multiple sources, creating fragmented datasets
• No location data is available for hardware
• No data on ownership of assets

Security and Risk:

• No insight into which assets contain sensitive data
• There is no information on risks by asset type
• Rogue systems need to be identified as part of risk management best practices
• No data exists for assets that contain critical/sensitive data

Procurement:

• No centralized procurement department
• Multiple quotes from vendors are not currently part of the procurement process
• A lack of formal process can create issues surrounding employee onboarding such as long lead times
• Not all procurement standards are currently defined
• Rogue purchases create financial risk

Receiving:

• No formal process exists, resulting in no assigned receiving location and no assigned receiving role
• No automatic asset tracking system exists

Disposal:

• No insight into where disposed assets go
• Formal refresh and disposal system is needed

Contracts:

• No central repository exists for contracts
• No insight into contract lifecycle, hindering negotiation effectiveness and pricing optimization

Outline hardware asset management challenges

1.1.1 Brainstorm HAM challenges

Participants

• CIO/CFO
• IT Director
• Asset Manager
• Purchasing
• Service Desk Manager
• Security
• Operations (optional)

A. As a group, outline the hardware asset management challenges facing the organization.

Use the previous slide to help you get started. You can use the following headings as a guide or think of your own:

• Processes and Policies
• Tracking
• Procurement
• Receiving
• Security and Risk
• Disposal
• Contracts

B. If you get stuck, use the Hardware Asset Management Maturity Assessment Tool to get a quick view of your challenges and maturity targets and kick-start the conversation.

To be effective with hardware asset management, understand the drivers and potential impact to the organization

Each level of HAM maturity comes with its own unique challenges

Conduct a hardware maturity assessment to understand your starting point and challenges

1.1.3 Complete HAM Maturity Assessment Tool

Complete the Hardware Asset Management Maturity Assessment Tool to understand your organization’s overall maturity level in HAM, as well as the starting maturity level aligned with each step of the blueprint, in order to identify areas of strength and weakness to plan the project. Use this to track progress on the project.

An effective asset management project has four essential components, with varying levels of management required

The hardware present in your organization can be classified into four categories of ascending strategic complexity: commodity, inventory, asset, and configuration.

Commodity items are devices that are low-cost, low-risk items, where tracking is difficult and of low value.

Inventory is tracked primarily to identify location and original expense, which may be depreciated by Finance. Typically there will not be data on these devices and they’ll be replaced as they lose functionality.

Assets will need the full lifecycle managed. They are identified by cost and risk. Often there is data on these devices and they are typically replaced proactively before they become unstable.

Configuration items will generally be tracked in a configuration management database (CMDB) for the purpose of enabling the support teams to make decisions involving dependencies, configurations, and impact analysis. Some data will be duplicated between systems, but should be synchronized to improve accuracy between systems.

See Harness Configuration Management Superpowers to learn more about building a CMDB.

Classify your hardware assets to determine the scope and strategy of the program

Asset: A unique device or configuration of devices that enables a user to perform productive work tasks and has a defined location and ownership attributes.

• Hardware asset management involves tracking and managing physical components from procurement through to retirement. It provides the base for software asset management and is an important process that can lead to improved lifecycle management, service request fulfillment, security, and cost savings through harvesting and redeployment.
• When choosing your strategy, focus on those devices that are high cost and high risk/function such as desktops, laptops, servers, and mobile devices.

ASSET - Items of high importance and may contain data, such as PCs, mobile devices, and servers.

INVENTORY - Items that require significant financial investment but no tracking beyond its existence, such as a projector.

COMMODITY - Items that are often in use but are of relatively low cost, such as keyboards or mice.

Classify your hardware assets to define the scope of the program

1.1.4 Define the assets to be tracked within your organization

Participants

• Participants
• CIO/CFO
• IT Director
• Asset Manager
• Purchasing
• Service Desk Manager
• Security (optional)
• Operations (optional)

Document