3 Reasons You Shouldn't Hate Change Requests - Inverse-Square
post-template-default,single,single-post,postid-16211,single-format-standard,ajax_updown_fade,page_not_loaded,,qode-content-sidebar-responsive,qode-child-theme-ver-1.0.0,qode-theme-ver-12.0.1,qode-theme-bridge,wpb-js-composer js-comp-ver-6.4.1,vc_responsive

3 Reasons You Shouldn’t Hate Change Requests

change requests

3 Reasons You Shouldn’t Hate Change Requests

I’m not really sure how it happened. I swore off formal process control documents when I left corporate life fifteen years ago, yet here I sit writing a blog post defending the use of Change Requests (CR) forms and actually meaning what I’m saying. I’ve grown to love CR forms, and I think our clients should too.

Ask anyone who’s been in a contract relationship how they feel about CR forms and the response is almost unanimous, they love to hate them. The reason is pretty straight forward; they tend to add project cost, slow things down and remove freedom. I used to feel the the same way and then I had to have one too many hard conversations at the end of a web application development project.

Here’s three reasons why you should learn to embrace these detail loving documents:

1. Change Requests create freedom, they don’t constrain it.

Contrary to popular belief, change requests don’t add cost to a project, they provide a method of reigning costs in. Whether you’re cutting code for custom software or pouring concrete, there’s going to be deviations from the initial design. Having a formal CR process that includes documentation provides everyone involved the opportunity to look at the options and pick one that makes the most sense.

2. Used appropriately Change Requests will save a relationship, not damage it.

I’ve heard too many stories about change requests being the straws that broke the camels back. While I have seen a few custom software developers abuse the CR process to cover up their own inadequacies, it shouldn’t and doesn’t have to be this way. If a custom software development project is allocated a risk or change buffer (we suggest 20%), the CR process gives the software developer and the client an appropriate vehicle to baseline unaccounted expenditures against. That process beats the heck out of going heads down and delivering an invoice that’s 40% above expectation with no documentation as to why.

3. Change Requests are the breadcrumbs of your project.

Almost all projects change and evolve over time. Time can be a few months in production or the first few feedback loops during development. Change Requests are the breadcrumbs to help to keep an integrated team on the same page. Those requests can be used to signal scheduling changes to the operations team, requirements changes to the development and testing teams, and financial impact changes to both teams’ accounting departments.

Admitting that things aren’t going according to plan is a difficult and painful thing to do, but it’s also the mature and professionally responsible thing to do. Creating a process to facilitate that conversation only makes sense.

To learn more about custom software development and how a custom web application can benefit your business, sign up today for our free guide.

Want to develop your custom software with Team Awesome? Request a consultation with us today.