The Big Ideas
■ There will be barriers between us and getting to Energy and Innovation.
■ There will be resistance to change.
■ Focus on value not dates, manage up, and learn how to collaborate with non-collaborators.
It’s Hard
I sometimes think life would be so much easier if people would stop getting in the way. Sadly, that is rarely the case. If we are in any type of leadership position, we deal with people. And, at an organizational level, we deal with the organization’s culture. At the core, it takes collaboration to move teams or the organization from point A to point B. Ideally, we do this by creating a compelling and shared vision so that our teams and organizations, willingly and passionately, will move to point B. In reality, we might encounter people and a culture that are reluctant or hesitant to go along. This becomes a barrier that we must deal with, one we may come up against again and again.
We might hear things like the following:
■ Why should we do anything differently? Things seem to be just fine.
■ This sounds like another one of those management fads.
■ I am tired of change. Just leave me alone.
■ If the leaders are not on board, I am not going to do anything.
■ That sounds nice but will never work here.
ptg12441863
Sometimes these walls come from rigid, unforgiving processes and rules.
What can we do about such “walls”? In this chapter, we present several tools that might be useful when you encounter a wall.
“I Need It by This Date! And I Need It All!”
Has this ever happened to you? You are tasked with leading the project that will create the company’s next killer product or that will replace that nag-ging legacy system or that will finally allow the company to analyze product and customer trends. Your marching orders are very clear—the project must be done by March 15. With the date fixed, you plan the project. You identify tasks, resources, costs, dependencies, and technologies and lay out a schedule. You manipulate tasks, resources, costs, dependencies, and technologies to achieve the project goal of hitting the required date.
When you meet with your project sponsor and stakeholders, are their questions all about the likelihood hitting that date? Whether intentionally or unintentionally, all things become subservient to hitting that date. Each time a dependency is late or a technology does not immediately work as advertised, you have to make project trade-offs. But the one thing you have learned is that you will not be able to trade off that date. So, you reduce the scope a bit and then a lot—whatever it takes to hit that date.
Some things fall your way and, as the project nears its due date, you can, with confidence, claim that you will hit that all-important date. True, the project is different from what you first planned but you will hit your date.
Your sponsor is relieved. Your stakeholders sing your praises. The product launches, the legacy system limps to the boneyard, and the analysis pro-vides some insight. But the product does not do as well, the new system does not perform as well, the analysis of product and customer trends is not as revealing because, in order to hit that date, you had to make a few sacrifices—in some cases a lot of sacrifices. You did the best you could but because the date became the most important deliverable, you designed around the date—even if that required you to suboptimize the product, the system, or the analysis.
What about a different approach? We start the project the traditional way with a hard and fast due date. The project is a major—and innovative—
upgrade of our customer portal. As we gather and sort through the high-level requirements, we ask, over and over again, what are we trying to achieve
ptg12441863
“I Need It by This Date! And I Need It All!” 139
with this upgrade? How will we know that the project has delivered value?
What are the drivers behind each required element of the upgrade? Who will use that piece of functionality and what do they want to accomplish?
How would they benefit from the upgrade?
Taking this more customer-focused approach to the project changes the conversation and the insistence on meeting a specific date. To be sure, hitting a date still matters but delivering the desired value to our custom-ers is the primary goal. As the project progresses, we make the traditional scope, time, and cost trade-offs but we make trade-offs that either retain or improve the value to our customers. In addition, our customer-value perspective encourages us and our sponsor to interact frequently with our customers—through a series of focus groups and product demonstrations—
in order to determine which features and functions provide the most value.
As we prioritize our work, the high-impact features float to the top and become the focus of what we will get done first. It turns out that our cus-tomers have a burning desire to know, in incredible detail, the status of their orders. It also turns out that some of the features we think are really cool and bleeding edge are just not that interesting to our customers.
When the project ends, we assess our performance. We delivered early the functionality that made the biggest difference to our customers and to the company. By continuously focusing on what creates customer value, we found the shortest, most direct path to customer value. As part of this ongoing prioritization we did not develop some of the features and func-tions that were originally planned—why build something our customers told us they did not really need or want?
But from a completely objective view, we were “late” with some of the low-priority features. Does this mean that the project was challenged?
Only if the goal were to hit a date first and worry about value second.
As twisted as this logic sounds, how often is this our thought process?
How often is a date how we define accomplishment? And, if this is com-mon, let’s agree to stop doing so right now and focus on value first.
This focus on due dates will be one of the biggest walls you will hit.
And you will come up against it again and again.
In real life there is always significant pressure to deliver the maximum value to the business and to our customers. This is evidenced by business managers demanding a long list of detailed requirements by a specific date. How do we deal with it? We need to understand the real issues and how best to respond to them.
ptg12441863
The issue is a classic one:
■ The business needs the maximum delivery.
■ The development team has limited resources and time.
■ The effort required is uncertain.
How do we deal with this reality? The business must deliver as much value as possible but it is the development team that actually does the work with limited resources. Without goodwill and cooperation this often leads to unhelpful and wasteful conflict between the business areas instead of focusing on problems as a whole business.
How can we avoid this?
Start by collaborating to understand and accept the dynamics and the reality of the situation.
■ The business needs the maximum that can be delivered.
■ Both business and development teams are well intentioned and motivated to do the best that they can.
■ There is essentially a fixed set of resources and time available.
■ Because the effort is uncertain, we don’t know exactly what can be done.
■ If we overload the delivery team, they will be demotivated and deliver less than they might and at a lower quality than we want.
Iterative approaches help take the pressure out of the situation and enable maximum delivery.
■ Jointly focus on cash flow and speed to market rather than on some theoretical plan.
■ Get the cash flow going by delivering the minimal viable product as quickly as possible.
■ Prioritize. Create the product incrementally, tackling the highest-value items first.
■ Have the business and development leaders work together to enable increased effectiveness in the engineering team.
■ The business must be available for quick decision making when needed.
ptg12441863 Managing Up 141
■ Invest in making the infrastructure and process as supportive as possible.
■ Remove interruptions.
■ Minimize unhelpful reviews.
■ Focus on delivery.
The foundation of dealing with this is a genuine partnership between business areas and development teams. A senior leader’s primary goal should be to jointly build a collaborative vision and alignment across the whole organization.
Managing Up
I once worked with a team that was not meeting their weekly commitments—
consistently. I wondered why. Their work was always good when they did deliver. So I stopped by their work area.
“How is it going?” I asked. “You seem to be struggling with your weekly commitments. What is getting in your way?”
There was a pause. “Mr. Shore comes by and keeps giving us new tasks to do,” the team leader replied.
“You don’t stop everything and do them, do you?”
“Well, yes. We are going to work for him when this project is over!”
I now understood the problem and walked up to Mr. Shore’s office.
“I know you are worried about getting the things built you will need in the future. And we will get them all done. Give us a list and the team will prioritize what they will do every week and they will deliver.” He did and the team was back on track.
A command and control manager is very difficult to deal with—but not impossible. As a team leader, if you have such a manager, you can manage up and protect the team. Or the team may select a leader from their team to manage this micromanager. How do they do this?
First, find out what is important to your manager and why. Most likely he wants control and certainty but how does he get them? Collecting met-rics no one actually uses? Having people do it “his way”? Seeing progress on a daily or weekly basis? Measuring against a plan? Is he afraid of failure?
In this situation, what can you do?
ptg12441863
Generate Data
Somehow micromanagers think that collecting data will assure them that things are working. Whether the data is really useful or not, they still want it. The essential part is to not waste the team’s time. As the team’s leader, you need to minimize the impact on the team by gathering the data and creating the report, just as your controlling manager wants it. Protect the team.
“Do It My Way”
Use the Macro-Leadership Cube in Chapter 5, Ownership Tools, either as a drawing or a mental image. With your micromanager, identify and agree to the constraints and expected results but in quantitative terms.
For example, it is not enough to have an expected result as increase sales.
It must be by how much sales will increase. Five percent? Eight percent?
Then ask the manager to step back as long as the team operates within the boundaries of the expected results and any constraints. As a first step, make sure the team agrees with the possible cube constraints and expected results before you talk to the manager.
Show Progress
Building an electronic stock exchange was a massive project. The project leader, Mr. Smith, was not technical so he focused on interfacing with the clients. After all, there were over 50 banks paying for the exchange, some very large and some very small. They all wanted their say.
I took the helm to deliver the product. After a close look at the effort, I realized that using waterfall methods would not cut it. There was way too much uncertainty to be able to accurately project the tasks and comple-tions. We needed something else and the team figured it out. They started an iterative development process. The team designed, coded, and tested small bits of functionality and showed them to customers. The customers gave feedback and we adjusted accordingly.
However, Mr. Smith wasn’t technical. The only thing he knew about software delivery was to use waterfall methods. On such a high-risk proj-ect, was he willing to go for an experimental “made up” methodology like iterative development?
ptg12441863