Shortly after graduating, I found myself an internship with miggle, a UK-based Web development specialist that uses Drupal exclusively.
As a web production assistant, my primary role required me to look after the latter stages of a new website rebuild for an organization in the education sector.
The Centre for Literacy in Primary Education (CLPE) is a charity that researches and promotes the importance of good quality literacy teaching for primary age children. It provides courses and resources for teachers across the country. Its Web content was once split across separate sites, each hosting information for a particular CLPE service – for example a subscription-accessed collection of carefully selected texts and accompanying teaching sequences.
The new website, known internally as “One Site,” was intended to bring all of this content into one place.
As we approached the time to go live, I was in touch with the marketing department at CLPE almost every day. We continued testing on a staging site whilst I wrote detailed instructions for a large spectrum of content management processes into a comprehensive user journey document for the client. We were also using Jira to keep on top of any issues that required further development or analysis.
The miggle team were always on hand to point me in the right direction if I was unsure of anything, and were also able to explain how and why each process was carried out the way it was. I found this really useful; it provided me with a more rounded knowledge of Drupal, but also meant I could pass on more thorough instruction and information to the client if needed. As a non-developer, the basic principle was that if I could do it, the client could do it.
Just before “go live,” and with my internship coming to an end, miggle and CLPE identified the need for a “change agent” to support the launch of the new site. Since I had become so close to the project, I was asked to join the CLPE team at their London offices during the changeover period.
There had been lots of communication on a daily basis leading up to the final deploy to live, mostly involving content population. As this was a big change for a small organization, it seemed likely there would be some teething problems in the short term. We also knew that development wouldn’t stop here – in addition to offering immediate assistance, my role was to manage and prioritize on-going improvements and extras planned for the future.
This biggest challenge in my new position was managing conflicting priorities within the organisation. Finalising development sprints with the supplier can pose its own difficulties -- dealing with time constraints or reacting to unexpected complications. But it’s a process that can only start once all tasks, bugs, issues, and improvements have been discussed, documented, and prioritised internally -- by the client.
I think it’s fair to say that the Agile methodology that I learned at miggle has influenced how I go about doing this. It has helped me to put each query or suggestion that comes my way through various stages before they’re created as a ticket and ranked in Jira. I believe I’m far more practical and efficient as a result (as is the project).
Although the client team is relatively small, there are significant differences between each department’s principal concerns, and each has its own view on what’s important.
It can also be tough when faced with amendments to existing functionality versus a new development. Sometimes it’s slightly easier for a client to make these kinds of calls. Does this have the potential to lose the business money? Is this bug interfering with basic user experience?
Transferring from supplier side to client side carried some major advantages, but took some getting used to. Initially it was difficult adjusting to the fact that I was no longer a part of the miggle team, having to limit correspondence to an appropriate, client-supplier level. I was also now absent from internal discussions on the miggle side.
However, with an understanding of how miggle operates and an insight into Web development, I was able to approach them with more relevant information from the get go. Acting as a kind of translator for the client, I was better able to identify what we really needed to relay to the developers. Whether this meant providing more detail into an issue, some perspective on its urgency, or avoiding it altogether with a solution the client was unaware of, the whole process was streamlined.
Another great benefit was being a mediator with a reasonable knowledge of the workings and objectives of both companies. I had to adapt to the client’s way of thinking, which is very much focused on keeping customers happy, maximising the reach and success of their online services, and an easy-to-use backend for admins.
The approach of a Web development agency – although fundamentally striving for similar targets – is by nature more systematic and pragmatic. With an awareness of what was truly important and feasible for both parties, I was able to help compromise both internal conflicts of interest within CLPE and between the client and supplier.
It can be difficult to avoid an “us and them” mentality between an agency and a client, but I hope my intermediary role between the two helped each to approach situations with increased consideration for the other.
