What's your problem?
Especially in the last year, there seems to be no shortage of issues to solve in any organization. While we grapple with our internal challenges, we are also helping our customers transform their businesses. In all these experiences, a constant that we always return to is the problem definition. Understanding what we're trying to solve before we tackle it helps us prioritize and efficiently implement.
Understanding the problem space
There's a big reason why our software team is full of Architects that code. Understanding the problem space is a shortcut to honing in on what to solve. Everyone is familiar with the frustration of their day-to-day work process. Sometimes all it takes is an elevated perspective to see how your work affects your teammates up and downstream. The better you can understand how your work is done in the context of others, the more certainty you'll have that the problem you're spending time on is the right one.
Having domain knowledge also saves you from implementation pitfalls. If you're unsure of something, asking BIM experts in your company or in the industry may provide insights. As your understanding of the problem space deepens, choosing how to solve the problem becomes clearer. You don't need to bet on a particular solution just yet, but this deeper understanding should allow you to list what you are looking for in a potential solution.
Fail small and fail fast
Solving small to build towards more sustainable solutions is starting to become cultural for us. Importance is placed on collaboration across teams to achieve a joint goal. Everywhere from dashboards to content libraries, our teams are taking initiative to work cross-functionally. A compelling problem resonates with the team. It is an effort people can rally behind.
Nothing shows people what can be done better than an example. Building a small example does not have to take a huge time commitment, but it's far better than any plan or deck. (not that plans are not important, it's the essential context and the purpose). A large problem can always be broken down into smaller more discreet problems. The 80/20 rule works great here. Focus on something that 1. is quick to implement 2. shows what you're after 3. proves the problem is big enough to create a more robust solution.
An example won't have a 100% success rate, and there will always be times where it seems that you have a solution looking for a problem that no one cares about. Small implementations are quick to create and quick to shelf. The solution may be in more demand when the problem context changes, but testing it will teach you volumes about what tangential problems could use your focus.
Each problem leads to the next
Identifying and refining problems, along with solution planning to solve is an iterative process. There will always be another problem, and each solution will eventually be outdated. The more we can embed problem-solving skills in every member of our team, the more close to the process solutions we will see. With effective prioritization and experience implementing surgical fixes, finding new problems to solve will almost feel enjoyable.
