Hello everyone. Looks like I found a job. It's only a temporary job but at least it involves IT. It's not game related but I'm not sure I should put it in the lounge but since it's job-dynamics related I guess I'll drop it there.

I have to give really bad news to my boss and I'd like advice on how to do that "professionally".

Albeit it's only a temporary job, I won't disclose details; hopefully this is not going to be an issue there since the question is mostly about business dynamics rather than anything else my elaborations below are mainly to let you understand my current mindset and problem perception.

As a start, I've only been there for slightly more than a month and everything went fine so far. About three weeks ago, I was introduced to a certain program (The Program). Since two weeks ago, I have been given the task to evaluate The Program with regards to some of its features. I'll have to discuss The Program next week.

Deploying The Program to end users is apparently a priority (at least in terms of marketing), nonetheless, it so far slipped through the cracks by a few months and it's still far from being integrated in the business practice. AFAIK, The Program had no more than a couple of deployments so far, both in quite specific scenarios. I suspect the open position I'm filling is meant to hold someone dealing specifically with The Program, as the officially appointed "expert" isn't really taking this being already overworked (he has a business role that allows him to pull off the task).

In the past, I have never been scared from being the harbinger of bad news but considering my previous experiences, I've come to the conclusion I have to reconsider at least my methodologies in doing so. I need suggestions on how am I supposed to bring out this issue. Calling it an issue is rather reductive in my opinion: I've dealt with crashes, general instability, incoherent UI, missing input sanification, overreliance on end-user correctness, missing documentation, lacking support, systematic bugs... I could go on forever! And don't even get me started on licensing, Vendor itself seems to have lost grasp on it!

I found so many issues I started to ask myself about the developer studio so I went to google to find a very minimal amount of hits. Trends also informed me about a very low search volume, a thing which I find in stark contrast to the concept of a globally established leader solution. I understand business-oriented software is not really such a big hot topic but I guess there should be some more hits. Am I worrying too much? Do I have to recalibrate my scale of things?

I'm therefore inclined to believe this vendor is selling fry-ware. Because if we start deploying this, we're fried. Sure thing: developer has no QA (nor people doing debugging, much less architecture).

Of course, since we deploy it to end users, we take responsibility on that and given its general instability and fragility to slip errors, I'd say

1. It's high business risk: component is critical to end user business
2. Probably not profitable: maintenance requires super extra special care, even license management itself is something to be performed with care.

So my personal opinion is that The Software should be ditched in favor of something that actually works or proprietary solution.

I mean, what's the reason to sell it? We're basically selling the licenses for this other company. Sure, we might get some benefit but at what cost? If we get even a single on-site support call per year (remote management will be unlikely) our margins are going to suffer massively.

According to my colleagues, "we're pushing it because all other competitors are doing the same". Sure thing. But what has the end user to gain? He as to pay. He as this extra layer of complexity. He has to be more careful than he already is when doing his daily activities. And that supposing the software works fine.

Of course I am not in the position of saying the whole policy over the last few months is to be scrapped. But I couldn't get along either and not expose the risks. How could I convey this message in a business-appropriate way?

Honestly, I don't want to support The Program either because that means I would be responsible to keep it working and explain the many bugs to end users by inventing stupid excuses. To further exacerbate the issue, I think I could write something equivalent (for most basic tasks) in no more than 6 man months, not to mention it would fit with company's core business perfectly.

General advice on the situation is also appreciated.

1. How could I convey this message in a business-appropriate way?
2. Honestly, I don't want to support The Program either because that means I would be responsible to keep it working and explain the many bugs to end users by inventing stupid excuses.

3. To further exacerbate the issue, I think I could write something equivalent (for most basic tasks) in no more than 6 man months, not to mention it would fit with company's

1. Present your concerns in a businesslike manner. Don't get dramatic; present facts and analysis. They asked you for your evaluation of the program. Give it truthfully.

2. If that's your job, that's your job. If it comes to that and you are demoralized, then you always have the option of resigning.

3. This is unlikely to be an option the company needs to hear, unless asked directly, "could you write us one of these but better, and how long would it take?" If you tell them up front that you could write a better one in six months, they're likely to look for other options.

