Janus Core: An Overview

Thanks to everyone for the feedback on my first post about Janus. As I mentioned, it’s still in the early stages of development. I thought it might be helpful to set out how the Core topics were identified and how they connect.

The diagram above shows the high-level relationships between the topics. It’s important to remember that these aren’t processes, and the links don’t imply any workflow between them—instead, they show the inherent relationships. There are no defined inputs or outputs from each area, as those depend on your methodology of choice. I don’t care whether you’re writing a business strategy, developing a process model, or writing a set of user stories for a backlog. In any of these cases, you must consider and address these areas.

You’ll note a central “cascade” from Define Challenge to Monitor Progress. At each level of the cascade, you are making decisions that affect and control choices in the other areas. Decisions and information can also pass the other way, as events in implementation affect your design, overall plan, and strategy.

At the top, we have Define Challenge—because solving any business problem requires clarity about your goal. I picked “challenge” to avoid the connotations of problem and opportunity—a challenge can be either or sometimes both. Identifying a challenge means understanding something that you need to change in the world. It also requires a causal understanding of the drivers and issues that make the change difficult. Defining a challenge is not goal-setting, which is often mistaken for strategy. It involves assessing a situation and finding some aspect that, if resolved, will allow you to make significant progress toward some of your goals. A goal describes where you want to go, but the challenge is whatever makes it hard for you to get there.

The next, related topic is to Set Direction—to choose an approach to dealing with the challenge from a set of alternatives. There is rarely only one way to deal with a problem, take advantage of an opportunity; or one best way. You must make tradeoffs between time, effort and cost to decide which makes the most sense for your situation. A fast, imperfect solution may be better than a perfect one that will take significantly longer to implement—or the fast solution may create new problems that make it unacceptable. You will have to choose among these alternatives based on your situation—both what is happening in the world around you and the resources you have available.

Once you have chosen a direction, you must Design Changes to your product, process, or organization. This involves developing a coherent action plan and working through precisely what will be done. That can apply to the actions people must take, such as exploring and researching aspects of the challenge and designing solutions. This is rarely a linear process. In many cases, we will tackle some immediate aspect of the problem and try to resolve it before moving on to the next step.

Finally, as we implement the changes, we must Monitor Progress being made and adjust as we encounter obstacles. Naturally, the chances that the changes we’ve identified will work precisely as expected are—not great. So, as we learn from seeing those changes realized, we will need to reconsider how some of those changes are designed, which may cause us to rethink our direction and, in the most extreme cases, may cause us to realize we are tackling the wrong challenge—we are trying to solve a problem that isn’t practical for us to solve, or which does not move us towards our goals the way we thought it would.

There are four other topics in the core, all of which support this problem-solving flow. The first, Survey Context, describes how we develop situational awareness around our organization and the challenge. Challenges are rarely abstract—they exist because of past actions, ongoing crises, and the interactions of a lot of different stakeholders. It’s critical to understand how you got to a certain point and what the drivers are that are making change urgent for a correct diagnosis of the challenge and to find a viable direction.

Assess Capabilities supports the setting of a direction and the design of changes—it involves understanding what your organization is able to do. The questions you need to be able to answer are what skills you have access to, what knowledge you have that’s applicable, and what resources can be committed to addressing the challenge. After all, most challenges aren’t existential threats that require every resource you have access to, and even if they are, you need to find a strategy for dealing with them that is a match to what you are able to do. If your organization makes $5M in revenue and has 30 people, and you have to compete with one that’s ten times your size, you won’t be able to throw money at the problem. You need a path forward that recognizes that asymmetry.

Align Changes is there to address the reality that most organizations have many changes going on at different levels—strategic multi-year efforts, projects, agile development teams, and many many more. Whatever approach you take, and whatever changes you are making, they need to be integrated with those other efforts to create a coherent overall effort. Similarly, when you are writing a user story, that story exists in the context of an application and needs to fit with the intent and customer need. It is, essentially, architecture of the solution and the organization.

Finally, I have Uphold Ethics (which is not a great name but will do for now). I think the last decade has really brought home the need for professionals to consider the ethical consequences of our actions. We should not be involved in or support the development of products that cause harm to people or the environment, make changes to organizations without considering the effects on staff or act like sociopaths in general. It’s not always easy to find the right actions to take, and there may not always be a solution that pleases everyone, but we must always at least try to minimize or mitigate harm.

About the Structure

I have a single Core and not different sets for different levels (like Strategy, Requirements, and Solution, say) because a challenge can be any size. It can range from “we are losing money and need a turnaround to stay in business” to “this feature is difficult to use” to a single user story in a sprint. As long as you have a situation requiring problem-solving in an organization, you must do these things.

That’s not to say there aren’t meaningful differences at different levels! Writing a user story doesn’t mean you have the skills to create a corporate strategy or vice-versa. This is, instead, a general framework we can use to describe the process of solving any significant business problem. We have several bodies of knowledge that discuss tackling specific types of business problems (such as the BABOK, BIZBOK, ABPMP BOK, DMBOK etc.), but not a statement of the general principles that underlie them.

What I want to do with Janus, ultimately, is build enough structure on this framework to allow it to serve as the basis for a cookbook or similar toolkit. It should help practitioners recognize the types of problems they face and identify an appropriate set of analysis and design tools to tackle them. Rather than define a single unified methodology, the goal is to describe the outcomes we need to accomplish and then work backwards to connect to the appropriate methods.

Janus isn’t and won’t be a best practice guide because what practices make sense are very dependent on your context. Problem-solving isn’t a self-contained, abstract activity. Your organization’s culture, practices, size and infrastructure all determine what is possible in your situation. What works for me may not work for you. And that’s fine—what I want is to help people get generally better at solving business problems, and a big part of that is identifying the right frame for a given problem and the right tools for solving it.

A note on influences: Obviously, Janus is the result of synthesizing a lot of work done by others before me and my own. Richard Rumelt’s work on strategy was the starting point for the Core. However, I’ve expanded his three key elements to eight and redefined them slightly to use terminology that will be more familiar to people. Roger Martin’s strategy cascade was the immediate inspiration for the presentation of these elements here, although conceptually, it goes back to Walker Royce. The diagram uses EDGY (from the Intersection Group), because I’ve found EDGY works very well as a notation that is simple enough to be easily grasped but powerful enough to communicate a broad range of business concepts. If you see other influences in this, you’re probably right.