Browse

All Posts in Uncategorized

|In: Process Management and Improvement|Last Updated:

Introducing a new way to do a job to experts in how it’s done now is hard.

The six dimensions of business function optimization can tell us  we need to find new and better ways to do a particular job. But, as a species, we struggle with doing something in a different way, using different tools, at least at the beginning. This struggle regularly kills business change projects, and study after study points out that paying insufficient attention to Business Change Management is one of  the top one or two reasons that a project may fail.

This isn’t new. I am guessing that some Babylonian construction engineer ran into problems with the team when he introduced them to a better way to build a ziggurat.

And, the “Remote First” approach to Project work has made Change management much, much harder.

Let’s start with trust, which is necessary for change management. It takes some different tools and skills to engage in trusted conversations in a remote meeting, and it isn’t a given.

Years ago, one colleague told me that he felt that needed to be in the same room as somebody to absorb their “pheromones” to help build trust. I am not sure those would be the words that I would choose, but it describes what some people might be feeling.

Second, the tools themselves are different for collaboration. There is a tremendous amount of innovation in collaborative tools, but with this innovation we need to do “Meta Training” on the use of new tools that help enable distributed collaboration. For example, instead of gathering around a white board, we may use a tool like Linq to map out a business process.  But, we will jointly need to invest the time to learn how to best use it so it feels as natural as drawing on a whiteboard. Even if we can do much more than we could have with the whiteboard, unless using it is intuitive we won’t get there.  Frustration with the collaboration tools could nudge us into the change resistance swamp right here at the beginning of the conversation.

So what else is to be done?  There are a lot of schools of thought on this, but I think we can get to a few takeaways that can lead to some quick improvements.

  • Use the right communication tool for the job. For critical conversations, Face to Face conversations are better than Video meetings. Video conversations are better than chat or email. And, by the way, insist that all parties keep their cameras on. Otherwise it isn’t a video meeting! Choose video because text messages with emojis may not help you get the alignment that you are craving. The overriding rule is that the most immediate and personal tool for a critical conversation is probably the best one.
  • When it comes to change, people really want two things in life—To feel like they are being heard, and to feel like they are not out of control. (This isn’t the same as feeling in control, it turns out). Simple tools (regardless of technology) that help them feel like they are being listened to, and that they are in control go a long way in building confidence. Working out rules of listening to each other, and “back briefing” of what the other party is expressing are like magic to Change Management.

 

  • The basic, (dare I say “Bare Bones”) tools for Change Management still work. Tools like a Stakeholder analysis, Training Plan and Culture Change Plan should be in the top tray of your toolbox. These tools will help you anticipate and plan activities that will give your business change project a fighting chance of success.

Final point– Change Management really could be thought of as another form of understanding and helping people deal with loss, and especially with the loss of the value their hard-won expertise gave them. They’re dealing, that is, with grief. People act unpredictably when they are grieving, and don’t always behave at their best.  Going with the wisdom a colleague named Daryl, I think it helps to always assume positive intent in the other parties—which is somehow harder to do when we are not face to face, and trying to read emotions or understand somebody via the small cues on a glitchy video tile.

Not to mention replacing body language with emojis when you’re trying to make a point.

 

 

Comments

|In: Architecture|Last Updated:

Sometimes, we’re too clever for our own good. A couple of recent trips highlighted several more significant issues to discuss around integrations and patterns. It might be that Tech leaders really are clever—but clever isn’t always the same as smart.

Take for example, times we overcomplicate choices. Continuing our conversation with the “Business”, it might make sense to set some expectations about integrations.

Have you considered what the additional functions will do to your infrastructure sizing and expected performance? Make sure your integration requirements include the often-neglected “Non-Functional Requirements”—we need to be able to back up and recover the system, keep users happy about performance, and meet our other reliability and scalability goals. The last thing you want is a system that doesn’t perform as well as its individual components. Remember- you want the Business to be your ally, and they leave it to you to understand what an NFR is.

You need to perform a bare metal recovery test, especially of any integrations. We inherited a pet duck from our neighbors, named “Ducky”. She swims around in her kiddie pool in the back yard, under the shade of a very large Tangelo tree. She is the happiest being I think I have ever met.

Do you know why? She doesn’t have to worry about the steps needed to recover a system with multiple integrations, that may or may not be recoverable in a logical order.

That’s why.

Think about an e-commerce system connected to an ERP for a moment. If the ERP has a brief system failure, does the E-commerce system understand that it needs to resend just the orders that were missed for the outage?  (Hint—good systems do this pretty well, but you should still check it. Because when it comes to data integrity, pretty well isn’t good enough.)

Is the juice worth the squeeze?  Good integrations are expensive. Your awesome technical teammates are going to work through edge cases, error handling through multiple platforms, message timing, and multiple development languages. Can your business teammates make the business case how this effort is going to deliver Some-X ROI or greater?  Will your business teammates defend the investment needed for quality integrations, especially as compared to the consequences of failing to make it?

Point to point vs integration platform (such as an Enterprise Service Bus). At the moment, here’s what I recommend to keep the decision relatively straightforward: If you must connect only two or three systems, Point to Point integrations make sense. If you are being asked to connect more than that, however, the number of integrations grows polynomially, and maintenance and technical debt will become an issue.

And so, following Bob’s rule of making the architecture cleaner than when you found it, an integration platform (such as an Enterprise Services Bus) makes a lot of sense. It is a big investment, however. Make sure that your colleagues understand what they are getting into.

One of your colleagues might have been reading about how “Microservices” are a thing, and that it makes all integration easy. Just like EAI platforms made integration easy, ESBs make it easy, and, if you like cloud stuff, IaaS makes it easy. That is, it doesn’t. Nothing makes integration easy.

Microservices architecture is just another way for you to own all of the architecture. Be prepared to manage the costs and staff levels to maintain it. Microservices does give you more flexibility—and you need the wisdom to use it. This is a controversial position I am taking, and I expect to hear disagreements. But, when you ride the microservices tiger, you may not get to choose when you dismount. You now own all of the choices in how the target systems work together. Be sure your team is ready for the adventure.

Real Time “Extract- Transform-Load” between systems is still an integration. Taking data from one system to another, even if we pretend we are not doing an “Integration”, means that we are doing an integration. The same points come up on cleanliness, architecture, sizing, currency, and so on. As my grandmother used to say “You are not fooling anybody!” The vendors that push this are using semantics to get around nervous stakeholders, not really inventing anything new. Let’s chalk this up to being part of the same discussion about investing in an integration platform.

Internet research on Integration isn’t necessarily real research. And some business executives think it is. I am continually bewildered that some people are taking medical, career or relationship advice from Tik Tok-ers. While I am sure that it is meant with the best of intentions, it is hard to believe that someone who doesn’t know us, or our situation, and has never had to do the hard work of making it work could give more than a handwaving opinion that would have relevance.

And, yet, some of our friends in the Business, doing a bit of research on the internet, will come up with “out-of-the-box” solutions that may or may not introduce a whole host of other problems. We do owe it to them to investigate their solutions. AND, we should ask that everybody keep an open mind on the solutions, taking into account security, scalability, and overall architecture.

Pro tip: Figure out a way to reframe the solution that will work (that is, your preferred solution) so it resembles what your business colleagues have discovered. This will make achieving consensus much easier.

When it comes to integration, following the long held KJR rule of “Keep it Simple”, turns out to be really complicated. My question for you—How do you make it look simple in your conversations without committing to something that won’t work in practice?

Comments