Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


Bringing really bad news, reccomendations


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 22 June 2013 - 04:25 AM

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.



Sponsor:

#2 frob   Moderators   -  Reputation: 22833

Like
4Likes
Like

Posted 22 June 2013 - 10:00 AM

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

It depends on the situation and the risk.

If it is a mild thing that you can do but just don't want to do, and is a small to moderate risk, just talk about it. Tell him the good, then the bad, then the concerns, then the alternatives. Get numbers if you can, but be open and frank in your discussion. Always keep an open dialogue with your boss.


If the risk is extremely high, such as millions of dollars or human lives, this something else. You have a very polite discussion in email. You present evidence of why it is bad (actual numbers) and you present multiple alternatives. Then you let your boss make the bad decision if he wants. Print the email exchange, keep in a CYA folder.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 Tom Sloper   Moderators   -  Reputation: 10179

Like
3Likes
Like

Posted 22 June 2013 - 12:08 PM


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.


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#4 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 23 June 2013 - 04:33 AM

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.



#5 Tom Sloper   Moderators   -  Reputation: 10179

Like
3Likes
Like

Posted 23 June 2013 - 08:29 AM


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.


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#6 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 23 June 2013 - 02:30 PM

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



#7 Orymus3   Crossbones+   -  Reputation: 10706

Like
0Likes
Like

Posted 24 June 2013 - 09:41 PM

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!



#8 Cornstalks   Crossbones+   -  Reputation: 6991

Like
1Likes
Like

Posted 24 June 2013 - 11:02 PM

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 ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#9 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 27 June 2013 - 06:12 AM

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.



#10 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 13 July 2013 - 01:18 AM

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.



#11 samoth   Crossbones+   -  Reputation: 5043

Like
1Likes
Like

Posted 13 July 2013 - 02:22 AM

Didn't you say that The Program was a customized backup system?

 

How can a backup system be so complex that it takes several days to write an evaluation for one of its components, and how can "hopefully it will work 99% of the time" be an applicable solution? This basically presumes that as it is, it doesn't even work 99% of the time! I should seriously hope that a backup system works 100% of the time, without any such thing as "hopefully".

 

I mean, don't get me wrong, but this sounds like a joke. I can't believe anyone would seriously consider to do business with a product like this. Even at a 30% discount, a backup system like that is a customer support and liability nightmare which just isn't acceptable. That must be pretty obvious to your bosses, too. It's like selling a car where the brakes and the safety belts hopefully work 90% of the time.



#12 Tom Sloper   Moderators   -  Reputation: 10179

Like
1Likes
Like

Posted 13 July 2013 - 09:11 AM

Good luck, Krohm.


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#13 DarkRonin   Members   -  Reputation: 616

Like
1Likes
Like

Posted 14 July 2013 - 08:18 PM

But you need to remember 99% of the time it works every time - Hehe!

 

Seriously though, your boss might also need to factor in who the consumer will see as liable for their data if it does fail miserably 1% of the time.

 

Imagine if Microsoft used this product and lost all of their data. Your boss would break the 100M sprint world records.



#14 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 15 July 2013 - 11:56 PM

How can a backup system be so complex that it takes several days to write an evaluation for one of its components

Basically because only a minor part of the options are orthogonal. The functionality matrix has a lot of invalid configurations, most of which are blindly accepted and don't bail out until runtime so every minor reconfiguration must validated. Sometimes the service would never reboot requiring the host to be power cycled.

Just FYI, there's a basic component - no wait, it's part of the super-duper package - which has an option "to optimize performance". I haven't measured any performance improvement but for some reason it breaks pretty much every successive component. I still haven't figured out how to use that specific option!

 

This basically presumes that as it is, it doesn't even work 99% of the time!

This is incorrect. The bug is deterministic thus when given the wrong input it fails 100% of the time - I've written a procedure to cause it and so far, it never failed to reproduce. When the "workaround" is implemented the data will never be in the configuration causing the bug but there sure is a small percentage of cases in which the workaround cannot be applied. I think I have chosen words poorly here.

 

It's like selling a car where the brakes and the safety belts hopefully work 90% of the time.

Yes, it is. I bet this is the reason for which the official "expert" is not spending any effort on promoting The program.

 

your boss might also need to factor in who the consumer will see as liable for their data if it does fail miserably 1% of the time

I don't get your concern. Before I started looking at this no one even had the idea this didn't work. I don't know who my boss will consider for the damage but sure I know who the customer will sue.



#15 Orymus3   Crossbones+   -  Reputation: 10706

Like
0Likes
Like

Posted 20 July 2013 - 05:29 PM

Piece of advice here. When shit hits the fan for the customer, a lot of times they don't care as much how you will fix it (so long as you do it quick) as much as they insist on making sure their vis-a-vis smites someone downstairs. Don't be that person because, in the eyes of the customer, if you can explain the issue - worse yet you recognize you are aware of it - then you are part of the problem... and your boss does not sound like someone who will rectify this and take the blame.
Trust me I've been there. Be extra careful not to become the easy target to blame.

#16 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 22 July 2013 - 02:40 AM

Talking about shitstorms, one (perhaps the most important) customer called back. Apparently the program misplaced something like 5000 files, which had to be re-catalogued manually. Upon scrutiny, it appeared the program was misconfigured since day one, a thing that doesn't take me by surprise since the UI is a total disaster and it's easier to get an invalid config rather than one valid. Let alone the one wanted.

I suspect this raised considerable doubts since it appeared obvious config was not thoroughly validated.

 

Anyway, I guess I can draw a line now.

 

Last day of work I rushed to produce the last document, which I swiftly delivered to the Technical Director, let's call him that way. Of course, there was quite some... things... in this as well, but at least no chance of data destruction.

A couple of hours later, I get called by the CEO to meet him in his office, toghether with the Technical Director, who I have been reporting since day one. Notably, the "official" expert was missing. The CEO appeared very worried the program didn't perform and told me he asked their 1st party hardware vendor for clarification but the higher business decisions were clearly stated: the program must be pushed to high-profile customers. He asked if I could modify the program to get the rid of the issues. Of course I told him this would likely be illegal and a major technical feat so I suggested to profile their customers and provide an alternative solution. To not contradict higher-rank decisions, the alternative solution would be considered "low end" while the program would officially be the hi-end, feature-complete, top-quality solution.

At first, the proposal seemed to have been taken very well. It seems like he has been looking in that direction for quite a while and starting drawing a system where... frankly put, everyone would win. Honestly, this thing got me quite excited! I'm inclined to think this would be business as business should really be in 2013.

Nonetheless, it appears the company cannot afford "logistically speaking" to embark on such a project, therefore they will call me "when the situation stabilizes in terms of workforce".

On the pro side, I won't have to deal with the asbestos slabs.

 

edit: small clarification on enterprise-y strategy.


Edited by Krohm, 22 July 2013 - 02:43 AM.


#17 Tom Sloper   Moderators   -  Reputation: 10179

Like
0Likes
Like

Posted 22 July 2013 - 08:07 AM


He asked if I could modify the program to get the rid of the issues. Of course I told him this would likely be illegal and a major technical feat

 

It's not clear from the preceding why "of course" it would be illegal to modify the program.  But anyway, you appear to have done the right thing and come out in one piece.


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#18 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 22 July 2013 - 09:02 AM

My wording is probably flaky here. I told him it's "likely [to] be illegal" because that's what happens when hacking is involved - we didn't have access to the source and even acquiring the reseller license turned out to be an involved process. The "of course" applies to what I've said because I believe it's safer for everyone saying programs by default cannot be modified rather than vice-versa, not to the fact that "programs cannot be modified".






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS