Stuck in the middle with you: how to balance internal stakeholders requirements with demands from an Agile agency

Gavin Mallory, Cogapp, UK

Abstract

This paper tells the tale of how Heidi Quicksilver went from “Hi Heidi. You’re running our new website project as of yesterday. I’ve got you an agency to help out, and it needs to be done in three months. KTHXBAI” to “Great work Heidi. We love the new website. Have a promotion.” At a moment’s notice, Heidi was given the task of managing the outrageously fast website redevelopment for the Rock & Roll Hall of Fame and Museum in Cleveland, and with it, the management of all internal stakeholders, content migration and creation, third-party service providers, and the digital agency Cogapp. In this paper, Heidi from Rock Hall and Gavin from Cogapp will talk through the tools and techniques used to ensure clear and effective communication throughout the organization; the innovative way we managed content; how we got the very best from our agency; and, of course, the things we got wrong, the biggest learnings, and what we’d do differently next time. We’ll also let you know how it felt to launch the website a day before the Republican National Convention rolled into Cleveland. Attendees will gain insight into our process and leave with tips on how to work effectively under extreme time pressure, with the eyes of the world on your city and institution. You’ll learn how to develop a true partnership from an agency, the issues to look out for on a project like this, and how to deal with them while you’ve got 1,000 things going on (as well as your day job). And because we’re Rock & Roll, the talk will be themed around the Steeler’s Wheel classic Stuck In The Middle With You. We won’t cut any ears off, I promise.

Keywords: collaboration, agile, stakeholder management, agency, partnership, delivery

Context

The Rock & Roll Hall of Fame and Museum (Rock Hall) exists to archive the history of the best known and most influential artists, producers, engineers, and other notable figures who have had a major influence on the development of rock and roll.

Before this project, RockHall.com had evolved organically over time. This brought a number of issues for the organisation, including the following:

  • The website did not meet accessibility requirements;
  • Rock Hall’s new brand was not represented and the site generally looked its age;
  • The site was not responsive;
  • The site did not adequately support the visit experience.

There had long been a desire to redevelop the website at Rock Hall, but in a time of competing priorities, it was not at the top of the list. However, all that changed when the announcement was made that the Republican National Convention (RNC) would be held in Cleveland…in just twelve weeks time!

The RNC was a weeklong event in the city. Cleveland was going to be filled with media from across the globe, as well as conference delegates from around the country. The eyes of the world were going to be on Cleveland in this week, and the Rock Hall was expecting record numbers of physical and digital visitors.

Our website, which did not meet accessibility requirements, did not function properly on mobile devices, looked dated, and didn’t adequately support the visit experience, suddenly became an urgent organisational issue.

That urgent organisational issue was amplified considerably with the knowledge that the RNC and the world’s media were arriving in just 12 weeks.

Greg Harris, the President of Rock Hall, knew Cogapp from his time at the Baseball Hall of Fame, whose website Cogapp designed and developed. His idea was to use the infrastructure behind baseballhall.org to get enough of a headstart on delivering the new rockhall.org in time for the RNC.

Rockhall.com on an ipad in a music studio
Figure 1: the finished website providing artistic inspiration in a recording studio

Getting started at MWXX

We discussed the project with Greg as well as Rock Hall’s Head of Technology, Marc Check. We felt it was possible to complete in 12 weeks, but we needed to start almost immediately.

The following week was Museums and the Web 2016 in Los Angeles. That was where we first met Heidi Quicksilver, who had just joined Rock Hall as the digital asset management specialist.

We met in the conference bar. The two Brits (myself and Andy Cummins, head of product development) were overloaded with jet lag, and Heidi was overloaded with the news that she was going to be running this project with us. As she very fairly put it “I’ve just been told I have to make this work with you guys, and I have no idea who the hell you are!”

The project got official approval in the next few days, and we set off for Cleveland almost immediately.

Pre-mortem

Before the trip, we ran a pre-mortem. This is a really useful exercise where the team comes together to identify risks before any work has been done. This brings the risks front-of-mind through the project, increasing the chance that you spot risks developing earlier, and are more able to manage them.

Kick-off in Cleveland

Our developer Neil Hawkins and I went to Cleveland to kick off the project with the senior stakeholders.

Brighton to Cleveland is a mighty long way, but because we were so pushed for time, we got off the plane, showered, and went straight to Rock Hall to start working. We had to see the museum to truly understand it.

The next day we ran a workshop. Marc kicked off by sharing the project goals:

  1. Accessible to Section 508 and WCAG AA
  2. On brand
  3. Prioritise the physical visit

Neil and I explained that we would take the Baseball Hall website and—as quickly as possible—repurpose it for Rock Hall. This first iteration offered exactly the same functionality as the Baseball site, and although the colors and fonts would be on brand for Rock Hall, the design would be the same.

