WEBINAR: How NFPA Is Bringing Paper Processes Online With Drupal 8

Nonprofit website for firewise communities

Firewise USA™'s paper application process existed for 15 years but, in 2016, the Firewise team decided to bring the process online. They chose to build this process on top of Drupal 8.





Webinar Overview

Since moving to Drupal, the Wildfire Division of the National Fire Protection Association has streamlined their processes - enabling them to more efficiently deliver on their program’s goal: teaching individuals how to adapt to living with wildfires and take community action to prevent loss of property.

Join us, Acquia, and our client Aron to discuss the challenges and rewards of bringing a paper process online as a Drupal 8 web app. Topics we’ll discuss:

  • Leveraging an agile philosophy to respond quickly to change, collaborate across disciplines and stakeholder groups and get to a working product in as little time as possible.
  • Balancing effective deliverables with shared understanding to produce working software that meets the organization’s needs.
  • Organizational hurdles to overcome when adding structure and bringing an established paper application process online.


Webinar Transcription 


ARON ANDERSON: Thanks, everyone. This is Aron Anderson, I'm an associate project manager with the National Fire Protection Association, we're a codes and standard organization that mainly focuses on fire life safety issues. Our bread and butter are things like the national electrical fire sprinkler pumps and things like that but I'm actually in the Wildfire division focusing on things wildfire.

NICK SWITZER: And this is Nick at Elevated Third. I’m the development director here. I manage our development team in addition to working on projects. So my role on the Firewise project was basically lead developer and architect. So let’s get into it, I’ll pass it over to Aron.

ARON: Alright thanks, Nick. So what is Firewise? FIrewise is one of the NFPA’s bread and butter wildfire programs. It’s really a grassroots campaign that started in 2002. It’s focused on a neighborhood watch-style program for wildfire risk. So the program really empowers neighbors to work together to reduce the risk of wildfire through mitigation activities. The program really started in 2002. We are in over 42 States, we have over 1400, actually closer to 1500 Firewise Communities across the United States. It is really at the community level and the community getting together to mitigate risk. How do they do that? There is really a five-step process. We partner with the US forest service in the national state Foresters Association at the state level as well. Basically, communities will get together for the five-step process. They will obtain a wildfire risk assessment, usually through the help of a local forester or fire department and create a risk assessment and understand what their risk is towards wildfire in their community. Then they go about and form a board or a committee and really create an action plan. They have a little working group that gets together and they come up with a plan on how to lower that risk whether it's vegetation removal or hardened structures making more fire resistant things like that. From there, in order to be an active member and actual program, they must conduct a FIrewise day event at least once a year. So really, they ‘action’ that action plan and go out and do the work that's needed to lower the risk and then document how much they’ve invested whether it's their sweat equity, whether it's grants they’ve received, whether it's the community themselves spending money to purchase a chipper to remove vegetation or things like that. So they have to document their minimum investment and the program right now is $2 per capita so we ask them to calculate the community’s population and they have to spend $2 per person every year. Once they do all that they submit an application to their state liaison so every single state has their own Firewise program, or every state that we are in has its own Firewise program. And it’s the state that is the one that’s proving or reviewing the Firewise Communities to make sure that they’ve actually met the criteria for the program. So, once the work is done at the local level, applications are submitted to the state for review and approval and the state approves applications and forward those applications on to NFPA for final approval and onboarding. So, the National Fire Protection Association in partnership with the US Forest Service is really the national overseer of the Firewise program but most of the work is done at the state and local level.

So, moving the process online with Drupal 8… the program really started as a grassroots campaign; we started with 12 pilot communities back in 2002, and really back then, the program grew organically and decisions were made based on what needed to be done on the fly and so that grew the paper/PDF application that we’ve used for almost 15 years. So basically, you see a picture of what our old application was. The whole process was fine when we had 12, 100, 500 communities, not a big deal, but now we’re at 1,400 and we’re continuing to grow. We really needed to take a step back and re-evaluate how we ran the program at every level. So, in order to do that we pretty much created a brand new portal with Elevated Third and Acquia using Drupal 8. We moved that whole process that I just described, online and into an online workflow and process that gives our communities easier access to stay in the program and encourage communities to apply.

