This seems like a bad way to do things. Is it? Is there a name for it?

In My Humble Opinion
1

Where I work (sorry, this is about to be pretty vague but I’ll try to be as specific as possible) my team put together project X about a year ago, and have been maintaining it ever since. Project X is customer-facing, and while customers interface with X mostly on their own via a website, we also spend at least half of our time helping customers with X.

X is something we created, and those customers who do talk to a person at my company about X talk to us.

Until yesterday, we had not heard any negative feedback from management about X.

Yesterday, management said it was getting rid of X because too many customers were starting out with X, navigating through it for a while, then never touching it again–when for our company it is imperative that most customers who begin X finish X.

This news about customers does not surprise anyone on my team. We have familiarity with the issues the customers are facing, and, being the team who designed X in the first place, and being the team who knows our customers’ problems and needs, we have several ideas about how to revise X to help with this situation.

But no one asked us about what was happening or what to do about it, nor (if not exactly by policy, then by clear precedent and established protocol) would we have been welcome to volunteer such information to anyone except our immediate supervisor, who himself is a very good manager and who has told us it is not considered his role to volunteer such information upwards. The higher-ups believe they have all the information they need by looking at generated data, and he knows to volunteer impressions from on-the-ground workers only when asked about them–and he is never asked about them.

So, instead of asking us what is happening and asking what ideas we may have for fixing it, the higher-ups simply decided unilaterally to get rid of X and replace it (in a few months) with something bought from a vendor (what they will buy has not been determined, or even thought about, yet). In the meantime we will be using Y instead of X, which is what we had before X, and which is universally known by all involved to be awful.

It has been made clear–and I believe it–that no one blames us, and in fact X is thought to be objectively good in many ways. They simply believe the best solution is to replace it rather than fixing it.

This has all happened very fast, and it is clear very little planning has been done as to how the replacement will take place. Whatever numbers they saw, must have seemed really awful to them. However it is very difficult for me to imagine numbers which mean “we definitely should not take a few days to discuss this with the people most familiar with what is happening, and we definitely should just pull the plug immediately.”

Well anyway, am I suffering from short-sightedness in strongly suspecting upper management is acting in error here, and that instead they ought to be interviewing my team and looking for solutions from us? I know that sometimes the people on the ground (that’s me) think they understand more than they actually understand. I know this. But in this particular case, it really feels like we (my team) have some pretty good ideas about how to solve this, and it really feels like people should have listened to us before acting so hastily.

Do you have an opinion about this?

*Note: This is what we originally told them to do, back when all of this began.

2

My guess is the product, let’s call it V, HAS been determined. And the maker of V is a friend or family or acquaintance of your higher-ups and said one day “Hey, heard you were using X. You should use V, it’s way better”

3

They decided to outsource. In many cases, these decisions are just arbitrary or based on trend.

If there is a rational reason, it could be things like better fit for requirements, better SLA, better features/reviews, etc.

How long has X been running with known issues? Who would have been responsible for deciding to make a start on improvements?

4

The way I characterize this is that management is thinking about this “strategically”, whereas Frylock is thinking about this “operationally”.

It is the responsibility of leadership to make decisions strategically (what direction do we go), whereas it is the responsibility of lower level management to execute operationally (how do we move in that direction).

When you are talking about making Project X better, be careful that you are not stuck in thinking how to make a better buggy-whip, when everyone is starting to manufacture automobiles instead.

Now, of course, not everything fits neatly into this paradigm. And very often the strategic decisions do not pay off. But it helps me to think about the differences in leadership, management, and workers, in this way.

5

It’s hard to judge what happened here.

My first thought (perhaps because it’s closest to an experience I had) is that they decided the fixes to X would be too expensive to do internally, and that switching to Y from a third party would be the better option. After all, there’s no reason to spend $100,000 internally re-inventing the wheel when you can license the wheel from Y for $50,000. Since a third-party vendor has many customers, the costs are spread out.

You do make it sound like there’s a lack of communication upwards, though, so I wonder if they had the needed information to judge the cost. Maybe it’s some kind of internal politics, or some decision-maker who’s already made up his mind about a third-party vendor.

6

IMO …

Italics mine. This part right here is all that matters. The rest is background noise.

Either your supervisor is a timid yes-man and sold you and your project down the river or you’re working for a company whose executive class simply believe all wisdom flows from the top.

The cure for the former is for you to work for a different supervisor. The cure for the latter is for you to work for a different company. Pretty much anything else is wishful thinking.

7

It does seem odd that either the higher-ups never asked for statuses on X, and/or that your manager did not offer them an overview of major issues encountered and what it would take to solve them. Perhaps he has been burned before, but it seems like at the very least covering his ass to explain that he is aware of issues and that he has solutions worked out should they decide it is worth pursuing them.