We planned to get to this first iteration as quickly as possible and use our remaining time to customize the functionality and page layout to Rock Hall’s needs.

This approach was essential because of the deadline, but it also made for a very effective way of managing stakeholders.

Our plan had been to run a half-day workshop with all the stakeholders, but schedules didn’t allow that, so we had to squeeze our fact-finding into 60 minutes.

Our aims for the workshop were the following:

  • To understand the organisational goals for the project;
  • To make sure stakeholders felt they had their say;
  • To ensure everyone understood the constraints of this phase of work, particularly around time.

The workshop revealed the key challenges stakeholders recognised with the old website, and that entire senior management was completely on board with the project goals for the new website.

The group was very pragmatic. They understood that for this project to succeed, we needed to maintain a laser focus on the project goals, with minimal distractions.

One of our key goals was to ensure all senior stakeholders understood the huge time constraint of the project. Our meeting was held 53 working days before the deadline.

In the course of the hour-long meeting I must have said “The website goes live in 53 days” approximately 3,000 times. Sometimes “53 days” was my answer to a feature request. If a conversation went on too long, I’d say “wrap it up people, only 53 days to go.” It became a joke, but I guarantee you that nobody left that meeting with any doubt about how long we had to do a project that would usually take months.

Chicken and beer

That evening we did something fundamental to the success of this project; something everyone should do at the start of a project: Heidi, Neil, and I ate fried chicken and drank beer.

Why was this important? Because we got to know each other a bit. We talked about work stuff and about other stuff, and we all had a jolly nice time. And that stood us in good stead for the rest of the project. We built up goodwill on both sides, which made any tough conversations down the line much easier.

The timing of this visit was really critical too—it was right at the start of the project. With remote teams, conference calls, etc., it is too easy to forget the value of face-to-face contact and bonding over a beer.

We had truly moved on from our jet-lagged “I don’t know who you are” conversation to a place where we knew we were going to be able to work together, and make sure we delivered an amazing website for Rock Hall.

To this day, we still talk about fried chicken. A lot.

Get programming

We came back to England, and a team of four of us worked on the site nonstop for 12 weeks.

This paper is about process, learnings, and actionable advice, so I’m not going to go into all the technical details. If you’re interested in how the back-end Drupal CMS works for an editor, then take a look at this blog post; the one-template museum websites.

Reporting on progress

Heidi and I reported to the senior management at Rock Hall every two weeks with our progress.

Before we had these meetings, Heidi and I discussed how we presented information, who was going to talk about any challenges, and we ironed out any misunderstandings (which happen on such a fast-moving project with many moving parts) on our own.

This meant that when we presented to the senior team, Heidi and I were completely united. I didn’t drop her in it by saying the wrong thing, and she was able to be confident in her progress reporting because she had up-to-the-minute information. Some things were better said by her, and some were better coming from me. We really thought about that.

At the first of these demo meetings we had a difficult issue to address—content. Content is always a challenge for projects like this, because it is often assumed that “we have a load of content on the old site so we’re basically done.”

Usually it’s the people managing the project that are expected to edit, enter, and even write the content. In my experience, this never works. Managing a website build is a full-time job. Editing and entering content into an entire website is at least one full-time job. And usually the person at the museum managing the website build already has a full-time job.

I raised this at our first senior management meeting, and again used the deadline to drive the point home. At this point we had 37 days to go, and we knew roughly how many pages were going to be on the new website (400, down from 17,000 on the old site). That meant I could show that meeting a slide that said “Pages per day of content to enter into the CMS to hit launch, if you start today: 14.”

Intentionally, the last slide—which was purposefully left up as we had the post-demo discussion—said the following:

  • We’re doing well so far, and there is still a lot to do;
  • Content is the biggest risk to delivery and needs addressing urgently;
  • This project needs your support to deliver.

The senior stakeholders definitely absorbed this unsubtle message, and by the next morning, Heidi had authorization to hire a content team for the duration of the project.

If you want to know how we managed the process internally (and it’s a good read, with loads of useful tips) see How to Rock (& Roll) your Agile website development.

Empowerment and trust

What the Rock Hall did very clearly was give Heidi autonomy on the project. Of course there were times we needed to check with colleagues, but most of the time, if we needed a decision, Heidi could make it.

This was critical to the project, not only because of the timescale but because it meant that between the two of us we held the vision for the project and could deliver it. If too many people try to hold the vision, it becomes diluted. If the project manager is not the decision maker, they often make bad decisions trying to second guess what the absent decision maker might think.

