Georgette C. Beatty

Article / Updated 05-03-2023

Building meaningful relationships starts with you. When remote employees join your team, what you do in the first 48 hours to welcome them to the group sets the standard for how the rest of the team will connect. Valuing the unique skills, abilities, and backgrounds of all your team members helps them feel appreciated and cared for. Openly encouraging dialogue, debate, and feedback provides the opportunity for contribution. All of these examples can help you to build a culture of connection and create a team of high-performing, happy remote workers. How to be a leader your virtual team wants to follow Chances are, you’ve had both good bosses and bad bosses, and you can probably easily explain the differences in approach, credibility, and style. Why not make the decision to be a leader that people choose to follow? Here are a few tips to help you: Don’t ask anyone to do anything that you wouldn’t do yourself. Don’t reinforce common hierarchy standards. If you want your team members to believe that you have their backs and aren’t above any type of work, prove it by stepping in when needed. Lead in alignment with a strong sense of purpose and values. Make sure your team knows what you stand for. Be vulnerable and courageous. It’s okay to acknowledge failure. Show your team that learning from mistakes is an opportunity to grow. Share information with your virtual team early and often. When you have new information, share it. Be as transparent as possible. Create space for innovative solutions to be considered. Be open to trying something that hasn’t been done before. Give people license to present new ways of doing things. Encourage creative thinking by using brainstorming in meetings. Be a skillful listener. Practice effective listening. Acknowledge what is being said by repeating back in your own words what you believe was the meaning behind the message. Practice self-care. Model healthy behaviors when working from home. Exercise, don’t text or email after 6 p.m., and check out when you take vacation. Get to know your virtual team members The challenge for the virtual leader is to transcend the boundaries of space and develop a supportive, collaborative connection with your team. Many of the best ways to establish a personal connection are also fun and sometimes even a little silly. Humor and laughter put people at ease and help you open up, so don’t brush aside these ideas immediately. Instead, figure out which ones you can try with your own team over the next few weeks: My Window: Ask team members to take a picture of what’s outside their window and upload it ahead of your virtual meeting. Team members share a story about what’s outside their window. Highs and Lows: Have each team member share a high and a low from the past week. TableTopics: Invest in a card deck of TableTopics (tabletopics.com) and ask questions that allow people to share their insights and opinions on different topics. Two Truths and a Lie: Use this activity to get people to share three things that the team wouldn’t know about them. Two of the facts are true and one is a lie. Your team members have to guess the lie. This activity always leads to some amazing discoveries about your team members. Our Global Team Map: Have a map of the world and a virtual pin in each location you have an employee. Ask your team members to share something unique about their country, city, or hometown. A Day in the Life: If your team is coming together for the first time, have your team members put together a collage about their lives that includes their families or friends, hobbies, pets, favorite movies, favorite books, and so on. Dine Together: This is another great idea to get to know more about someone’s heritage or ethnicity. Have each team member share a favorite family dinner recipe. Once a quarter, send a grocery list and gift card to each team member to buy the ingredients and cook the recipe. Have a virtual dinner together while your team member shares information and interesting facts about her family recipe. Reach out and build rapport with your virtual team A key reason to take the time to connect with your virtual team members is to build rapport. Building a sense of camaraderie on your virtual team or increasing accountability and engagement is impossible if you don’t have a plan for reaching out and staying connected. Effective virtual team leaders create time in their schedules for building relationships and rapport. They make a conscious effort every day to build more effective relationships. If you want to know how you’re doing, rate yourself on how well can you answer the following questions: How effectively are your team members meeting expected results and performance measures? What performance will be needed from them in three to six months given their role and where the business is headed? Are they prepared? What are their aspirations at work this year and in the future? What makes their work (and their objectives) meaningful and satisfying to them? Why are they here? What motivates them? What stresses them? How do they like to be recognized, acknowledged, and rewarded for a job well done? What limits them from delivering their best? What are their derailers? What support, tools, resources, skills, or empowerment do they need from you as their manager to be more effective? Adopt a reach-out strategy with your team to keep your finger on the pulse of what’s happening with each team member and make sure they’re getting the support and feedback they need to achieve their very best. Don’t try to adhere to a rigid schedule; instead, reach out as needed in 10-, 20-, or 30-minute sessions. The following table shows reach-out recommendations. Reach-Out Recommendations Reach-Out Timing Purpose How Often Questions 30 minutes Talent development/career advancement discussion. This reach-out needs an analysis conversation with a future focus. Quarterly Where are you? Where would you like to be? What do you love to do? When are you in the zone? How does this fit with our strategy? What is needed in the department and from your role to move the needle forward? What’s needed now? What’s needed in the next 18 months? What skills or experiences would you like to develop to help you grow in this role or in the future? What’s your plan for development and how can I support you in getting there? Based on our conversation, what will you start/stop/continue doing as a result? 20 minutes Tactical conversation with a current focus used to assess and support what tasks and projects they’re involved in that are making progress toward their goals and development plans. Monthly What opportunities exist right now on this project or task to move the needle? What one or two things are you focusing on to grow? What opportunities are available to develop the skills we discussed? How can I best support you? Based on our conversation, what will you start/stop/continue as a result? 10 minutes or less Feedback conversation with a just-in-time focus used to provide immediate feedback, coaching, and support. Weekly Can I sit in on this call with you? How about we brainstorm your approach with this customer/vendor/team member? Would you like to role-play how you’ll handle this conversation? Tell me how it went? What was challenging? How did you handle it? What feedback do you need from me? Based on our conversation, what will you start/stop/continue as a result?

Cheat Sheet / Updated 04-14-2022

It’s well known that you can’t take care of others unless you take care of yourself, and that statement rings even more true today. You can become calmer, more fulfilled, and more grounded with the help of a variety of self-care practices. These practices include mindfulness, self-compassion, resilience, fitness, clean eating, stress management, and reduced online activity.

