DCRs (Design Change Requests)

Have you ever came across something that was just not the way you thought it should be or did not work like it looks like it should but that was the way it was purposely designed and developed? If you came across this in a software application, you could submit a DCR to fix it to the way you think is the right design. Submitting a DCR is as easy as opening a bug and giving the description of what is happening and what you think should happen and the design you feel is better than the current one.

Opening the DCR is the easy part… the harder parts comes when the development team has to triage it, figure out whether or not to take the change requested, its customer impact, priority, resource costing PM, Dev, Test, & UE, what the schedule impact is, any security implications, risks associated, dependencies, affected DLLs, etc… and the list can go on and on dependent upon the given DCR.

As a Release Manager for my team, I'm the one to come up with the process to use for handling DCRs. This may sound like an easy task to you but, there are many things to take into consideration such as, making sure that everyone has the same understanding of what a DCR is and what a DCR is not across to the team and getting them all to agree that, that is what a DCR is and isn't. There's also the, "What do we do with a DCR after it is accepted?" question that needs answered to everyone's understanding so that they agree with it and actually follow it.

So being a Release Manager in itself is like being a DCR because as Release Manager, you are constantly trying to change processes to better them for your team to follow. To do that means that you have to communicate with others and listen to their feedback to get results that they will follow. It can take up great deal of time to do the leg work but the payoff and benefit to your team and customers when the process is right, can help everyone greatly enhance their productivity and improve the quality of the bits being developed.