It seems short-sighted of the higher-ups to not at least be briefed on details beyond a summary set of data, especially if that data is indicating something needs to be done. And not just on this project, but as you say as a general rule. If it were a one-time thing I’d think they are just using the data to support a decision they already want to make anyway.

8

I did just, coincidentally, have a one-on-one meeting with my boss’s boss, and in that meeting he asked me what I thought. I laid out basically the concern I expressed in the OP, and he was actually pretty frank that he felt he had missed an opportunity to “go into solution mode” when he had seen two months ago (!) that the numbers were doing the things that eventually led to this. (Exclamation point because we at the bottom knew nor hide nor hair of this.)

He’s a good guy. Also, I agree with him.

9

I can see a couple of red flags here.

You say that X launched a year ago, and that you spend at least half your time helping customers get through it. Are these first-time customers, or customers who have used X before but are still having trouble with it?

Management says too many people are starting out with X, then giving up on it. Together with your first comment, that suggests to me that X has significant problems.

That could also explain why your manager isn’t being asked about this. Unfortunately, blaming the customer is a frequent response of people who are invested in a project, which doesn’t help senior management.

Alternately, it’s possible that manager has been in the loop, but he’s trying to shield you, and that management has lost patience with your department’s efforts to work out the problems.

You may think that Y is awful, but management’s decision to go back to Y tells me the problems with X are worse than you think they are, or at least that your customers will feel more comfortable with Y.

That there’s an external product V available that apparently does what X and Y are supposed to do suggests that management has decided to wash the company’s hands of this problem, contract it out, and tell the vendor they’re responsible for fixing any problems at no additional expense.

Because one or more outside vendors are offering solutions, I’m guessing that you’re in an industry with a number of competitors, and that the problems with X are seen as alienating your customers. That by itself can be enough to panic management into a quick decision.

10

OP and his entire team should now walk into higher management’s office, sing a few bars of Alice’s Restaurant, and walk out again.

11

Not necessarily, those customers may have been browsing. I was recently browsing for a certain type of software; every one I tried was functionally satisfactory but I am not interested in buying at this point in time, it was only market exploration. If I ever do buy, which one gets chosen will depend on who else am I buying for and on things that are “administrative” for lack of a better word (team size = number of licenses needed; flex licensing; cost of hosting).

12

The OP is pretty vague about X, but management might be very surprised to find out that Y or V won’t solve the problem - if the “workflow” is the same.
As an example, I recently went on a comparison shopping spree for some custom large-format photographic prints. I was surprised at the number of websites that made it impossible to actually, you know, get a price. They either they wanted me to “sign up,” or contact an individual, or fill out way to much information - none of which I was going to do, so I just left the site and went somewhere else.
If Y or V does this (the same as X did), then the end results will be lots of click abandonment.

13

If creating and maintaining ‘X’ is the only work the OP’s group does, it is time to find another job.

FWIW: A large clothing manufacturer based in SF (not naming names) decided to replace its AR system.
They had a large IT group in-house (1980’s). They were told: 2 years, $5 million.

A manager found a ‘perfect’ package from a brand-new company for $125000.
He crowed about how much smarter than the IT department he was.

Once the bugs were beaten down to the point it would compile, it was junk. The daily cycle would run 32 hours*.
After 4 years and $6 million trying to get it to work (vendor sent the one bright person in the shop to work onsite), they gutted it of all the bells and whistles they wanted and declared victory.

  • the thing actually still ran counters on file access. A table with a total of 80 records was read 2.2 MILLION times.
14

I don’t know if there is a specific “name” for your scenario, but as a management consultant, this is typical of the type of problem my firm would be called in to solve at a client site.
Your description is a bit vague. But what I am interpreting is that you and your team support some sort of bespoke client-facing technology solution. While you probably do provide great service by supporting this application and your client’s are happy, what the higher ups in management have probably determined is that this project is spending way too much time and money for whatever results it is supposed to produce. They may have determined that there are out of the box solutions they can have an outside vendor implement that, at least on paper, is cheaper and more efficient.

One thing that is telling is your use of the term “project” to describe what you are doing. By definition, a “project” is a short term temporary initiative with a clear (ish) objective, start and end points. If you are supporting this thing indefinitely, it is no longer a project and has become an ongoing business operation. That also means it will continue to appear on some executives P&L year after year.

I often see where people who support internal applications really have no idea how their application impacts the rest of the business or how in many cases it is actually absurdly inefficient and outdated compared to what is currently available.

If the OP works for a company of any size, unless that friend or family or acquaintance works for a company like IBM, SAS, Oracle, EMC or something of similar scale, it’s actually kind of hard to just pull in one of your buddies to build a system with real impact across the enterprise.