Listening
To start, you need to listen non-judgmentally. Too often, we jump to conclusions, share observations, blurt out solutions, and fail to give others time to assimilate information from our point of view.
A few years ago, I was talking with a potential client that had a very successful data analysis company. The problem they were having was with a custom piece of proprietary hardware they had designed and built to collect the data. The business development manager, who loved hardware design, was managing the product development and was relaying the current situation. I asked for the history on how they got to their current disheveled state. He sighed and told me his tale of woe.
The first release was a success, but after short time a key supplier of one of the core components, a small company, went out of business. This made him look for a new supplier. Adding to the frustration was that all the other suppliers charged a significant amount more. We talked about the functionality and a few other particulars on that version. He continued by saying that about a year later they created a new revision and changed that same component's functionality to use firmware so reprogramming would be easier. They contracted with an individual to design the part, who was desperate for work. As a result, they got a great deal. Unfortunately, the protocol used was nonstandard and no other suppliers knew it. When the contractor found fulltime employment, they were again without support. Version 3, the version in current use, had another component losing support and they needed to find a new vendor.
The present problem was on a contract with a new company, started by a recent college graduate, to supply a subset of components. He was running into multiple problems, various vendors were arguing that he had designed the interfaces incorrectly, and now he had taken another job out of state. The business development manager was left with money invested in an unusable product. He insisted the problems were unavoidable and the company's strategy was prudent and fiscally conservative.
Projects take more than managers, they need leaders. Leading is a special set of skills that one needs to hone and develop. We have numerous white papers on the topic. One, Transforming Project Managers Into Project Leaders talks specifically about what a PM must do to become a leader. |
Look at the
|
Building The Story
I returned to my office to determine how to approach telling them that they needed to focus on gathering and analyzing data, not building hardware, and the business development manager's pet project should be given to a company that specializes in developing custom hardware. I sent them an email asking about their growth plans for each business unit and clarifying a few other points from our conversation. From this information, I outlined the following agenda:
- Summarize the information that I had gotten, ask how they are going to achieve their aggressive growth goals, and what role the business development manager would have in that.
- Ask them how they were going to address the common issues any growing company would see—security, cross-training, hiring new staff, etc.
- Ask how they are going to continue managing a custom product development while doing this ramp.
- If required, list the problems with the previous versions highlighting the areas that were a result of not having an established hardware company managing and building their custom equipment.
As I replayed what I had been told, they started filling in the answers, arriving at the conclusion that they should focus on their core business of collecting and analyzing data, rather than building hardware. I never had to mention bullet 4, they came to that conclusion on their own. Investing time in building a trusting relationship with a reputable product development group, whose responsibilities would include architectural design, building, and supplier management, would free up time of the business development manager to... well... develop new business. It would also insulate the company from problem in the hardware supply chain.
Obvious Solution
I could have told them in the first meeting that product development was not their forte, and that the business development manager's pet project of managing all the vendors was costing them dearly, but I would have not been invited back. As obvious as some answers seem, when situations have evolved over time the people in the middle are unable to see some of the most obvious answers. Replaying their words in a different context is the key to shedding light on the proper direction and draws them to the conclusion using their own words. You simply facilitate the process.