So, when we started this process we were open to any technology and all proposals. My organization, historically, had contracts with other developers and had done things a certain way for a long time but our priorities were the cost-effectiveness, the ability to be flexible - have a product and developer that could make changes as this is such a radically new project and the sense of bringing this whole process online that had never been done before, we really needed that flexibility. We also had a high priority of the developer understanding the user experience and our audience, which tends to be more retired and an older generation, not so much the millennial generation. We had previously worked with developers who were very experienced in wildfire-related things, but our top priority was to find that developer who could really understand our audience.

There were a few a hurdles for this project. My organization has no in-house development or IT support is all. We’d never used Drupal before so we knew we would have to find a developer who could not only build our site but support and manage the site after launch. We were moving away from existing contracts. We wanted to find new technologies that met our needs a little better than the way we had been doing things in the past. And really just convincing my leadership that Drupal was the right way to go, having never used an open source platform.

Going from an idea to an RFP. I kind of alluded to this a little bit, but the program really grew organically and decisions were just made as they went, which is pretty simple to do when you’re running a process on paper or in your head but having a whole system to manage workflows and tools were really tough. So, the first thing we did was to sit down and do an audit of the program itself. We called that the Firewise lifecycle. We really sat down and looked at when a Firewise community applies and are approved, what happens and what do we do to that community. We send them physical materials, like signs, that they can hang up, and do a bunch of outreach and offer different levels of support. So we really tried to sit down and document everything that happens to our Firewise communities throughout the year. After we got a grasp of that audit, we did a lot of research and outreach with key stakeholders. Everyone at the local fire and emergency management level, to the state foresters and Firewise state liaisons, all the way up to the federal level. From that research, our business unit and the wildfire division partnered and developed a functional requirements document that we used as supplemental information to create that RFP which we eventually sent out.

NICK: This is Nick. I can talk about why this felt like a good project for our agency and why we felt like Drupal 8 was the right choice. We are a Drupal-exclusive shop. So, if we do a proposal, we’re building in Drupal and we’ve been working in Drupal 8 for close to two years now and exclusively in Drupal 8 for about a year and a half - since April/May of 2016. It’s a great fit for all of the projects that we take on, but for Firewise specifically, some things stood out. This is a system that has a lot of complex permissions and different users logging and managing different aspects and it was really important that those permissions were enforced in a way that users in communities that needed to have access to something, did not have access to the others. And like I mentioned, that's Siloed access around states and communities and so a contributed module called “Groups” gave us a great headstart on that functionality. That is kind of a successor to a module called “Organic Groups in Drupal 7.” I believe organic groups will be a thing in Drupal 8 as well but we’ve had great success with groups.

The meat of this thing was the actual application process, which is a pretty complex multi-step form that can have lots of different nested types of data and things that need to be saved and revisited and viewed in different states by different users. Drupal’s core form API is really strong with this -- we leverage a contributed module called paragraphs a lot, mostly for front-end, component designed related things, but we used it in more of a back-end capacity on this project to build out things like the nested data on applications so that users can submit individual events and multiples, and still have them in a pretty easy to manage UI and tore it in a way that they are related to the application but they don't necessarily need to be available to the users outside of that specific application. Finally, and I’ll touch on this a little bit later in the presentation, but the development tools that we have available to us with Drupal 8 give us a lot of power in regard to stable, predictable deployments. And CMI is configuration management, which is something completely new for Drupal 8 which gives us a lot of power to manage configuration as code, and deploy that across environments rather than the traditional “Oh, well I set it up as staging, now I need to remember to point and click all those same things on my production environment.” And for us, missing stuff isn’t an option because there are users constantly managing applications in their communities and we can’t risk a feature not being there or full site downtime. And now I’ll pass it over to Kim who's gonna talk about why Drupal 8 is great for nonprofits.

