I vividly recall working with a client a few years ago whose product encompassed both hardware and embedded software. The problem of the moment was that the hardware people were not talking to the software people. So much mistrust, misunderstanding, and bad blood had developed that the two sides literally were not on speaking terms.
Instead, I heard accusations. “They got the specs wrong.” “They sent the specs late.” “They told us to do the wrong thing.” “They did the wrong thing.” “They didn’t listen to us.” We eventually discovered the root of the miscommunication with the help of the assessment process described in this article, but needless to say, failing to exchange words with your colleagues is not exactly a recipe for product development success.
Just being part of the same company doesn’t necessarily lead to harmony or even offer a foundation for a shared vision. One person or group might see a problem while another doesn’t. Or everyone sees a problem but no one understands or agrees on the cause.
These situations are the perfect occasions for conducting an assessment. Read on to find out why.
How assessment fits into the product development process
If all your projects get done on time and under budget, you may never need to undertake an assessment. Most of us aren’t so lucky. When product development projects go off course or face challenges, conducting an assessment can lead to profound change.
Typically, an assessment consists of analyzing past projects through three lenses—context, facts, and perspective—to gather real-world information that you can apply going forward. Project teams reach conclusions through theme interviews. An oversight or steering team then ranks individual teams’ input and presents its rankings to the teams for feedback on potential ways to solve the problems identified.
The first step in an assessment is to get all the “facts” up—literally up in a timeline on the wall. I put “facts” in quotation marks because these are subjective facts. It doesn’t matter if someone is “wrong” from an objective viewpoint. If a team member perceives something as a problem, it is a problem.
The timeline gives you a big-picture overview of a past project, with input from all involved.
This first step in the assessment process turns out to be extremely powerful. Simply creating a timeline of everything that happened, using a methodology that lets everyone involved have their say, helps break down barriers to communication.
Seeing the other side
In the case of the client company with the two sides that weren’t speaking, working through the timeline allowed the hardware folks and the software folks to see the other side’s frustrations. The challenge they faced was the problem of slipping project dates and consistently missed product delivery dates. Everyone knew that people felt frustrated and angry and weren’t talking to each other, but no one knew why. It turned out that the management team had a background in engineering (typical for many old-line manufacturing companies) and wasn’t comfortable with software issues or software people. Reviewing the project history process as part of the assessment uncovered this problem. Eventually each side found ways, during follow-up meetings, to begin understanding what areas caused problems for the other.
In some ways, this methodology resembles the communication process involved in gathering voice-of-the-customer data. The initial interviews are non-evaluative. You simply listen. Similarly, in creating a timeline for an assessment, there’s no blame and no finger-pointing. You’re just getting the information out.
Another client, Industrial Scientific, turned to assessment as a self-reflection tool after a series of quality issues in 2011 led to a recall of one of its highest volume products. VP of Global Operations James Quasey said of the assessment, “One thing I didn’t expect is that it was almost a healing process… We got issues on the table so we could learn and improve.” Rather than devolving into blame and finger-pointing, “people came out of the process feeling better.” That’s high praise for a process that began with a product recall.
In another case at Industrial Scientific, we investigated why a particular project was not meeting its schedules. As we constructed the timeline, we discovered that one group’s manager had different priorities from the project leader. So the manager assigned people first to projects he considered higher priority, leaving the project understaffed. Because the project leader didn’t know this, he published project schedules assuming the work was getting done as discussed. It took some digging while building the timeline to identify the fact that priorities were not consistent across functions. We had to keep asking “Why?” to get to the root cause.
Elements of successful assessments
Successful assessments have these key elements in common:
- They involve cross-functional teams. This allows functions that may have been underrepresented during product development to explain how their unaddressed issues might have affected the end result.
- Team members conduct the assessment—not a select leadership team. Because of this, participants feel ownership of the process and are more willing to accept its conclusions. Each member of the oversight/steering team also attends one project history meeting, enabling that person to represent the team when the oversight/steering team discusses the results.
- Each project team being assessed presents its findings to the oversight/steering team, whose members digest all the information prior to determining their findings. This achieves buy-in at the individual team level as well as the oversight/steering team level.
- The oversight/steering team returns to individual teams with its findings to gather additional input, driving further buy-in.
Have you used a process such as assessment to help get a project back on track? Let us know below or by commenting on our LinkedIn page.