Cheat Sheet / Updated 02-22-2022

Successful organizations create projects that produce desired results in established time frames with assigned resources. As a result, businesses are increasingly driven to find project managers who can excel in this type of work environment. To get started in project management, you should understand the phases of a project’s life cycle, processes involved in project management, and the basic tasks you’re expected to perform.

Cheat Sheet / Updated 02-08-2022

Starting and running your own business can be one of the greatest joys in life. It can also be the hardest thing you ever do. The fact that no one is going to be standing over your shoulder telling you what to do can be simultaneously exhilarating and frightening. Finding sources of inspiration for great business ideas can keep you going in the absence of that voice over your shoulder. Nailing down a handful of basic, fundamental practices can keep you on the right track. And getting a grip on the money constantly flowing in and out of your business is one of the big keys to success.

Article / Updated 12-17-2020

Product development teams and project managers need to evaluate whether teams are following agile principles and whether their actions and behaviors are consistent with agile values. The Agile Manifesto was generated from experience, not from theory. As you review the values described in the following discussion, consider what they would mean if you put them into practice. How do these values support meeting time-to-market goals, dealing with change, and valuing human innovation? Although the agile values and principles are not usually numbered, they are numbered here for ease of reference. The numbering matches their order in the manifesto. Value 1: Individuals and interactions over processes and tools When you allow each person to contribute his or her unique value to a product, the result can be powerful. When these human interactions focus on solving problems, a unified purpose can emerge. Moreover, the agreements come about through processes and tools that are much simpler than conventional ones. A simple conversation in which you talk through a product issue can solve many problems in a relatively short time. Trying to emulate the power of a direct conversation with email, spreadsheets, and documents results in significant overhead costs and delays. Instead of adding clarity, these types of managed, controlled communications are often ambiguous and time-consuming and distract the development team from the work of creating a product. Consider what it means if you value individuals and interactions highly. The table shows some differences between valuing individuals and interactions and valuing processes and tools. Individuals and Interactions Versus Processes and Tools Individuals and Interactions Have High Value Processes and Tools Have High Value Pros Communication is clear and effective. Communication is quick and efficient. Teamwork becomes strong as people work together. Development teams can self-organize. Development teams have more chances to innovate. Development teams can quickly adjust processes as necessary. Development team members can take personal ownership of the product. Development team members can have deeper job satisfaction. Processes are clear and can be easy to follow. Written records of communication exist. Cons To enable more team empowerment and less command and control, managers may have to unlearn traditional leadership tendencies. People may need to let go of ego to work well as members of a team. People may over-rely on processes instead of finding the best ways to create good products. One process doesn’t fit all teams — different people have different work styles. One process doesn’t fit all products. Communication can be ambiguous and time-consuming. If processes and tools are seen as the way to manage product development and everything associated with it, people and the way they approach the work must conform to the processes and tools. Conformity makes it hard to accommodate new ideas, new requirements, and new thinking. Agile approaches, however, value people over process. This emphasis on individuals and teams puts the focus on their energy, innovation, and ability to solve problems. You use processes and tools in agile product management, but they’re intentionally streamlined and directly support product creation. The more robust a process or tool, the more you spend on its care and feeding and the more you defer to it. With people front and center, however, the result is a leap in productivity. An agile environment is human-centric and participatory and can be readily adapted to new ideas and innovations. Value 2: Working software over comprehensive documentation A development team’s focus should be on producing working functionality. With agile development, the only way to measure whether you are truly finished with a product requirement is to produce the working functionality associated with that requirement. For software products, working software means the software meets the definition of done: at the very least, developed, tested, integrated, and documented. After all, the working product is the reason for the investment. Have you ever been in a status meeting where you reported that you were, say, 75 percent done with your project? What would happen if your customer told you, “We ran out of money. Can we have our 75 percent now?” On a traditional project, you wouldn’t have any working software to give the customer; 75 percent done traditionally means you are 75 percent in progress and 0 percent done. With agile product development, however, by using the definition of done, you would have working, potentially shippable functionality for 75 percent of your product requirements — the highest-priority 75 percent of requirements. Although agile approaches have roots in software development, you can use them for other types of products. This second agile value can easily read, “Working functionality over comprehensive documentation.” Tasks that distract from producing valuable functionality must be evaluated to see whether they support or undermine the job of creating a working product. Table 1-2 shows a few examples of traditional project documents and their usefulness. Think about whether documents produced on a recent project you were involved in added value to the functionality being delivered to your customer. Identifying Useful Documentation Document Does the Document Add to Product Value? Is the Document Barely Sufficient or Gold-Plated? Project schedule created with expensive project management software, complete with Gantt chart No. Start-to-finish schedules with detailed tasks and dates tend to provide more than what is necessary for product development. Also, many of these details change before you develop future features. Gold-plated. Although project managers may spend a lot of time creating and updating project schedules, team members tend to want to know only key deliverable dates. Management often wants to know only whether the deliverable is on time, ahead of schedule, or behind. Requirements documentation Yes. All products have requirements — details about product features and needs. Development teams need to know those needs to create a product. Possibly gold-plated; should be barely sufficient. Requirements documents can easily grow to include unnecessary details. Agile approaches provide simple ways to enable product requirement conversations. Product technical specifications Yes. Documenting how you created a product can make future changes easier. Possibly gold-plated; should be barely sufficient. Agile documentation includes just what it needs — development teams often don’t have time for extra flourishes and are keen to minimize documentation. Weekly status report No. Weekly status reports are for management purposes but do not assist product creation. Gold-plated. Knowing status is helpful, but traditional status reports contain outdated information and are much more burdensome than necessary. Detailed project communication plan No. Although a contact list can be helpful, the details in many communication plans are useless to product development teams. Gold-plated. Communication plans often end up being documents about documentation — an egregious example of busywork. With agile product development, barely sufficient is a positive description, meaning that a task, document, meeting, or almost anything created includes only what it needs to achieve the goal. Being barely sufficient is practical and efficient — it’s sufficient, just enough. The opposite of barely sufficient is gold-plating, or adding unnecessary frivolity — and effort — to a feature, task, document, meeting, or anything else. All development requires some documentation. With agile product development, documents are useful only if they support development and are barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting. Stop producing a document and see who complains. After you know the requester of the document, strive to better understand why the document is necessary. The five whys work great in this situation — ask “why” after each successive answer to get to the root reason cause for the document. After you know the core reason for the document, see how you can satisfy that need with an agile artifact or streamlined process. Agile teams produce fewer, more streamlined documents that take less time to maintain and provide better visibility into potential issues. You can create and use simple tools (such as a product backlog, a sprint backlog, and a task board) that allow teams to understand requirements and assess real-time status daily. With agile approaches, teams spend more time on development and less time on documentation, resulting in a more efficient delivery of a working product. Value 3: Customer collaboration over contract negotiation The customer is not the enemy. Really. Historical project management approaches usually limit customer involvement to a few development stages: Start of a project: When the customer and the project team negotiate contract details. Any time the scope changes during the project: When the customer and the project team negotiate changes to the contract. End of a project: When the project team delivers a completed product to the customer. If the product doesn’t meet the customer’s expectations, the project team and the customer negotiate additional changes to the contract. This historical focus on negotiation, avoidance of scope change, and limitation of direct customer involvement discourages potentially valuable customer input and can even create an adversarial relationship between customers and project teams. You will never know less about a product than at its start. Locking product details into a contract at the beginning of development means you have to make decisions based on incomplete knowledge. If you have flexibility for change as you learn more about a product and the customer the product is serving, you’ll ultimately create better products. The agile pioneers understood that collaboration, rather than confrontation, produced better, leaner, more useful products. As a result of this understanding, agile methods make the customer part of the product development on an ongoing basis. Using an agile approach in practice, you’ll experience a partnership between the customer and the development team in which discovery, questioning, learning, and adjusting during the course of product development are routine, acceptable, and systematic. Value 4: Responding to change over following a plan Change is a valuable tool for creating great products. Teams that can respond quickly to customers, product users, and the market are able to develop relevant, helpful products that people want to use. Unfortunately, traditional project management approaches attempt to wrestle the change monster and pin it to the ground so it goes out for the count. Rigorous change management procedures and budget structures that can’t accommodate new product requirements make changes difficult. Traditional project teams often find themselves blindly following a plan, missing opportunities to create more valuable products or, even worse, unable to react timely to changing market conditions. The figure shows the relationship between time, opportunity for change, and the cost of change on a traditional project. As time — and knowledge about your product — increases, the ability to make changes decrease, and costs more. By contrast, agile development accommodates change systematically. The flexibility of agile approaches increases stability because product changes are predictable and manageable — in other words, it’s expected and non-disruptive to an agile team. In the rest of Book 4, you discover how agile approaches to planning, working, and prioritization allow teams to respond quickly to change. As new events unfold, the team incorporates these realities into the ongoing work. Any new item becomes an opportunity to provide additional value instead of an obstacle to avoid, giving development teams a greater opportunity for success.

