S.M.A.R.T.E.R Problems
So far we have talked about Why The Problem Manager was created, First Principles regarding What is a Problem Manager, and the Anatomy of a Problem. With these as background, we can now talk a bit about setting up our Problem garden (for horticulturists), stable (for horse people) or infrastructure (for IT people).
S.M.A.R.T.E.R is, of course, an acronym:
- S is for Stored
- M is for Managed
- A is for Accessible
- R is for Relevant
- T is for Trustworthy
- E is for Evolving
- R is for Related
To be successful your Problem Management garden/stable/infrastructure must have these seven fundamental aspects covered.
S is for Stored
Where are you keeping your Problem definitions and descriptions? On napkins? Cue cards? Email? Powerpoint? I recommend you store your Problem definitions and descriptions somewhere central that will be accessible (more on this later) by your entire team and in their own special place. In case the point has been too subtle thus far, I believe Problems need to be first-class citizens in your Project, Program, Product, Service, Consulting or other work. So just like Accounting has their own home for accounting data, and Sales has their own home for Sales data, likewise Problems deserve their own special home as well.
This special home does not have to be fancy or sophisticated or expensive. It just has to be dedicated to Problems. For example, a spreadsheet will do perfectly well. As we go through the other letters of S.M.A.R.T.E.R you will see that we will want to be able to access (A) these, evolve (E), and relate (R) them so you may find a database or other tool which meets these goals to be most effective.
We want our Problems to have their own lifecycles. So embedding them in any kind of project documentation where the project will end is not helpful. For similar reasons email and powerpoint are not good solutions. We need our Problems to be stored somewhere where they can live and grow independently until such time as they are no longer of interest to us.
M is for Managed
We covered what managed means previously when we talked about What is a Problem Manager. We discussed that manage comes from the greek word referring to hand and a synonym is handler. And we liked this term because, like a horse hander, a manager cares for and nurtures.
Let’s go back to this idea of Problems being first-class citizens. Too often in projects, programs, engagements, products, or features the Problem is simply described in an introduction or referred to tangentially when describing solution work. Often in software development Problems will be articulated as User Stories, but even then these user stories are often treated only as a means to the end of delivering a feature or capability.
When we talk about problems being Managed we mean treating them as first class citizens, related but independent of other project documentation or artifacts. Even if you think this might be a one-time only consulting project, I highly recommend managing the Problems separately. Why? Because, as we will see in future content, Problems will typically outlive most of our individual projects, programs, features, releases, etc. In fact, many problems will outlive us as well. And chances are high that if we define and describe our problems well, then they will become a, well, well from which we can draw insights and value for many projects, programs, features to come.
So managed here means that Problems have their own lifecycle. They support projects, releases, programs, features but they live independently and are reviewed, maintained, updated, validated and verified regularly throughout their lifecycles, which are independent, and typically longer, than project, release, feature, program lifecycles.
A is for Accessible
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
Hitchhiker’s Guide to the Galaxy, Douglas Adams
For your Problems to be useful and used they must first be accessible. If your team, colleagues, and stakeholders can’t access them quickly and easily when needed then they may as well be in the disused lavatory.
Of course if you are an independent consultant and your team is you then this will be easier than if you work in a several-thousand person corporation.
As the quote above suggests, accessibility is not just about being able to access but also about knowing how and where to access.
Rather than having to create new behaviour, I have found it easiest to make Problems available where key stakeholders already access other, related information. So if your team already has an intranet, google docs, wiki or content management system like Confluence then it’s good to create links for easy access in these places. You want your Problem information to be top-of-mind for key stakeholders and that means being easily accessible with a few clicks.
R is for Relevant
Something is relevant if it is “closely connected or appropriate to what is being done or considered” and “appropriate to the current time, period, or circumstances; of contemporary interest.”
Like the “R” for relevant in SMART goals, our R here is about making sure our Problem definition and description work is meaningful and useful to our current and foreseeable work.
Relevance should be assessed at all levels of information as well. The relevance of a Problem we are defining may be 100% but if weigh it down with too many irrelevant details then we are off-course.
Relevance is all about context. What are we trying to achieve? Will this help or hinder? Is this useful? These questions must be asked and answered regularly. Like weeds, irrelevant information should be removed regularly. A good problem garden is weeded regularly.
T is for Trustworthy
Our problem garden, inventory, stable, infrastructure should be the foundation of our projects, programs, features, products and services. This means it must be rock solid. Like a house, it doesn’t matter how many bathrooms we have or if our kitchen has been newly renovated if the foundation is weak.
If we expect to build our projects, programs, features, products and services upon our bedrock of problems then it must be reliable and dependable.
People feel trust when they rely on one another. In the relationships we have, we build trust through vulnerability (Bonior, 2018). … In other words, trust is developed when our partners have the chance to let us down or hurt us, but they don’t. — PositivePschology.com
For your Problem inventory to be trustworthy then simply requires the following unbroken virtuous cycle:
- Problem inventory is used
- Users of Problem inventory are not disappointed
- Repeat at 1
This may sound simplistic or trite but it is not. As someone who has worked in the trenches of technology product management for two decades, this author can attest that having great information and simply putting it out there is not enough.
You and your teammates and stakeholders are super busy. Your and their attention is a prized commodity for which we must compete fiercely.
Until such time as you and your stakeholders have developed trust, and ultimately reliance, on your Problem inventory you will need to work hard to ensure it is used as much as possible.
Think about something as automatic as brushing our teeth or showering regularly. Most of us don’t question the value of these activities but someone (probably our parents or caretakers) had to teach us to brush and shower and nag and remind and cajole us into doing it until became a habit, right?
The same cycle is needed for your Problem data.
Persuade yourself and others to use it until it becomes habit.
Now the second item is the critical one. It cannot disappoint. Every time you and your stakeholders shop at your Problem store it must be a valuable and satisfying experience. Or neither you nor they will return for more.
Just as weight is easy to gain and hard to lose, trust is hard to gain and easy to lose.
Work at building it and maintaining it for your Problem store regularly.
E is for Evolving
“What’s dangerous is to not evolve” — Jeff Bezos
Whatever your problem domain, be it affordable housing, enterprise supply chain management, or digital identity, one thing is true: The only constant is change.
The reality with most efforts at curating and sharing knowledge is, like a neglected garden or investment portfolio, they quickly become outdated and cluttered and their value and usefulness atrophies and it dies. Entropy is the enemy. Evolution is the answer. If your problem store is not evolving it is dying.
As you discover, define, describe and put your problems out there to be tested by reality you will get feedback from the universe. What tests as true should be kept. What tests as false should be removed. Simple starting premises must evolve and become more nuanced and sophisticated as we learn more about our Problems.
In my experience with many projects and products and features, problem definition is typically seen as a task. One and done. Check it off the list and forget about it. This is not treating problems as first class citizens.
Let’s go back to our analogy of your problem store as the root system supporting the tree that is the solution you are providing. As a tree grows does the root system remain static? Of course not. The root system grows symmetrically with the tree above the ground.
Is this how problems are treated in most projects, programs, features, products and services? Not in this author’s experience and probably not in yours.
The problem is written down once at the beginning and then all of the energy goes into building out the tree, ignoring the root system.
This is a recipe for fragility at best and disaster at worse. This tree will NOT withstand the winds of change. It will fall over with the first strong gust.
As a Problem Manager your job is to continually evolve the root system. Every solution that you or your team or your company is putting forward should have at least as rich and deep a problem root system.
Just like your solution is constantly evolving so must your problem store.
You shouldn’t have a complex solution built on a simplistic set of problem definitions. First evolve your problem space and validate it. Only then build your solution on that strong foundation.
R is for Related
The term holistic’ refers to my conviction that what we are concerned with here is the fundamental interconnectedness of all things. I do not concern myself with such petty things as fingerprint powder, telltale pieces of pocket fluff and inane footprints. I see the solution to each problem as being detectable in the pattern and web of the whole. The connections between causes and effects are often much more subtle and complex than we with our rough and ready understanding of the physical world might naturally suppose” — Dirk Gently, Holistic Detective
Like no person is an island, the same is true for your problems. In total isolation they are meaningless and useless. What gives them meaning is their connections to other problems, to your personas, to target markets, to existing and planned projects, programs, features and services.
‘Whoa’ you may be thinking. You had me up till now but this is starting to sound way too complicated.
I hear you. Hang in here with me. We will get into more detail on tools in future content.
I am NOT suggesting that you need have a PhD in information theory and put all of your problem information into a fancy relational database system supported by lots of diagrams with boxes and arrows. Although I suspect there may be a few brave readers willing to do exactly that.
Like any new skill we should certainly start small and grow at our own pace.
Fortunately, we live in an era where managing information is a very mature domain and chances are if you are reading this then you have access to many tools which can help with this.
But let’s get back to the importance of relating our problems to other things.
Unless you are managing just one problem for one persona for one time then chances are you will be collecting and curating a lot of information as you evolve your problem store. When I recommend relating all of this what I am referring to is keeping separate things separate but linking them to each other when they are related.
This is important because we want to evolve separate things separately while at the same time evolving the relationships of these separate things.
For example, if we put all of our problem information in one document then it will be harder to individually manage the separate elements. Similarly if we put everything in their own individual documents but don’t link them then we lose the value and meaning of the important connections.
Sticking with tree analogies, we want to manage the lifecycle of both the individual trees and the related-tree forests on our problem farm.
So problems, personas and supporting evidence need to evolve individually. We may shift our problem focus by dropping some problems and adding others. And our initial personas may change and evolve as we learn more about our target audience. So each problem and persona needs to be stored in its own place, in its own document and follow its own lifecycle. Same with personas. Next we need to link our problems to the relevant personas and evolve these relationships as we learn.
Terra and the Tumbleweed
Let’s see an example of S.M.A.R.T.E.R problems using our fictitious on-going story of Terra and the Tumbleweed.
S is for Stored
Terra wonders where she should store her Problem information. Many software development teams using the Jira and Confluence tools from Atlassian. Confluence would be a great choice for storing Problem information. But Terra’s team at Shiny don’t have Confluence. They use a tool called Monday.com which provides them with Sprint Planning, Bug Tracking, Backlog, Product Roadmaps, and Product Launches. No Problem Manager. Sigh.
Terra is drinking the Problem Manager Kool-aid and wants to ensure Problems are first-class citizens with their own system and storage. She wants something that will allow her and her team to start simple and grow to fit their needs. Her management has given her carte blanche to choose whatever tool she wants. After a few weeks of research, Terra has settled on a tool called Obsidian. Terra likes this tool because of both its’ simplicity (text-based markdown files) and its richness to grow as her needs evolve.
In addition to Monday.com, everyone at Shiny has access to shared file directories and files via Microsoft OneDrive. Since Obsidian simply requires a shared file directory this works great for Terra.
Because she knows each piece of problem information needs to have its own file so it can have its own lifecycle, her plan is to put each unique persona in its own file as well as unique files for each problem and other elements.
M is for Managed
As the new product manager for ShinyEnterprise, Terra has a team of four product owners. Terra decides she will divide ownership and management of problems, personas and other elements to one of the product owners and she will review and approve these on a scheduled basis. Terra has also decided to change the product owner time allocations from 100% on sprint work, to 80% for Sprint support and 20% for problem management.
A is for Accessible
Terra’s new Obsidian tool works with what are called vaults, which is basically the root directory of a set of markdown files. Markdown files are plain text files with some basic codes embedded for formatting. Think of HTML but much simpler. Terra knows that her Problem store will only succeed if it is easily accessible by her teammates and key stakeholders. Terra has herself, her four product owners as well as four important stakeholders in Marketing and Sales and another three on the executive team. That is twelve key stakeholders who she needs to have easy access to the Problem store. Terra gets twelve licenses approved for the Obsidian tool and arranges a lunch and learn training session for all stakeholders.
R is for Relevant
Terra coaches her product owners on the importance of keeping all information in the Problem store clean and relevant continuously. As soon as a problem is no longer valuable or a persona is no longer used it must be removed from the Problem store immediately.
T is for Trustworthy
Terra works hard to grow the trust of her eleven stakeholders in the Problem store. She refers the stakeholders to its content at every opportunity and often answers many stakeholder questions by providing links to relevant answers in the Problem store.
E is for Evolving
Terra guards the 20% time her product owners are to spend evolving the Problem store firmly. She does weekly reviews with each PO to ensure they are investing that full 20% in evolving the items they own. Terra monitors the Problem store regularly and challenges her team if and when it appears that information has not changed when she knows that more has been learned or new market information is available.
R is for Related
One of the things Terra liked most about the Obsidian tool is its tagging and linking capabilities. Basically any file in Obsidian can be linked (forwards and backwards) to any other file and tags/keywords can be used to group related information dynamically. Terra makes sure her product owners become experts at keeping files specific to a single topic and tagged and linked appropriately.
To Do
Think about how Problem information is stored, managed, accessed, relevant, trusted, evolved and related in your project, program, or product work. Rate your current Problem store on a scale of 1 (poor) to 10 (outstanding) for each of these aspects:
- Stored (1 to 10)?
- Managed (1 to 10)?
- Accessible (1 to 10)?
- Relevant (1 to 10)?
- Trustworthy (1 to 10)?
- Evolving (1 to 10)?
- Related (1 to 10)?
Did you score a perfect 70? If yes, then please try again, be honest this time. Kidding. This stuff is hard. If there are specific areas where you scored much lower than others then think about what you could do to improve your scores in those areas.
To be good Problem Mangers we must have a good Problem system and to be great Problem Managers we must have a great Problem system. In other words smarter Problem Managers have S.M.A.R.T.E.R problem systems.
