Chapter 5
Get Work Done in an Efficient and Focused Way

Perhaps your biggest responsibility as a manager, in terms of day-to-day priorities, is making sure work is done in an efficient and focused way. Of course, good managers are highly attuned to the “people” side of their job, as we discuss in later chapters, but the focus here is primarily on the efficient coordination and alignment of tasks. Think of the firm as a well-oiled machine, where everything links together in beautiful alignment – that is what you should be aiming for.

Unfortunately, most large firms are nothing like well-oiled machines, for two reasons. First, they are often so large and complex that people are oblivious to what is happening elsewhere, and senior executives – even with the best will in the world – struggle to provide a coherent message to everyone. Second, the bigger the firm, the further removed individual employees are from the fruits of their labor, and the harder it is to keep them motivated to continuously improve on their performance.

This chapter provides a set of tools and techniques you can use to improve efficiency and focus in day-to-day work. The first two are high-level techniques that you will partly be on the receiving end of, specifically translating the firm's mission into goals that people understand (#26) and aligning people's objectives with corporate goals (#27). The others are techniques that you should use with members of your teams to help achieve your objectives. Two are focused on efficiency – systematically analyzing and optimizing the work people do (#28) and using structured, continuous improvement methods (#29). Two are more concerned with effectiveness, i.e. doing the right things – identifying the “gaps” that need filling to achieve objectives (#30) and conducting post-project reviews to make sure you are prioritizing the right activities (#31). Finally, we provide an overview of agile methodologies for managing projects (#32) – agile is one of the hottest current trends in the business world, so it is important to be up to speed on how it works.

There is a long history of management research on the issues described in this chapter – for example, the original scientific management and time-and-motion studies of Fredrick Taylor, as well as the quality revolution inspired by Edwards Deming and first implemented by Toyota. Recent management innovations, including Six Sigma and agile development, build on these traditions. But though the terminology changes over time, the underlying need to create alignment and efficiency at work is timeless.

26. Translate the Organization's Mission into Goals That People Understand (OGSM)

We have already discussed how important it is to have meaning in your life and how different aspects of the way you work can contribute to this. An important part of meaning, though, comes from what your organization does to address the needs of its stakeholders. This is typically expressed in a mission or vision statement that provides what Ratan Tata, former CEO of Tata Sons, calls a “spiritual and moral call to action.” (See #81 for more on mission statements.)

But it is often difficult to see how the work we do, day to day, contributes to the organization's mission. Or to put it slightly differently, it is hard for senior managers to translate higher-level objectives into individual targets without producing lengthy plans that people struggle to understand and that they quickly forget. This is where OGSMs (objectives, goals, strategies, and measures) are useful. Developed by Marc Van Eck and Ellen van Zanten in The One Page Business Strategy and used by many large companies, this framework brings together the full hierarchy of objectives used by the organization and summarizes them on a handy one-page sheet that everyone can make sense of. The one-page rule is great for pushing senior managers to make difficult decisions rather than lazy compromises. It's also great for communicating what people need to do in a clear and very condensed way.

The objective is a concise and emotionally appealing statement of what the organization is seeking to achieve. For example, your objective might be “to become the world leader in electric van manufacturing.” You could expand on this by adding “by developing cutting-edge battery technology, high-performance motors, and an innovative workforce.”

Goals are a small number of statements (typically three or four) of what success looks like. An example might be: “Within the next 12 months, develop a battery pack capable of giving a 10,000-pound vehicle a range of 650 miles.”

Strategies are short descriptions of what you'll do to achieve your goal (this is a very particular meaning of the word strategy and different than how the term is used by others, as we'll discuss in Chapter 15.) An example might be: “Recruit a team of seven engineers with strong experience of developing and integrating specialist electric vehicle battery packs.”

Measures are the specific quantitative things you'll monitor to check that your goals and strategies are being met. (These are often presented on a dashboard.)

Find out more about OGSMs, including downloading an OGSM template: http://mnd.tools/26

Source: Adapted from van Eck and van Zanten 2014. Reproduced with permission of Marc van Eck and Ellen van Zanten.

27. Align People's Objectives with Corporate Goals (OKRs)

OGSMs are great for translating the organization's mission into actions for specific operating units or departments. But how can these goals and strategies be translated into the work that individuals do?

This is where OKRs (objectives and key results) are useful. Developed by Andy Grove, former CEO of Intel®, and widely used in leading organizations, they are a refinement of the notion of management by objectives, developed in the 1950s by Peter Drucker (which you can find out more about using the URL on the next page.)

Objectives define what someone needs to achieve during a defined period, and key results are measures of progress or milestones along the way to achieving them.

OKRs start at the top of the organization, and they are based on the business plan or OGSM. They cascade down from level to level so that, ultimately, every individual has personal objectives and key results that contribute to the OKRs of the manager above them.

So how are OKRs defined? Typically, your manager will gather a team together to discuss the overall plan. Then he or she will work with each individual and agree on the personal objectives that help deliver on the collective goal. Rather than simply tell people what to do, the manager should ask for each individual's insights into the goals being set, giving them the opportunity to discuss any problems they see and bid for any additional resources needed.

There are two types of objectives – operational and aspirational. Operational objectives are the first priority, and they either are achieved or not. Aspirational objectives – also known as stretch goals or “moon shots” – are a way of encouraging people to do something hugely significant.

For each objective, your manager will discuss and agree on two or three key results. These will either be measures showing whether they have been achieved or milestones that you'll need to reach along the way to achieving the objective. The two of you will then work out a structure of one-on-one meetings to review progress and quarterly meetings where you'll look at where you should be going next and how your OKRs might be adjusted.

Having done this with your manager, you then replicate the process with the people who report to you, and they do the same, until OKRs have rippled down through the whole organization.

Find out more about management by objectives: http://mnd.tools/27-1
Learn more about OKRs, including seeing an example: http://mnd.tools/27-2

Source: Adapted from Grove 1995. Reproduced with permission of Pearson Education, Inc.

28. Systematically Analyze and Optimize the Work Team Members Do (DILO)

With mature, experienced individuals, setting objectives may be all that you need to do to get them working well. With less experienced team members, though, you often need to get more involved, which means understanding the detail of the work they are doing.

By getting into the detail, you become knowledgeable about what is happening in your team, you can help people to focus on the right things, and you can assess their need for additional training and resources. You will also come to understand who you can rely on to work with minimal supervision and who you need to manage closely.

A useful technique for doing this is DILO, which stands for day in the life of. It was originally developed as a way to understand customers' lives, but it is equally useful for understanding what's going on in your team.

It involves tracking the details of what people are doing over a period of time and then analyzing this to improve efficiency. There is a risk of appearing overbearing and intrusive in this activity, which could, in turn, generate resentment and resistance, but when done right, it can make life better for everyone. An example of a completed DILO analysis for an airport worker is in Figure 5.1.

Tabular illustration of part of an example DILO (day in the life of) analysis for an airport worker.

Figure 5.1 Part of an Example DILO Analysis for an Airport Worker

Start your DILO analysis by defining its scope. For how long do you want to run the analysis? What parts of your team's work do you want it to apply to? And for what purpose – do you want to identify training needs, fix problems that team members are experiencing, or explore new ways of doing things that might be useful?

Communicate this to the people involved. Explain what you want to achieve and why and, most importantly, make it clear that you won't be using this process to judge them – otherwise, they'll be suspicious about what you're trying to achieve.

Next, set up the time recording worksheet – a simple time log noting the time the activity starts, what the activity is, how long the person takes to do it, and a rating of how effective the person feels they are being. It is often best to ask people to complete the log themselves – this gives them control over the situation.

When the study is complete, review the time logs with the individual. Make sure you are clear what each task is. Where someone feels they weren't doing the job as effectively as they might, explore the reasons (for example, using the five whys; see the URL below).

If done sensitively, this gives you the starting point for some great conversations about addressing frustrations, solving equipment issues, improving processes, and so on. Make sure to keep your promise not to judge the person being studied.

Find out more about how to do a DILO analysis, including downloading a DILO worksheet: http://mnd.tools/28-1
Find out more about the five whys: http://mnd.tools/28-2

29. Use a Structured Approach to Continuous Improvement (PDSA)

PDSA (plan, do, study, and act) is another technique you can use to improve the way your team works in a systematic and controlled way. It is a scientific approach to continuous improvement: Develop a hypothesis for improving a process, try it out, assess whether it is supported, and act on the findings.

Developed by W. Edwards Deming in the 1950s, PDSA became a core part of the wave of lean manufacturing and quality improvement movements, which reshaped global industries in the subsequent decades. It was developed in a manufacturing context and is now widely used in any situation where process improvement is important. (PDSA was originally known as PDCA, but Deming asked for the acronym to be changed after it caused confusion.) It follows the cycle shown in Figure 5.2.

Schematic illustration of the PDSA (plan, do, study, and act) cycle.

Figure 5.2 The PDSA Cycle

In the plan phase, you focus on a problem to understand its underlying causes (use the five whys and cause and effect diagrams (#34) to do this effectively). You develop a hypothesis saying what you think the problem is and state quantitatively what your expectations are if it is resolved. You brainstorm options for resolving the problem, select the solution you want to test, and plan how to run the test, ideally on a small-scale basis first.

In the do phase, you carry out your plan and collect the data you need to assess whether expectations have been met.

In the study phase (originally called check), you study the data to see whether the problem has been solved. If yes, you move on to the act phase; if no, you return to the plan phase.

In the act phase, you roll your changes out fully and embed them in the organization's way of working. (This can be harder than you might initially think – see Chapter 17 for more on change management skills.)

You can then move back to the start of the cycle and identify the next improvement you want to work on.

Find out more about how to use PDSA/PDCA: http://mnd.tools/29-1
Learn about kaizen: http://mnd.tools/29-2
Find out how to use the build-measure-learn cycle: http://mnd.tools/29-3

30. Systematically Identify What Needs to Be Done – Gap Analysis

To make changes such as those in the do phase of PDSA or to meet other objectives, you will often need to run projects – temporary streams of work with clear start and end points. An important part of setting a project up is defining what work you'll do in it, and this is where gap analysis is useful.

Gap analysis is simply about defining the space between your current state (where you are now) and the desired future state you want to achieve and then figuring out what work needs to be done to close the gap. Take the following steps:

  1. Define the scope of the project. Define what your project will and won't cover. Try to keep the scope small and focused – larger projects have a tendency to run out of control.
  2. Identify the desired future state. For the chosen activity, define where you want to end up. For example, if you are building a website, define what success looks like in terms of visual quality, hits, click-through rates, etc.
  3. Identify the current state. Next, put together a frank assessment of the current state of play, consulting with others as necessary. If you already have a prototype website, how would you rate it on the relevant quantitative indicators you have chosen?
  4. Identify how to bridge the gaps. It may be obvious what actions you need to take to bridge the gap between the current state and the future state, but in more complex situations, it is often worth using cause and effect analyses (#34) or brainstorming (#48) to generate alternatives.

As an example of a gap analysis, you could define the scope of your project as “shortening the resolution time for customers making inquiries through your website.” Your desired future state could be “to solve 85% of customer issues within 2 hours of their inquiry and 100% within 24 hours while maintaining a 93% or higher satisfaction rate.” Your current state could be: “We solve 85% of customer issues within 8 hours of their inquiry and 100% within 24 hours with a 93% satisfaction level.” Cause and effect analysis allows you to explore why you are not achieving the desired service levels and identify possible ways forward.

Learn more about gap analysis: http://mnd.tools/30-1
Find out more about the McKinsey seven Ss model: http://mnd.tools/30-2
Learn how to use the MoSCoW method: http://mnd.tools/30-3

31. Conduct Post-Completion Project Reviews (Retrospectives)

DILO and PDCA are good techniques for getting work done more efficiently. When you couple them with OGSM and OKRs, you'll be working in a much more effective way as well – by focusing on the right things. You can do even better when you put a formal “learning from experience” step into how your team works, and you can do this by running retrospectives at the end of projects.

Retrospectives are a key feature of agile project management, and they are run at the end of each agile sprint, typically every two weeks. (We'll look at agile in more detail next in #32). They are also known as after action reviews, a term that has been used in the military world for many years.

The purpose of retrospectives is to get team members to take collective responsibility for learning from their recent experiences and improving the way they work the next time they encounter a similar challenge. These sessions need to be run promptly and in a nonhierarchical, blame-free way; otherwise, people will have forgotten the details of what happened or they may cover up things that went wrong for fear of looking bad.

Start by explaining the context and purpose. Make it clear that everyone is expected to contribute and that disagreement is okay as long as it is nonpersonal and constructive. Focus on the following questions:

  1. What was supposed to happen? What did happen? Where and why was there a difference?
  2. What didn't go well and why?
  3. What did go well and why?
  4. What will we stop doing, start doing, and keep doing to make the next project a success?

You can just let people talk and take notes, or you may prefer a more structured process – for example, getting people to write on sticky notes and putting them up on a chart for all to see. Depending on where you work, there may also be special templates that everyone uses.

Ultimately, you're looking to improve the way your team works – by improving training, codifying people's knowledge in key areas, or improving procedures and working methods. Make sure that you take down a list of actions coming out of the session and that you follow up on these to make sure they happen.

Find out more about how to run an after action review: http://mnd.tools/31-1
Learn how to run a retrospective, including different approaches to use for them: http://mnd.tools/31-2

32. Manage Projects Using Agile Methodologies (Agile Project Management)

The previous two techniques (#30 and #31) addressed specific aspects of project management. But there is also the question of how to manage projects in their totality. Broadly speaking, there are two approaches available to you. Where the technologies used by the project are well understood, where the product is quite standardized and can be designed in detail (such as a house, a bridge, or a ship), and where it needs to be delivered to a tight budget and a defined timescale, a structured approach to project management such as PMBOK and PRINCE2 is useful; these allow projects to be delivered in a controlled and highly efficient way.

Unfortunately, this structured approach doesn't work well in many high-tech sectors where requirements are not well understood in advance, technologies are evolving quickly, and customer requirements are shifting. Highly structured project methodologies do not cope well with changing demands, and the net result is missed deadlines, cost overruns, and, often, a product that doesn't meet the evolving needs of the organization. Working on such projects can be stressful and demoralizing.

This is where Agile Project Management is useful. In essence, it replaces the top-down process where everything is planned in advance with a bottom-up process that adapts to the changing circumstances. It involves a trade-off: Customers and sponsors lose their right to know exactly when the project will be finished and how much the product will ultimately cost, but they gain a flexible and dynamic approach that starts delivering small, useful results almost from the start of the project, resulting in a product that meets the needs of the evolving organization.

One popular approach to agile project management is called scrum. Here, projects are built around small, self-directed teams where team members work together in short bursts of activity called sprints. These are typically two to four weeks in length, and the aim is for the project team to deliver a small, fully tested, working deliverable by the end of each sprint.

Within the teams, there are several key roles. Product owners act as representatives of customers and end users. Before each sprint, they reprioritize the order in which deliverables will be worked on and describe how the deliverables will be used through a format called a user story. At the end of the sprint, product owners confirm that the team has successfully delivered a solution to the user stories being worked on.

Scrum masters manage the process of each sprint. They break the user story down into smaller user stories that can be completed within the sprint, protect the project team from scope creep, help to solve problems within the sprint, and conduct project retrospectives (see #31) at the end of each sprint to identify lessons learned so that these can be fed into future ones.

Agile coaches are the third key role – these individuals provide support to several teams, helping with personal development and offering advice on team dynamics.

Project team members decide which user stories can be completed within the sprint, and they self-organize to develop a working solution for each one by the end of the sprint. Team members meet at the start of the sprint to decide how this will be done and then hold 15-minute stand-up meetings every day to update one another on progress.

When it is used effectively, this agile approach gives senior managers a high level of visibility over the progress of the projects they are responsible for, and it gives project team members more autonomy and greater opportunities for personal development. However, it is not that easy to use: You need to invest a lot of time building the new structures and developing the skills needed to put it into practice.

Learn more about PMBOK (pmi.org): http://mnd.tools/32-1
Find out more about PRINCE2 (axelos.com): http://mnd.tools/32-2
Learn how to use agile project management (Mountain Goat Software): http://mnd.tools/32-3
Learn how to use agile project management (Scrum Alliance): http://mnd.tools/32-4

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset