One attribute of a successful problem solution is affordable cost. At every stage of development from conception through elaboration, design, deployment, usage, and retirement, the cost of the solution must be within the reach of the users of the solution. One common pattern that hinders finding successful solutions is excessive concern with costs during the conception stage.
To clarify the importance of understanding the problem in depth, consider this admittedly artificial scenario based on a workshop exercise:
The Marigold project team has been charged with building a tower using only index cards. Neither tape, nor glue, nor fasteners of any kind are permitted. The tower should be as tall as possible using no more than 5000 cards. According to the rules, the "revenue" for the invention is calculated as 1000*E, where E is the elevation of the tower's highest card in centimeters. The "expenses" are calculated as 10*C, where C is the number of cards used. "Profit" is Revenue minus Expenses.
The team immediately starts exploring ways of building tall card towers using very few cards. After about a half hour of this, two team members, Roberta and Robert, leave the room to get ice creams and to think. When they return, the other tower builders have constructed a wobbly tower about two meters tall, which immediately collapses from the breeze that comes through the door Roberta and Robert opened when they returned.
While the other tower builders rebuild their tower, Roberta and Robert decide to read the rules again. (In the real world, the "rules" would be called "requirements.") They discover that the rules have a loophole. If they insert a single card into the crack between two ceiling tiles, that one card meets the definition of a "tower" according to the rules. And the elevation of that card is as high as the room will allow. So, highest possible tower, minimum possible card count. Voila! Maximum "profit."
This scenario Devising brilliantly clever problem
solutions often requires a deep
understanding of the problem spaceillustrates two important points about problem solving. First, devising brilliantly clever problem solutions often requires a deep understanding of the problem space. And second, understanding cost sources for solutions requires understanding the properties of the available solutions.
Problems of scale are high risk
The importance of these two ideas is perhaps most obvious when the solution to the problem at hand must scale. In problems of scale, after we find a solution, we must deploy many copies of that solution to large numbers of users. Because some solutions scale more readily than others, cost comparisons among solution options must take scale into account. And that can be tricky for some teams.
The composition of many problem-solving teams is biased in favor of knowledge relevant to conceiving and implementing solutions. There are sound reasons for this. Early in the problem-solving process, the range of possible solutions is poorly understood. Because the people most familiar with implementation technologies are also best able to generate solution options to investigate, we tend to populate problem-solving teams with people who are needed early in the problem-solving process.
But in some cases this practice introduces risk when the team focuses on cost comparisons among solution options too early in the problem-solving process. Consider what happens when significant costs of all relevant solutions are associated not with implementing or manufacturing copies of a solution, but instead, with deploying the solution, or with convincing users or customers to adopt it. For such problems, comparisons of costs of solution options based on comparing their implementation costs are likely to provide misleading results.
This phenomenon is more likely to occur when a solution has significant cost components that lie downstream of the conception phase of problem solving. For example, consider two kinds of attributes such a problem solution might have.
- Implementation costs are associated with the technologies employed in actually conceiving the solution. For example, if we're making an adhesive, the chemistry of adhesives would be one of the implementation technologies. And the implementation costs would most likely be dominated by the cost of discovering and manufacturing the adhesive.
- Problem solutions have stakeholders. Stakeholder classes vary in size, but the stakeholder classes most likely to contribute significant costs are those associated with large groups of customers or users. The costs that are most significant for problems of scale are those associated with marketing a solution to customers, or with persuading users to adopt a solution, or with obtaining the approval of regulators, or with the logistics of delivering solution-related materials to users.
Teams that have expertise biased in favor of implementation-related issues are more likely to tend to emphasize effort to minimize implementation-related costs. The estimates of stakeholder-related costs by such a biased team are more likely to be inaccurate or incomplete. If teams address cost concerns too early in the problem-solving process, before they acquire team members who are expert in stakeholder issues, their exploration of the space of possible solutions is more likely to be biased in favor of solutions that have low implementation costs, rather than low total cost. For example, they might reject a solution on the basis of high implementation costs, without recognizing that it has very favorable stakeholder-related costs.
Estimates of costs of solutions to inherently large-scale problems must consider how scale affects the viability of each solution. And that consideration is more likely to be objective if it occurs after the team has developed an array of solution options.
Although problems of scale present special risk for teams that have expertise biased in favor of implementation-related issues, problems of any sort can present special risk for teams that have biased expertise. To manage these risks, tailor the composition of problem-solving teams to match solution discovery risk to the needs of the organization. First in this series Top Next Issue
Are your projects always (or almost always) late and over budget? Are your project teams plagued by turnover, burnout, and high defect rates? Turn your culture around. Read 52 Tips for Leaders of Project-Oriented Organizations, filled with tips and techniques for organizational leaders. Order Now!
Your comments are welcomeWould you like to see your comments posted here? rbrenogMhuqCxAnbfLvzbner@ChacigAthhhYwzZDgxshoCanyon.comSend me your comments by email, or by Web form.
About Point Lookout
Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.
This article in its entirety was written by a human being. No machine intelligence was involved in any way.
Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.
Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.
More articles on Project Management:
- See No Evil
- When teams share information among themselves, they have their best opportunity to reach peak performance.
And when some information is withheld within an elite group, the team faces unique risks.
- The Politics of the Critical Path: II
- The Critical Path of a project is the sequence of dependent tasks that determine the earliest completion
date of the effort. We don't usually consider tasks that are already complete, but they, too, can experience
the unique politics of the critical path.
- Personnel-Sensitive Risks: I
- Some risks and the plans for managing them are personnel-sensitive in the sense that disclosure can
harm the enterprise or its people. Since most risk management plans are available to a broad internal
audience, personnel-sensitive risks cannot be managed in the customary way. Why not?
- Wishful Thinking and Perception: II
- Continuing our exploration of causes of wishful thinking and what we can do about it, here's Part II
of a little catalog of ways our preferences and wishes affect our perceptions.
- Seven More Planning Pitfalls: III
- Planning teams, like all teams, are vulnerable to several patterns of interaction that can lead to counter-productive
results. Two of these relevant to planners are a cognitive bias called the IKEA Effect, and a systemic
bias against realistic estimates of cost and schedule.
Forthcoming issues of Point Lookout
- Coming December 6: Off-Putting and Conversational Narcissism at Work: III
- Having off-putting interactions is one of four themes of conversational narcissism. Here are seven behavioral patterns that relate to off-putting interactions and how abusers use them to control conversations. Available here and by RSS on December 6.
- And on December 13: Contrary Indicators of Psychological Safety: I
- To take the risks that learning and practicing new ways requires, we all need a sense that trial-and-error approaches are safe. Organizations seeking to improve processes would do well to begin by assessing their level of psychological safety. Available here and by RSS on December 13.
I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenogMhuqCxAnbfLvzbner@ChacigAthhhYwzZDgxshoCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.
Get the ebook!
Past issues of Point Lookout are available in six ebooks:
- Get 2001-2 in Geese Don't Land on Twigs (PDF, )
- Get 2003-4 in Why Dogs Wag (PDF, )
- Get 2005-6 in Loopy Things We Do (PDF, )
- Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
- Get 2009-10 in The Questions Not Asked (PDF, )
- Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )
Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info