KIM: Hey everybody this is Kim. Since we are talking about NFPA I thought it would be a good idea to talk from a high level about why Drupal is a good fit for nonprofit organizations, but this is really relatable for any industry that might be listening. There are four things that come up in a lot of conversations I have with different organizations. I think one of the top ones is mobile responsiveness. Everything out of the box with Drupal 8 supports mobile and the reason this is important is for a number of reasons. Obviously, if a site is mobile optimized, it’s better for your SEO. There’s more and more data coming out about how email is opened more frequently on mobile devices, more social media traffic is coming from your mobile device, and people are donating more on their phones as well. So you want to be able to have an easy and sharp experience for your customers coming to your website from their mobile device or their tablet or whatever type of thing that they’re using to get there. The second one is the overall flexibility of the platform. There’s different pieces of Drupal like modules and integrations that are really great for organizations that have a lot of different systems that need to integrate with the site. A lot of times I talk to organizations that have a CRM, an association management platform, an ecommerce platform, a donation platform, and there are all these different systems that really need to integrate. Drupal is great because a lot of these come out of the box with Drupal or you can customize them to fit your exact needs. You have those options with a system like Drupal. The next one is security. Drupal itself has a huge security team that’s constantly monitoring the code that’s contributed to the Drupal platform as well as modules and integrations and all of those type of things so there’s a large emphasis on security of the platform which is important for organizations passing a lot of data. It might be people's information, credit card information, general data, scientific research or applications. So it’s really important that you're on a secure platform. And lastly, I hear a lot about multilingual capabilities. This is something that is out of the box on Drupal 8. Again, this is important because a lot of organizations are global and have different audiences across the globe or you might even be targeting a specific part of the globe that has multiple languages within that region.

NICK: Thanks, Kim. I’m gonna talk a little more about the process of how we actually got this thing together and collected Aron and his team’s requirements and turned it into a living, breathing, web application. When our process starts, we begin with a Discovery phase. The goal of that is to make sure that we’re aligned with our partner’s team and their goals and expectations of the project and we can deliver something that meets their needs. In this case, like Aron mentioned, he and his team had spent a good bit of time developing a very comprehensive doc of their vision of Firewise 2.0, which is basically the web version of Firewise, would be. So, we had a lot to dig into and it initially took the form of a 2 day Discovery of a very intensive discussion of those requirements and also the broader goals of the program to make sure we were understanding what we need to put into this and what we need to get out of it in terms of actual user data.

So, we started with a UX process based on the conversations we had up to that point. We find that a low-fi brainstorm goes a long way. We’re big believers in collaboration and we tried to include Aron and his team as much as possible just because we like to iterate quickly and fail early and often to get to the meat of the problem and answering the right questions. We started with a basic affinity diagram where we all sat in a room together and wrote down everything we could think of about the Firewise program and the requirements. Out of that, we also developed user personas because that’s obviously a huge part of this program; the people actually using it. Without those people, the program wouldn’t work. We spent a lot of time understanding who needs to use this program and what do they need to do. Like Aron mentioned, we’re dealing with users who maybe are not the most web savvy or just aren’t very excited about the program moving online, so we wanted to make sure that our solution was really simple and straightforward and we kept in mind a lot of benchmarks like TurboTax that are very straightforward and easy to work with. All of this is happening in tandem but another aspect of this process is figuring out the site architecture and estimating to make sure that all of this stuff aligns with the budget that Aron and his team came to us with. What you can see in the slide here is an example of how we started to think about what the different users of the application are and what they can do and we carried that all the way through to the different content types and user roles and how these things interact with each other and what does everything look like in a spreadsheet before we started to build everything out.

So once we got all of those pieces together and Discovery drew to a close we transitioned into the implementation phase. For us we deliver a final “stack of digital papers” which we refer to as the blueprint. And that basically gives us everything we need to hit the ground running with the project. It’s by no means a comprehensive outline of everything that will be included. We had only done initial wireframes, no designs yet. But, it was enough to give Aron and his team what they needed to prioritize features and what the required time investment was.