Article / Updated 10-31-2020

Agile planning happens at a number of points. A great way to look at planning activities is with the Roadmap to Value. The figure shows the roadmap as a whole. The Roadmap to Value has seven stages: In stage 1, the product owner identifies the product vision. The product vision is your product’s destination or end goal. The product vision includes the outer boundary of what your product will be, how the product is different than the competition, how the product will support your company or organization’s strategy, who will use the product, and why people will use the product. The product vision should be revisisted at least once a year. In stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a general time frame for when you will develop those requirements. It also gives context to the vision by showing the tangible features that will be produced during development. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. The product owner, with support from the development team, should revise the product roadmap at least biannually. In stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working functionality to the customer. The release serves as a mid-term boundary against which the scrum team can mobilize. Many releases may be required to accomplish the product vision and the highest-priority features should appear first. You create a release plan at the beginning of each release, which according to Principle 3 should be “frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale In stage 4, the product owner, the development team, and the scrum master will plan iterations, also called sprints, and start creating the product functionality in those sprints. Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, which establishes the immediate boundary of work that the team forecasts to accomplish during the sprint, with requirements that support the goal and can be completed in the sprint. The scrum team also outlines how to complete those requirements. In stage 5, the development team has daily scrum meetings during each sprint to coordinate the day’s priorities for accomplishing the sprint goal. In the daily scrum meeting, based on what was completed up to that point, you coordinate what you will work on today and any roadblocks, so that you can address issues immediately. In stage 6, the scrum team holds a sprint review at the end of every sprint. In the sprint review, you demonstrate the working product to the product stakeholders. In stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses the completed sprint with regard to their processes and environment and makes plans for process improvements in the next sprint. Like the sprint review for inspecting and adapting the product, a sprint retrospective is held at the end of every sprint to inspect and adapt your processes and environment. Each stage of the Roadmap to Value is repeatable and contains planning activities. Agile planning, like agile development, is iterative and barely sufficient. Progressive elaboration During each stage of product development, you plan only as much as you need to plan. In the early stages of your work, you plan widely and holistically to create a broad outline of how the product will shape up over time. In later stages, you narrow your planning and add more details to ensure success in the immediate development effort. This process is called a progressive elaboration of requirements. Planning broadly at first and in detail later, when necessary, prevents you from wasting time on planning lower-priority product requirements that may never be implemented. This model also lets you add high-value requirements during product development without disrupting the flow. The more just-in-time your detailed planning is, the more effective your planning becomes. Standish Group studies show that customers rarely or never use as much as 80 percent of the features in an application. In the first few development cycles of an agile product development effort, you complete features that have the highest priority and that people will use. Typically, you release those groups of features as early as possible to gain market share through first-mover advantage; receive customer feedback for viability; monetize functionality early to optimize return on investment (ROI); and avoid internal and external obsolescence. Inspect and adapt Just-in-time planning brings into play two fundamental tenets of agile techniques: Inspect and adapt. At each stage of development, you need to look at the product and the process (inspect) and make changes as necessary (adapt). Agile planning is a rhythmic cycle of inspecting and adapting. Consider the following: Each day during the sprint, the product owner provides feedback to help improve the product as the development team creates the product. At the end of each sprint, in the sprint review, stakeholders provide feedback to further improve the product. At the end of each sprint in the sprint retrospective, the scrum team discusses the lessons they learned during the past sprint to improve the development process. After a release, the customers can provide feedback for improvement. Feedback might be direct, when a customer contacts the company about the product, or indirect, when potential customers either do or don’t purchase the product. Together, inspect and adapt are fantastic tools for delivering the right product in the most efficient manner. At the beginning of development, you know the least about the product you’re creating, so trying to plan fine details at that time just doesn’t work. Being agile means you do the detailed planning when you need it, and immediately develop the specific requirements you defined with that planning. Remember the Agile Manifesto value: “Responding to change over following a plan.” After you know a little more about how agile planning works, it’s time to complete the first step: defining the product vision.

