A Conversation with W. Scott Cameron and Terry Little
We’re all interested in quality, but if we can’t deliver a project on time, quality becomes a moot point. The subject of speed came up at NASA’s Masters Forum of Project Managers held in Tysons Corner, Virginia in August ’02. During a panel discussion about planning, Scott Cameron of Procter & Gamble and Terry Little, then head of the Air Force’s Center for Acquisition Excellence, discussed approaching projects with speed as the primary focus.
In this excerpt, Scott and Terry share examples of how speed affects the way they manage projects in their initial phases, and they suggest why speed might be important in how you manage yours. We invite you, after reading these excerpts from the panel, to tell us about how you address speed on your projects.
ASK: Let’s start with the obvious: why the emphasis on speed?
Cameron: In the Consumer Products business, being first to the market or hitting a defined marketing window with a quality product requires us to always look for ways to improve or reduce our execution schedules. As such, we’re often called “speed merchants.”
Little: I have found that when you establish speed as your single focus, you go back and look at how you do business with a clean sheet of paper. It’s not hard to understand why speed counts when it comes to national defense. In the Air Force, we have a fairly structured system of procurement, oriented towards not making a mistake. We have a highly detailed, highly structured proposal evaluation for most big projects that typically lasts, give or take, a year. On a few of my projects, we have found ways to cut the yearlong process down to as little as 3 or 4 weeks. How can we accomplish that? Looking at our requirements in capability terms, not specific numbers, is part of the solution. We tend in the Air Force to be too detailed in requirements. Yes, there are times where speed isn’t as critical or you take what you can get- however long it takes, that’s how long it takes. But I would judge that for the vast majority of projects, speed really does count, even when it’s not explicit. The key is this: When you have a single-minded focus on something like speed, it encourages creative, innovative thinking.
Cameron: I would just reiterate that. One time when I began work on a new project, we benchmarked similar projects which indicated the best schedule we could anticipate achieving was 24 months. Our marketing window was only 17 months to execute the project. We aligned the team to do it in 17 and they accomplished the task.
ASK: Those are clearly impressive results. How do you get a team to “align” like that?
Cameron: I think Terry’s point says it all, as the schedule was the single point of focus. The project manager also took the time to align all the factional team members and their hierarchy, as well as our contractors and suppliers, to this importance of speed. He also worked with the team and hierarchy to determine the cost impact of going this fast. Our ability to achieve this schedule was threatened throughout the duration of the project. However, I’ve found that when you make it clear to someone that they have become the critical path, the reason a project will succeed or fail, then they begin to come up with very creative solutions that they probably never realized existed. Sometimes it comes down to asking, “Can you meet this schedule?” and “Will you put your career on the line?” Then the answers you get back are far different than the norm. Then a team aligns, and it decides to challenge the traditional barriers.
Little: Everyone has to share the common goal, speed, and it has to be a goal that drives their behavior and their contribution. Focusing on one issue, such as speed, comes down to deciding what you’re not going to do. You can’t expect a contracting officer who is wedded to “let’s avoid any sort of protest from the contractor, let’s make sure that we’ve got a fireproof contract” to work that problem and the speed problem at the same time. It won’t happen. So you’ve got to have, as an essential element of a functioning team, a shared, common objective- speed, we’ll say- for which everyone accepts accountability. Without that, you’ll never get anything from the engineer, from finance, from procurement, from the lawyer, and so forth, because they each have a different objective. You can call it a team, because you happen to work in the same location or you are on the same work chart, but it is not a team if every single member of the team doesn’t share a common objective.
ASK: How is quality affected by a focus on speed?
Cameron: There are tradeoffs. The big three when it comes to a project are cost, quality and speed. They’re all negotiable. If speed is the most important, then the question is: what does that do to cost, what does that do to quality? From a consumer product standpoint, putting a lousy product out there fast means you’re going to fail in the marketplace. So, if quality is the number one vector, then how do you balance cost and speed? Again, it’s all negotiable. Some of the biggest obstacles I’ve faced in managing a “speed” project are the technical engineers and their desire to have everything perfect from day one. They’ll say, “We just need a couple more days.” But a couple more days could be critical if you’re trying to hit a marketing window. Sometimes you may not need perfection. Like I’ll pick pet food. Do dogs and cats really know what the container looks like? Do they care? It’s what’s inside that pets care about, but when you go through market studies, it’s always: “What’s the quality of the container?” Maybe you won’t have the perfect container if you go for speed; maybe you live with something secondary and then six months after your product has rolled out, you come up with a new and improved container. Quality is the most important aspect of any project. If you put an inferior product into the marketplace it will fail. But, like anything else, there are probably more negotiations on those three- cost, quality and speed- than you give yourself credit for.
Little: I think it’s important to clarify that speed isn’t necessarily the preeminent concern of every project. But when speed is critical, it’s important to have a clear set of priorities in order to decide what does and doesn’t require the attention of your team. There is a misconception, I think, that if you emphasize something like speed or like cost, that everything else goes in the toilet- that if you focus on speed when you’re developing a car, you’ll deliver a lemon in the end. My observation is that people working the problem won’t let that happen; that what you give up is very modest in comparison to what you gain. What you’ve got to do, I am convinced, is to “unlearn,” to use Alex Laufer’s term, all of our processes that are not oriented toward speed or credibility, but are oriented toward not making a mistake, playing it safe. When you take on a problem, there is plenty of room out there for all kinds of extraordinary alternatives that will both increase speed and increase credibility. There really are. We have seen some of those work.
ASK: Could you give an example?
Little: A lot of our processes that we have, both procurement and post-award, are built on lack of trust. That’s essentially what it is. When you hand somebody an 11-page specification rather than a 100-page document, however, you are sending a clear signal that you trust them to do the right thing. In general, we don’t do that because we don’t trust, or the system won’t allow us to trust; I’m not sure which. But my own belief is that, as an individual project manager, you can go a long way in that direction by starting not with the notion that someone has to earn your trust, but starting with the presumption that they’re trustworthy until proven otherwise. It allows things like an 11-page specification. My biggest disappointment in the past has been when I have given project managers the opportunity to innovate, and they don’t know what to do with it. They demand processes, rigidity, templates, and prescriptions. It is as if you give them a blank check and they write it for a dollar.
Cameron: To come back to your question about an example, one type of project comes to mind: site clearance. Unfortunately, we have had a few brands that haven’t made it and we have had to clear out everything we’ve put in. Site clearance to me is pretty simple. You walk in the room, you see the equipment making the product, and you say, “Here’s my spec: I want all of that gone,” and you’re ready to bid the job. Somebody might accuse me of oversimplifying it, but that’s pretty much what you want done. The interesting thing is, when you go out and you ask people to write the site clearance specification, it comes back 400 pages long. I think Terry’s point is right on: often what’s required is unlearning of old thinking. If speed is your priority, you should approach the job differently.
ASK: How do you address risk in a speed-first approach?
Cameron: There’s one thing I always tell people when they’re managing a speed project, and that is to remember “speed kills,” too. The project manager must understand where the gas and the brake pedals are located as the project is executed. The project manager has to have the experience to use the proper pedal because there are times when speed can kill a project. Not every portion of a “speed” project has to be executed as fast as possible, thus the project manager must understand how and when to operate each pedal.
Little: I think in the Department of Defense one comment I hear frequently is that you get the behavior from project managers that you reward. I don’t know about NASA, but if you want project managers to be risk-takers in the sense of taking a modest risk to achieve an extraordinary gain or an extraordinary improvement, then the system is going to have to be rewarding of that behavior.
Cameron: I had one project where I thought I was going to be appointed the project manager. It turned out it was a five-site rollout. You had 26 weeks to start up the fifth site. The first site had to start up week 18. We hadn’t ordered any equipment. We weren’t funded, but the end date had been set. We only knew two of the five sites. Aside from those “minor details,” it was a fairly defined job. I’m joking, of course. I went in to my boss and expected him to say, “We want you to be the project manager.” What he actually said was: “We want you to be the project manager but you have to answer one question: Will you stand by your decisions?” Because this was an extremely aggressive schedule, there was no time to second guess my decisions or even take significant time to make decisions. I had to deliver a quality product- let me be very clear about that-I couldn’t put swill out there and meet this schedule. At the end of our discussion, my boss said, “I will give you a night to think about it.” It was as though that was the only criterion- my willingness to stand by my convictions, because I had to drive speed. In that job, the project manager was going to be rewarded for speed. So Terry’s point is well made: you are likely to get exactly what you reward. If it is complacency, if it’s status quo that you reward, then that is what you are going to get. In this job, I would be rewarded for quality and speed. And I delivered it.
Little: I will offer just one more thought. I just completed an informal, non-scientific assessment of a few successful Air Force programs, big ones. At the root of every one of those programs there was one element in common, and it wasn’t adequate funding or stable requirements or good systems engineering. The common element was a program manager on the government side who challenged the status quo, took risks and persevered. It was a project manager who was a leader.
About the Author
 |
Terry Little is currently the Director of the Kinetic Energy Boost Office of the Missile Defense Agency. Before that he was the head of the Air Force’s Center for Acquisition Excellence. He is one of the Air Force’s most seasoned program managers. He entered the Air Force in 1967 and served on active duty until 1975. In 1997 he was promoted to the grade of SES. |
 |
Scott Cameron In an interview last year (ASK 7), Cameron reflected on his tenure as a project manager: “When I think about how I have grown throughout my career, I can talk about the projects that I’ve worked on. But when I get down to the root cause of my growth and development, the most important factor has been the people who managed, coached and challenged me. Individual managers have had a profound impact on me. As I look back, I can see how this boss taught me how to write proposals. This mentor taught me financial aspects and cash flow of the company. This peer focused me on schedules. This one focused me on team dynamics. This one taught me how to listen and not immediately react. A collection of people helped me become the manager I am today, and now I feel that it’s part of my job to share my experience with younger managers the same way that others invested in me.” |
