Projects: Splits, Mergers, Growth and Shrinking

At this point in my career, I've been part of many efforts to split systems, merge them, grow them and shrink them. These are all due to the companies or divisions I worked in or with doing just that same activity.

As part of one of these activities quite a long time ago, I had been included in a workshop giving those of us involved some tips on how to proceed and what to expect.

Lately, being both part of a big, public merger, but also by chance speaking with several unrelated groups of people who are splitting, it brought back some of the tips I received all those years ago. That workshop gave a few basics that have always stuck with me and I tend to take for granted. Since then, of course, I have gained a lot of experience and tips to pass along. While I have been verbally passing some of this along, let me share a few ideas with the rest of you, as well.

Whether a company or division is splitting or merging, or whether it is growing or shrinking, there are certain tasks that are the same regardless which of those you are doing. Then, there are the types of tasks that are very different. The categories of tasks tend to be very similar across all these situations, but the way you approach them might be different, is what I mean to say. I will come back to that in a later section of this article.

The Main Similarity

The main similarity all these have is that they are projects. We approach them the same way we do most projects, although these have their own types of issues to know about, but like any other project, they have resources, budgets and timelines, for example.

Note: To put this in a slightly different manner, as an example, a software project and a business process reengineering project are both projects. They have the same constructs of scope creep and other issues they face. At the same time, they are not the same type of project and they have different types of resources they need.

In any case, as is the case with projects, you will run into communication issues that you need to manage. You might lose people just as you might with other types of projects and the way you communicate what you're doing will affect this situation.

In addition, the same as it is with any other type of project, they are often underestimated and under-resourced for what they promise to deliver. Again, similar to any other type of project, some of these projects will be given more money when they fall short, others will not.

Communications

That early workshop I attended stressed to us that the way we approach the communications will affect the level of churn and anxiety of these types of projects. I will add that this is yet more critical for these types of projects over even our large software projects.

Think about this - is there really anything more stressful to most employees than these types of situations? Typically, these are the most stressful times to be involved with a company. Just be aware that project communications both can help the project be as successful as possible, but where you want to keep anxiety as low as possible, that is another piece to your communication strategy.

Thoughts From My Own Experiences

Now, all these years later, here are a few details of my own to add to what I learned in that early workshop.

First of all, when we talk about the communications and stress, I did work with one such project where they told us they didn't care at all about managing churn or how stressed anyone was, that they barely had the ability to get through the whole thing, that whatever outcome they had was what they ended up with, and that they would fix it all, later on.

What they were saying is that they did not care about retaining people and were perfectly satisfied to rehire whatever roles they needed to after they were done.

It sounds harsh but at least they were honest with everyone about it.

Details on Tasks

I did promise to give a few tips on the tasks, and this is also just a few items I've learned, over the years.

As just one example, let's talk about licenses and contracts. I've spent so much time in my own business and as a consultant reading these and reviewing them for these and other situations, and it's one similarity all these situations typically have and is something probably everyone has to deal with.

It's just one of several categories that all these projects have in common.

But here are just a few ways they typically differ:

• Splitting is not as easy as copying all the systems and dividing the licenses. Some software vendors won't allow you to make it happen in this manner. If you had a volume discount with the greater number of licenses, you might no longer have this discount when you now have two smaller sets of licenses.
• Merging does not quite mean it's the opposite of splitting. Do not assume a smaller group of licenses of the same product gets less of a discount (sometimes, they negotiated better than the larger group). Also, the licensing schemes could be entirely different, where one bought the license per seat, the other per concurrent user, as just one example.
• As a company grows, there are some software packages that are meant for smaller companies that cannot grow with the increase of data. However, software packages that are sold to smaller companies do sometimes have ways to increase the resources to help support a company as it becomes larger than the software is intended for, and there is sometimes less of a rush to move off that software than you might expect.
• When a company shrinks, there are typically too many systems to be supported by what is now fewer people who are often told they are lucky to keep their jobs. In some ways, those fewer people truly will support more systems. However, some systems typically do have to fall by the wayside. Just make certain you are deliberate in choosing which systems are the most important and you will make this smoother than if you leave it to chance.
• Beyond some of the business aspects such as the licensing, the technical details aren't much easier. Taking the same brand of some of these large systems and trying to either split or merge to make them one system of that brand is typically difficult. Again, splitting is often more difficult than copying the system and "deleting some stuff," nor is merging as easy as just "importing a bunch of records."

Finally

Back to that original seminar I attended many years ago, one of the goals it stressed was to do this work in a manner to maintain trust among all stakeholders, including the employees. It stressed the value of keeping as many of them as possible.

In the example I gave above, obviously that was not something that was of value. In that situation, the goal was just to get it all done and rebuild the culture at a later time.

In fact, in some of these situations, the goal is to end with fewer people around. I am not clear if that is what that project I spoke about was hoping for. However, my response to that situation is that they made that choice, they now live with that choice, and that each company makes its own choices in these situations and does not get a friendly ear from the rest of us when they later complain about it.

In the end, project management is about doing what we can to make choices that take us in the direction we need to go, to get all the work done with our budget and timeline, and to be able to get to that end goal as closely as we possibly can.