Introduction

In Chapter 1, we covered the history of project management and discussed the concept of project management as it relates to IT services and software delivery. Since the 20th century, project management has been a competency and an area of knowledge that is widely adopted in IT. Whether teams deliver software or provide ongoing IT support, they need to manage their time according to the deliverables – software products enabling specific functionality or software products that allow them to manage all aspects of their business (for organizations) or their life (for individual clients).

Frequently, people think of the IT industry when they think about computer science and software delivery; however, in fact, software development and IT services cover absolutely all aspects of our life – from designing spaceships to performing complex surgery or managing activities on our calendars. Each of these activities requires products – software for aircraft design, calculations for fuel, and user interface for calendar management. In the real world, we are surrounded by software products. Each product enables us to perform specific functions, and this is why we refer to the product life cycle – from envisioning to adoption and then sunsetting once it is replaced by higher functional and more modern products with similar or higher capabilities.

A project, on the other hand, is a specific effort with the deliverables outlined in the beginning. For example, a compliance project could be created as a result of an audit check to implement the changes outlined in the audit and resolve all the issues listed there by a specific date. Projects have a defined start and a finish date, while product life cycle is dependent on the market and provides flexibility to address customer and market demands on a rolling basis. In modern project management, project-based thinking (specific deliverables done one by one) is replaced by long-term thinking based on the flexible understanding of customer needs within a constantly changing landscape.

Chapter 2 covers the most important starting point of any initiative – whether it is a new project of a specific scope or a brand-new product being launched via a startup or in a corporate setting – establishing a shared understanding of why this is being done and what are the measures of success.

In traditional project management, this is being done by establishing a Project Charter. PMBOK defines a project charter as a document issued by the project initiator or sponsor that formally authorizes the existence of a project and identifies key resources and deliverables. Project Charter usually is a one-pager providing the project name, one-line description, listing sponsor(s), key stakeholders, and team members, stating business objectives and key milestones, and managing risks and constraints. In Agile, charters are not frequently used since flexibility is implied from the beginning. However, for larger product initiatives, team charters or product charters are sometimes used to establish a baseline understanding and connection between the team and stakeholders. Instead of defining timelines and deliverables, Agile Charter establishes a vision and a mission, outlines the minimum viable product (MVP), describes major resources and repositories, and summarizes stakeholder expectations.

The goal of this chapter is to start with the vision and mission for your product and discuss mechanisms of establishing clear and unambiguous success criteria along with the ways of measuring progress against those. This allows to align deliverables with the vision and mission as well as establish clear ways of measuring progress toward achieving those.

Simon Sinek is a bestselling author who understands the power of starting with why. He shares an example of TiVo, a great product that did not address the why. It was launched in 1999 and marketed as a digital video recorder that was able to pause live TV, skip commercials, rewind live TV, and memorize an individual’s viewing habits. It was a high-quality product, and it was well funded. However, commercially, it was not successful. Some analysts thought it was a few years ahead of its time. This is not so. The major reason for that is that instead of a vision, they had a list of features. If they said: we want to give you full control over what you watch and how, and this tool provides you with the ability to be in control. After this “why,” they could have listed the same features: pausing live TV, skipping commercials, and others, but they failed to do so. Establishing “why” is the first step in positioning your product or project for success – it inspires the Scrum team and the customers alike. This concept lies at the start of any software product or service delivery.

Organizational Mission and Vision

Each organization, from a startup to a corporation, has its mission. The mission statement is a formal summary of the aims and values of the organization, an explanation of why it exists. It shapes the products that the company creates and the behaviors of its employees. Customers take their perception of the mission statement in making purchasing decisions related to the company’s products vs. their competitors as much as the features of the products themselves. Companies that have compelling mission statements that resonate with their customers create products that achieve success in the market.

A mission statement is closely connected to its vision. Vision is focused on tomorrow and describes the desired future position of the company and what it wants to become. According to multiple studies, organizations that align their mission and vision statements with their strategic planning perform significantly better than those that do not take their mission and vision statements that seriously. As stated by John Kotter, a Harvard University professor and a thought leader in organizational change management, “a vision always goes beyond the numbers that are typically found in five-year plans. A vision says something that helps clarify the direction in which an organization needs to move” [1].