ARON: Yeah and I can’t stress enough how important the Discovery process was for us. As an organization, we spent almost two years going through our own Discovery, if you will. Initially, some of my team questioned why we were doing an initial Discovery when we've been doing this for two years already. But going through it with Elevated Third allowed us to understand the process a lot more. The specs document was even vastly different than our original functional requirements document.  

NICK: Once we were all aligned in Discovery, we moved into implementation. As a team, we decided to work as agile as possible, which I referred to before. As a company, we like to take a lot of the ideas from Agile and apply them wherever possible. I think the big things are flexibility and collaboration. Aron was really great about being available and he was a very engaged product owner and willing to jump in headfirst and work with our team to design and build this thing and it really made those quick sprints a reality so we could have those reviews and standups and constantly talking and changing. The initial part of that was sprint planning. This wasn't something where the Account Manager just sat down and did this on her own. Aron came into the office and we had our whole design and dev team involved and we all worked together with the project priorities to plan out what our overall project looked like and what our first two sprints looked like just so that Aron can know what to take back to his team so they know what to expect. It is a really collaborative process and I think what gets missed a lot of times is that it does require a lot of engagement on both sides and we wanted to make sure that everyone was prepared for that.

ARON: Yeah, and this was my first experience with a sprint planning process and being a project owner but it allowed us that level of involvement and engagement from the get-go. I was able to get with Elevated Third and talk through the organizational challenges we had. We integrated this system through a single sign-on so they had to work with another developer on the East Coast, which we had a longstanding contract for. Being able to know about those challenges upfront and plan accordingly allowed us to meet our target deadline and things like that.

NICK: Just briefly, for the structure of those Sprints, we worked in two-week increments with three, 15-minutes standups each week. At the end of every Sprint, we would do a live demo with Aron. We tried to be really true to this which was challenging from a development perspective, and probably from Aron’s perspective as well, because two weeks into a development project there’s not a whole lot to look at. So a lot falls on us as developers to make sure he knows what he's looking at and can ask well-informed questions.

ARON: For me, it was incredibly powerful. Even though we did a functional requirements document. Even though we did an in-depth Discovery, we were still learning on my side and having that flexibility to make changes with Elevated Third was really powerful.

NICK: So just real briefly I wanted to touch on Drupal 8 and some of the game-changing features it gave us as developers and make it such a powerful tool for enterprise level web applications like this. One, like I mentioned was configuration management. We used a contributed module on top of that called config read only. And what that does is essentially allows us to lock down all the configuration on the dev site so when we were in active development we know we wouldn’t be overwriting other changes on the development environment. We could treat the configuration and code as canon, which made that a very simple to manage solution that made for some stable deployments. Additionally, it's not a Drupal-specific tool, but a tool called composer which is essentially a PHP package manager. I don't want to get too in the weeds with that but what lets us do is effectively manage all the different pieces of code being pulled into this project. One of Drupal 8’s mantras is “proudly founded elsewhere.” And there is lots of great code written by the Drupal community but there’s also lots of code leverage from outside of Drupal and composer gives us a great, automated way, to manage that stuff.

Moving out of implementation, QA and functional testing always play a big part in our process, but for applications like this its very important to make sure we’re following through and being very regimented. We had five user roles we needed to test and a huge plethora of features across those user roles that we needed to make sure all worked together and individually in the ways we expected.

Just to touch on some key points in this process, we made it a priority to make sure that our testing doc wasn’t a throwaway deliverable. We took it directly from our user stories and applied those user stories to roles and actually brought in people who had never seen the project before to take on those user roles to make sure everything made sense from a UI and functional perspective. With bug tracking, we managed it the same way for everyone on the team so we didn’t have Aron and his team adding bugs to the spreadsheet which would then have to be translated by an Account Manager. Instead, we managed everything from Asana which is super cool and easy to use. That provided a lot of value in terms of making the team more efficient and it allowed our team to be able to directly ask questions to people who were actually testing the application and vice versa.