So the boss made a decision, you disagree. Is that it?

I'm not sure who decided what. If they have decided something. The chain of command is a bit flexible. I have no access to actual data, but The Program is basically a customized backup system. So the "only" risk is customer's data loss; I'm unable to assess the incidence on company profile.

1. Present your concerns in a businesslike manner. Don't get dramatic; present facts and analysis. They asked you for your evaluation of the program. Give it truthfully.

2. If that's your job, that's your job. If it comes to that and you are demoralized, then you always have the option of resigning.
3. This is unlikely to be an option the company needs to hear, unless asked directly, "could you write us one of these but better, and how long would it take?" If you tell them up front that you could write a better one in six months, they're likely to look for other options.

1a - Would it be excessive to say that I wouldn't trust The Program even for personal use?

1b - Do you think I should hide the fact I don't want to sell this, unless explicitly asked about?

2 - Yes, that's really what I was thinking while writing this. I'm currently inclined to try keeping it going for a few months so I can pass the knowledge and have time to find another income. Hopefully this will turn out to be less problematic than expected!

3 - Very useful advice thank you. Unless they ask me explicitly, I'm not going to take further initiatives much less comment about that possibility.

1a - Would it be excessive to say that I wouldn't trust The Program even for personal use?
1b - Do you think I should hide the fact I don't want to sell this, unless explicitly asked about?
3 - Very useful advice thank you. Unless they ask me explicitly, I'm not going to take further initiatives much less comment about that possibility.

1a. You can say that, if you back it up with facts and reasons.

1b. Yes.

3. There's a saying, "don't just give me problems -- give me solutions." It would be good to offer a list of concrete steps to fix the problems you identified. I think "scrap it and start over" could be one, but one that a young company chasing profits is unlikely to welcome with open arms.

Ok, solutions. I'll try to get more information about their current plans, this is sure the best I can do now. Thank you!

Piece of advice here, which somewhat correlates to Tom's 1st point.