When creating corporate mission statements, it is important to share a compelling outcome with current or future customers. For example, Southwest Airlines’ mission statement emphasizes customer service linked to employee behavior and corporate image. It states: “Connect people to what’s important in their lives through friendly, reliable, and low-cost air travel.” Southwest Airlines’ corporate vision is “to be the world’s most loved, most efficient, and most profitable airline.” It reflects the company's long-term strategy to expand its operations globally and to achieve significant growth while continuing to be people oriented and service focused [2].

 Topic for a Group Discussion

In groups, review two to three vision and mission statements of well-known companies and reflect whether they resonate with you or not. Suggest ways to rewrite those that need improvement. Some of the examples:

InVision is the digital product design platform used to make the world's best customer experiences. We provide design tools and educational resources for teams to navigate every stage of the product design process, from ideation to development.

Apple mission statement is “to bring the best user experience to its customers through its innovative hardware, software, and services.”

Google company mission is to organize the world's information and make it universally accessible and useful.

In the 20th century, the company's mission and vision would not be directly relevant to IT professionals who saw their role in developing, testing, and delivering high-quality code, no matter which industry and which mission they supported. Nowadays, IT professionals are direct drivers of business success, and their contribution to and support of the company’s mission and vision are paramount to business success.

Frequently, even for technology companies, their mission and vision are not driven by technology; it’s driven by people and positive change to the society. Microsoft’s mission statement is “to enable people and businesses throughout the world to realize their full potential.” Vision statements change over time, though not frequently, to reflect rapidly changing reality. For example, Microsoft’s original vision was “A computer on every desk and in every home.”

  Exercise

 Match mission statements to the company name in the following examples:

1. We believe in a world where everyone can contribute. Our mission is to change all creative work from read-only to read-write. When everyone can contribute, consumers become contributors and we greatly increase the rate of human progress.     2. We foster an inclusive environment that leverages the diverse backgrounds and perspectives of all our employees, suppliers, customers, and partners to drive a sustainable global competitive advantage.	Samsung Electronics, Oracle, Intel, Alphabet, GitLab
3. Delight our customers, employees, and shareholders by relentlessly delivering the platform and technology advancements that become essential to the way we work and live.
4. Mission is to make the world around us universally accessible and useful.
5. We will devote our human resources and technology to create superior products and services, thereby contributing to a better global society.

Answer Key: 1 – GitLab, 2 – Oracle, 3 – Intel, 4 – Alphabet, 5 – Samsung Electronics

Product Vision

Within each organization, there are multiple products and services. For example, Atlassian products include Jira Software, Jira Service Desk, Jira Core, Confluence, Bitbucket, Trello, and Jira Align. Each of the products has its own vision that drives its delivery.

A product vision statement describes the overarching long-term mission of a product. Vision statements are aspirational in nature. They concisely communicate what the product will achieve in the long term. Product definition will be reviewed in detail in Chapter 3, but for the purposes of defining organizational strategy, it is important to understand how product vision is derived from the organizational mission and vision.

To formulate the product statement, use the following “elevator pitch” template introduced by Geoffrey Moore in his book Crossing the Chasm (2). An elevator pitch is a short description of a product that explains the concept of this product in such a way that any listener can understand it in a short period of time. The goal is to convey the overall product concept in an exciting, clear, and concise way. The name – elevator pitch – reflects the idea that if an employee gets into an elevator with a business executive, it should be possible to deliver the summary in the time span of an elevator ride. The template for the product vision suggested by Geoffrey Moore is provided below.

This template reflects the product’s value proposition by summarizing the customer segment, competitor targets, and the core differentiation of the product from the competitor offerings.

It is important that the elevator pitch is compelling and reflects customer value rather than technical implementation. For example, for Intuit tax software, TurboTax, the product statement would emphasize the value of saving time and money for individuals to dedicate to their families rather than providing spreadsheets to calculate annual taxes. A compelling product vision statement would sound like “For the family members responsible for the annual tax return, who spend a lot of time and effort to prepare their taxes and frequently make mistakes that need to be corrected afterward, TurboTax provides a fast and worry-free way of preparing their annual tax return. Unlike other tax preparation software, TurboTax is inexpensive, intuitive, and easy to use.”

 Topic for a Group Discussion

