The Queen’s Awards for Enterprise are some of the most prestigious business awards in the country. They’re highly competitive, with a large number of applicants and a rigorous application process. So when we were selected to rebuild their software, we were very excited.
However, every web project has its pressures and its constraints. For the Queen’s Awards for Enterprise project we completed earlier this year, the challenge was a very tight deadline.
Following the GDS Service Design Manual, and using Agile methodology throughout, we delivered an end-to-end digital service that met user needs in time for the 2015 award cycle. We did this while preserving core features and functionality, introducing new ones and limiting risk at all stages of the build.
In this blog post, we’re going to have a look at some of the methods our Delivery Manager used to guide the project to success.
Use prioritisation to your advantage.
In order to ensure an agile delivery, you need to be pragmatic when making decisions around project scope, using evidence that you’ve gathered in the Discovery phase and through user testing.
With QAE, we started by using the findings from Discovery and the early stages of the Alpha to establish which features would create the most value for both public users and the Queen’s Awards for Enterprise team.
1. Prioritise features that create the most value for users.
For example, our research showed that many users would get a long way through the application process before realising that they weren’t eligible for any of the awards (which meant they would waste their time filling out the application).
So, in the new service, we introduced eligibility questionnaire as the first step in the application process. The objective was not only to ensure that ineligible applicants wouldn’t have their time wasted but also that assessors do not have to evaluate applications that do not meet the basic criteria.
Prioritise the development of features that will be used first.
This is particularly useful if you’re working to a tight deadline, as we were for most of the QAE project. Our team gave high priority to features – like the eligibility questionnaire and the application form itself – that would be used early on in the application cycle.
On the other hand, something like the assessment related features were less important to the early success of the service. So we delayed the build of those functionalities until the Beta phase of the project.
The best way to engage your clients is through constant communication.
Agile methodologies call for high project visibility, and for clients to generally be very involved in the project. This means that for an Agile delivery to be successful, it’s important to build constant formal and informal communication into your processes.
Sprint meetings for regular, formal communication.
Throughout the entire QAE project, we held formal sprint meetings with the QAE Service Manager, giving her the opportunity to see the project progress, test the software and make important project decisions together with our team.
Depending of the phase we were in, different members of the Bit Zesty team would attend these meetings alongside the Delivery Manager. For example, during the Discovery and Alpha, it would be the research and UX teams, whilst as we moved through Beta our technical staff became more heavily involved.
Engage with Government Digital Services teams.
On top of these regular meetings, we also had a number of one-offs. Our technical team met Government Digital Services (GDS) team during the Beta phase to ensure that the application was up to the Government’s data security standards.
We also met with another team of GDS to check the content for the Queen’s Awards for Enterprise marketing site met their content guidelines.
To meet Assisted Digital requirements, we first discussed with the QAE team, the numbers of Assisted Digital users they had received in the past, and would expect on the new service (not many). Then we created a workaround (a set of offline measures) in collaboration with QAE team, which got approved by GDS during the Beta assessment.
Use modern tools to keep the project (and the product) visible.
We used the latest collaboration and project management tools to maintain a virtual, always up-to-date status board of the project for the QAE team to view, and gave them access to the application itself on the staging environment so that they could access it at any time.
The aim here was to make sure that we could communicate effectively with them, passing information back and forth, and making it easy for their Service Manager to keep track on the progress on daily basis.
Constant communication builds a shared vision within the team.
Constant communication – whether in the form of email, IMs, daily standups, phase retrospectives or sprint meetings – keeps your project team working together as a single unit. This communication should be in addition to other project documentation – in the form of research insights, user stories, wireframes, and flowcharts – that can be shared across the whole team.
For a project like QAE, which relied so heavily on implementing the results of user testing, having a shared vision of the service was essential to our success. Plenty of open communication channels between the development, content design and UX teams meant that all of our team members were able to see the project’s bigger picture, and where their own work fitted in.
This fast communication was also crucial to achieving working software within the first week of the Alpha, and helped us stay on top of the QAE project’s tight deadline.
Agile doesn’t mean you should stop planning. It means being ready for your plans to change.
Compared to traditional ‘Waterfall’ methodologies, where most projects open with a long period of setting out inflexible lists of features, timelines and goals, it’s often said that Agile methodologies don’t encourage planning. But the best Agile projects are far from unplanned.
For the Queen’s Awards for Enterprise project, planning began in our very first meeting with their Service Manager, and continued throughout all the phases of the project. In every sprint meeting, the backlog or features was re-prioritised and goals and outcomes for the next week were planned.
Plan for the phase you’re in.
The QAE Alpha phase was also planned so we could begin user testing as soon as possible, with the whole team working on a stripped down fully-working version of the software based on only one of the four QAE application forms. The structure of this application was then duplicated, and the content team was able to work on the copy of all four forms based on the results of the initial testing.
Throughout the Beta phase, the team began working in lock-step, so it was our Delivery Manager’s job to make sure that we stayed in sync. So whilst the UX team was gathering feedback on one part of the software – say, the application forms – the development team would be building features from the administrative back end of the system, ready to be tested next, and the design team would be making improvements to the marketing site based on the results of the previous usability tests.
Manage your delivery.
Our whole team was able to work at full capacity for the entirety of the QAE project because we stayed focused on delivery.
We had our Delivery Manager working constantly to keep communication channels open, remove obstacles and plan each step of the project.
The QAE web application is currently in the Public Beta on GOV.UK.
Do you need help creating or improving a digital service? Contact Matthew, our Technical Director, today on +44 207 125 0160 or drop him a line on [email protected] for a free consultation.