There was a second level of empowerment and trust on this project that worked really well. Heidi explicitly said that she was happy for me to make decisions without her. Not all clients are comfortable with having that faith in their agency producer, but it worked really well for us. It moved things forward much quicker—especially considering the five hour time difference between—us meaning we can work all morning, and then show Heidi an entire morning’s progress by the time she gets to the office. Then while we’re at home, she has time to review with colleagues and send us any feedback in time for when we get in the following morning.

Trusting each other also extends to being honest; we were very open if we didn’t know something, if we’d forgotten something, or if something had gone wrong. We worked with complete transparency. On occasion, we would disagree. Sometimes we’d do what I thought was best, sometimes we’d do what Heidi thought was best, and very occasionally she’d have to say “look, I’m the client and it has to be this way” and I got that. It was an excellent working relationship, founded on chicken and beer!

Dedication

Both Heidi and I were able to make the project our main focus (around four days per week each).

Having this focus meant we moved things forwards really quickly, and also respond to emergencies immediately.

My calendar was basically cleared, so when one Rock Hall department went to Heidi with some concerns about the project, we were able to get on the phone that same day and sort it out.

Being dedicated also meant our minds were all about the website, all of the time. If you’re grabbing a couple of hours to “do website stuff” in between other meetings, you’ll never do as good a job as if it is what you eat, breathe, and dream for 12 weeks.

Tools

The most important tools we used in this project were the telephone and our mouths. Yes, we actually spoke to each other at least once a day, often more.

This was by far the most efficient way to get things done.

If I had a list of decisions, particularly that involved looking at work in progress, then I’d send Heidi an e-mail with a list, trying to be as clear as possible.

The best e-mail any client ever sent me came from Heidi. It simply said, “Let me know what you guys need from me today.”

We used Pivotal Tracker to monitor work, which the Cogapp team all knew. It was great for us, but didn’t suit Heidi, so we adapted the way we worked. Decisions popping out of Pivotal would be discussed on the phone or in an e-mail between me and Heidi, and then popped back into Pivotal.

We also used Skype for immediate or quick requests (often secretly sent while in VP meetings, but don’t tell anyone we told you that).

Results

  • Site is accessible to Section 508 and WCAG AA;
  • Responsive across devices;
  • Stands up to huge traffic spikes at induction announcements;
  • Social media fully integrated;
  • Events calendar working with Tessitura;
  • Page views up 25%;
  • Pages per session up 13%;
  • Bounce rate reduced by 20%.

We continue to work together to further develop and enhance rockhall.com.

Extended takeaways

  • Run a pre-mortem to identify risks before they happen.
  • Have a really tight brief, and communicate it clearly and repeatedly to your stakeholders. Be consistent in pushing back if people ask you to go outside the tight brief.
  • When speaking to stakeholders, decide the one thing you need them to leave the meeting with (e.g. content is the biggest risk to this project; we have 53 days until the site has to be live), and make sure they leave with that.
  • Get stakeholders together early, and make sure everyone has their say. Record the results so you can demonstrate delivering against the mandate they gave you, or be able to tell them why they won’t get it right now.
  • Look for ways to get a headstart, e.g. using the Baseball Hall of Fame site as the core of our new site, which was what made the project possible in such a short time frame, and for the budget.
  • Find opportunities to build goodwill as early as possible. This might be beer and chicken. It might be starting work before the contracts are signed. It might be showing photos of your family. If you like each other, then it is much easier to work together in a high intensity environment.
  • Always show a united front to everyone else. This builds confidence in the project and your collective ability to deliver it.
  • Show your work regularly to stakeholders.
  • Listen to people who have challenges for you, and deal with them.
  • Use numbers to make your point with senior leadership. “If you start today then you need to write 14 pages of content every day until launch” was a very powerful message.
  • Leave those numbers up at the end of your presentation.
  • If you are managing the project, make sure you are empowered. If you aren’t, then work with your agency to push back.
  • Be visible in your organization. Put stuff on the wall where colleagues can see it, keep people informed, and encourage questions.
  • You need time to do your best work. Make sure your organization let’s you have this, and if not, then work with your agency to push back.
  • Focus on delivery. Get it done.
  • Be honest. If you don’t know, say so. Never bullshit.
  • If you need to put your foot down, do it.
  • Talk—with mouths rather than fingers wherever it is practical to do so.
  • If a process isn’t working for you, change it fast. Use regular retrospectives to find issues and resolve them quickly.
Lady in a cafe holding a mobile phone showing the Rock Hall homepage
Figure 2: a museum patron in Cleveland using the website to plan her evening of live music at the Rock Hall

Cite as:
. "Stuck in the middle with you: how to balance internal stakeholders requirements with demands from an Agile agency." MW17: MW 2017. Published April 5, 2017. Consulted .
https://mw17.mwconf.org/paper/stuck-in-the-middle-with-you-how-to-balance-internal-stakeholders-requirements-with-demands-from-an-agile-agency/


Leave a Reply