Article / Updated 10-31-2020

A project stakeholder is any person or group that supports, is affected by, or is interested in your project. Your project’s stakeholders can be inside or outside your organization, and knowing who they are helps you Plan whether, when, and how to involve them. Determine whether the scope of the project is bigger or smaller than you originally anticipated. A project stakeholder register is a living document. You need to start developing your register as soon as you begin thinking about your project. Begin your project’s stakeholder register by considering the initial version of the register that’s generated upon completion of the development of the project charter. (This charter authorizes the existence of a project and provides the project manager with the authority to use organizational resources to support the performance of project activities.) Next, write down any other names that occur to you. When you discuss your project with other people, ask them who they think may be affected by or interested in your project. Then select a small group of the stakeholders you identify and conduct a formal brainstorming session. Continue to add and subtract names to your stakeholder register until you can’t think of anyone else. Use specific categories To increase your chances of identifying all appropriate people, develop your stakeholder register in categories. You’re less likely to overlook people when you consider them department by department or group by group instead of trying to identify everyone from the organization individually at the same time. Start your stakeholder register by developing a hierarchical grouping of categories that covers the universe of people who may be affected by, be needed to support, or be interested in your project. You can start with the following groups: Internal: People and groups inside your organization Upper management: Executive-level management responsible for the general oversight of all organization operations Requesters: The person who came up with the idea for your project and all the people through whom the request passed before you received it Project manager: The person with overall responsibility for successfully completing the project End users: People who will use the goods or services the project will produce Team members: People assigned to the project whose work the project manager directs Groups normally involved: Groups typically involved in most projects in the organization, such as the human resources, finance, contracts, and legal departments Groups needed just for this project: Groups or people with special knowledge related to this project External: People and groups outside your organization Clients or customers: People or groups that buy or use your organization’s products or services Collaborators: Groups or organizations with whom you may pursue joint ventures related to your project Vendors, suppliers, and contractors: Organizations that provide personnel, raw materials, equipment, or other resources required to perform your project’s work Regulators: Government agencies that establish regulations and guidelines that govern some aspect of your project work Professional societies: Groups of professionals that may influence or be interested in your project The public: The local, national, and international community of people who may be affected by or interested in your project Continue to subdivide these categories further until you arrive at job titles (or position descriptions) and the names of the people who occupy them. (The process of systematically separating a whole into its component parts is called decomposition.) Consider stakeholders that are often overlooked As you develop your stakeholder register, be sure not to overlook the following potential stakeholders: Support groups: These people don’t tell you what you should do (or help you deal with the trauma of project management); instead, they help you accomplish the project’s goals. If support groups know about your project early, they can fit you into their work schedules more readily. They can also tell you information about their capabilities and processes that may influence what your project can accomplish and by when. Such groups include Facilities Finance Human resources Information technology (IT) Legal services Procurement or contracting Project management office Quality Security Help desks Call centers End users of your project’s products: End users are people or groups who will use the goods and services your project produces. Involving end users at the beginning of and throughout your project helps ensure that the goods and services produced are as easy as possible to implement and use, and are most responsive to their true needs. It also confirms that you appreciate the fact that the people who will use a product may have important insights into what it should look like and do, which increases the chances that they’ll work to implement the products successfully. In some cases, you may omit end users on your stakeholder register because you don’t know who they are. In other situations, you may think you have taken them into account through liaisons — people who represent the interests of the end users. (Check out the nearby sidebar “Discovering the real end users” for a costly example of what can happen when you depend solely on liaisons.) People who will maintain or support the final product: People who will service your project’s final products affect the continuing success of these products. Involving these people throughout your project gives them a chance to make your project’s products easier to maintain and support. It also allows them to become familiar with the products and effectively build their maintenance into existing procedures. Examine the beginning of a sample stakeholder register Suppose you’re asked to coordinate your organization’s annual blood drive. The image below illustrates some of the groups and people you may include in your project’s stakeholder register as you prepare for your new project.

Article / Updated 10-31-2020

