3 ms·

You haven’t communicated the cost. To the business manager it’s essentially free to leave it in - so why not keep the optionality. If you could estimate “keepi

You haven’t communicated the cost. To the business manager it’s essentially free to leave it in - so why not keep the optionality. If you could estimate “keeping feature X costs $200,000 per year in added development time” it would be an easy decision. Through this process of cost estimating you may find that while annoying it only costs $10,000. Any ill will generated from removing it would cost more than that so it should be left alone.

Pamar 8y ago
This has never worked. The project has a maintenance budget that covers everything (bug fixing, new features, migration to new versions of OS, DB etc.). Business requires a certain number of enhancements, the development team is already understaffed and therefore they are often missing the required number of enhancements in a specific release cycle. So the full discussion goes something like this: "Can we remove support for Roman Numerals? We are pretty sure nobody uses these anymore, and we estimate that this would cost 20 man/days in this release but result in a saving of 800 man days over the fiscal year..." "Not sure, it could be useful again, use these 20 days to add support for Aztec calendar to the Insurance reports - you have already postponed this twice!" (I.e. they get the impression that somehow there are 20 "extra" days available and those have to be diverted to implements something that may have become already obsolete).
- slededit 8y ago
  Never lead a sales pitch with the price tag, always with the benefit. The conversation shouldn’t be about it costing 20 days to remove something. It should be about the net savings from doing so. “Removing rarely used feature XYZ will open up 780 man-days of schedule time this year for new features by improving our efficiency”
  - Pamar 8y ago
    I am working on a legacy application which brings in 90% of the revenue of the company (imagine something managing bookings for an hotel chain: of course we get also revenue for what guests pay during the stay, and maybe for cups, pens, and bathrobes with our logo, but the vast majority comes from the bookings, of course). As such, every different part of the business may request changes/enhancements - our team provides these to lots of different "business departments" across the whole company. Again, imagine a hotel chain with hotels all over the world, each national branch may require specific changes due to local laws and regulations, or because they need to start a new incentive campaign or participate in a joint venture with a flight company or whatever. There is one application, and N different (competing) "customers" each one considering only their own specific plans and priorities. (In case of conflicts, the pecking order will be used to solve who gets more attention: biggest hotels, or hotels in regions that bring more revenue have more "clout"). Now, when I say "we have to postpone your request for X in order to recoup 780 more days later" the guy in front of me will immediately conclude that he will not necessarily get a bigger share of these 780 days - he will have to fight for his piece just as strenuously as before, and in any case this will happen maybe in three months, and he needs his stuff yesterday - so he better insist to have his own specific request included in the release, no matter if it costs 21 days, 20 days, 5 days: he wants this to be done because the rest of his business needs it for a specific date, and everything else is just a way for IT to postpone his request once again. In other words: everybody wants their own specific request implemented as soon as possible, and anything else has absolutely zero interest for them. Especially if it is some promise of future "gains" from guys who are constantly late. In my experience, this is not so uncommon when you work on an app that has been developed internally (and so there is no unified marketing department which represents a single stakeholder) - note also that precisely because we have to work for a myriad different "internal customers" we tend to accumulate "technical debt" at a faster rate: there is only one codebase, and has to accommodate all these pesky requirements from all over the world...
    - slededit 8y ago
      If you have multiple teams competing for features, it shouldn’t be too hard to sell it that way. “If we could open up 780 days on the schedule - what new features would you like?” At this point you want the client dreaming of all the extras they never thought they’d get to have. Then at the end you mention the 20 day delay. At this point they will feel the “loss” of the new features they just imagined. It’s an extremely powerful sales technique that works almost everywhere. Given your earlier comments about the extra 20 days they seem particularly susceptible to this technique.
      - user5994461 8y ago
        If you announce that you have 4 man years free for new tasks, in a team that may not even have 4 developers, after abandoning a feature that already existed and worked, you're delusional and so is the stakeholder if he believes it. I agree on the principles nonetheless. You want clients to write a formal request for new features, then development has a backlog of requests and can prioritize them. Clients might not like the prioritization but that's life, limited bandwidth, it's simple to show there is too much to do and not enough resources.
        slededit 8y ago
        I’m using the numbers I was given as I’m not in a place to judge if they are realistic. Certainly if you make false promises no amount of sales techniques will save you in the long run.
        Pamar 8y ago
        The 200000 vs 10000 (and therefore the 20 vs. 780 man days) come straight from your example. Which is part of the problem: while I know for sure that are a lot of things that should be refactored/changed/improved/cut off it would be very difficult for me to give an estimate of "how much resources we save over the next year" - as a simple example, I could revamp significantly the GUI (God knows how much it needs it)... and in the next six months I get 85% of the requests for changes having to do with business logic, financial batches running at the end of the month and stuff like that, maybe because there are new regulatory hurdles to clear like GDPR or The EU Travel Directive. Then the promised extra resources that would have become "available" fail to materialize, and the whole initiative is considered a failure. Good luck trying this again on the next year.