In groups, create a product statement for one of the products you all know – use any electronic or software product that all team members are aware of. Read your statement to other teams without naming the product and see whether they can get what the product is. If it is easier to guess, your product statement is adequate. If not, discuss how to change it in order to represent the product in a clear, concise, and non-ambiguous way.

Objectives and Key Results (OKRs)

Throughout this chapter, we started with the company’s mission and vision, then moved to the product-level “elevator pitch,” and now arrived at defining strategic objectives.

Every product should have a set of well-defined quantifiable objectives shared across all the stakeholders so that everyone has a shared understanding of the “true north” – how success will look like. As with everything in Agile product management, OKRs may change if the market situation changes or any major enterprise-level decisions are made; however, those are usually quite stable for the period they are set up, with any change being discussed, aligned, and communicated to a broad group of stakeholders.

OKRs are a popular concept nowadays. There are opinions that OKR is a buzzword for “key performance indicators” (KPIs) or even for “management by objective” (or MBO), described by Peter Drucker in his 1954 book The Practice of Management [3]. Management by objective refers to a process of defining specific goals within an organization that management can convey to organization members, followed by the decision about who will be responsible for achieving each objective in sequence and how. An integral part of MBO is the measurement of an employee’s performance and comparing it with the previously established management expectations.

In fact, OKRs are as far from MBO as the Agile mindset from Waterfall project management. MBO is about top-down management, and OKRs are about self-organization; MBO is about individuals, and OKRs are about high-performing teams; MBO is about performance, and OKRs are about outcomes. MBOs were a tool that worked over 50 years ago; OKRs work today.

The reason why OKRs work is because they are about motivation (people are setting objectives that they are passionate about); they are about collaboration (people who have similar passion collaborate to achieve results); they are about innovation (no one tells them how to do things and achieve the results they chose), and furthermore, they are measurable (3). OKRs are aligned across the organization so that everyone has a chance to contribute.

OKRs have been around since the 1970s. The concept was invented by Andy Grove at Intel. Andy Grove used to say “Leaders have to act more quickly today. The pressure comes much faster.” OKRs fueled Intel’s ability to respond fast to market needs by aligning on jointly set objectives. This concept was made popular by John Doerr, who was one of the earliest investors in Google. OKRs quickly became an important focus for Google, and companies such as LinkedIn, Twitter, Dropbox, Spotify, Airbnb, and Uber have since followed suit.

John Doerr suggests the following template to use while setting OKRs: I will (Objective) as measured by (this set of Key Results). As the name implies, there are two components, objectives and key results. As Marissa Mayer, former Google Vice President, said, “if it does not have a number, it is not a key result.” The objective should be simple, aspirational, and easy to relate to and memorize. Key results should be no less than two and no more than five, specific, and measurable. Felipe Castro, one of the leading consultants in the OKR field, makes a great observation that if you have to stop breathing while reading your Objective, you are doing it wrong.

 Topic for a Group Discussion

Review the following OKR from GitLab:

OBJECTIVE – We will achieve market leadership for GitLab by

KEY RESULT 1 – The growing use of GitLab for all stages of the DevOps life cycle by 10% via establishing three proven case studies (Product)

KEY RESULT 2 – Ensuring appropriate transactional business pricing (Sales)

KEY RESULT 3 – Launching advertising for the customer base for Manage, Plan, Create and increase overall pipeline coverage by 8% (Marketing)

What do you think about this OKR? Does it follow best practices in terms of the number of key results, ability to quantify progress against each of those, clear ownership, and other best practices discussed before?

In sum, objectives are ambitious and qualitative. They are almost impossible to achieve fully. On the other hand, key results are specific and measurable. They can be quantified in one of the multiple ways:

OKRs are “cascading” throughout the organization – from company level to divisional, product, and team. Some companies introduce individual OKRs related to the professional growth of their employees. (See Figure 2-1.) It is important that OKRs are set and assessed by individuals who do the work rather than being imposed by the managers.

Once OKRs are established (usually annually), they are reviewed, self-graded, and adjusted (if needed) at least on a quarterly basis. OKRs have to be realistic but aspirational, almost impossible to achieve. They reflect outcomes (actual product or business deliverables, such as features delivered, number of users, or profitability data) vs. outputs (how many meetings the team had, how many hours they spent building the functionality, or how many bugs were fixed).

 Topic for a Group Discussion

