Here at Essex County Council (ECC) the platforms that we use are the cornerstone of information and function. The platforms enable our staff to do their jobs and for residents they become a vital source of relevant information to interact with.
As a constantly evolving space ECC wants to ensure that the platforms that are used are fit for purpose and works with our Data, Digital and Technology strategy.
To this end we wanted to run a collaborative platforms discovery to understand the options in adopting platforms as services, so that ECC can improve the ability to deliver digital services including but not limited to:
- How ECC might move away from the current inflexible systems to a modern technology stack and infrastructure;
- How ECC could create digital solutions and services quickly, and iterate them easily and continuously so that ECC can meet our users’ needs in a scalable way;
- How to simplify and consolidate ECC’s technical architecture and benefit from supplier competition in the open-source space; and
- Ensuring compliance with continuously evolving accessibility standards.
After a successful procurement phase, we selected a supplier who understands our needs and has the background that we need, so that we are confident the discovery could be delivered in scope, on time and with the insights needed to make informed decisions about our future in the realms of digital platforms.
Working in the open we have been producing week notes that provide stakeholders and interested parties the information they need to be informed about the work we are doing, so that they feel engaged and part of the journey.
------------------------------------------------------------------------------------------------------------------------
Weeknotes 10 - w/e 4th June 2021 & 28th May 2021
We held off sending the final week notes due to the bank holiday, and so that we could include notes on our final show & tell.
What we did this week (and last week)
We have now concluded the large bulk of our 10-week discovery. To get there, our final sprint involved the team coming together to consolidate our research, refine our hypotheses and organise all our discovery into an outcomes-focused presentation.
Putting together the final presentation
To get to this point, the team worked collaboratively to put together a final presentation, which was targeted at the specific audience we would be delivering to. Our lives were made infinitely easier as, throughout the discovery, we used a ‘living deck’, which is a presentation (google/ppt.) that the team would constantly drop updates on our progress into, including our weekly show & tells. This way, all we had to do was figure out the narrative we wanted to tell, and which slides we would need to adapt to communicate it best.
Delivering our findings
We wanted to tell the story of our discovery in as simple and as clear a way as possible:
- At the outset, the council had several assumptions about what the issues are.
- In the kick-off stage, we boiled these down to 3 core challenges that needed to be resolved.
- Through our discovery, we researched those challenges into as great a depth as made sense and then worked together to produce some potential opportunities, which we constantly refined, prioritised, and then turned into hypotheses that we thought would make strong candidates for tests in an alpha.
The slide below best demonstrates the connection between our problems and opportunities (which became hypotheses). You can watch the full presentation and Q&A, here If you would like to receive the full deck from the presentation do let us know.
Reflecting on the project through a final retro
To reflect on the project, Greg took the team through a final, Muppet themed, retro. Beyond the joy of doing our best muppet impressions came a strong discussion around what has gone well during this discovery, what hasn’t gone so well, how we move forward and what they key learnings from discovery are.
We’re proud of what we have achieved so far but are also fully aware that the hard work starts now. We need to communicate our hypotheses around ECC, to the many stakeholders who will be impacted by our work, as well as start testing and trialling our ideas in an alpha as soon as possible.
Planning next steps (spoiler: another sprint)
As aforementioned, the next steps are now the priority of the platform project team. Planning the next steps will come in several stages. First, we need to map out our journey to alpha, ensuring we’re speaking to the right people and prioritising the right, and riskiest, hypotheses. We also need to ensure there isn’t any significant lag between our discovery and any alpha.
To get started early, we have included one additional sprint to our project where we will find one small, high risk, area from one of our opportunities which we can improve and test. Our hope is that with a successful early test, we can build a stronger business case to move forward with.
What’s next
We will continue to keep you in the loop with how we are progressing and have no intention of allowing our hypotheses to dilute into ‘nice-to-haves’. If you would like to see any of our frameworks, presentations or supporting documents, or if you have any other questions or comments, you’re more than welcome to contact us direct.
Who is on the team this week?
Greg (delivery manager, full time) , Ert (head of product, part time), Oliver (senior product manager, full time), Lorraine (business analyst, full time), Stephen S (technical architect, full time), Milo (senior developer, full time), Stu (principal technologist, 2 days a week), Stephen P (senior applications analyst, ad hoc)
------------------------------------------------------------------------------------------------------------------------
Weeknotes 9 - w/e 21st May 2021
To recap, last week we finished our penultimate fourth sprint for our discovery, entering the fifth and final sprint. Sprint 4 was all about listing and prioritising our solutions using various prioritisation methodologies, such as MoSCOW, through numerous team workshops.
What we did this week
This week our objective was to take all our opportunities that we felt confident could amount to a few tests through an Alpha and begin to develop the hypotheses that we would need to test.
When we kicked off sprint 4, we were confident that we had enough evidence to move forward but then found ourselves still working into greater detail about each solution we had identified through previous workshops. It felt like we were getting too deep into solutioning so, to kick off the first workshop of this week, we revisited the GDS Discovery Framework to clarify at what point we needed to move on from ideas and into developing hypotheses that we could test. We realised that this was the next important step.
Building hypotheses for Alpha
We wanted to ensure that the hypotheses we developed were as robust as the research, ideation and prioritisation that got us to this point. We also wanted to ensure that whatever we produced would be well defined and measurable to ensure that we could prove success. We worked through another workshop, using the Conversion hypothesis framework (below) which gave us the outline for hypotheses that could provide far more detail. This framework was particularly effective for us as it puts the data (both qual and quant) first, which we have plenty of. It also separates the levers and concepts and validates the success criteria for our tests up front.
It took a few workshops to turn all the potential opportunities into hypotheses, but we now have a strong collection to move forward - all of which ladder up to the initial challenges we identified. We will share these and explore in detail in our next show & tell.
Final sprint planning
As the hypotheses was quite a large piece of work and required a lot of team effort, it bled slightly into the start of our fifth and final sprint. However, on Wednesday we entered final sprint planning and explored what outputs would be required to close out our discovery. We explored who our main stakeholders in the project will be going forward, how we need to communicate our findings and where to list thing that were out of scope for this discovery but should be looked at. Below is our sprint goal.
Our focus is to present a summary and report of our findings as well as defining what the 'follow on' work will be. We believe this will effectively communicate the challenges, give the organisation confidence in our 'solutions' and allow us to move on to the next stage. This will be confirmed when we have 'solutions' identified and written up with highest priority recommendations identified and this has been presented to and understood by key stakeholders.
Talking to Stockport
We ended the week by having a great conversation with the Product Owner and Head of Technology for stockport.gov. This was a vital conversation as the essex.gov site was built off the back of the Stockport open-source website several years ago and so we wanted to see the direction in which they took their platform and if we could learn anything from their experiences.
The conversation boiled down to the ‘desire’ of leadership and how that impacts the pace of progress on your digital products. They are slightly further ahead than us in terms of our challenges (they also only have 30 microsites all sitting on WordPress), but are experiencing a period of malaise without strong direction and support to move further, faster, from their leadership - which we believe we have. Below are some notes we took to summarise our chat:
- It’s important to decide how the council want to operate. 4-5 years ago focus was to build in house skills/capability. Senior leaders changed so support has lessened.
- Buying something still needs expertise to integrate, you just “shift focus of the work”.
- Suppliers “have you over a barrel” when you’re in a contract because you’re held to their roadmap and priorities
- In house is better to make changes quicker and easier, you own the changes so can make them when needed
- SP.gov was seen as a ‘source of truth’ during Covid.
- Microsites imply the council’s brand is disposable - Analogy: the iPod department wouldn’t create a microsite away from Apple.com
- Accessibility is better served having it on Stockport.gov.
- People want to compare the in-house solution to a commercial product.
It was clear that there was a lot we could learn from each other and so we have made plans to cultivate an ongoing relationship for support and shared learning.
Next Steps
As this is our final sprint, we will be delivering our final findings to everyone soon. So, watch this space! :), Any questions or comments, or if you’re interested in how we use agile/ product methods to prioritise, you’re more than welcome to contact Ert, Greg or Oliver.
Who is on the team this week?
Greg (delivery manager, full time), Ert (head of product, part time), Oliver (senior product manager, full time), Lorraine (business analyst, full time), Stephen S (technical architect, full time), Milo (senior developer, full time), Stu (principal technologist, 2 days a week), Stephen P (senior applications analyst, ad hoc)
------------------------------------------------------------------------------------------------------------------------
Weeknotes 8 - w/e 14th May 2021
To recap, our goal for this sprint (sprint 4) is to list and prioritise opportunities and explore solutions. We believe this will enable us to recommend which solution(s) to take to alpha. This will be confirmed when we feel the output is good enough to present opportunities with solutions to stakeholders.
This sprint is about identifying and prioritising our opportunities, as a team, through several workshops.
What we did this week
This week has been all about turning our research from sprints 0-3 into a list of prioritised opportunities, which we can then refine and build on as recommended solutions.
Prioritising opportunities
Last week we held a workshop which, by taking key insights from our research stages, presented us with a list of possible opportunities which we could take forward to alpha. To continue this work, on Monday, we held a prioritisation workshop to try and understand which of our 7 opportunities was most important and which would be out of scope for this discovery.
To achieve this, we explored several potential trade-offs. We looked at importance vs urgency to try and find the opportunities which were most urgent and most important. Those that were most urgent and most important were moved up the list of priorities. We then looked at which opportunities would present the most value to the organisation vs how much effort it would require to complete, and, subsequently, which opportunities would provide the most benefit to residents vs the effort required. Once we worked our way through these workshops, we comprised a high-level prioritised list of opportunities.
We presented our findings at our S&T and received some very helpful feedback from Ert and others who told us that, though we managed to prioritise, our highlighted opportunities were missing some of the technical aspects of our research that needed to be brought to light, and that we needed to make the most of our technical experts from MadeTech while in discovery.
Mid-week sprint review
Given this is a pivotal and complicated sprint, we set some time aside, at the mid-way point of the sprint, to review where we are so far and adjust our plans if needed. Taking on board the feedback from the S&T, we decided to go back through our workshops, adding in additional insights which prompted more technical answers, and updated our prioritisation work based on what we uncovered. Therefore, while our potential opportunities remained broadly the same, the evidence base and the solutions that will come from them will be stronger and have both technical and process challenges fully considered.
Determining solution criteria with MoSCOW
Once we felt comfortable with how we got to our opportunities, we then set up another workshop to prioritise what would be the most important aspects within each one. We did this through using the MoSCOW technique (M for Must Have, S for Should Have, C for Could Have and W for Won’t Have This Time). As a team we identified all of the integral aspects of each solution, and then consolidated all of our answers to higher level themes. Below is an example of how we MoSCOW’d one potential opportunity.
Next Steps
We still have quite a bit of work to do in terms of prioritising these opportunities and getting into a level of detail where we are confident we are taking forward the right ones. We also need to understand the dependencies across these opportunities as our challenges (too many microsites and the inability to change essex.gov) are not separate but very much linked, and so our solutions are likely to be, too. We will continue this next week with further workshops.
Any questions or comments, or if you’re interested in how we use agile/ product methods to prioritise, you’re more than welcome to contact Ert, Greg or Oliver.
Who is on the team this week?
Greg (delivery manager, full time), Ert (head of product, part time), Oliver (senior product manager, full time), Lorraine (business analyst, full time), Stephen S (technical architect, full time), Milo (senior developer, full time), Stu (principal technologist, 2 days a week), Stephen P (senior applications analyst, ad hoc)
------------------------------------------------------------------------------------------------------------------------
Weeknotes 7 - w/e 7th May 2021
In our previous sprint (sprint 3), we presented the main findings of our research stage of discovery. This involved an exercise where we categorised the 90+ microsites at ECC in terms of complexity and ease of migration. We also presented our findings on Essex.gov.uk after digging a bit deeper, demonstrating how the site is built in terms of technical and content architecture.
What we did this week
Now that we believe we have enough research and evidence from discovery, sprint 4, which started this week, is to target the solutions and the opportunities that our findings have led us to.
Sprint 4
Sprint 4 is a vital one for this discovery as we are at the stage where we now need to build the case for how we may move these challenges into potential solutions. To kick off, we held an iteration planning session, returning to our roadmap to see what steps we would need to take in the next two weeks to feel confident that have the right solutions to the challenges we identified. To ensure we were moving in the right direction we started with a clear sprint goal which stated that:
- that the focus of our sprint is to list and prioritise opportunities and explore solutions.
- We believe this will enable us to recommend which solution(s) to take to alpha.
- This will be confirmed when: we feel the output is good enough to present opportunities with solutions to stakeholders.
For us to all feel confident that we are producing the right answers to the challenges, a large part of this sprint will involve collaborative working through a series of workshop which will help us:
- List the opportunities identified from our research
- Prioritise those opportunities
- Determine the solution criteria for the top opportunities
- Brainstorm all the solutions and look for any convergence
Workshop 1: Listing opportunities
We held the first workshop today (Friday 7 May) to collaboratively list all the possible opportunities identified from discovery. We took the key insights from our research stage and conversations across the council, turned them into questions, and together thought through the ideas and opportunities we think may resolve them. We then carried out an exercise where each member of the team challenged the potential opportunities by playing the role of either pessimist, optimist, or realist. This exercise enabled us to challenge our assumptions and avoid any team biases taking us down potentially wrong routes.
Now that we have listed our opportunities (we will share these in our next show & tell), next week we will begin the process of prioritising these opportunities and determining the criteria for which ones we hope to take forward.
Star Wars Retro
For Star Wars day (may the 4th be with you), our amazing delivery manager, Greg Holt, put together a Star Wars themed retro for our previous sprint. Great fun and a model for all delivery managers! You can have a look at the Miro board yourself - https://twitter.com/gh0lt/status/1389622834666876931?s=20
Next Steps
Next week will be the continuation of our exploration into potential solutions, starting with the prioritisation of opportunities we identified today. We will share our progress in our next show and tell.
Any questions or comments, you’re more than welcome to get in touch.
Who's on the team this week?
Greg (delivery manager, full time), Ert (head of product, part time), Oliver (senior product manager, full time), Lorraine (business analyst, full time), Stephen S (technical architect, full time), Milo (senior developer, full time), Stu (principal technologist, 2 days a week), Stephen P (senior applications analyst, ad hoc)
------------------------------------------------------------------------------------------------------------------------
Weeknotes 6 - w/e 30th April 2021
What we did this week
Our work has predominantly been focused on two key areas: Categorising our microsites to provide a clear understanding of the work involved in migrating to a more sustainable solution, as well as digging deeper into essex.gov.uk to gain a stronger understanding of the code and complexity of the site.
Understanding essex.gov.uk
Our aim for this sprint is to map how information and services across essex.gov is accessed by residents’. This required us to both understand the architecture of the site (what types of pages exist on the site, what is the content, do they have forms, do they manage transactions, etc) and to get a closer look at the code. To achieve this, we began by exploring each section of the site in detail, looking at what it can do, what it can’t, and the technologies that support it. We turned this into a simple map of the site architecture and the supporting technologies. To understand how this site is causing challenges to users, we created personas that detail Essex.gov users needs, fears, aspirations which helps us understand, at a high level, and the customer journey and pain paints for each interaction a user may have with our site.
We are also currently working on user stories for the functionality currently supplied by 3rd party providers on essex.gov.uk and the microsites, such as Granicus and Capita who provide certain services, and this will be used for the next sprint where we start to test potential solutions. Beyond the content architecture, we also reviewed the Essex.gov.uk code in detail to understand the technical architecture in relation to key journeys and common patterns. This helps us to understand what it is that essex.gov.uk does do and could do within reason from a technical perspective. We spun up Contentful, the Essex content management system (CMS) to see what it is capable of and possible blockers with this choice of CMS.
We built a data-flow diagram for simple page requests to essex.gov.uk. We documented and checked what code is being used, not used and what would be useful in the future, documenting all of this into what is known as a "Technical Path" document. We also uncovered that there are some further questions about the code we are using from Stockport Council, and so we will be hoping to meet with their digital team to investigate further, and to share ideas.
Categorising microsites
Our aim for this Sprint was also to use our, now segmented, list of the 90-plus microsites and start to unearth which sites could be easily migrated and which would be more difficult.
We categorised these microsites by 2 key criteria.
- Whether there is high or low technical risk
- The ease of replicating the site on a shared platform (ie; is it easy to move, or not)
We found that :
- 1/4 of websites are in the low risk and easy to migrate category. These are sites that are mainly content, so have basic features, mainly being built on WordPress.
- 1/8 sites are high risk but, similarly, easy to migrate, these are mainly core delivery sites and predominantly built on the Umbraco CMS.
- Finally, we unearthed around 10 sites that are high risk but will also be difficult to migrate. These are core delivery sites that are built on bespoke/ non-standard technologies.
Now that we have this strong picture we feel comfortable moving into sprint 4 where we will begin targeting opportunities and exploring solutions.
Refocusing sprint 3
It is worth mentioning that we have also spent some time this week refocusing our sprint 3 as we felt that, though we had a well-defined sprint goal, we needed to spend some additional time looking at the pieces of work required to achieve this goal. Through a number of meetings, we now feel confident that our sprint 3 is positioned well to continue delivering on our discovery goal, with confidence that we will have gathered enough evidence to move, comfortably, into sprint 4.
Next steps
This week and until the end of this sprint (ending on 5 May) we will continue to dig into essex.gov.uk, which we will explore in our show and tell next week.
Who is on the team this week
Greg (delivery manager, full time), Ert (head of product, part time), Oliver (senior product manager, full time), Lorraine (business analyst, full time), Stephen S (technical architect, full time), Milo (senior developer, full time), Stu (principal technologist, 2 days a week), Stephen P (senior applications analyst, ad hoc).
------------------------------------------------------------------------------------------------------------------------
Weeknotes 5 - w/e 23rd April 2021
Firstly, lets formally introduce Oliver the very recently joined Senior Product Manager in the P&D team. he will be working exclusively on the platforms project and writing the notes going forward.
What we did this week
This week we made really good progress on our analysis of the too many microsites on too many platforms problem.
Microsites segmentation
Our aim for this Sprint is to come away with a segmentation of the 90-plus websites we’ve got in terms of:
- Whether they carry a statutory duty or not
- What their technical risk score is
- How easy it would be to replicate the site on a different platform
We’ve had to drop our inquiries around budgets allocated to these sites and the type of the supplier they are built by, because the amount of effort required to capture all this information is disproportionately high, and at times the information just does not exist.
Once we finish this segmentation, we believe that we can point to a more informed roadmap of migration for some of them onto the new platform. The criteria mentioned above will ensure we concentrate our immediate efforts onto the sites that will provide most value to our users, as well as fixing the technical risk that is currently costing us a lot of time and effort.
We are now very close to having the full picture of this segmentation. We need a couple of more data points to add to our master spreadsheet, and we will then share our prioritisation with you in our next Show and Tell, scheduled for Wednesday, 28 April, 2-3pm (link to show and tell)
Stakeholder interviews
We had three stakeholder interviews this week with our colleagues in Tech Services. These have been very helpful in identifying the constraints and opportunities of how we can manage our products and services in the near future.
From these interviews, we concluded that:
- Where there is a good fit between our needs and a commercial product, we will look to try these options out, as long as the financial model and the practical details are favourable
- Where there is a more complex need for our residents or businesses or our internal teams, we might also choose to get help from an external supplier working with our internal teams to develop solutions collectively. This will enable us to use our design expertise, combined with modern software development practices and continuous improvement and delivery.
The website segmentation work we’ve been doing will answer which of our sites can fall under the first category, whilst some others might point to the second model.
The other important point is that we know we have to do something about the Schools and Infolink sites quite soon. This is informed by some of the technical risk we discussed, as well as some commercial constraints presenting us real opportunities to rethink these sites.
Essex.gov.uk Code
Colleagues in Tech Services have been really helpful in providing us access to the essex.gov.uk codebase. We’ll now start to run some concepts and tests on the code so that we can confidently make an assessment on the actual potential of the website. We know there are limitations to what the website can do, but we will check whether there is anything in the actual code that causes this, or whether it’s our implementation of Contentful.
Roadmapping
We have also spent some time this week revisiting our core goals for the whole of discovery, highlighting core project milestones and sprint deliverables. The exercise, now a clear roadmap, is helping us focus our sprints, ensuring our work addresses the key challenges. We will share the roadmap in the next show & tell.
Next steps
We’re going to finish the website segmentation and present back the results on Wednesday in the Service Transformation show and tell.
Who is on the team this week
Greg (delivery manager, full time), Ert (head of product, part time), Oliver (senior product manager, full time), Lorraine (business analyst, full time), Stephen S (technical architect, full time), Milo (senior developer, full time), Stu (principal technologist, 2 days a week), Stephen P (senior applications analyst, ad hoc)
------------------------------------------------------------------------------------------------------------------------
Weeknotes 4 - w/e 16th April 2021
What we did this week
This week was a slow one for the project as half of the team members were out as a result of a training commitment. That naturally impacted the amount of work and analysis we could continue doing. Fortunately, as of today, we are back on full capacity with the team. That means we could only meaningfully progress one of our problem areas, and this week we concentrated on having too many sites on too many platforms problem. In the last weeknotes, we talked about investigating the “technical risk” that exist on our microsites. You might remember that we define that risk as:
- Having serious security risks
- Having unnecessarily locked themselves into a particular technology
- Their commercial contracts not accounting for support or changes
- Built by suppliers who are not responsive or who are too small to respond to our change requests
- Having unnecessarily complicated their features/tech through bespoke development
- Not having any google analytics or other web metrics implemented
- Where they fall on the accessibility range added to technical risk,
We are also looking at if the website fulfils a statutory duty for the council, and how much roughly we are spending on it each year.
Based on these criteria, we’re looking at each of our sites and coming up with a combined score of risk and suitability. We are still carrying out this analysis and will have more to report on next week. We also conducted a research session with a Tech Services Business Analyst, who was able to talk us through how business teams decide on what features they want on their sites, how Tech Services inform the build of the website through non-functional requirements, and sometimes domain ownership and procurement.
Our colleagues in Tech Services are doing a fantastic job in managing the volume of these website asks from anon-functional requirements perspective, but they do not currently have plans to question whether the set of features the business teams would like are the right ones for the problems they want to solve. Currently it’s the Service Transformation and specifically the Product and Delivery team that have the conversation with business teams whether the website is the right solution to the business problem, and if so, what’s the right set of features that might be needed for the users of the website. We’re keen to continue with this division of labour, but this process needs to be formally established and published on the intranet and our digital manual.
Lastly, we’ve been also working to get an accurate picture of how much our microsites are costing us. Unfortunately, there is no single source of truth across ECC where we can query the financial data and come away with a precise figure. That’s why we’ve been working with our colleagues in Procurement who have recently done a spend analysis and provided us a dataset for generic IT spend. Based on that dataset, we are able to make some assumptions. Based on a sample of 20 websites listed there, we can see the average website spend is between 10-15k per year. If that’s the case, then the total spend on approximately 90 sites are quite high. We’re looking at some other sources of information to verify these numbers, and we’re hoping to write about these next week.
Next steps
Who is on the team this week
------------------------------------------------------------------------------------------------------------------------
Weeknotes 3 - w/e 9th April 202
Problems we are trying to solve
- At ECC, we’ve got too many websites, built by many different parties, run on many different technologies and platforms.
- We are not able to iterate on essex.gov.uk because of: a. lack of domain knowledge b. lack of modern and continuous deployment/integration pipelines
- We are not able to launch new digital services that are accessible and meeting the needs of our residents and businesses.
Question to answer in this discovery:
- How might we simply the management of our websites?
- How might we turn essex.gov.uk into a modern web-facing product that we can continuously iterate on based on user and business needs?
- How might we deliver common technological components that help us create new and accessible digital services quickly and efficiently?
What we did this week
- Have serious security risks.
- Have unnecessarily locked themselves into a particular technology.
- Their commercial contracts have not accounted for support or changes.
- Built by suppliers who are not responsive or who are too small to respond to our change requests.
- Have unnecessarily complicated their features/tech through bespoke development.
- Do not have any google analytics or other web metrics implemented.
- Where they fall on the accessibility range.
- whether any of these sites are carrying out a statutory duty for the council
- whether we have any indication that they are performing well for our residents and businesses
- how much they cost annually and how much we spend on introducing change to them (cost/timeof change)
Next steps: We’ll start mapping all our sites according to this criteria and will aim to come away with a prioritisation framework for the future stages.
We also need more information on how we currently decide on the set of features for any microsite. We’re scheduling interviews with a few tech business partners to get some clarity on that, and we’d like to thank to all who’ve already volunteered to meet with us next week.
Not being able to iterate on essex.gov.uk.
Our current hypothesis is that:
“If we take the current code, add some new tests to it, and re-platform it in a way that a supplier, or a blend of a specialists and an in-house team of developers can continuously deploy code to it,
Then we can make essex.gov.uk meet different business and user needs by iterating on it,
So that we can reduce the need to create new sites, and we will be making financial and operational savings ”
In order to test our hypothesis, we’re currently making arrangements for the team to access the full code base of essex.gov.uk. We’re going to run a copy of the site locally and hope to test a few concepts on it, such as how much it’ll take a non-specialised web developer to understand the code and make changes to it.
We are also pulling together a site map, with handover points between essex.gov.uk and different products across different services. Next steps: We have stakeholder interviews with the senior leadership team in Tech Services, to understand opportunities and constraints around ownership of essex.gov.uk and what capabilities (externally and internally) we might need going forward.
What’s next
How can you help?
Who is on the team this week
------------------------------------------------------------------------------------------------------------------------
Weeknotes 2 - w/e 1st April
What problems we are trying to solve
- At ECC, we’ve got too many websites, built by many different parties, run on many different technologies and platforms.
- We are not able to iterate on essex.gov.uk because of: a. lack of domain knowledge b. lack of modern and continuous deployment/integration pipelines
- We are not able to launch new digital services that are accessible and meeting the needs of our residents and businesses.
- How might we simply the management of our websites?
- How might we turn essex.gov.uk into a modern web-facing product that we can continuously iterate on based on user and business needs?
- How might we deliver common technological components that help us create new and accessible digital services quickly and efficiently?
What we did this week
- Business teams are not confident in who to contactor which route to procurement to follow when they need a website. It is not that easy to get the right information from the intranet currently.
- When they are clear on the internal process, job roles and allocation of responsibilities are not clear
- By going to an external delivery partner, business teams often miss the opportunity to get advice from either Service Transformation or Tech Services. This later causes sites launching with accessibility issues, not having the right metrics set up to track user behaviour, not complying with GDPR rules.
- If the person who commissioned the website leaves their role in ECC, the websites are sometimes left to their own devices, causing problems of ownership.
- Business teams are also not able to get the assurance they need whether a website is the right solution for their and their users’ needs. This again alludes to the need of defining a proper process to support our business teams with technology and product thinking. In addition to the interviews, we also identified which of our sites are receiving the highest traffic. We’ll analyse what features these sites are built with next week.
Next steps: We still need more interviews to understand what features our business teams have commissioned on their websites, and why they thought they would be the right ones. We’ve reached out to the Senior Business Partners in Tech Services who will now put forward Business Partners who have previously worked on a website procurement / build project. These conversations will help us understand how we translate our user and business needs into feature requirements on our websites.
What's Next
Who is on the team this week
------------------------------------------------------------------------------------------------------------------------
Weeknotes 1 - w/e 26th March 2021
What problems we are trying to solve
- At ECC, we’ve got too many websites, built by many different parties, run on many different technologies and platforms. This means we have a complex web estate to manage and influence. We are spending an unnecessarily high amount of money and organisational effort on these websites.
- We are not able to iterate on essex.gov.uk because of: Lack of domain knowledge and Lack of modern and continuous deployment/integration pipelines. This means, at times, we cannot meet user and business needs by creating new pages or templates of essex.gov.uk. This then leads to new microsites being created, adding further complexity to our web estate. We are also not able to meet the ever changing needs of our residents and businesses as quickly as we’d like.
- We are not able to launch new digital services that are accessible and meeting the needs of our residents and businesses. This is because some of our current solutions are not as flexible as we’d like, or are inaccessible. This then results in manual workarounds, increased contact coming into the contact centre, leaving us with less time to spare for our residents with more complex needs.
Question to answer in this discovery:
- How might we simply the management of our websites?
- How might we turn essex.gov.uk into a modern web-facing product that we can continuously iterate on based on user and business needs?
- How might we deliver common technological components that help us create new and accessible digital services quickly and efficiently?
What we did this week
We spent our first week to form a joint team between ECC and MadeTech, our delivery partners. From ECC, we’ve got a user researcher (Rich), a product specialist (Ert), a delivery manager (Greg), and a senior application analyst (Stephen P). From MadeTech we have a business analyst (Lorraine), a technical architect (Stephen S), a senior developer (Milo), and a senior technologist (Stu). We are working together collaboratively 5 days a week, so almost everyone in the project team is full time on this piece of work. This has proved to accelerate our delivery pace significantly
After agreeing our ways of working and sorting the logistical details of forming a join team remotely, we held a couple of workshops to set our goals and priorities for the next two weeks. We know that all three of our problems mentioned above need to be solved, but equally we need to pick a place to start and build on our knowledge. That’s why we as the project team decided to focus on the “too many websites” and “not able to iterate on essex.gov.uk” problems for the next two weeks.
- Since we have a dedicated user researcher in our team, we could immediately start recruiting some of our microsite owners from ECC for our research. We need to understand what they need from their sites, how they went about procuring them in the past, and what their experience have been like.
- Essex.gov.uk is our flagship product that has immense potential, but we are not able to capitalise on that within our current boundaries. Our hypothesis is that if we can start iterating on essex.gov.uk, this will solve some of our “too many websites” problems.
- Both of these focus points are well defined that the team is able to cope with the scope, whereas the third problem mentioned above around digital services and transactions are potentially too big, and need a bit more scoping work.
Leave a comment