Pamar 8y ago

This has never worked. The project has a maintenance budget that covers everything (bug fixing, new features, migration to new versions of OS, DB etc.). Business requires a certain number of enhancements, the development team is already understaffed and therefore they are often missing the required number of enhancements in a specific release cycle. So the full discussion goes something like this: "Can we remove support for Roman Numerals? We are pretty sure nobody uses these anymore, and we estimate that this would cost 20 man/days in this release but result in a saving of 800 man days over the fiscal year..." "Not sure, it could be useful again, use these 20 days to add support for Aztec calendar to the Insurance reports - you have already postponed this twice!" (I.e. they get the impression that somehow there are 20 "extra" days available and those have to be diverted to implements something that may have become already obsolete).

slededit 8y ago
Never lead a sales pitch with the price tag, always with the benefit. The conversation shouldn’t be about it costing 20 days to remove something. It should be about the net savings from doing so. “Removing rarely used feature XYZ will open up 780 man-days of schedule time this year for new features by improving our efficiency”
- Pamar 8y ago
  I am working on a legacy application which brings in 90% of the revenue of the company (imagine something managing bookings for an hotel chain: of course we get also revenue for what guests pay during the stay, and maybe for cups, pens, and bathrobes with our logo, but the vast majority comes from the bookings, of course). As such, every different part of the business may request changes/enhancements - our team provides these to lots of different "business departments" across the whole company. Again, imagine a hotel chain with hotels all over the world, each national branch may require specific changes due to local laws and regulations, or because they need to start a new incentive campaign or participate in a joint venture with a flight company or whatever. There is one application, and N different (competing) "customers" each one considering only their own specific plans and priorities. (In case of conflicts, the pecking order will be used to solve who gets more attention: biggest hotels, or hotels in regions that bring more revenue have more "clout"). Now, when I say "we have to postpone your request for X in order to recoup 780 more days later" the guy in front of me will immediately conclude that he will not necessarily get a bigger share of these 780 days - he will have to fight for his piece just as strenuously as before, and in any case this will happen maybe in three months, and he needs his stuff yesterday - so he better insist to have his own specific request included in the release, no matter if it costs 21 days, 20 days, 5 days: he wants this to be done because the rest of his business needs it for a specific date, and everything else is just a way for IT to postpone his request once again. In other words: everybody wants their own specific request implemented as soon as possible, and anything else has absolutely zero interest for them. Especially if it is some promise of future "gains" from guys who are constantly late. In my experience, this is not so uncommon when you work on an app that has been developed internally (and so there is no unified marketing department which represents a single stakeholder) - note also that precisely because we have to work for a myriad different "internal customers" we tend to accumulate "technical debt" at a faster rate: there is only one codebase, and has to accommodate all these pesky requirements from all over the world...
  - slededit 8y ago
    If you have multiple teams competing for features, it shouldn’t be too hard to sell it that way. “If we could open up 780 days on the schedule - what new features would you like?” At this point you want the client dreaming of all the extras they never thought they’d get to have. Then at the end you mention the 20 day delay. At this point they will feel the “loss” of the new features they just imagined. It’s an extremely powerful sales technique that works almost everywhere. Given your earlier comments about the extra 20 days they seem particularly susceptible to this technique.
    - user5994461 8y ago
      If you announce that you have 4 man years free for new tasks, in a team that may not even have 4 developers, after abandoning a feature that already existed and worked, you're delusional and so is the stakeholder if he believes it. I agree on the principles nonetheless. You want clients to write a formal request for new features, then development has a backlog of requests and can prioritize them. Clients might not like the prioritization but that's life, limited bandwidth, it's simple to show there is too much to do and not enough resources.
      - slededit 8y ago
        I’m using the numbers I was given as I’m not in a place to judge if they are realistic. Certainly if you make false promises no amount of sales techniques will save you in the long run.
        Pamar 8y ago
        The 200000 vs 10000 (and therefore the 20 vs. 780 man days) come straight from your example. Which is part of the problem: while I know for sure that are a lot of things that should be refactored/changed/improved/cut off it would be very difficult for me to give an estimate of "how much resources we save over the next year" - as a simple example, I could revamp significantly the GUI (God knows how much it needs it)... and in the next six months I get 85% of the requests for changes having to do with business logic, financial batches running at the end of the month and stuff like that, maybe because there are new regulatory hurdles to clear like GDPR or The EU Travel Directive. Then the promised extra resources that would have become "available" fail to materialize, and the whole initiative is considered a failure. Good luck trying this again on the next year.