Innovative Design vs. Lean Product Development April 17, 2013
Posted by Tim Rodgers in Management & leadership, Product design, Project management, Quality.Tags: innovation, management, process, product development, six-sigma, strategy
2 comments
I’ve been very busy focusing on my job search and some self-improvement projects, and unfortunately it’s been harder to find some time to address my accumulated backlog of topics. I regularly follow several group discussions on LinkedIn related to product development and quality, and lately a popular discussion topic is how to inspire innovation in product design.
See for example Wayne Simmons and Keary Crawford “Innovation versus Product Development” (http://www.innovationexcellence.com/blog/2013/04/12/innovation-versus-product-development/), and Rachel Corn’s blog “Is Process Killing Your Innovation?” (http://blog.cmbinfo.com/bid/87795/South-Street-Strategy-Guest-Blog-Is-Process-Killing-Your-Innovation?goback=%2Egde_2098273_member_229196205). The latter post quotes a former 3M vice president who says that Six Sigma killed innovation at 3M, apparently because 3M’s implementation of Six Sigma required “a full blown business case and even a 5-year business plan to get a new idea off the ground and into production.” The VP wonders: how do you institutionalize innovation without stifling it?
The conventional wisdom seems to be that product design is inherently a creative, right-brain activity that will fail or at least fall short if constrained by process. You can’t make art on a schedule.
I think this is a false conflict. I don’t see any reason why teams shouldn’t be able to conceive new designs within a structured and disciplined product development environment. Obviously the ultimate objective is to get a product to market, so at some point the experimentation must end, doesn’t it?
Six Sigma is about reducing variation. The lean movement is about eliminating waste. I understand that the early stages of product development may be wildly unpredictable and seemingly inefficient. Shouldn’t the latter stages focus on predictable outcomes, standardized processes, fast time-to-market, defect prevention, and efficient production?
Can Managers Make Innovation Happen? February 12, 2013
Posted by Tim Rodgers in International management, Management & leadership, strategy.Tags: innovation, job satisfaction, leadership, management, performance measures, strategy
add a comment
I’m hearing a lot about innovation these days. It seems that everyone is looking for new breakthrough ideas in products and services in order to grow revenue, differentiate from competition, and establish sustainable profitability. However, waiting for a flash of inspiration or “Eureka” moment is too random and unpredictable for most businesses. They would like to actively innovate, or at least provide an environment where productive innovation is more likely to happen.
What role do managers play in an organization that’s looking for innovation? What can managers do to inspire or foster innovation? I’ve always operated under the assumption that innovation is a creative, “out of box,” right-brain activity that can’t be managed with performance objectives and a schedule. I’m not convinced that you can innovate on-demand. I can’t recall ever attending a scheduled group brainstorming session that led to breakthrough ideas.
Some years ago I visited a peer manager at a different HP site to do some internal benchmarking and look for some best practices that I could bring back to my team. On a monthly dashboard of department metrics this manager included a bar chart showing the number of patent applications proposed by the team. I was astonished that this group of about 30 engineers and managers were averaging 30-40 applications every month. I was especially curious because this was a software quality team, and it wasn’t clear to me what part of our work could be patentable.
It turned out that the patent applications up to that time had nothing to do with software quality, or software testing, or anything remotely related to the products we were working on. Most of them seemed to be new applications of existing HP products. There may have been some occasional good ideas for new products in there somewhere, but I can almost guarantee that none of those patent applications were new, or unique, or valuable enough to be actually filed by the HP legal staff.
At the time I wasn’t eager to challenge the HP manager who was hosting my visit, but I still wonder what they were trying to do. The energy put into patent proposals didn’t seem to provide any direct contribution to the department’s objectives. I suppose it’s possible that the team brought more creativity and innovation to their work in software quality as a result of their patent efforts, but I couldn’t tell how that positively affected their other performance measures. I don’t think this was a good example of inspiring innovation.
I’m still not sure what managers can do to make innovation happen, but I think managers have a lot of influence over the work environment, and that can create conditions where innovation is more likely to happen:
1. Managers can communicate the business’s strategic interest in innovation, and help channel the team’s creativity to address specific needs (e.g., new products, new processes to reduce cost or improve quality).
2. Managers can identify those people in the team who are inherently creative and encourage them. Good ideas can certainly come from anywhere, but the fact is that some people are better able to think outside the box and make unexpected connections.
3. Managers can keep an open mind about new ideas and provide sufficient time and resources to evaluate them. This can be hard when resources are limited and the innovation is unfamiliar and risky. On the other hand, you shouldn’t expect the team to be innovative when there’s no chance their ideas will be given an opportunity to prove themselves.
I don’t think of myself as an innovative person who can generate creative ideas. I do think of myself as someone who understands the value of innovation to the business, and I want to do what I can to enable others to innovate effectively.
How Much Information Should a Manager Give To Their Team? February 4, 2013
Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Project management.Tags: communication, leadership, management, manager, power, project management
add a comment
I’ve been pretty busy over the last few weeks focusing on my job search, interviewing for a couple of positions, and preparing for a possible teaching assignment at a local university. The evaluation process at the university included a 15-minute audition that was intended to provide some insight to each candidate’s presentation and facilitation skills in a classroom environment. Fifteen minutes is not much time, and during my lesson planning I decided to deliver a small packet of information, repeated and reviewed. I know from experience that there’s a tendency to overestimate the ability of an audience to listen and absorb.
This reminded me of something I read during my preparation for the Project Management Professional (PMP) certification exam last year. One of the topics on the exam was Project Communications Management, which included identifying stakeholders, and planning the communication processes necessary to keep them informed, according to their expectations. Project managers were encouraged to strive for efficient communication, providing only the information that each stakeholder requires.
I suppose the intention is to keep it simple and avoid the confusion and doubt that can accompany information overload, but I don’t think this is necessarily a good strategy. There are potential problems when the project manager is the only person who has all the information about the project:
1. You run the risk of creating a dependency bottleneck, where one person must always be available to communicate status, resolve issues, and answer questions. This can be mitigated somewhat with easily-accessible project documents, assuming people know where to find them and are willing to use them.
2. Team members may be constrained by a narrow perspective that limits their ability to respond quickly or deal with ambiguity because they aren’t permitted to see the big picture. Surely the project benefits when the brainpower of all team members is fully-engaged. even at the risk of sharing “too much” information.
Look, I don’t think everyone needs to know everything all the time. I just think we shouldn’t be too quick to withhold information in the name of communication efficiency.
Reinventing the Wheel: Overcoming the Bias Against Internal Best Practices January 15, 2013
Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Process engineering.Tags: leadership, management, power, process
add a comment
I’ve been puzzling over this one for some time: Why is it so hard for companies to leverage best practices developed internally? At HP we used to think the problem was poor knowledge sharing mechanisms within the corporation, especially across geographically-dispersed and independent business units, but I think it goes deeper than that. You can tell people to document and archive their processes on SharePoint, and you can host internal conferences to provide a forum for learning, but unless people are open to the possibility that there’s a better way you’re going to waste money reinventing the wheel.
The “not invented here” syndrome leads to bias against ideas that come from the outside. “They don’t understand our unique environment,” and, “Just because it works there doesn’t mean it will work here.” Even when compelled to use the new process there’s often passive-aggressive undermining or outright sabotage. Unfortunately these internal antibodies are often more antagonistic towards ideas from within the same company. If we use someone else’s ideas, doesn’t that imply that they’re smarter than we are? We don’t want them to get the credit, do we?
Sorry, but the smarter one (and the more valuable one to the organization) is the person who focuses their attention on the unsolved problems instead of those that were already solved. We all build on the foundations of engineering and process development that came before. Of course the local environment may indeed be different, and that may require a tweaking of the imported process. However, senior leadership should encourage leveraging of internal processes as another example of maximizing return-on-assets, and both the exporter and importer should be recognized as efficient collaborators. Also, when teams insist on using their own process they should bear the burden of proof to explain why the company should incur the additional expense to maintain more than one means to accomplish the same goal.
It’s Business, Not Personal January 8, 2013
Posted by Tim Rodgers in Management & leadership.Tags: career growth, job satisfaction, management, manager
add a comment
The line is from the movie “The Godfather.” Al Pacino as Michael Corleone insists that his plan to murder a New York City police captain and a rival mobster who tried to assassinate Michael’s father is motivated by business considerations, not revenge. As we watch Michael’s rise to power and systematic elimination of his enemies it becomes hard to see any difference between what is personal and what is business, and it hardly seems to matter anyway. But, at least in the beginning, the implication is that “making it personal” is a bad thing, leading to cloudy judgment and decisions that are not in the best long-term interest of the enterprise.
In the world of organizations not characterized as organized crime, “making it personal” is not necessarily a bad thing. When employees feel a passionate and visceral connection to the success or failure of the business, they are far more likely to give their best effort, particularly when they perceive alignment between business goals and values, and career goals and personal values. This linkage is even stronger when personal rewards (salary, bonus, stock, options, other perks) are tied to some measure of business performance.
Of course the wrong choice of performance measures can lead to decisions that are good for individual but bad for the organization, for example bonuses tied to sales and revenue targets that ignore the profitability of the new business. This is why we have laws and regulations governing insider trading.
Unfortunately there are many other potential conflicts of interest. When the reward pie is fixed in size, people will compete, sometimes in unethical or even dishonest ways. I’ve worked at companies where CEOs made strategic decisions that have been attributed to personal motives and perceived threats, although a CEO’s emotions are theoretically supposed to be held in check by the board of directors and major shareholders.
A manager’s job is generally easier when the team is energized, each person for their own reasons. The challenge for the manager is finding a way to “make it personal” without unwittingly undermining the business’s strategic objectives, by rewarding the wrong behaviors, or allowing personal achievement to become more important than business success.
Decisions Based on Psuedo-Quantitative Processes December 28, 2012
Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Process engineering, Quality, strategy.Tags: leadership, management, performance measures, problem resolution, project management, six-sigma, strategy
add a comment
I’ve spent a lot of time working with engineers and managers who used to be engineers, people who generally apply objective analysis and logical reasoning. When faced with a decision these folks will look for ways to simplify the problem by applying a process that quantitatively compares the possible options. The “right” answer is the one that yields the highest (or lowest) value for the appropriate performance measure.
That makes sense in many situations, assuming that improvement of the performance measure is consistent with business strategy. You can’t argue with the numbers, right? Well, maybe we should. In our rush to reduce a decision to a quantitative comparison we may overlook the process used to create those numbers. Is it really as objective as it seems?
There’s a common process for decision making that goes by several different names. Some people call it a Pugh diagram or a prioritization matrix. A more sophisticated version called a Kepner Tragoe decision model includes an analysis of possible adverse effects.
These all follow a similar sequence of steps. The options are listed as rows in a table. The assessment criteria are listed as columns, and each criterion is given a weighting factor based on its relative importance. Each row option is evaluated on how well it meets each column criterion (for example, using a scale from 1 to 5), and this assigned value is multiplied by the weighting factor for the column criterion. Finally, the “weighted fitness” values are summed for each row option, and the option with the highest overall score is the winner.
At the end there’s a numerical ranking of the options, and one will appear to be the best choice, but the process is inherently subjective because of the evaluation criteria, the weighting factors, and the “how well it meets the criteria” assessment. It’s really not that hard to game the system and skew the output to provide any desired ranking of the options.
I’m not saying this is a bad process or that the result is automatically invalid. What I am saying is that this isn’t like weighing two bags of apples. The value of a decision analysis process isn’t just the final ranking, it’s the discussion and disagreements between the evaluators, which are obviously subjective. We shouldn’t consider the process to be an infallible oracle that delivers an indisputable answer just because there’s math involved.
I’m sure there are other examples of psuedo-quantitative processes that shouldn’t be accepted at face value. Leaders should question assumptions, listen to dissenting opinions, and check for biases. It’s rarely as cut-and-dried as it seems.
Leaders and the Illusion of Control December 20, 2012
Posted by Tim Rodgers in Management & leadership, Organizational dynamics.Tags: change management, job satisfaction, leadership, management, power
add a comment
I’ve just finished Anne Applebaum’s excellent book Iron Curtain about the systematic efforts by Soviet-sponsored communist governments in the post-WWII period in Germany, Poland, and Hungary to eliminate opposition, collectivize the economy, and generally create a new society. The local leaders of these countries were guided by their interpretation of Marxist-Leninist principles and the contemporary model provided by the USSR, with guidance and direct orders from Moscow, often approved personally by Stalin (at least up until his death in 1953).
Despite each government’s aggressive efforts to stamp out all institutions and businesses that were not approved by the state, the people of these countries retained a strong desire to assert themselves economically, spiritually, and socially. The communist party leadership believed they could raise the awareness of the working class and mold the young minds of the next generation, but ultimately all of these regimes collapsed in the late 1980s.
I think there’s a lesson here for business managers and leaders. Certainly few modern managers think of themselves as totalitarian dictators, but to some degree we all try to exert some kind of control over our teams. On a group level we guide the team toward a business objective, and on an individual level we try to modify or influence the behavior of subordinates. But, how much control do we really have? Can we really move people to a place where they don’t want to go?
Leaders need to take the time to understand the motives and interests of the individuals they’re trying to lead, and use those as an energy source to keep things moving in the desired direction. People are much more likely to support change and achieve organizational objectives when they perceive some alignment with their own personal values and goals. If that alignment is missing, then your ability to control outcomes is limited and illusory, regardless of your positional power.
Changing the Tires While Driving the Car December 13, 2012
Posted by Tim Rodgers in Management & leadership, Process engineering, strategy.Tags: 30-60-90 day plans, change management, leadership, management, process, strategy
add a comment
That’s a phrase we often use to describe a chaotic work environment, but what if anything can be done when you’re faced with this situation? How should we manage when the current processes are incomplete, insufficient, ineffective, or even missing? How do you evaluate and implement process improvements without jeopardizing commitments to deliverables and performance metrics? Is there a logical way of managing these changes, or do we muddle through it, and later smile sympathetically when we hear about another manager’s struggles?
Obviously the whole point of introducing a new process or making a process change is to gain some improvement in performance, output, and/or cost. However there’s no getting around the fact that any process change will be accompanied by at least a short-term loss of productivity until you’re past the learning curve.
Will the current activities or projects continue long enough to benefit from an immediate change? If the benefit doesn’t outweigh the “distraction cost,” then it’s probably better to wait for scheduled downtime or a natural break between projects (in other words, wait until the car is stopped before changing the tires). If there is no natural break, then at least one project will have to pay the price so that future projects can realize the advantage. Which project can best tolerate the cost, or the risk of failure to meet scope or schedule requirements?
One practical question is whether it’s even possible to switch processes in mid-stream. If you’ve already started with the old process, can you finish the job with a new one? Starting over again from the beginning should be considered a last resort, only practical if the existing process is so unsatisfactory that you’re willing to sacrifice time for better results.
Another key concern is whether or not the organization as a whole is aligned with the need for a process change. It may be politically useful to roll out the new process on a small scale in order to build support for broader implementation. On the other hand, if there’s enough critical mass, it can be highly effective to “burn the boats,” essentially making it impossible to return to the old process.
If it’s the right thing to do, it’s just a question of when. If the benefits can’t be clearly articulated, it will never be the right time.
Consulting Pull vs. Push Strategies December 10, 2012
Posted by Tim Rodgers in Management & leadership, Organizational dynamics, strategy.Tags: change management, leadership, management, problem resolution, strategy
1 comment so far
Several of my former colleagues are now working to establish themselves as independent consultants. I’ve thought a lot about consulting over the last few years. I’m attracted to the narrative of tackling a new puzzle, dispensing wisdom from an independent perspective, solving problems and fixing whatever needs fixing, and then accepting the team’s grateful thanks before riding off into the sunset in search of the next opportunity.
I suspect it doesn’t work that way for the majority of solo consultants. Consultants are no different from other businesses in that they have to define a value proposition that’s compelling to their target market and provides some competitive differentiation. Building a successful practice requires advertising and promotion. You have to offer something that people need, and you have to sell it.
It seems to me that selling a consulting service should be focused on making it easy for a potential client to understand how you can solve a problem. The client’s gain that will be realized after the solution of the problem provides the potential energy or attractive force that pulls the consultant in. Some effort is necessary to identify a problem that’s worth solving (your target market), but that surely requires less effort than trying to push a solution on a skeptical or reluctant client.
Your choices are:
(1) Wait for a client whose problem is so serious and evident that they know exactly what kind of help they need (“the power’s out, so let’s call an electrician”). That definitely doesn’t require much energy on your part, but it’s also a very passive approach.
(2) Cold-call clients armed with your credentials, in the hope that one of them will have a problem that coincides with your current availability and skills (“excuse me, do you need an electrician?”). This is the hard-sell push and requires a lot of energy.
(3) Think about how your skills can benefit potential clients, then target your business development activities accordingly (“I can help you reduce your energy bill”). This approach is still active, but uses the customer’s emerging awareness of the problem to pull you in.
Just as change management requires people to first accept that the status quo is unacceptable, clients are more likely to be open to a consultant if they first acknowledge the existence of a problem. The consultant looking for business should focus on problems that need solving and the benefits to clients (in terms the client can appreciate), not tools or specific solutions.
Business Processes: Configuration, Customization and Convergence November 27, 2012
Posted by Tim Rodgers in Management & leadership, Organizational dynamics, Process engineering.Tags: change management, leadership, management, process, product development
add a comment
In the mid-00s after Mark Hurd’s accession to the CEO office HP’s senior leadership aggressively pursued overhead cost reduction to improve the firm’s profitability. HP’s CIO used this opportunity to consolidate IT functions, simplify processes, and eliminate redundancies due in-part to “shadow IT” groups that had grown up during the previous era of independent business units and local autonomy.
One of the early targets were the defect tracking systems used by product development teams for reporting, management, and disposition of defects found during pre-release testing. I don’t remember the exact count, but apparently the number of active defect tracking systems was in double figures. The IT team determined that convergence on a single, common, corporate-wide DTS hosted on corporate servers would lead to significant savings: from reduced headcount and other support resources, and harder-to-quantify efficiency, productivity and communication improvements.
The DTS convergence project did not go smoothly. Many product development teams objected strongly to the plan. They claimed that they would not be able to meet schedule and quality commitments for projects already in-progress if they were forced to switch to a different DTS in mid-stream. Unfortunately it didn’t help that the corporate IT team seriously underestimated the effort required to manage the transitions. Some product development teams appealed to their business unit executive, looking for an exemption or at least a delay. Others adopted a passive-aggressive position that only hardened the resolve of the IT team.
The corporate IT team objected strongly to the idea of local customization of the DTS and supporting processes, arguing that the overall cost savings and other benefits would be significantly reduced if every product development team were allowed to run their own system. I think the IT folks would have had a better chance of success if they had acknowledged the value of local solutions and introduced a system that enabled local configuration instead of customization.
The core functionality of the DTS could be retained, and the support resources minimized, while allowing the local product development team to define or select options to match their familiar and preferred style. Certainly this would not have eliminated all resistance to the change, but it would have enabled a more balanced discussion of the benefits of a common DTS that recognizes and values the needs of product development.
This happens frequently in business processes of all kinds, especially in multi-site organizations or in the aftermath of a merger/acquisition . One side pushes for convergence and the other side insists that they need a custom solution because of their unique requirements. The trick is to find a way to design a common system that can be locally configured without giving up the expected benefits in support cost and communication.