Finally, it seems like a small thing but in practice is hard to stick to, having a release schedule in QA you can create a lot of chaos if you’re just randomly pushing fixes up and not informing anybody. So we only pushed changes up at a certain time of day which gave Aron the ability to know when they needed to be available so we could stick to that tight schedule and work as quickly as possible.

And after QA, we launched! The fun part; everything we had been working towards. I should mention that launch doesn’t mean it's over. This is an ongoing project and we have a release cycle we stick to and it's very much an evolving project. But, what was really great about the specific launch for this site is we had the opportunity to launch it as more of a closed Beta launch, which from a development perspective was great because we could move everything into the production environment and test things like live single sign on and an SSL certificate. It also gave us the ability to invite in the users who would actually be using this thing so we could get some perspective from them.

ARON: From a Firewise standpoint we’re building something that just didn’t exist before, so we were in a unique position to roll out when we we’re ready. So that allowed us that flexibility to get it right the first time.

NICK: After we were live, training and documentation was huge part of this because, like we mentioned we had a variety of users from across almost 1,500 communities that needed to use this system. And for a lot of them, it was completely foreign and not something they were particularly excited about using. At the highest level, we had Aron and his team who are the Firewise program administrators and Aron was very involved, as we mentioned, throughout the project, so he was able to see and use features and shape how they came together. So, by the time we had a “finished” product for him to look at, he had a pretty good idea of how to use it. But then he could assist in training the rest of his team with how to use the application and help things move a little more quickly and efficiently.

On top of that we also created some PDF training documents that the Firewise team leverages to send out to users who maybe having issues or are brand new to the program. We found those to be pretty effective.

ARON: As NFPA, we are national administrators of the program so we took it upon ourselves to work with Elevated Third to have those different types of training documents. We also did some real time webinars with real users at different levels just to make sure we we’re educating and giving the right resources for this website.

NICK: On top of that, we also did some screencast tutorials so we had a more visual walkthrough component of training. I can’t emphasise enough how helpful these wore and how simple they were to create. And that just gets back to that agile mentality of producing the minimum viable product -- the most effective thing we can -- then iterate on that and make it better as we get feedback.

That's basically start to finish what happened. Like I mentioned, there isn't a hard and fast finish line for us but this is something we’re continuing to work on as the program evolves.

ARON: Yeah and we’re about six months after the launch now and we’ve already learned a great deal and we’re already working on future phases and changing things and adding things.

NICK: To wrap up, we just wanted to touch on some top three lessons learned.

ARON: For my team, going from a program that's been on-paper, there were a lot of assumptions that they could just keep doing the same things. So we had to have to tough conversations about building a system that has to account for everything and we couldn’t just assume that we would have a system that could do X if you’ve never talked to them.

Second, have a plan for unexpected contingencies. Things came up as we were learning things on the fly. So try to have some forethought so you don't waste time and money on moving to plan B.

Last, document everything. I had a hard time dealing with decisions that needed to be made on my team and implementing those decisions with Elevated Third only to have the same repeated conversations with my team with a different option. So make sure you document all the decisions made by your team so that everyone is on the same page.

NICK: From my perspective, clear communication and honesty are so important. It’s easy to talk about but hard to do. But we make it priority to level with one another. There was no reason to make excuses when we’re in it together and it’s a partnership because we have the same goal in the end.

Next, as developers we talk a lot about environment parity and how important it is to make sure things across your environments match and with Acquia it’s really easy to do that in terms of software stack and moving things across environments. But what we learned is how important it is, with such a big project with lots of users and very important legacy data, that all of that stuff needs to match across environments as well because we want to be testing as accurately as possible before pushing to production.

Finally, staying on budget is a team effort. Sometimes you can run into the mentality that budget is the clients' thing to manage or the Account Manager but a big part of agile in our process and being collaborative in general is that everyone should be aware of the budget and the burn rate and what that means to the project. A lot of times, we were able to shift our burn rate around and change our priorities.