Enterprise agility is agile for big products — typically one that requires many different teams throughout the organization that coordinate with many different departments and stakeholders. The best way to implement enterprise agility in your organization is to take the following three steps: Review the top enterprise agile frameworks. Identify your organization’s existing culture. Create a strategy for making big changes. This three-step process isn’t really unique to enterprise agile transformations; it’s pretty standard for making any large-scale organizational changes. You want to better understand the changes you’re proposing, then understand the environment in which you’re making the changes, and finally figure out how to apply these changes to your environment. Step 1: Review the top enterprise agile frameworks The first step toward an enterprise agile transformation is to understand what being agile means and get a sense of what different manifestations of agile look like. The fact is that you can achieve enterprise agility in an infinite number of different ways, just as you can use different health and fitness programs, mix-and-match programs, or develop your own program to become healthy and fit. A great way to start is to look at the top enterprise agile frameworks: SAFe, LeSS, DAD, the Spotify Engineering Culture, Kanban, and Lean. Collectively, they provide several frameworks and include numerous agile principles and practices. Simply by exploring the different frameworks, you will start to develop a more agile mindset and begin to appreciate the full scope of enterprise agility. As you explore the enterprise agile frameworks, try to look beyond each framework to understand the rationale behind it. If you can understand what the developers of each framework were thinking and the problems they were trying to solve, you will be well on your way to making the right decisions and choices for your organization. Remember, pulling a framework off the shelf may work fine, but be open to the possibility of tailoring it to your organization. No framework is a one-size-fits-all solution. Step 2: Identify your organization’s existing culture One of the biggest reasons organizations fail in their transformation effort is that they don’t take their existing culture into account. The problem is worst when an organization with a firmly embedded traditional management matrix tries to become more agile, because strong management tends to clash with some of agile’s emphasis on self-organizing teams. Organizations don’t intentionally ignore culture. They’re just so immersed in it that they no longer notice it. Culture is sort of like the air that surrounds us; we don’t notice the air until a cold front sweeps in. We don’t notice culture until it comes in contact with another culture, at which point cultural differences become readily apparent. You may not notice your organization’s culture until you try to change it to something that’s very different. Don’t make the common mistake of ignoring your existing culture, so size up your culture before attempting to transform it. Following are four common corporate culture types: Collaboration culture: Common in schools and professional training organizations, collaboration cultures are run like family businesses, with leaders acting as decision-makers, team builders, and coaches. Managers work closely together like a small group of friends, and the closer you are to the head of the organization, the more authority you have. These organizations are typically more open to change than those with a control or competence culture, so they tend to adopt an enterprise agile mindset more readily. However, in a collaboration culture, leadership may have a difficult time allowing decisions to be made at the team level. Competence culture: Those with the highest level of expertise rise to the top, become managers, and create and delegate tasks. A meritocracy. The management style is task-driven; it’s all about who can do the best job at finishing the work. People in competence cultures often become highly specialized in their areas of expertise, because expertise is what is valued and rewarded. If they excel in more than one area, they’re likely to be given too many tasks and become quickly overwhelmed, so they specialize. They also don’t like to share their knowledge, because it places them at risk of losing some of their authority. Control culture: This culture is authoritarian with alpha managers setting the direction and beta managers following close behind. Leadership gives orders and demands compliance. Only a few individuals in the organization have decision-making powers; others must seek approval or permission, making the organization slow to respond to change. Such organizations favor order and certainty and rely on large management systems that ensure predictable outcomes. Cultivation culture: Employee growth and development form the cornerstone of the organization. Managers seek to bring someone into the organization, hold them up, and then build them up. Charismatic individuals quickly rise to the top, and generalists commonly do well. These organizations tend to be more democratic and transition more easily to an agile mindset, but decision-making can be slow as consensus is sought among large groups of individuals. Consider choosing a framework that’s a closer match to your current culture than a match to the culture you want for your organization, so the transformation won’t be too much of a stretch. Some frameworks are much more agile than others. For example, Spotify’s approach gives teams a lot of autonomy, and that may strike you as the way you want your organization to be. However, Spotify’s approach works for Spotify, because it’s not a huge organization. Spotify has nurtured a collaborative culture from its inception, and the company redesigned its product’s architecture to make it more modular, so a squad can work on one feature without having to integrate its work with a lot of other squads and tribes. If your organization has a strong control culture, making the leap to Spotify’s approach may be as challenging as trying to jump across the Grand Canyon on a motorcycle. Instead, SAFe may be the better choice because it has more practices for top-down decision-making. It allows for some agility while giving managers deep insight and control over the organization. An organization may fit into more than one category; for example, its engineers may be driven more by a competence culture, whereas marketing is run more in line with a cultivation culture. The famous management consultant Peter Drucker once said that “Culture eats strategy for breakfast.” This holds true for enterprise agility. Whatever strategies you pick for your enterprise agile transformation, they won’t succeed without the support of a culture that values people, respect, trust, and innovation. Step 3: Create a strategy for making big changes As you think about your strategy for making big changes, look for the sweet spot between your organization’s acceptable and unacceptable change, as shown. Finding that sweet spot is more art than science. Identify areas you want to change and areas where you’re likely to encounter resistance. Try to understand why you may encounter resistance in certain areas. Your organization probably has gravitated toward a particular culture for good reasons, so you can decide whether and how an area needs to be changed. If a certain area is less agile for good reason, you may want to let it be. After you’ve found your sweet (and not so sweet) spots, you’re ready to start adopting the agile frameworks, processes, and principles you choose. Choosing a top-down or bottom-up strategy When you’re ready to start your enterprise agility adoption journey, you basically have two big-change strategies from which to choose: Fearless Change: A bottom-up approach, which can be driven by a few employees. Fearless Change tends to work better in competence, cultivation, and collaboration cultures. Fearless Change may also be effective in smaller, newer organizations that don’t yet have a deeply entrenched hierarchy. Kotter approach: An eight-step, top-down process driven by a change leader, who can be a manager or an outside consultant. The Kotter approach tends to work better in control cultures — the most common culture in large organizations, which typically have a well-defined hierarchy. Whichever strategy you choose, look for opportunities to make smaller, realistic changes. Instead of trying to force change on your organization all at once, win the war gradually, battle by battle. Pick the low-hanging fruit. Giving teams shared workspaces and providing agile training can get the culture ball rolling. Then, build on the momentum of your success. Mapping out your plan After you’ve thought about which approach is likely to work best, map out your plan. As you develop your change management plan, you’re likely to end up with an odd combination of general and specific. You’ll have specific deadlines of when to expect real improvement. Maybe you’ll have a concrete objective to have all your business analysts sit with your team in a shared workspace. But then you’ll have general guidelines on how to reach that objective. You may decide to have everyone in that shared workspace receive coaching on the benefits of sitting together. You could also just make it a simple matter of rearranging desks. This combination of specific and general guidance gives your plan enough structure to be useful, but enough flexibility to allow teams to adapt. No change management plan will survive implementation; that is, your plan will change as you implement it, and that’s okay. The trick is to spend just enough time planning to make your organization more agile, but not so much that you steal away time from the implementation or make your plan so restrictive that it undermines the agile mindset. Setting the stage for business agility A growing movement among businesses is to extend enterprise agility from product delivery to the entire organization in order to achieve business agility. This movement is really about “agile management” — taking agile ideas that have worked well for product development and using them to run an entire organization. Business agility is about “agilizing” every part of your organization. The best way to think about the relationship among agile, business agility, and enterprise agility is to look at them as three levels of agile implementation: Agile (at the team level): You have one-or-two agile teams working on a part of a larger product. Business agility: The entire organization adopts an agile mindset and a set of agile principles that guide the way everyone works independently and together. Enterprise agility: You have dozens or hundreds of agile teams working in concert on a single large product — an enterprise-level product. Some enterprise agile frameworks are simply expansions of team agile approaches; for example, SAFe is Scrum only with more Scrum teams and additional roles and structure to coordinate their work. In general, business agility deals with all domains, including those outside of product development, such as adaptive leadership, organizational design, and budgeting. While the more robust frameworks, including SAFe, touch on these domains, they offer little guidance to help you extend agile into these domains. It’s a little like old maps that put dragons in place of uncharted territory with the caption “there be dragons here.” They suggest that agility involves changes in other domains, but they don’t explicitly describe the changes or offer guidance on how to make those changes. Resist the urge to tackle all three circles at once. Start with a few agile teams. After finding success with those teams, try enterprise agility with a larger product. As you gain success with several teams working together to deliver a whole enterprise solution, you can begin to start thinking about using agile methodologies to rework your entire organization. Don’t try to rework your whole organization until you have a proven strategy for delivering enterprise-level products. Enterprise agility is not business agility. Enterprise agility is about delivering product. All the changes that you make to your organization in terms of frameworks, roles, processes, and practices should sit neatly within the realm of product development. Any changes you make to the overall organization or to organizational leadership will be in the realm of culture and mindset — to make management more receptive to an agile mindset and supportive of the big changes you’re introducing to product delivery. Stay focused on delivering better products and not on creating a better organization. Certainly, success in product delivery may lead to an expansion of agile to the entire organization, but start with product delivery and work your way up. You may find it strange to use practices that were designed for software development to run domains such as human resources, sales, marketing, or legal, but advocates of business agility argue that the accelerating pace of change demands that the entire organization become agile. Practicing shuhari Many of the agile and enterprise agile frameworks are influenced by Japanese manufacturing models developed to minimize waste and optimize workflow. Another common agile practice that comes from the Japanese is shuhari, a martial arts model of learning and honing one’s skills: Shu: Follow the rules and learn the basics. Ha: Start to break the rules and put your own learning in context. Ri: Create your own rules and find your own way. As you transition your organization’s product delivery to enterprise agility, follow the shuhari approach. Here’s how: Shu: Explore the top enterprise agility frameworks, principles, and practices to gain knowledge and wisdom of the commonly accepted approaches to enterprise agility. In other words, learn from the masters. Ha: Start thinking about how these approaches to enterprise agility would look in your organization. Think about them in the context of what’s already in place and in the context of your organization’s existing culture. What ideas make sense to you? Where do you think the developers may be wrong? Which ideas are likely to work well (and not so well) in your organization? Ri: Using all the knowledge and wisdom you’ve acquired, create your own custom framework tailored to your organization. Adopt the principles and practices that work best for your organization, mix and match, modify, and create your own. No two organizations are identical, and none of the enterprise agile frameworks is a one-size-fits-all solution. Use what works, toss what doesn’t, and keep your eye on the prize — delivering value to your customers while achieving your business goals. That’s what agile is all about.

