#tldr: I’m here to validate your feelings

“Therapist”, you ask? “I thought I needed a developer, or maybe a project manager?” The Developer can develop, the Project Manager can manage, but it’s the Therapist that helps you figure out what you need, and how to make it happen.

As your therapist, I can help you to put a plan together to build a solution that you and your users will want to use. You see, it’s not enough to boil everything down to the nuts and bolts of development steps. The cult of hyper-rationality has made us all believe that facts are enough, and everything can be organized into a succinct list of tasks that are then doled out, executed, and completed. But have you ever actually seen it work like that?

I haven’t. And I’ve seen hundreds of successful deployments. But they didn’t succeed because of Waterfall or Agile, or a good task list. I’m not saying you don’t need structure, tasks, lists and assignments – clear communication is critical to getting a job done. Requirements gathering and technical know-how are necessary but not sufficient. You’ll need something more, as well. I call it “therapy.”

What is therapy, in this context? First, I would say it is simply a recognition that even technical models are built and run by people. Once you accept that, then it’s important to recognize that people can and do have a lot of feeling about their jobs in general, and about the systems they work with. Is your user base frustrated or satisfied? Do your developers feel confident or uneasy about the current work effort? That’s why I ask questions like this throughout project:

·       How does everyone feel about the solution being proposed?

·       How does it feel to use the system?

·       What are the underlying fears that we may not be addressing?

·       What makes this process satisfying for you?

These are not “squishy” or “soft” questions. The differentiation between “objective” and “subjective” is, like so many things, a spectrum, not a binary. I would invite you to consider that more decisions lie in the middle of the spectrum than we realize. The questions above will immediately lead you to areas that need to be addressed, areas of strength of your models, and help reassure your audience/client/internal customers that you are actively trying to solve their problems.

Let’s look at 3 key places this approach can be applied: during design, for a mature existing model, and for model expansion within an organization.

Therapy first shows up when you start a new project, perhaps building a planning application in TM1 for the first time. This is probably the part of development that most mimics therapy. When a team of people at a company invest in building a new planning model, it’s important to ensure the Phase 1 of your project will be value-add, and address your company’s current concerns. That can feel very overwhelming, and can easily turn into a runaway train. Here are some things to consider at the very early stages of a new project.  (My general answer is shown in shorthand in the parenthetical.)

·       What do you include in Phase 1? (“The basics”)

·       How involved is the business? (“Some”)

·       What is IT’s role vs. the business? (“Server availability, data sources”)

·       Do you take on changing business processes at the same time, or implement what you already have in place first? (“The former, whenever possible”)

·       Which calculations are driver-based, vs. input? (“The ones you already use drivers for, not too many at first”)

These types of questions should be part of any kick-off, but the discussions involved generally need some wrangling in order to reach agreement across the group, and the organization. It helps to have someone from “outside” talk through these critical items. The tendency in design meetings is to try to please everyone, try to get “everything” in Phase 1, and try to make the model as flexible as possible. My job is to steer you away from all three of these things.

·       Pleasing everyone: To avoid this pitfall, determine who the audience is, determine the level of granularity that will be supported throughout the model, and determine what needs to happen now vs. later.

·       Phase 1: Focus on a smaller deliverable first whenever possible to get something up and running that is in production and solving for some pain in the organization. Once you do this, the rest of the phases will follow almost automatically.

·       Flexibility is fantastic, but is generally directly opposed to simplicity. If your system architecture allows you to optimize both, then that’s fantastic. Generally, these two goals oppose each other, and trade-offs have to be made. I advocate simplicity over flexibility for a Phase 1, if that trade-off is necessary.

Get in the habit of asking questions during design sessions such as: “How is all this feeling to you?” “Do you feel like we’re going the right way?” “Do you feel we addressed your concerns today?” Not only will the answers steer your project in a helpful way, but also these conversations will increase the buy-in from your audience, and, eventually, adoption and usage rates.

Many of you out there may already have a TM1-based (aka IBM Planning Analytics) planning model in place. Generally, any model, of any type, that is in production with a large group of users, has fans and detractors. What’s the best way to keep your user base happy and engaged? And how do you prevent your model from becoming outdated, sluggish, or irrelevant?

Here’s the quick answer:

·       Talk to your users – brown bag lunches, one-on-one, all of the above. Find out what they like, what they don’t like, and how they can be better served

·       Upgrade! Keep your software up to date, with the latest features and fixes, to ensure the health of your model

·       Keep up to date – often models go stale because they are not given regular tune-ups. Systems benefit from care & feeding. Ask yourself these questions to see if this is an area that’s important for you:

o  Are you using an outdated interface?

o  Are you still over-relying on Excel?

o  Have you integrated the latest best practices including Cubewise Bedrock and TM1py?

I encourage you to take a hard look at how you are servicing your model to ensure that your solution evolves as new technologies and capabilities become available.

Once you’ve built a successful application, then others in the organization may be interested in following suit. Expanding your TM1 footprint to include manufacturing, marketing, inventory, sales forecasting, and operational planning models is a natural next step as TM1 is a proven solution in all these areas.

If you are feeling reluctant to share your group’s success with TM1, it may be because you are not wanting to be the “owner” of a system for another group. That is perfectly reasonable, as we have all been in the position of having to take on extra responsibilities in our jobs. But it is not a foregone conclusion that the development and management of models must fall to the own who originally set up the system! Done correctly, the expansion can help the entire organization reach a larger audience and integrate a number of related systems. The benefits of this are fairly obvious – as more people use a certain tool for modeling, the entire organization becomes more facile with that tool, and gets more out of it over time. Cross-training becomes possible, and facilitates opportunities to change roles across groups , which is a big plus. Here’s 3 things to keep in mind that can be a roadblock to such expansion:

1.     Watch out for gatekeeping. Gatekeeping is when a group or an individual do not want the tool to expand, so they “keep it to themselves.” The way to prevent this is to ensure that as the usage of a platform expands, the keepers of the platform also expand across the new groups getting added to the system.

2.     Get IT involved to ensure that the right hardware/cloudware is available to support a wider group, and ensure upgrades and issues are centrally managed.

3.     Get the licensing right – if you need more users inputting in the system, get more licenses. Avoid work-arounds that involve bursting reports or other offline distribution methods, as these approaches come with a whole host of issues from security breaches to version control

In short, when something is couched as a “feeling” it is frequently dismissed as irrational or lacking logic. Consider that the boundary between logic and feelings is largely a construct. People, especially in Tech, have a tendency to value logic more highly. This leads to either labeling their own subjective opinions as logic to push their particular agenda, or conversely, dismiss opinions they disagree with by labeling them as subjective.  I encourage us all to not get caught up in a semantic debate about subjectivity, but, rather, listen to all input being offered. There is real, relevant, and actionable information in how your team, your internal customers, and your clients feel.

Need some TM1 therapy sessions? Let me know what you need help with, I’d be happy to assist.

Connect with me on LinkedIn!

Robin Stevens