Have you ever heard someone say “You don’t know what you don’t know.”? That’s the worst kind of situation. What you don’t know represents risk and it can severely harm your project. Let’s take a closer look.
There are basically three types of knowledge available to a software development team:
- Knowledge the team has — “You know what you know.”
- Knowledge the team is missing and aware of — “You know what you don’t know.”
- Knowledge the team is missing and unaware of — “You don’t know what you don’t know.”
#1 is the easy stuff. There’s a lot of work to do on the project and all of it can be planned and estimated. The team has reviewed the backlogs and knows what needs to be done. There are surely countless details to be ironed out during the project but that’s to be expected. With time and brain-power, the team will figure it out and deliver the software.
#2 is tougher. This is represented by items that the team knows need to be done but not necessarily how to do them. These items can be planned but not estimated. For example, the team knows that the data it needs is located in a remote, secure database. However, they don’t know how to access the database, what it’s table structures look like, or how fast it can provide the data. Additional analysis will be needed to fill in the missing knowledge.
#3 can be a killer. This represents items that the team is unaware of. These items cannot be planned or estimated. For example, late in the project a key stakeholder who has been unavailable until now, comes forward and casually mentions that due to security constraints, the software has to run on local servers across the country. It cannot be run from a single server location meaning distributed databases will need to be synchronized. Looks like time and cost just increased … a lot!
Every form of knowledge carries risk.
Each of these groupings involves risk. In #1, some of the assumptions will be proven wrong. In #2, the analysis could prove to be far more complex than envisioned. In #3, well, anything could happen and none of it is good.
For these reasons (and many others), you need to stop planning and start delivering. In many situations, no amount of analysis and planning will guarantee success. Let me tell you a story from the automobile industry.
When Ford was redesigning its Windstar minivan in the 1990’s, it conducted extensive focus group testing. One of the ideas being tested was a driver’s side sliding door for passenger use. Back then minivans had a sliding door on the passenger side only. The focus groups weren’t impressed by the idea and Ford decided not to include one on the new Windstar.
Meanwhile, Chrysler was redesigning its minivans and added dual sliding doors. The doors went on to become so popular that all minivans now have dual sliders. Ford had to hastily re-design it’s Windstar.
What happened?
“You don’t know what you don’t know.” Talking about an idea and interacting with a prototype are not enough. Most of us need to use the idea in real-life situations. Only then can we derive knowledge and articulate it clearly.
That’s why agile approaches to software development are superior. Scrum, Kanban, Lean, XP, etc. get working software into people hands sooner. The software will be incomplete, but as long as there’s enough functionality to derive new knowledge, the stakeholders and end users will be able to offer better information and the final software release will benefit.
Agile approaches work because they help software development teams do the following:
- Validate what they know.
- Build their knowledge base to fill in things they don’t know.
- Discover the things they didn’t know they needed to know.
That’s why I’ve said many times that software development teams need to — Plan Less. Deliver more. By doing so they’ll learn a lot and produce better quality software.
Here is the challenge… how do we manage stakeholder expectations? What people want are low risk high return investments. I want to know exactly what I am going to get for my money and exactly how that investment will perform in market. If I were putting my money in the stock market, I’d be looking for that guaranteed insider deal.
The reality is that many of our projects are full of unknown unknowns and are super risky. Unless the yeild on these investments is incredibly high, making the gamble worth it, maybe its better not to do the project. The challenge is that many companies are investing in high risk, low margin products and trusting that traditional predictive plans or even agile plans will save the day.
All we can do is optimize our chances of success… there are no guarantees. As stakeholders, we have to determine if the reward is worth the risk… becuase as you mention, no amount of planning is going adequately reduce the risk. We have to do something to learn. That said, it costs money to do something… and the reality is that money is at risk.
We have to acknowledge that, accept it, and be okay with it.
This is an insightful comment. There are few, if any, low-risk, high-return, stock-market investments. Similarly, low-risk, high-return, technology projects are hard to find. Companies need to be willing to take risks. One of the critical success factors is taking risks that offer multiple rewards. For example, the project may fail, but if the team learns new skills that can be applied to another project, there may be longer term rewards. Long term vision trumps short term activities.