Article / Updated 10-30-2020

Project management is the process of guiding a project from its beginning through its performance to its closure. Project management includes five sets of processes: Initiating processes: Clarifying the business need, defining high-level expectations and resource budgets, and beginning to identify audiences that may play a role in your project Planning processes: Detailing the project scope, time frames, resources, and risks, as well as intended approaches to project communications, quality, and management of external purchases of goods and services Executing processes: Establishing and managing the project team, communicating with and managing project audiences, and implementing the project plans Monitoring and controlling processes: Tracking performance and taking actions necessary to help ensure project plans are successfully implemented and the desired results are achieved Closing processes: Ending all project activity As illustrated, these five process groups help support the project through the four phases of its life cycle. Initiating processes support the work to be done when starting the project, and planning processes support the organizing and preparing phase. Executing processes guide the project tasks performed when carrying out the work, and closing processes are used to perform the tasks that bring the project to an end. The figure highlights how you may cycle back from executing processes to planning processes when you have to return to the organizing and preparing phase to modify existing plans to address problems you encounter or new information you acquire while carrying out the project work. Finally, you use monitoring and controlling processes in each of the four phases to help ensure that work is being performed according to plans. Successfully performing these processes requires the following: Information: Accurate, timely, and complete data for the planning, performance monitoring, and final assessment of the project Communication: Clear, open, and timely sharing of information with appropriate individuals and groups throughout the project’s duration Commitment: Team members’ personal promises to produce the agreed-upon results on time and within budget Project management: the initiating processes All projects begin with an idea. Perhaps your organization’s client identifies a need, or maybe your boss thinks of a new market to explore, or maybe you think of a way to refine your organization’s procurement process. Sometimes the initiating process is informal. For a small project, it may consist of just a discussion and a verbal agreement. In other instances, especially for larger projects, a project requires a formal review and decision by your boss and/or other members of your organization’s senior management team. Decision-makers consider the following two questions when deciding whether to move ahead with a project: Should we do it? Are the benefits we expect to achieve worth the costs we’ll have to pay? Are there better ways to approach the issue? Can we do it? Is the project technically feasible? Are the required resources available? If the answer to both questions is “Yes,” the project can proceed to the organizing and preparing phase, during which a project plan is developed. If the answer to either question is a definite, ironclad “No,” under no circumstances should the project go any further. If nothing can be done to make it desirable and feasible, the decision-makers should stop all work on the project immediately. Doing anything else guarantees wasted resources, lost opportunities, and a frustrated staff. Project management: the planning processes When you know what you hope to accomplish and you believe it’s possible, you need a detailed plan that describes how you and your team will make it happen. Include the following in your project-management plan: An overview of the reasons for your project. A detailed description of intended results. A list of all constraints the project must address. A list of all assumptions related to the project. A list of all required work. A breakdown of the roles you and your team members will play. A detailed project schedule. Needs for personnel, funds, and non-personnel resources (such as equipment, facilities, and information). A description of how you plan to manage any significant risks and uncertainties. Plans for project communications. Plans for ensuring project quality. Always put your project plans in writing; doing so helps you clarify details and reduces the chances that you’ll forget something. Plans for large projects can take hundreds of pages, but a plan for a small project can take only a few lines on a piece of paper (or a tablecloth!). The success of your project depends on the clarity and accuracy of your plan and on whether people believe they can achieve it. Considering past experience in your project plan makes your plan more realistic; involving people in the plan’s development encourages their commitment to achieving it. Don’t let the pressure to get fast results convince you to skip the planning and get right to the tasks. Although this strategy can create a lot of immediate activity, it also creates significant chances for waste and mistakes. Be sure your project’s drivers and supporters review and approve the plan in writing before you begin your project. For a small project, you may need only a brief email or someone’s initials on the plans. For a larger project, though, you may need a formal review and sign-off by one or more levels of your organization’s management. Project management: the executing processes After you’ve developed your project-management plan and set your appropriate project baselines, it’s time to get to work and start executing your plan. This is often the phase when management gets more engaged and excited to see things being produced. Preparing Preparing to begin the project work involves the following tasks: Assigning people to all project roles: Confirm the individuals who’ll perform the project work and negotiate agreements with them and their managers to make sure they’ll be available to work on the project team. Introducing team members to each other and to the project: Help people begin developing interpersonal relationships with each other. Help them appreciate the overall purpose of the project and explain how the different parts will interact and support each other. Giving and explaining tasks to all team members: Describe to all team members what work they’re responsible for producing and how the team members will coordinate their efforts. Defining how the team will perform its essential functions: Decide how the team will handle routine communications, make different project decisions, and resolve conflicts. Develop any procedures that may be required to guide performance of these functions. Setting up necessary tracking systems: Decide which system(s) and accounts you’ll use to track schedules, work effort, and expenditures, and then set them up. Announcing the project to the organization: Let the project audiences know that your project exists, what it will produce, and when it will begin and end. Suppose you don’t join your project team until the actual work is getting underway. Your first task is to understand how people decided initially that the project was possible and desirable. If the people who participated in the start of the project and the organizing and preparing phases overlooked important issues, you need to raise them now. When searching for the project’s history, check minutes from meetings, memos, letters, emails, and technical reports. Then consult with all the people involved in the initial project decisions. Performing Finally, you get to perform the project work! The performing subgroup of the executing processes includes the following tasks: Doing the tasks: Perform the work that’s in your plan. Assuring quality: Continually confirm that work and results conform to requirements and applicable standards and guidelines. Managing the team: Assign tasks, review results, and resolve problems. Developing the team: Provide needed training and mentoring to improve team members’ skills. Sharing information: Distribute information to appropriate project audiences. Project management: the monitoring and controlling processes As the project progresses, you need to ensure that plans are being followed and desired results are being achieved. The monitoring and controlling processes include the following tasks (see Chapter 3 in Book 2 for specific activities): Comparing performance with plans: Collect information on outcomes, schedule achievements, and resource expenditures; identify deviations from your plan; and develop corrective actions. Fixing problems that arise: Change tasks, schedules, or resources to bring project performance back on track with the existing plan, or negotiate agreed-upon changes to the plan itself. Keeping everyone informed: Tell project audiences about the team’s achievements, project problems, and necessary revisions to the established plan. Project management: the closing processes Finishing your assigned tasks is only part of bringing your project to a close. In addition, you must do the following: Get your clients’ approvals of the final results. Close all project accounts (if you’ve been charging time and money to special project accounts). Help team members move on to their next assignments. Hold a post-project evaluation with the project team to recognize project achievements and to discuss lessons you can apply to the next project. (At the very least, make informal notes about these lessons and your plans for using them in the future.)

