I have come to embrace the use of cross-functional teams for product launch as being vital. But my initial exposure to cross-functional teams was frustrating to say the least. I was working for Viasoft in Phoenix. At the time Viasoft was rocking and rolling due to Y2K hysteria and we were loving every minute of it. Viasoft had grown to a size where bringing a new product or version to market was getting complex, and being a publicly held company there were more T’s to cross and I’s to dot.
For the most part the company was winging product launches. Diving catches in the end zone with seconds before the game ends were the norm. Wisely, the management team adopted the cross-functional team (CFT) approach. We started a project office and a small team of people with no previous product launch experience were given the task of defining a company standard project template for product launch. These folks were talented project managers with a commanding knowledge of MS Project, but they just weren’t familiar with the nuance of bring a software product to market. There are lots of variables and gray areas that aren’t always easy to represent in a project plan.
I was given responsibility of a product line and walked into my first CFT. The attendees were already designated and of course we had someone from the project office to oversee the process. I walked into a conference room filled with 22 people. These were people from every nook and cranny of the company and believed they had a stake in the process. I conducted the meeting and smiled, but knew that this would never work. This many people in a room at one time is counter productive. Period. The first meeting went for several hours. The expense to the company on an hourly basis was immense.
Keep in mind that although the company wanted CFTs to improve execution, we didn’t receive any training on how to use CFTs effectively. Every product manager approached their CFTs differently. Some refused to use them at all. I decided to lean into it.
I started by setting some ground rules. First, there could only be one representative from each functional area. That person must have the authority to act on behalf of their department. That one took a little finesse to make happen, but it worked. OK, now the number of people was cut down considerably.
Second, I limited CFT meetings to 1 hour. This was a status meeting. Anything that started down the path of problem solving or brainstorming was tabled and scheduled as a separate meeting.
Third, I developed a standing agenda that was distributed in advance of the CFT meeting. Everyone had what they needed to be prepared for the meeting. And they knew if their participation was mandatory or optional.
Fourth, I schedule a standing meeting. Same day of the week. Same time. Even when I was traveling we conducted the meeting. No excuses for not knowing when the meeting was scheduled.
Fifth, it became apparent that these meetings could easily be dominated by the development team going over the status of the most minute feature details that had no relevance to a number of the CFT members. To address this I scheduled a separate, standing meeting with the product development group just to cover product development status. Established members of the CFT could attend if they wanted, but it wasn’t mandatory.
Sixth, I designated someone to take meeting minutes. That freed me up to drive the meeting and keep the flow going.
I still had challenges and learned many more ways to make CFTs better, but these 6 simple things enabled the team to be more effective, more attentive and more committed to achieving results.
