Now then. One of the most contentious parts of any project is the change request process. Sometimes it can feel like an update should be considered a bug, or sometimes it can feel like the cost should’ve been included in the original cost, right?

We thought it would be valuable to explain the process that goes into quoting and working on design and development change requests, so you have a clearer understanding of why work takes the time it does, and why quotes are costed as they are!

We’ve noted below in bullet points what goes into quoting CRs and the different process for carrying out an out-of-scope change.. 

How we quote for Change Requests

  • You, the client, submits a change request (e.g. ‘Actually, can we have a new section on that page highlighting the founder journey?’)
  • Your Studio Graphene contact receives this request, and then translates this into a working requirement by interrogating the request (‘Should the section feature an image? How much content? Should it be CMS editable? Will it link anywhere?’)
  • They then send this to both the design and development teams, to assess and quote
  • A Studio Graphene designer assesses the necessary design changes and estimates the effort required to produce the updated designs and / or assets required. They also consider whether this amendment would have any knock-on impact to the design as a whole, and whether any broader considerations are needed.
  • A Studio Graphene developer works to understand the working requirements, and estimates the effort required to make the change (this will include front end development, back end development, quality assurance testing, deployment requirements and any required database architecture.) 
  • Your Studio Graphene PM then consolidates these requirements, answers any queries raised by the team, translates the effort requirements into commercials, looks at resource availability to give you an idea of timelines, writes this up and returns it to you, the client


How we work on Change Requests

So! You’ve approved the cost and timings involved for the change. How exciting. But what happens next…?

  • You, the client, approves the change
  • Your Studio Graphene PM confirms and writes the functional requirements, and arranges a quick discussion between the relevant team members to brief the change in
  • The wider Studio Graphene team (as appropriate) meet to receive the brief, and discuss the change to discuss the change. This often includes 4 or more members of the team.
  • A Studio Graphene designer carries out necessary design work, including bringing all previous designs into line with the new design
  • The Studio Graphene PM reviews the design, checks it matches the original requirements and then either feeds back to the designer to make amendments, or sends to the client for approval
  • You, the client, review the design change and either signs it off, or feeds back (which then triggers the designer working on the designs for a second iteration, before being reviewed by the PM before coming over to you, the client, again)
  • Once the designs are signed off, the Studio Graphene PM hands over the design files, specification notes and any required assets to the development team
  • The Studio Graphene developer then... 
    • Takes a pull of the Git repository 
    • Creates a code branch for this particular change
    • Works on the branch, and, when they’re happy the task is complete, submits the branch to a Quality Assurance Tester
    • The QA gives feedback to the developer on the update
    • The developer incorporates the feedback, as required and submits to the QA again for testing
    • Once the QA approves the chqwange the developer then makes a merge request
    • A Technical Architect will then approve the code change and deals with any merge conflict
    • Once the branch is merged with the main code, the QA will review the update again and - all being well - will approve the change for go live 
    • This staging instance is then sent to the Studio Graphene PM who double-checks the update and sends to the client for final approval or - if there are any issues - sends the update back to the developer
    • Once you, the client, approves the change the developer will then deploy this change into the live (production) environment

As you can see, not only does it take time to sensibly estimate these changes, the actual work required to make changes that are out of the initial scope is extensive too. (Even writing that process down felt like a reasonable amount of effort…!)

So, practically, what can you (as a client) do to make the process smoother, and more cost-effective?

The one big practical consideration you could make is grouping updates into ‘chunks’ of work.

Lots of the steps in the process above have to be worked through regardless of whether we’re making one minor change, or several larger changes so - with this in mind - we would really encourage you to group up changes where possible to complete in one go, as this will increase efficiency (as opposed to completing several changes in succession).

So that’s it! Change completed.