Article / Updated 10-30-2020

No matter what your job is, you handle a myriad of assignments every day. For example, you may prepare a memo, hold a meeting, design a sales campaign, or move to new offices. Or you may make the information systems more user-friendly, develop a research compound in the laboratory, or improve the organization’s public image. Not all these assignments are projects. How can you tell which ones are and which ones aren’t? People often confuse the following two terms with project: Process: A process is a series of routine steps to perform a particular function, such as a procurement process or a budget process. A process isn’t a one-time activity that achieves a specific result; instead, it defines how a particular function is to be done every time. Processes, like the activities that go into buying materials, are often parts of projects. Program: This term can describe two different situations: First, a program can be a set of goals that gives rise to specific projects, but, unlike a project, a program can never be completely accomplished. For example, a health-awareness program can never completely achieve its goal (the public will never be totally aware of all health issues as a result of a health-awareness program), but one or more projects may accomplish specific results related to the program’s goal (such as a workshop on minimizing the risk of heart disease). Second, a program sometimes refers to a group of specified projects that achieve a common goal. The 3 main components that define a project A project is a temporary undertaking performed to produce a unique product, service, or result. Large or small, a project always has the following three components: Specific scope: Desired results or products. Schedule: Established dates when project work starts and ends. Required resources: Necessary number of people and funds and other resources. As illustrated, each component affects the other two. For example: Expanding the type and characteristics of desired outcomes may require more time (a later end date) or more resources. Moving up the end date may necessitate paring down the results or increasing project expenditures (for instance, by paying overtime to project staff). Within this three-part project definition, you perform work to achieve your desired results. Although many other considerations may affect a project’s performance, these three components are the basis of a project’s definition for the following three reasons: The only reason a project exists is to produce the results specified in its scope. The project’s end date is an essential part of defining what constitutes successful performance; the desired result must be provided by a certain time to meet its intended need. The availability of resources shapes the nature of the products the project can produce. The diversity of projects Projects come in a wide assortment of shapes and sizes. For example, projects can Be large or small Installing a new subway system, which may cost more than $1 billion and take 10 to 15 years to complete, is a project. Preparing an ad hoc report of monthly sales figures, which may take you one day to complete, is also a project. Involve many people or just you Training all 10,000 of your organization’s staff in a new affirmative-action policy is a project. Rearranging the furniture and equipment in your office is also a project. Be defined by a legal contract or by an informal agreement A signed contract between you and a customer that requires you to build a house defines a project. An informal promise you make to install a new software package on your colleague’s computer also defines a project. Be business-related or personal Conducting your organization’s annual blood drive is a project. Having a dinner party for 15 people is also a project. No matter what the individual characteristics of your project are, you define it by the same three components described in the previous section: results (or scope), start and end dates, and resources. The information you need to plan and manage your project is the same for any project you manage, although the ease and the time to develop it may differ. The more thoroughly you plan and manage your projects, the more likely you are to succeed. 4 phases of a project life cycle A project’s life cycle is the series of phases that the project passes through as it goes from its start to its completion. A phase is a collection of logically related project activities that culminates in the completion of one or more project deliverables. Every project, whether large or small, passes through the following four life-cycle phases: Starting the project: This phase involves generating, evaluating, and framing the business need for the project and the general approach to performing it and agreeing to prepare a detailed project plan. Outputs from this phase may include approval to proceed to the next phase, documentation of the need for the project and rough estimates of time and resources to perform it (often included in a project charter), and an initial list of people who may be interested in, involved with, or affected by the project. Organizing and preparing: This phase involves developing a plan that specifies the desired results; the work to do; the time, cost, and other resources required; and a plan for how to address key project risks. Outputs from this phase may include a project plan that documents the intended project results and the time, resources, and supporting processes needed to create them. Carrying out the work: This phase involves establishing the project team and the project support systems, performing the planned work, and monitoring and controlling performance to ensure adherence to the current plan. Outputs from this phase may include project results, project progress reports, and other communications. Closing the project: This phase involves assessing the project results, obtaining customer approvals, transitioning project team members to new assignments, closing financial accounts, and conducting a post-project evaluation. Outputs from this phase may include final, accepted, and approved project results and recommendations and suggestions for applying lessons learned from this project to similar efforts in the future. For small projects, this entire life cycle can take just a few days. For larger projects, it can take many years! In fact, to allow for greater focus on key aspects and to make it easier to monitor and control the work, project managers often subdivide larger projects into separate phases, each of which is treated as a mini-project and passes through these four life-cycle phases. No matter how simple or complex the project is, however, these four phases are the same. In a perfect world, you complete one phase of your project’s life cycle before you move on to the next one, and after you complete that phase, you never return to it again. But the world isn’t perfect, and project success often requires a flexible approach that responds to real situations that you may face, such as the following: You may have to work on two (or more) project phases at the same time to meet tight deadlines. Working on the next phase before you complete the current one increases the risk that you may have to redo tasks, which may cause you to miss deadlines and spend more resources than you originally planned. If you choose this strategy, be sure people understand the potential risks and costs associated with it. Sometimes you learn by doing. Despite doing your best to assess feasibility and develop detailed plans, you may realize you can’t achieve what you thought you could. When this situation happens, you need to return to the earlier project phases and rethink them in light of the new information you’ve acquired. Sometimes things change unexpectedly. Your initial feasibility and benefits assessments are sound, and your plan is detailed and realistic. However, certain key project team members leave the organization without warning during the project. Or a new technology emerges, and it’s more appropriate to use than the one in your original plans. Because ignoring these occurrences may seriously jeopardize your project’s success, you need to return to the earlier project phases and rethink them in light of these new realities.