3
2 Comments

Change Request Management as a Service

I refined my old idea and posted it in Kernal, please let me know what you think (and maybe vote it up).

https://kern.al/idea/change-request-management-as-a-service

I have actually started to write the code (bad programmer's habit I know), but stopped working on it for long time as I'm getting worried if no one would use my service.

Any inputs are welcome, especially if you have any idea how to validate this with as little efforts as possible.

on July 21, 2021
  1. 2

    Decision makers will likely require:

    • impact analysis on proposed change[s] (including comparing going ahead vs rejecting)
    • cost of realizing change request vs cost of not doing it (development, testing, infrastructure, DevOps, documentation, etc.)
    • dependencies between change requests (e.g. if you reject X you make requests Y and Z impossible)

    to make an informed decision.

    1. 1

      @CodoSaur Thanks for the feedback!

      Agree. In my company's internal similar system, there's some mandatory fields like "business justification" and "potential impacts". It's mostly used as a portal to inform tech and non-tech managers about the changes we're going to make (along with execution plan, backup plan, schedules, etc), so they can ack and do necessary preparations. The decision making is usually already done beforehand, so submitting to the portal is more like paperwork and audit logs to hold everyone involved accountable for the changes.

      So far I still can't figure out how to address the requirements you mentioned other than detailed descriptions and centralizing the discussions.