By Alan Zak
I’m a vice president at Line6, where we produce electronics for musical instruments. My company recently developed a guitar that can be programmed to sound like twenty-five different classic guitars — everything from a 1928 National “Tricone” to a 1970 Martin. It is quite an amazing piece of technology.
The guitar started as a research project because we needed to know if the technology was going to be viable and if the guitar design was going to be practical. I’ve been in this business for about twenty years now, and I still enjoy starting up projects whenever the opportunity presents itself. During the research phase, I headed up the project myself.
Once we completed our preliminary research and made the decision to move into development, that’s when I handed the project off — and that’s where this story really begins.
Orchestrating a hand-off
We had an engineer, Dave, who had project management experience on comparatively smaller derivative projects, some of our more-or less-matured signal-processing gear. In that role he was performing well, and he had been brought in to help the researcher developing the concept for the new guitar. When we made the decision to develop the guitar, Dave asked me if he could take over the project.
When I kick off new initiatives like this one, I never take them to the finish line. I hand them off to a project manager already in the ranks, or I try to mentor someone who’s just starting out in project management. The guitar project was going to run nine to twelve months, which is a relatively short span for our projects, and would only require a small team. It didn’t seem too big a project to consider a new manager.
I have to admit, though, that I had my concerns about handing off the project to Dave. He wanted to keep his hands in the firmware development, and become the project manager on top of that. There were many, many challenges in the project. Could we give the instruments an authentic sound? We had never done this. That was the first challenge. The second was that we weren’t simply dealing with electronics. As an instrument, the guitar required attention to aesthetics as well as its tactile qualities. It needed to be desirable for the customer from a “playability” standpoint. We might get our arms around it from an engineering vantage point, but we also needed to work with an outside manufacturer for the body.
Dave is certainly a competent engineer — but one of the problems we sometimes have with engineers is that their people skills aren’t strong enough to be effective project managers. Now, I knew that Dave had a hard-core engineering background, but I also knew that he had worked well with his team when managing derivative programs. Plus, he was a guitarist himself. So, he had the enthusiasm I look for. The other thing that I suppose sold me is that he told me that he had been doing some soul-searching and looking at his career track and so forth, and he really wanted to develop his skills as a project manager.
We talked about all of this a lot before I agreed to let him lead the project. I said, “You know, this can be difficult. If you want to do it, more power to you. We will try to help in any way we can, but if the situation does get to be more than you can handle, we need to know.”
I gave Dave the project because he had a good track record. But I knew that I was introducing an element of risk to the project, because the scope was larger than what he had handled before. This was something we would need to watch carefully.
Project discord
Fast forward a few months: Dave did get himself into trouble. The main problem was that he wouldn’t relinquish his technical responsibilities. In essence, he was saying, “While I’m doing the engineering myself, I’m also going to be managing the project.” And he did deal well with the engineers and technicians on the program. But we also needed for him to be dealing with the manufacturing interests, supporting the subcontractors, looking ahead to the marketing aspects, keeping control of the financial planning, and staying on schedule. There’s a reason that project management is a full-time job.
Dealing with the body manufacturers in Korea and China, and integrating that with our own electronics manufacturing here in Los Angeles, came close to being a full-time job in itself. The electronics work was also experiencing some minor setbacks. As a result, the project was falling farther and farther behind schedule. I had to have some very frank discussions with Dave. “In my view,” I told him, “you’re spreading yourself too thin.”
Invariably, a young project manager will respond, “I’m not spreading myself too thin. I can keep this thing going, and it’s going to get better. Just because I was here until midnight, you know, it doesn’t really matter. Give me a week, you know, we’re going to turn this thing around.”
In this case that went on for more than a month. From my perspective, it got worse and worse as we went. At last, I said, “Dave, if we get to this next milestone and it’s still apparent that you can’t function at the higher level of visibility that we need, we’re going to have to bring in some help.”
I think the nail was put in the coffin when the production units arrived, and they were badly flawed. They were 50 to 60 percent unusable. At that point, I knew I had to bring in a new manager.
Dealing with the dissonance
It never is pleasant to replace a project manager, especially a young one, because you always, to a certain degree, hurt their feelings, their pride. I brought in a manager, Kevin, with a proven track record who was winding down work on a couple of other programs. He was the best project manager we had on staff.
Earlier, when I had handed off the project to Dave, it was a natural progression. Kevin and I both understood that this second hand-off was very different; it was a sensitive matter. Kevin didn’t want to come in and usurp the good things that had been going on, including the camaraderie that had developed among the team members at that point.
By telling their leader to step down, we might inadvertently be letting the team down, and the project could have unraveled quickly. Once things do start to unravel, I know from experience that sometimes you can’t put these things back together. My prime concern during the transition was to keep the team enthusiastic and highly motivated.
The way I dealt with that was by staying involved after Kevin took over. I had as much open dialogue with the team as possible — with the schedule as a backdrop. In other words, when Kevin and I put together a new schedule, we didn’t foist it upon the team saying, “Look, you’ve got nine months. You had better make it happen.” No, it was a collaborative process. The team not only signed up for the new schedule, they authored it. Once we all had agreed on a schedule, I held regular weekly meetings with the team and the new project manager where we looked at the milestones against our schedule.
And what of Dave? Yes, I replaced him as project manager, but I wasn’t saying, “You know, we’re just going to cast you aside and move on.” I believed that he still had much to offer the project, and that he was committed to see it through to the end. Dave remained on the project, but strictly in a firmware capacity.
His first reaction was typical of what I usually see in cases like this. The project manger that’s being replaced says, “Well, okay, I understand. We’ve got to do what’s best for the program.” He understands that was a logically sound decision to make; but then the emotions kick in. In general, the people who work for us put their heart and soul into these projects. When they’ve been disappointed like Dave was, often they’ll start acting out. Sometimes it’s as benign as being a little less responsive. In extreme cases, they find ways to demoralize the rest of the team.
This was not an extreme case. Dave’s bitterness, or resentment, simply had to be managed. I would say that his cooperation ebbed and flowed. In order to let the new project manager focus on more important issues, I took on the job of monitoring Dave’s attitude. I made an effort to work alongside him on occasion, so that I knew when I needed to take him out to lunch and have a talk with him, or when I needed to let things go to give him some space.
The next movement
In hindsight I can see that I made a mistake in picking Dave to be the original project manager. He had a good track record with smaller scope projects, but I misjudged the level of risk that I introduced to the project by selecting a manager whose experience had not prepared him for the magnitude of this particular project with its many interfaces — including manufacturing teams, offshore contracting, and FCC oversight interfaces.
I also had to relearn another lesson: Project management is a full-time job. If a project manager also wants to take on a technical role on the project, it must be a small, limited role — and not something in the critical path. If you have anyone trying to take on a managerial role, but they’re also implicated in the critical path, really in all cases that’s a recipe for difficulty if not disaster.
Dave is still with our company, and still working productively. For now, I have made the decision that his future lies on the architecture side of our work. He might have thought that he wanted to be a project manager, but it became clear that his heart was still in the engineering. More than anything else, he wants to be working with the latest, greatest digital signal processing. So, he’s very happy in that role. For now, anyway.
And what of the guitar? Even after the new manager came on board, we couldn’t get the project back on schedule. Early missteps are difficult to make up, and it was clear that in several respects we did not meet our objectives. One example: We didn’t deliver in time to make our original marketing window.
Still, I didn’t let the project slip too far before interceding. Ultimately, the project was saved. The guitar was delivered three months later than we had hoped, but it’s doing extremely well on the market. In fact, it was our most popular product in the industry last year.
Lessons
- Project management requires skills and experience, but first of all it requires dedicating sufficient quality time to the project. A novice project manager must understand that his or her new role will demand significant energy and time.
- When a project manager is replaced, even if the transition is handled in a timely fashion and with sufficient sensitivity, the project may still require a great deal of oversight on the part of project sponsors. Substituting one project manager for another should not be seen as a “quick-fix.”
Question
Under what circumstances should a project sponsor remain closely involved in a project after a hand-off?
Search by lesson to find more on:
- Mentoring