My job as an engineer often resembled the famous comic strip Dilbert. That resemblance was due mostly because of the communication – or lack thereof - between management and the engineering department. Please indulge me for a moment in exploring how I tried to apply the concepts discussed in Kenna’s Dilemma (by Malcolm Gladwell), Turn Customer Input into Innovation (by Anthony Ulwick), and Metaphorically Speaking (by Gerald Zaltman) on one of my projects at my previous employer. I wish I had read these articles before.
For a while I had the job nobody wants in the engineering department: project manager. In fact, most other engineering departments in that company didn’t have one, because first level managers didn’t want to deal with a person who didn’t understand the ins and outs of the engineering tasks at hand. However, schedules had to built, progress had to be tracked, and budgets organized, with carefully crafted reports that were sent weekly to second and third level managers for appraisal.
So let’s assume that I was dealing with a real market situation and the following character were involved:
· Engineers are the experts described by Gladwell – they know what has to be done in a project in great detail, they are actually doing the work, and they need a tool to show them where they are in the project
· Second and third level managers are the end consumer – since they are actually using the reports and paying for it
· “Market research” - a third party translating the needs of the end consumer to my company. In this case trying to use tried and true techniques to find out what the end consumer wants)
· The company who needs to provide a service is my first level manager and me, the people generating the schedules, metrics, and reports.
As a company with a service to provide and easy access to experts but not the end consumer, I held a series of interviews with those experts trying to identify what they thought was important in managing a project. This was the first instance where Turning Customer Input into Innovation would have come in handy. My mistake was that I started the interviews with a lot of biases and asked very guided questions regarding what our project schedule should look like, how granular the tasks should be, and how progress should be tracked. I didn’t follow the steps of breaking out the project management task into pieces, organized the solutions into outcomes, or tried to rank the outcomes in order of importance. I also didn’t use metaphors or imagery to try and get the best information out of my experts. I assumed that as one of the engineers in the project that was unnecessary.
Still, a schedule was built that captured all the important tasks to the experts, with dates and durations that they liked and a way for them to monitor when a task was lagging behind, so that corrective actions could be taken. The experts seemed happy with the outcome. I was also happy with the outcome, since as a service provider, I made sure that the metrics and the schedule were easy for me to update. It was a good set of product and services. I was proud of my accomplishment.
But then news came out of “market research” that our end customer wanted something else. According to market research, our customer really wanted a schedule that had more constraints: each task should not exceed 90 days. Also, the tracking mechanism for progress should be a direct translation between the percentage of task completed and the hours spent on that task. To the experts, that was a travesty, because it assumed no room for any error on their part in assessing the lengths of tasks or for additional work that could have come up on those tasks. Plus, there had to be a report showing the discrepancies between the hours planned for each week and the hours worked on each task, if they did not match.
There were countless meetings, in which I argued with the customer (I guess that should never be done in real life) about how the system I had developed with the experts was good. I felt like Dilbert trying to present an idea to his pointy haired boss, knowing very well it was falling on deaf ears. After reading about metaphors, I would have used more images and analogies to present and sell my point to the customer, as opposed to using it as a way to finding out what the customer wants.
As if it weren’t enough, the end customer kept changing its “wants” every 2 or 3 months. Market research would indicate there was a need or a want for a new report or a new plan for the same project to accommodate new dates.
As a good service provider, I adapted. I change the schedule to be as flexible as possible to meet what I thought were the end customer and the experts needs. I tried to make it my business to anticipate the end customer in new reports, so that I wouldn’t be caught off guard. I also kept close contact with the experts, to identify changes in the project itself early on, so that the reports would flow smoothly.
When I was leaving my job to start graduate school, nobody in my team wanted to take that task from me. I think that after reading these articles, I have a much better understanding of what needed to be done. I would have conducted the interviews with the experts in a different manner. I would have communicated more with market research before developing a product based only on the experts’ opinion. I know I would have come up with a better product for everyone.
No comments:
Post a Comment