(I'll answer your question with an example that has occurred no later than last week).

I've had a severe concern about the general direction that a specific production unit was taking. I had no facts to support this, just a general 'bad feeling about it'. I didn't speak up, because, well, I didn't have much to say, and understood probably ever less at that stage.

Things started to change when I laid my eyes on a budget planning.

Essentially, the budget was miles too thin to work. My analysis was based on a previous project tackled only a few weeks prior by the same development team. From what I could read, the scope was marginally higher, but still within acceptable range. The two real differences were:

- The budget was about 20% smaller

- The product actually had to ship (whereas the base reference was a proof of concept)

Armed with this evidence in mind, I wrote an email including all of the major stakeholders. I did not say 'omgwtf!', I simply voiced concerns, with a prologue that underlined my engagement in the unit, my intent to see things through, but my concern (which I said could simply be lack of information too) as I saw these numbers. At no point did I say it couldn't work, or that it was faulty, etc. I didn't even yet go as far as to say that, if all stakeholders were aware of the risks/consequences, we'd do our best but...

It was just an initial contact to touch-base on the potential risks (or my personal lack of information, which would've rendered me useless in order to perform my function appropriately).

One of the stakeholders immediately replied, passionately. The bulk of his argument was that 'with this amount of money, you should be able to make a project of that scope'.

The problem was that this stakeholder failed to present arguments as to why this amount of money equaled this scope, and in the same process, ignored my argument which was based on a mere comparison of similar elements, underlining the differences.

My reply, just as candid as the first one, started with a prologue that resembled probably this: "To be honest, I'm not really in a position to determine whether I should be able or not to make such a project with the allocated money, my only concern at this stage is that I have recent evidence that, with a larger budget, and a smaller scope, we've failed to deliver. I just want to make sure everybody understands that. Now, there is a possibility that the team has acquired experience from the initial project, perhaps there are tidbits of code or functions that can be reused, perhaps there's a number of things I'm not seeing right now that could explain how we'll be able to deliver on-time and on-budget, but so far, there is no evidence to support this, and as a result, I believe it is my duty to inform everyone that is committed to this project of the potential risks."

I never got a reply, and, well, the project went to hell, but at least I did my part to try and warn people off. Ultimately, its really not my decision, and in the greater gist of things, what I perceive as a failure may have value to somebody else looking through a different (more strategic) lens.

We can all close our eyes, hope for the best, or recognize the risk and react accordingly. Every boss has to choose between these two things, and while you may believe that the former is definitely wrong, it is sometimes very useful. When a lot of people start to question a project, without evidence to support the risks they are describing, this can quickly turn into a mass hysteria unless somebody simply says 'jump'.

So, in essence, do your job: voice the part of your concerns that can be supported by evidence and facts. If asked, explain your current position in regards to the project, but always make sure you are open to an explanation. Most companies that survive do so because they think strategically. While there are the dark corner 'oddities' that creep in unnoticed from higher management, most things have a reason to exist. If there's a shippable software that appears to be unprofitable and of poor quality, perhaps there is some form of cross-promotion involved to showcase other products, or perhaps the idea of a single platform or entity through which you can get all of your services has value. Essentially, somebody upstairs probably has a reason for this, and while it may not be a glamorous one, knowing of it might help you accept the situation. Likewise, informing people upstairs of the quirks might help them rectify their vision accordingly and make a few adjustments along the way.

Not too long ago, I was working with a client, providing 3rd party development services for their ongoing project. It was initially meant to make profit, but after they've realized that it would never pay for itself in the end, they were faced with a decision: shut it down?

Most people usually shut the projects down when they don't work, because they don't find sufficient value in a project that keeps costing more than it earns.

However, in this case, the client chose to keep it alive (much to our surprise) because he saw value in maintaining a presence on this specific platform. The client was a publisher with a strong ability to cross-promote his other products. User acquisition through different channels (such at the dying project) proved to be cheaper than big advertisement campaigns, and overall more appealing (there's an actual game to play instead of an ad to watch).

Thus, to everyone's surprised, the project continued simply because it fit a different need that the client was willing to satisfy. Don't get me wrong, they weren't happy about it, but since the product was completed and only required maintenance, they felt that, (ignoring the amount of money lost during development), the project was worth keeping alive.

Good luck!

I just hope, Krohm, that you come back after this is over and share what you told them and how they responded. i.e. a kind of mini post mortem, of sorts. It's actually kind of interesting.

I was planning to do so already.

In the meanwhile, I'm taking back the various notes I've produced in the last couple of weeks and consolidating them in internal formal documents. We had some surprises already but it's too early to say how it will turn out.

Here's an update, more than two weeks later. Time is running out and by the end of next week I'll likely know if my contract will get renewed or not.

I am afraid the "give me solutions" thing might have been a bit too successful.

The program is set up in components. Every time I got to look at one I produced one of the aforementioned documents, claiming to be "documenting" it but integrating the known issues as well as the possible solution. Due to the program "peculiar" design each of those documents took 2-4 days and it's in average twice as long as the official documentation. I could find solutions only in a minor percentage of the use cases considered and in a good 50% of those cases, the solution is often just statistical: "it's hopefully going to work in the real world in 99% of the cases".

Nonetheless, it appears the documents were well received: I've got to know they are considered very solid and someone is evaluating the idea of just integrating them "as-is" in the training sessions (a thing I would rather not do without some minor editing). They were actually too well received and I got several other requests which I had to prioritize over the basic prototype I had in mind - I realized I needed that as it seemed they didn't quite got the idea I could be able to deal with the basic features myself for real.

Looking at my bank account, I've come to the realization I'd currently appreciate to keep writing those for somewhat more than a grand each month. Even with that determination, I couldn't manage to hide my attitude towards the program to my co-worker who is supposed to be the official responsible for it and isn't moving from its standpoint. As I said, he can afford it.

I have heard that the company has somehow managed to get a discount on the licenses (like 30% off). I sincerely hope this isn't the result of pointing out the issues.

Anyway yesterday I have been hinted no decision has been taken on renewing my contract so I guess now I just have to wait and see.