Missing the Obvious
/We often see advanced development teams miss the obvious; in terms of a technical solution or an innovation in the way they work, which could result in an acceleration of the project schedule. Why do brilliant people sometimes miss the obvious?
Why Even Radiologists Can Miss A Gorilla Hiding In Plain Sight is an NPR story about research being done at Harvard Medical School into why Radiologists "sometimes fail to see important things" -- It got me thinking about a similar observations we've made about new product development teams in Silicon Valley working on advanced technology projects -- sometimes some of the most brilliant people in the world can miss the obvious.
When teams are immersed in a problem, it is sometimes hard to see the "forest for the trees" and the more they work at it, the less they can see.
Further, when they don't involve people who are external to the project/problem, there's a tendency for a group of experts to work within their paradigm (i.e. a fixed mindset or problem solving framework) and not outside of it.
In these cases we've brought in "external scrubbers" to help teams see technical solutions and/or to find innovative ways to accelerate schedules. This works for schedules and for overcoming technical barriers (which cause schedule delays). The advantage of the outside person is that they can ask the stupid questions and look at the problem from a different perspective. Most teams are reluctant to do this for fear of "IP leakage" or out of some sort form of professional arrogance.
Alternatively, a concern is when schedules are dramatically accelerated a team may have missed something (in an effort to make the project go faster) or that they are not challenging assumptions; for fear that the answers will result in information that could push-out the schedule. The logic is that it is better not to know -- but we know that this just pushes the pain forward into the future when eventually it will manifest itself in a major slip to the schedule.
The list above is from a set of recommendations we made to one team. Over about a 6 month period they had achieved a major schedule pull-in. They were developing bleeding-edge technology with a significant number of unknowns and challenges still ahead, but felt that they could achieve the accelerated schedule targets (because they had to). We wanted external validation and for the team to go through a "challenge" process from people outside the team, in order to help them uncover lurking technical issues in the project -- and once known, to put in place contingent actions to mitigate the problems. We wanted them to pull the pain forward.
We've done this many times with great success. The "scrubbing" seems to work best with a "triad" of external Subject Matter Experts (SMEs). Fast teams conduct these "critical design and schedule reviews" on a regular basis in order to help them find the Gorilla's in the project.