Back around April 2022, our Senior Deputy General Secretary kicked off a big review of IT at CWU. It was a chance to look across the union at what we needed to do, including our core membership tools.
I thought the challenge of our old membership system contract coming to an end in 18 months could also be an opportunity to move to a more modern infrastructure that could better support innovation.
I fed this into the project and ended up managing the membership system overhaul that resulted from it. I started out with a kind of soft discovery process across September 2022. I went department by department, speaking to everybody about how they were using the system, and hearing about what their hopes might be for a new one.
John Chadfield joined the project as an in-house consultant. John is fortunately also branch secretary of our union’s tech branch, UTAW. That means he understands the union’s workings, as well as having considerable technical expertise. He’d also helped out regularly with our existing membership system – an old Integra system. Tragically in 2020, our administrator for it had passed away suddenly. John had stepped in to help us patch up the old system and keep it going.
Approaching suppliers
John helped us with an RFP document template (Request For Proposals – a format for suppliers to give you their suggested approaches to a problem, rather than quoting to a technology you specify), and we started making a brief to send out to possible suppliers. We also engaged an external advisor called Steve Pye. He’s done work for a number of unions and knows the industry well. He helped us shape up the RFP.
We kept it relatively vague as we didn’t have a strong preference for the platform we wanted. The main points of it were about where we were as a union, the system we were currently using, and the short timescales we faced.
In the first round we sent it out to 12 different suppliers, a mixture of Dynamics and Salesforce implementers, and one open source supplier. Two or three suppliers didn’t want to engage with the RFP unless they were given a contract for doing the discovery work themselves. We could understand that, but it wasn’t what we wanted.
Honing our requirements
We had 6 full responses to the RFP and saw documentation and pitches from those suppliers. Looking at the pitches helped us learn a lot about what we might want from the project. So we refined the RFP based on what we were seeing.
For example there were companies who offered a full-featured product, built around Dynamics. They’d addressed everything you might use it for and many things you wouldn’t use. And it was very expensive as a result.
We were more attracted to the approach of an MVP (Minimum Viable Product). That means replacing just what you currently need, and then developing more as you start to better understand what would work for your union.
That idea resonated partly because of our aggressive timeline, but also because CWU is still on a journey towards digital maturity, and we’ll need to handle the change in our organisation at our own pace. So for now we needed more of a go-kart than a Ferrari.
We dropped the options that didn’t fit the refined RFP so well, leaving us with three – one Dynamics, one Salesforce and one CiviCRM. And those agencies then gave us a fuller pitch on the basis of that MVP idea.
Steve helped us more with the contract analysis at this stage, so we could better compare like-for-like on approaches with varying build costs, license costs and support costs.
Making a choice
In the end we picked the Dynamics implementer Incremental. They were one of the cheaper options we’d seen, but we liked that they were an approachably sized agency owned by the telecoms giant Telefonica, so they had larger support behind them, and scope to support us with anything that might come up. They are also a Microsoft Platinum partner, giving us a level of access to Microsoft that we couldn’t get with some other suppliers.
We also liked their pitch as it gave us a degree of independence. We’d been with one supplier for a very long time, and it had been hard to support the product by the end as it was a niche and outdated system. Whilst we were looking for a long-term support option, we also wanted to know we had the fallback of being able to move to another supplier very rapidly if we needed to. So that led us to choose a low-code/no-code solution.
I think that’s probably something unions should be looking at in general, and it’s one of the benefits of Dynamics that many suppliers will build it in a more portable way, rather than incorporating too much proprietary code that you don’t own and can’t move.
Discovery and contracts
After we signed the contract, we did a very rapid discovery period – doing three, two-hour sessions nearly every day for just over two weeks. We included everyone who worked with our current system, to find out what they needed. Incremental staff came into the office so they could see how some processes worked in person, as well as what they looked like on the system.
They then did a playback session with us, where they showed us what they thought the solution should be. There was a project in itself to make sure that representatives from every department reviewed the playback session so they knew what was proposed and had a chance to agree it, or clarified bits that they weren’t sure of.
That discovery gave us the basis for Incremental to refine what they had initially quoted for for the whole project. It didn’t increase cost by very much at all. It wasn’t like them promising the earth before discovery, and then all of a sudden finding out it’s going to be double the price. But as it was pretty much bang on, I think it did show that they really spent the time to grasp and be curious about our project in that initial stage.
That gave us a lot of confidence at the time. What you don’t want is an organisation saying, “We fully understand unions, and we’re going to sell you exactly what we gave the last union”. Whilst Incremental had worked for lots of membership organisations, they hadn’t worked with any unions. However they were open about wanting to learn about a new space, and demonstrating they were able to deliver large scale projects.
The final contracting took ages. There was lots of me running between the Senior Deputy General Secretary and Incremental, and doing lots of last-minute edits to the contract. Not an enjoyable part of the project, but we got there in the end.
Working with internal users
We then had a small lead time before they could start the project, and we used that to do a small internal exercise to explain to the CWU’s project team what “agile” meant and how it was going to work. We also tried to prepare them as much as possible for things like working in a DevOps environment. That turned out to be really useful in working with our membership colleagues. These are people who know the union’s processes like the back of their hand but who haven’t traditionally been very tech-focused. They could add their comments and see decisions being made and the thought processes behind them.
Working with an agency, we need to make sure our people are ready to work in a way that will fit in with their project management culture – things like sprints, or the role for daily stand up meetings. Otherwise we’d end up wasting time that we were paying for with Incremental, or missing the right opportunities for colleagues to get necessary points across.
Managing our data
It’s also worth saying that there was a huge data migration element of the project. We did this separately, with lots of time dedicated from John Chadfield and another expert contractor, Ethel Morgan – working directly for CWU rather than through Incremental.
They managed the transformation of data from our old system and its migration to work in the new system. Having people like John and Ethel so close to the migration, who really understood our organisation and our data, was absolutely unbeatable. I think the time it would have taken to explain that to an external agency would have been tricky, and taken us a lot more in time and costs.
Implementation and testing
To CWU I acted as the project manager but to Incremental, I was the product owner. This meant that I decided the backlog and was the ultimate decision-maker throughout the project. I would of course take the advice of the wider project group, but having one decision maker meant that solution, cost and time could be prioritised throughout.
In terms of prioritising the work, we decided that we’d start with the payment stuff first, as that’s so critical. That covered our deduction-at-source (a large proportion of CWU subs) and direct debit payments. It was one of the main bits of code that we have in the system, and was very complex. So getting that done as soon as we could was really important.
After that I managed the prioritisation for other features and did all of the day-to-day meetings with Incremental, drafting in people from the project group as and when they were needed.
Almost immediately we had a real Dynamics install in front of us, but with hardly anything in it – just the skeleton of a CRM. But having something real to look at was really helpful when working with non-technical staff. We could see it being built brick by brick, which meant the project team could ask for tweaks to it before the work had gone too far – like “I wouldn’t want that of the bit of the form to be there”. It was useful for the kinds of things that you couldn’t pick up just as a project manager, but which made perfect sense when you’ve got end users in the room with a live example to comment on.
We were testing a sprint behind. So we had to be really effective with our time. You’d have your two weeks of helping Incremental build the next features, and then the next week you’d be testing what was built. And the whole thing was repeating concurrently.
One thing I remember was that it was hard for the membership team to really get their heads around testing, until there was real data in there. That’s probably the key thing I’d say about the migration phase: Try to get, if not live data, then real-looking data into the test environment. It saves users having to think about how the system would work in a theoretical way, and lets them understand it as a process they would be working on themselves.
Once we’d got real data into the system – about two months into the project – then the testing went forward so much more easily.
We had hoped to go live in September. That absolutely did not happen, and the main reason for that was industrial. It was a hugely busy time for the union more widely, and we didn’t have the resource to do it all at once. The membership team were flat out supplying the data for major ballots and working with branches to get that data accurate.
However it wasn’t too much of a deal to move the project back two months in the end. We were able to add in one contingency sprint when we found an area that needed more time for build. Unpredictability in unions is one of the few things we can predict! We also added in a few weeks break from working with Incremental to give us more time internally for the data transformation, to do a bit more internal training, and to exhaustively test the deduction-at-source solution.
For that, there was essentially one person in the union who fully understood it, and was the only person who could really do accurate testing of it. As a project manager, I can learn how deduction-at-source should work, but I’m never going to see it with the same level of insight as somebody who’s been working in it for 10 years. So we really relied heavily on her.
Staff and training
In terms of internal capacity, we hired a new Dynamics system administrator, who began mid-project in July, and so could see it being built and really help us with that testing.
That helped on-board him to both the system and union. And he’s since been around to help train the membership team and make sure people are supported and comfortable.
Incremental did provide train-the-trainer sessions for some key people, but we did most training ourselves. Videos were made from Incremental’s training too. But because people had the live system throughout the project, by the time go live came around, they mostly understood the system and what they needed to do.
Going live
November was the last rounds of user acceptance testing and bug fixes. It did feel a bit like going down the big dipper of a roller coaster. Everything was happening really quickly. We were finalising dates, migration testing, finalising deduction-at-source, testing all kinds of bits and pieces.
On the 7th of December we froze our Integra system to new data. And on the 12th of December, we went live with the Dynamics system. We went live internally, but also externally with new branch and membership portal.
So my time was then taken up with day-to-day troubleshooting: helping branches interact with new portal. Obviously as soon as we brought in large numbers of new users, they found things that they would rather do differently, or old things the new system didn’t do yet. Incremental were able to really quickly jump on those things as we identified them, and get them changed under our support agreement, which was fantastic. And we also found some bits of data that we hadn’t migrated across with the main system, which John was able to really quickly pipeline through.
That happened throughout December and early January. There were some big bugs in deduction at source. For example, we found that after the DAS files had been run, the system had removed join dates from some members. We were able to identify that problem quickly, repair it (thanks to John and Ethel keeping thorough data backups during transformation and migration), and get Incremental to fix it very quickly. That was something they understood was vital and it got fixed really quickly, despite being a complex fix, drafting the original developers back in as well as the support engineers.
That was most of January, finding and fixing lots of small bugs and a few bigger bugs. But now that’s complete, we’re completely live and comfortable on the new software. As project manager, I’m stepping back from the day to day and our system administrator is taking over.
My role is now in listening to feedback, and (due to the sort of support agreement we have) making tweaks to the system. That makes for happy branches, and that makes for a happy leadership. That’s before we start again on planning our future phases of development for it.
Amie Retallick is deputy head of communications, engagement and media for CWU and product owner/project manager for the union’s new CRM project.