Timeline for How can I sell a legacy program rewrite to the business?
Current License: CC BY-SA 2.5
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2010 at 12:49 | comment | added | luis.espinal | @OAOD - Also, development units must have a right to reject requests (barring those are are truly critical path). For the most part, requests should be non-trivial, atomic, verifiable and must come from a valid business concept. In-house development is an intrinsic part of business and needs to have the power to negotiate with other internal business units. This negotiating power should be established as a critical part of the internal business process. If that's not the case, then there is no way with which to implement valid cost estimation and trade-off analysis. | |
| Oct 25, 2010 at 12:45 | comment | added | luis.espinal | @OAOD - that's a good point. The problem with setting up such a large fee per hour is that it is fictitious and cannot be backed with data - it could be done for external development, but not for development done in-house. Also, it's not just $40/hr; it's that * 2 to account to ancillary costs. One way to counter-measure such micro-request changes (if there are many) is to deliver at periods no shorter than 12 weeks. This creates a back-log of micro-changes that you can put a ballpark cost on them. | |
| Oct 25, 2010 at 0:38 | comment | added | Engineer2021 | Only downside I see is if it is a trivial change, then the cost could be too low and the customer would request trivial changes constantly (for instance, if the fee comes out to $320 for a $40/hr salary at 8 hrs and 1 person). Setting the fee large (such as $1000 per engineer hour) discourages trivial changes and encompasses all phases of changes including tech support should something go wrong | |
| Oct 19, 2010 at 16:28 | history | answered | luis.espinal | CC BY-SA 2.5 |