Review the following OKR:

OBJECTIVE – Increase the efficiency of QA processes

KEY RESULT 1 – Test cases for all P1, P2 stories are completed and handed over to dev before development starts (compliance to be measured every Sprint)

KEY RESULT 2 – One week before the release date, no blockers and critical bugs should be open. Bug leakage to production for critical issues is less than 1%

KEY RESULT 3 – Less than three bugs reported by end users per release

What do you think about this OKR? How would you rewrite it to make it more meaningful?

Most companies use Google's self-grading scale from 0 (no progress has been made) to 1 (objective and all key results are fully achieved). They specify that since OKRs are highly aspirational, a grade of 0.6–0.7 or higher is considered a success. It is important to use OKRs as a visibility and alignment mechanism, rather than using this data for blaming teams and team members for not meeting the OKRs they have set for themselves. OKRs review sessions are a prompt to have a meaningful conversation about challenges, learnings, and continuous improvement opportunities.

In large organizations, cascading OKRs are frequently visualized from company level to product and team level. An example is provided in Figure 2-2.

 Five key questions to review:

1. 1.

   What is meant by DevOps?

    
2. 2.

   Why DevOps OKRs are important for business?

    
3. 3.

   What are the five architecture questions for each organization to address?

    
4. 4.

   What are DevOps competencies that may be measured via OKRs?

    
5. 5.

   Come up with a DevOps OKR for a well-known company and explain the value of this OKR to the business.

    

 Tip

OKRs cascade across the enterprise, thus aligning all functions and creating transparent outcomes. In order to provide full transparency at enterprise level, it is usually not sufficient to use spreadsheets, a collection of basic templates, or a common repository, such as SharePoint or Confluence. Large organizations are using online cloud-based tools to record, align, and grade their OKRs. Popular tools include Betterworks, Workboard, 7Geese, Perdoo, Weekdone, and many others. In addition, Agile management tools, such as Jira Align and Rally Software, provide cascading OKR functionality.

Four Steps in the Annual OKR-Setting and Alignment Process

There are four steps in the OKR process:

1. 1.

   OKR setting: This is done at the beginning of every year when organizational-level OKRs aligned with the company’s mission and vision are communicated, and the product teams and individuals engage in setting their OKRs, taking organizational-level OKRs into account. At this time, basic information is provided, as shown in Figure 2-3.

    

As a result of this process, the information is more detailed and validated within the organization, as shown in Figure 2-4.

1. 4.

   OKR iteration: Once OKRs are set, aligned, and refined, a review cadence is established, which allows the whole organization to review progress against OKRs with full transparency and traceability at the organizational level (see Figure 2-5).

    

I refer to this sequence as the SARI framework based on the first letters of each step – setting, alignment, refinement, and iteration. It is important that the SARI framework for OKRs is not sequential; it is cyclical – all steps repeat on a regular basis allowing for continuous alignment and ongoing value delivery as shown in Figure 2-6.

 Tip

Remember that OKRs are about outcomes, not about processes or activities. Setting up a process is not a good key result; we want to measure the objective why this process has been set up. Grading is seen here as a prompt to a conversation, not a punishment or a measure of performance. The worst OKRs are the ones that are ambiguous, for example, “achieve significant increase in performance,” “empower the teams to deliver applications to customers,” or “implement a new pricing strategy.”

Different organizations create their own practices of OKR adoption. One fact is absolutely clear: OKRs need to be managed. If OKRs are set once and reviewed at the end of the year, this framework becomes just another bureaucratic overhead for companies.

Overall, many companies see OKRs as a mechanism for setting their business and implementation objectives and aligning business, technology, and other organizational structures with the needs of their customers. OKRs are a way for IT professionals to erase the division between business and technology since this framework empowers developers, testers, and other engineers to deliver products and services that delight the customers.

While OKRs are a popular and powerful framework, many companies do not use OKRs and still deliver high-quality products and services that delight their customers. OKR framework is not a pre-requisite for success. However, a clear mission and vision, well-defined goals that drive prioritization, and quantified progress against these goals is a must for any successful company.

Key Points