The term “reorg” strikes fear into the hearts of many, but it can be a healthy and productive process that positions a company for transformation, rebirth, and long-term success.
There are several moving parts and
interrelated elements to consider when undergoing a reorganization. Nailing the
fundamentals is critical. These include strategic alignment, executive
engagement and accountability, and communication.
For the implementation team tasked with making a reorg happen on the ground, here are the 4 most important factors for making the initiative a success.
To write a post on a trending topic, one would typically start with a definition, but in this case, “Digital Transformation” means different things to different people. From the Bennet Frank survey, CIOs’ Perspectives on Digital Transformations, industry analysts, and our own client engagements, we have heard the term used to describe anything from consolidating ERP systems to accepting bitcoin payments. You could attend an IT conference and listen to three Digital Transformation sessions that give contradictory advice. Practitioners in the trenches can easily get confused and overwhelmed.
So let’s break down the key components of a Digital Transformation into a systematic approach to help you focus your efforts and align expectations with top management.
Whenever I hear the expression “one throat to choke,” it makes me cringe. The phrase, in most cases, refers to contracting with a single vendor to help with every aspect of a technology project. Another variation is, “a single wringable neck.” Either way, it sounds like an explicit threat to the vendor: If this project fails, the blame will be placed squarely on your shoulders.
In reality, if a project does fail, it is very difficult to go after a vendor. Most organizations don’t. Lawsuits are risky, costly, and time-consuming. The only practical concession you can expect from a vendor is free labor, hardware, or software. But it’s from the same vendor that botched things in the first place.
Let’s face it—setting up a one-throat engagement is not really a threat. It’s a bluff. And it stems from an attempt to outsource accountability.
The success of an Agile transformation stems from three key areas: behaviors driven by an Agile mindset at all levels of an organization, adherence to frameworks, and a relentless pursuit to deliver value to the customer.
One of the more nuanced tactics I use to
drive rapid, incremental delivery of value to customers is called vertical
Think of a development project like a tiramisu.
Each vertical slice of tiramisu contains many decadent layers of flavors and varying
textures. Each portion is delicious because the combination of layers is better
than eating one layer at a time. To do so would reduce the value of the culinary
Similarly, a large item on your
product backlog can be sliced up into smaller pieces either horizontally (that
is, so the work only relates to a single architectural layer) or vertically (so
the work spans multiple architectural components).
Let’s say you’re planning to repaint your living room this weekend. You shop for supplies online: drop cloths, painter’s tape, and brushes. Alexa, innocently, puts scrub brushes in your cart instead of paint brushes. The delivery arrives the next day. Do you have the tools you need to get the job done? The scrub brush has a handle and bristles! The bristles can be dipped into the paint! Will it require more work to create the desired outcome with a scrub brush rather than a paint brush? My guess is, no matter what, it’s not going to be pretty.
It’s not that the scrub brush is a bad product. On the contrary,
it’s probably the highest rated scrub brush on the web. The issue is that you
need a paint brush specifically designed to apply paint evenly and precisely.
You need the right tool for the job.
Flash forward to the work week: How often are we using the
wrong tool for a job?
Detailed schedules and beautiful Gantt charts might stop the screaming for visibility into your project, but they won’t help you sleep at night. In the back of your head, you’re waiting for the binky to fall out—for the project timeline to slip—and everyone starts crying again. Here’s how to break the habit of leaning on these common IT project management crutches.
Almost 30 years ago, when my wife and I were proud and exhausted new parents, we found that pacifiers would help our newborn twins sleep. This strategy worked for a little while, but when a binky fell out of one of their mouths, they cried. One of us would get up, put it back in place, and enjoy a few more moments of rest until it fell out again. We always say that one of the things we would do differently as parents is to have not used pacifiers. The boys became dependent on them, and they only postponed the inevitable.
Binkies remind me of how IT teams often use detailed timelines
and project plans.
Have you participated in or led a digital transformation at your organization? Was it really a transformation, or was it perhaps just a series of initiatives that sounded nice, felt good, and checked a few boxes?
I’ve seen many executives who’ve tried in earnest to digitally transform their organization, but were forced to settle for a set of random projects that don’t truly qualify as transformative. I’ve also seen some well-meaning but misguided initiatives fall short of embodying an effective transformation.
Sorry to break it to you, but swapping an analog clock for a digital clock in the lobby does not qualify as a digital transformation.
An important distinction between Agile and Waterfall methodologies is how far out you plan. In Waterfall, you need to plan out the entirety of the project. This approach works beautifully for known products of understood scope. But when a deliverable is complex or has many unanswerable questions, Waterfall tends to fall apart, because there’s no way to do a sufficient amount of planning.
On the other hand, Agile thrives when products are complex and filled with unanswerable questions. With an Agile approach, you plan for only the next iteration—usually just 2 weeks. Agile works not because it avoids planning (Sprint Planning is one of the critical ceremonies, after all), but because it constrains the amount of work that you try to plan.
The idea is to reduce the total scope of work to a well-defined set of user stories. Each user story gets an estimate; the estimation metric is called a Story Point.
With all the hype around Agile, I feel compelled to state the obvious: not all IT projects are Agile. (And not all should be—although it’s easy to get that impression from Agile champions!) A waterfall approach is still a viable option for many IT projects.
As any good manager knows, a team infused with a strong sense of responsibility will produce a higher quality outcome. Instilling ownership across a team is more an art than a science. It is a transformation that requires a deliberate communication style, some leadership savvy, delicate execution, and patience.