23 March 2016

Jeff Bowman, The Mountaineers Sally Kleinfeldt & David Glick, Jazkarta Karen Uffelman, Percolator Consulting

#16NTCwebanatomy

Anatomy of a Major Website Redesign Project

SALLY: Welcome to our session, Anatomy of a Major Website Redesign Project. Thank you for joining us! Let’s get started.

Housekeeping

Collaborative Notes: http://po.st/webanatomy-16NTC

SALLY: First some housekeeping. Here is a short ink to the collaborative notes for this session. That document provides details about the session such as speaker contact information and the evaluation link. You can take notes about the session there, as we are speaking!

Presenters

Jeff Bowman IT Manager The Mountaineers jeffb@mountaineers.org

Sally Kleinfeldt Director of Consulting Services Jazkarta sally@jazkarta.com

Karen Uffelman Principal Percolator Consulting karen@percolatorconsulting.com

David Glick Architect/Developer Jazkarta david@glicksoftware.com

SALLY: Let’s get started by introducing ourselves: - JEFF: The Mountaineers’ lead on the project - SALLY: Project manager of the website implementation team - DAVID: Lead developer - KAREN: Strategy consultant

SALLY: Now I’m going to hand it over to Jeff to tell us a bit about The Mountaineers.

Anatomy of this Session

1. A gorgeous, hard-working site

2. Keys to Success

3. The strategy & vision

4. What does technical discovery look like?

5. UX & visual design

6. The build: timeline, process & shifting priorities

7. Bumps in the road

8. The project doesn’t end at launch...

JEFF: I’m going to kick us off by telling you what we’re going to share in this session. First off, we’re going to share the final product, which we’re very proud of, and then we’re going to talk about - The work it took to get there. - The strategy that helped us ask the right questions and got us to a shared vision. - The intense technical discovery that ensured we knew exactly what it would take to get that vision. What it took in terms of design to make sure the site both looked and worked great for our end users. - The actual implementation. - The challenges we encountered along the way. - And, finally, the fact that a project like this doesn’t ever really end. Along the way, we’ll be pointing out the key factors that made this project successful.

Our presentation should take about an hour, leaving a half hour at the end for questions and discussion. Feel free to interrupt with quick clarifications, but let’s hold more in depth discussions for the end.

One question from us: ● How many of you are thinking of or planning to embark on a major website project? ● How many of you are in the middle of such a project? ● How many of you finished such a project in the last 5 years?

The Mountaineers

JEFF: But first, let me tell you a little bit about my organization. Since 1906, The Mountaineers have been helping people in Washington State and beyond enjoy the outdoors safely and responsibly. The Mountaineers have less than 20 program staff and yet offer hundreds of outdoor activities and classes every month -- almost all of them led by volunteers.

Where We Were

JEFF: Before we started this project, we had a website that was supposed to support all of the work of our volunteers plus serve all of our members. We’d spent a lot of money developing it in 2003, and it did a lot of stuff, as we’ll talk about later in the session, but none of it particularly well. A couple of years before we embarked on this project, we invested some money in a facelift for the site, which made it look a little better, but it didn’t work any better. Our board president at the time was always referring to the “lipstick on the pig”...And not only did we have the one main site, which looked okay but didn’t work that well, we had a bunch of sites that our branches and committees had built and maintained to varying degrees. It was, to put it kindly, a giant mess.

Where We Are Now: A Gorgeous, Hardworking Website

JEFF: We love how our new site looks, and even more, how it works. I’m going to give you a little tour...

JEFF: We really wanted to inspire with this site, and the big, beautiful images on the homepage and beyond do that well.

Blog

JEFF: Our old site had very little fresh content, apart from course and activity listings. Our new site is a cornucopia of content that our members love.

Member Profiles

JEFF: Every member has a sophisticated profile. Here’s mine: for me I come here to see the courses and programs I’m registered for, my payment history, my volunteer profile, get to my committees, etc. Other members can see my primary activities, the committees I serve on, my bio and photo, and ... my badges!

Badges

JEFF: My badges! Folks who are involved with The Mountaineers are constantly getting certifications, etc. many of which you need to participate in other courses or activities, and we have developed an entire badge system that shows up on your profile. It’s so cool.

Member Profiles: Badges

JEFF: Here are my badges, so other members and activity members can see my experience and level of expertise when I join one of their activities or when I offer to lead or teach one.

Course and Activity Search

JEFF: The course and activity searches are awesome, and make finding the exact right option for your schedule, experience level, etc. so much easier than it was using our old website.

Course Registration

JEFF: Requirements for registration and course information are clear and it’s easy to register.

Shopping Cart

JEFF: Our new point of sale system is awesome. You can purchase courses, course materials like books, and even make a donation all in one action.

Rosters

JEFF: For our volunteer course instructors and activity leaders, they now have well-designed student rosters and other forms and tools which, although our old website offered these, they needed significant improvements.

Rosters Continued

JEFF: Here are the bulk management tools that our volunteers have for course rosters.

Dashboards

JEFF: And, finally, with all of our data going into Salesforce on the backend, we have great analytics tools to understand how all the work on the front end is paying off for us. We can track membership growth, revenue, retention and transition, etc.

Keys to Success

JEFF: Before we dive into a description of the project, I want to point out what we think were the key factors that made this project successful.

Keys To Success

Solid Strategy Agile Process

Trusted Partners

JEFF: - Having a Solid Engagement Strategy guiding what we wanted to accomplish - Using an Agile Process that minimized risk and adapted quickly to change - Working with Trusted Partners with great communication skills who understood us and the technologies we were adopting

Watch out for these, which we’ll be talking about as we describe what happened on this project

Okay… Let’s go!

JEFF: Okay let’s dive into the project - I’m going to turn it over to Karen to talk about Strategy.

The Strategy & Vision

KAREN: The Mountaineers started by investing in a strategy process.

Engagement Strategy

1. Theory of Change 2. Audiences 3. Roles & Value Propositions 4. Superpowers 5. Engagement Pyramid 6. Secret Shopping

KAREN: Specifically, an engagement strategy process. The Mountaineers’ primary goal for their new website was to do a better job at engaging their current and future base of members and supporters, not just solve some technical challenges. They hired Groundwire Consulting, where I was the Director of Client Strategy, to conduct this engagement strategy process for them, and the process consisted of these six elements:

Theory of Change

KAREN: Here’s The Mountaineers’ theory of change. You likely can’t read it, but the vision statement at the top of this theory of change says “People of all demographics experience the lessons & pleasures of the outdoors and are committed to protecting it.” We mapped out all of the ways The Mountaineers programs lead to this vision, what audiences must be reached or are required to take action, etc.

Theory of Change

KAREN: Then we drilled down on the specific elements of the theory of change where their website was or could play a key role, as well as identifying their biggest untapped or under-resourced opportunities. In broad strokes: new members and students were critical to the organization’s growth and mission, and they desperately needed a simpler onramp for recruitment and retention. At the same time, volunteers are the lifeblood of the organization, would be heavy users of the website, and needed better tools and recognition to avoid burnout.

Audiences

KAREN: Having identified the key audiences in The Mountaineers’ theory of change, we developed personas for them. If you haven’t worked with personas before, the idea is that you boil down an entire audience segment to its archetype. Give that archetype a name (like Vera the Volunteer or Max the Member) and a picture and write down all the things that would help you think about them as an individual. What do they want? Why would they be inspired or motivated to get involved with our organization? What roles do we want them to play? What challenges might they have? Some of you may be familiar with the “Saddleback Sam” persona from Rick Warren’s THE PURPOSE-DRIVEN CHURCH, which I show here on the right for comparison. In essence, the website we were building were for these people [5 personas]. When making decisions throughout the project, we referred back to Vera, Olivia, and Max and reminded ourselves of what they needed/wanted.

Superpowers

KAREN: The Mountaineers are an amazing organization, and have a number of Superpowers: 1) amazing experiences and opportunities to build skills through trips and classes, 2) super-committed volunteers, 3) great community Priorities: 1) first time participants and 2) volunteer leaders

How could the new website facilitate ENGAGEMENT?

KAREN: So with all of that under our belts, we built out The Mountaineers’ engagement pyramid.

Q: Does anyone in the audience have experience with engagement pyramids?

We identified every role and every way a person could become engaged with The Mountaineers in service of the organization’s vision and mission, we weighted those roles and activities so that shallow engagement was at the base of the pyramid and deep commitment roles and activities were at the top, and then we focused on all of the roles and activities that would be supported by the website.

Secret Shopping

KAREN: Finally, we don’t do this for every engagement strategy project, but another element that was very useful for The Mountaineers was that I secret shopped their existing site. Knowing what The Mountaineers’ roles would be for me as an audience member (making a donation, registering for a course, etc.), I tried to interact with their website to do all of the things that The Mountaineers’ would want me to do and then recorded my experiences in great detail. This helped to challenge a lot of the staff and board’s existing assumptions about how well their current website was working, and lit a fire under the board to find the funding for implementation. By the time we gave our presentation on engagement strategy recommendations to the board and staff of The Mountaineers, the entire team was on the same page about goals, priorities, opportunity and urgency, and they were ready to dive in.

What Does Technical Discovery Look Like?

KAREN: The Mountaineers were ready to go, and the next step was technical discovery. Sally’s going to tell you about that.

Agile

SALLY: Before I dive into the details of technical discovery, I want to give a quick overview of Agile Software Development - we’ll be using Agile terms and concepts in the rest of our presentation. - How many of you have heard of Agile? - How many of you have experience working on a project that used Agile? - How many of you are not using Agile, but are thinking of switching to it?

Things Change

Priorities Requirements

Personnel

?!?

SALLY: In software development, as in life, things change. Priorities shift, requirements come and go, key stakeholders move on and are replaced. With an old-style, “waterfall” development process - with a rigidly defined, highly specified plan - change is expensive and possibly disastrous.

Graceful Change

SALLY: Agile methods were invented to handle change gracefully. Agile is a way to structure, plan, and control the process of creating any software application. There’s an old saw, that projects can have only 2 of the following 3 things: fixed time, fixed budged, and fixed specifications. With agile projects, you fix budget and time and allow the specifications to evolve. Agile is the most reliable way of delivering what a client needs on time and within budget, and using an agile process was key to this project’s success - it let us adapt to changes and shifting priorities quickly.

Agile Essentials

User stories Iterations Communication

SALLY: Agile has 3 essential ingredients: - User stories are used to efficiently define requirements - Iterations provide a mechanism for incremental development with continuous testing - Lots of team Communication is built into the process

We’ll be saying more about iterations later, but in the discovery phase User Stories are the critical ingredient.

User Stories

As a <role> I want <goal>

so that <benefit>

SALLY: User stories are the fundamental unit in agile software development. They are: - Brief - traditionally, short enough to go on an index card - Testable by users - Define features in “who”, “what”, “why” terms

There will be stories for many different roles, for example staff, site users, content editors, etc.

SALLY: Back to technical discovery: In this phase of the project we needed to translate all the information we learned in the strategy phase - the Mountaineers superpowers, their goals and priorities, the activities that need to be supported - into requirements for their website.

Requirements Gathering

SALLY: There are lots of ways to gather the information need to generate a requirements list: 1 on 1 interviews, meetings, written materials that the client has created. My personal favorite is to have a brainstorming session - a non-judgemental environment where stakeholders write their ideas on sticky notes, organize them on the wall, and prioritize them with colored dots.

The Business Requirements Document

SALLY: Another way is to hire an analyst to create a Business Requirements Document, also known as a BRD. This can be very helpful, but the downside is that analysts can get carried away with bullets, sub-bullets, and sub-sub-bullets. A formal Business Requirements Document is a snapshot of the requirements at a particular point in time, and it is unwieldy to update as things change. And remember, things *are* going to change. So it’s best not to over-define your requirements.

The ideal deliverable from a requirements gathering process is a simple list of sentences that briefly define the features in end-user terms.

Requirements List

(screenshot of Ryan’s list)

SALLY: Because of all the strategy work that Groundwire had done, there was no need for a separate requirements gathering process. Groundwire had already turned what they had learned into a requirements spreadsheet, shown here.

Turn Requirements into User Stories

SALLY: Once you have a requirements list, no matter what format that takes - BRD, sticky notes, spreadsheet - the next step is to translate it into the user stories that will form the basis of an agile process. This is done jointly by the client and an implementation partner who understands both agile and the target technologies.

User Stories

SALLY: The deliverable from user story definition is called the “Backlog” - a list of user stories in priority order. Here are a few examples of what The Mountaineers user stories looked like.

We’re not co-located so we couldn’t use the traditional index cards. We used an online system that let us define stories, order them by priority, pull them into iterations, assign them, tag them, mark their status, comment on them, and do a task breakdown. We also used this system to estimate the stories (the gold numbers on your right) which we’ll talk about in a few minutes.

All this work on user stories gave our team the information they needed define the Technical Architecture for the project. David is going to tell you about that.

Technical Architecture

DAVID: One of the deliverables in our planning phase is a document describing the planned technical architecture. This is a high-level sketch including things like: - what platforms are we using and why? - what add-ons or plugins do we anticipate using? - if there are multiple platforms, what is the approach for sharing data between them? - where will the final product be deployed and hosted?

We write this toward the end of discovery when the developers really understand the project.

It is not meant to be set in stone, but a snapshot of the plan at this point in time. The plan may change -- maybe you need to work with a new implementation partner, or maybe a key technology choice becomes invalid due to a newly discovered requirement -- but this document provides a basis for evaluating those changes. It’s also useful for beginning to plan for ongoing costs of running the site.

Product vs. Platform

DAVID: Choosing tools for custom development requires a different mindset than choosing a third-party software product. Product - Does it do everything in our requirements? Is there good support? Platform - Is there an ecosystem of plugins/addons? Have others built similar solutions with it? How hard is it to customize and extend? Is our implementation partner familiar with it and do they like working with it?

How many of you have had to decide whether to go with a Product or a Platform on a project?

The Mountaineers Platform

DAVID: Our platform choices: - Plone CMS. Lesser-known, more enterprisey cousin to Wordpress and Drupal. Mature, flexible, open source. Jazkarta knows it well. Organizations that use Plone include the FBI, KCRW.com (which won a Webby last year) and many

universities. - Salesforce CRM. Flexible, cloud-hosted CRM platform available at a discount to nonprofits, with lots of third-party integrations. Percolator knows it well. - Stripe payment processor. Hosted service. Good API, can accept credit cards directly so you don’t have to worry about PCI compliance. - ACUMEN Book Publishing. Mountaineers’ existing book inventory/fulfillment system. Proprietary software from CyberWolf, runs on server in Mountaineers office.

Key factors influencing our choices: - Strong volunteer leadership in the organization meant we needed lots of flexible control over who can do and see what, which Plone is great at. - Better content management was a key motivator for doing the project, but they also didn’t want to lose good reporting and integration with other services like email marketing. So we looked for a way to integrate CMS and CRM. - Strong desire to integrate book sales with activity registration.

Are these the right choices for every project? Absolutely not. Are we happy with how things turned out with our choices? Yes. Would we choose the same things again today? Maybe.

How big is it?

SALLY: By the end of discovery, one question is uppermost in any client’s mind: How big is it? How much money will it take to implement my website?

Bad Estimation

http://xkcd.com/1658/

SALLY: As shown on this XKCD comic, developers hate estimating things because it is such an inexact science. (The suggestion here is to start with a realistic estimate, and start multiplying - which doesn’t work well if you can’t come up with a starting estimate.) Fortunately Agile has a better way. With Agile you can answer the “how big” question using either a bottom up or a top down approach.

Bottom Up

SALLY: The bottom up approach is to estimate the total project budget from the sum of all the user stories. To do this we must estimate each user story.

Planning Poker

SALLY: We estimate stories using “Planning Poker” - a consensus-based, gamified technique for estimation. The developers learn about the stories from the client, play cards with their estimate given in “story points”, discuss differences and come to consensus on an estimate. Story points are relative - something like shirt sizes S, M, L, XL - not days or hours.

Planning Poker

SALLY: This is a screenshot of the tool we use to play planning poker online. Planning poker is time consuming, with lots of discussion to clarify what the stories mean. All this discussion has benefits:

- The team coalesces and establishes communication norms. - We all develop a mutual understanding of the project. - Developers gain an understanding of the project. - The client gains an understanding of what things are easy and what things are hard. This helps them prioritize the work

From the total story points we can estimate the total budget, based on the team’s past performance

[Details if anyone wants to know how:]

Team Velocity = # Story Points / Iteration # Dev Iterations = # Story Points / Velocity # Deploy Iterations = .1 * # Dev Iterations Budget = Cost per Iteration * (# Dev Iterations + # Deploy Iterations)

Top Down

SALLY: The top down approach is to start with a budget, and do as many user stories as you can. To do this, we move estimation into the implementation phase, and estimate the highest priority stories in batches as we go.

To some extent, this is what happens anyway, since more user stories are always added during implementation when the budget is cast in stone.

Hard Choices

SALLY: But as the Rolling Stones said, “You can’t always get what you want…” We’ve never seen a project where the client was able to implement all the user stories they had envisioned with their available time and money. Organizations are always faced with hard choices - what to leave out. In the case of The Mountaineers, they decided not to develop a mobile-friendly responsive design as part of the original project. They set fundraising goals to be able to add it later - and in fact we’ll be working on it this summer.

And speaking of design - now Karen is going to tell you more about the user experience and visual design on this project.

UX & Visual Design

KAREN: Once you’ve established everything you need the site to do, the next step is to figure out exactly how it’s going to work and look for your users

Developers & Designers: Coordination is Key

KAREN: Extensive communication between UX designer and developers is key! One great luxury that we had in this project, and that we’d recommend for other similar projects is that once the meat of the user stories was done, the detailed User Story definition and UX wireframe design happened in parallel. Sometimes stories came from wireframes, sometimes wireframes came from stories. Darrell Houle was our UX designer for this project and he participated in many of our project standups and was an integral part of planning and implementation.

What good UX process looks like

KAREN: Here’s a user flow diagram from the project which gives you a sense of how specific you want to be when charting complex functionality. We had pages and pages and pages of these, and they were critical in implementation.

One million wireframes

KAREN: We had wireframes for all of the different types of pages. The developers reviewed them for problems (impossible or too expensive to implement) and to make sure they completely understood them. In this particular example, the wireframe shows a calendar rendering that ended up being too complex to implement. The UX designer and the developers were able to talk through alternatives, and come up with a solution that met the designer’s requirements for usability without breaking the system or The Mountaineers’ budget.

The Value of Visual Design

KAREN: As for visual design, you can spend a LOT of money on it, and going back to The Mountaineers’ board chair’s quote about lipstick on a pig, visual design can’t make up for your website not working well. However, strong visual design is important for inspiring, attracting, and delighting your audiences. And in the case of The Mountaineers, whose very large, very vocal, sometimes challenging board that was footing the bill of the website project, it can make everyone proud of their investment.

Visual Design: Creative Brief

KAREN: Neal Maher was the visual designer on this project, and one of his deliverables, which was so helpful for all of The Mountaineers’ stakeholders, was a creative brief. Before he did any design for the project, he produced a creative brief which reflected back all of the criteria he had gathered from The Mountaineers team on what would make the website visually successful. Everyone signed off on his goals and criteria, which meant that when he presented his initial design, everyone was in agreement on how they would judge that design.

KAREN: When The Mountaineers’ board saw the initial homepage visual design, they all smiled. And their support was incredibly important to the success of the project.

The Build: Timeline, Process

& Shifting Priorities

SALLY: Now we’re going to talk about actually building the site, the implementation phase.

Timeline

May June July Aug Sept Oct Nov Dec Jan Feb Mar Apr

May 6, 2013

May 5, 2014

Launch!

20 Development iterations

UX Design Visual Design & Theming

Data Migration

TestingDiscovery

SALLY: This graph gives a high level overview of the project timeline - Discovery began in March, took 2 months of focused work (after many months of initial conversations). - Launch was not the end, but the beginning of a new phase of ongoing development (more on this later). - Implementation took a year, during that time we had 20 development iterations - one every other week, with some breaks for holidays and vacations. - UX design started during discovery and finished about halfway through implementation; visual design started up soon after that. - Theming - applying the visual design to the site - happened section by section, as the visual designs were approved. - Staging deployments and testing were continuous throughout the project. - Data migration was a big effort, more on that later.

● Jeff Bowman, Project Owner ● Sally Kleinfeldt, Project Manager ● David Glick, Carlos de la Guardia, Cris Ewing, Plone

Developers ● Chris McCullough, Karen Uffelman, Strategy Consultants ● Matthew Scholtz, Nicolas Campbell, John Fine,

Salesforce Developers ● Kevin Brooks, HTML/CSS developer ● Darrell Houle, UX Designer ● Neal Maher, Graphic Designer

SALLY:Here are the team members that implemented this project, and a bit about their roles. - Project owner: Single point of contact, domain expert, decision maker, available for meetings - the team’s ability to make decisions in an agile way depends on this person. - PM: Facilitate communication, record decisions, understand both client and developer worlds, translate client requests into developer language - really good for this person to have technical knowledge of CMS and CRM. - Strategy consultants: Extensive client knowledge, make sure decisions support strategy goals. - Plone and SF Developers: Technical experts, open minded, honest about implementation difficulties and alternatives. - Designers: Part of dev team, need feedback on design implications.

Iterations

Timeboxed Highest priorities Testable product

SALLY: More about iterations. User stories are implemented in a series of short iterations: - “Timeboxed” - Fixed hours, cost - Always be working on the highest priority stories - Results deployed to staging server for testing

User stories in an iteration: - Focus communication on what we are working on - Developers get the story details during the iteration - “just-in-time” details - you don’t want to waste time on them before they are needed because things may change - Too big? Break into several stories

How it Works

from: extremeprogramming.org

SALLY: This is a high level picture of how Agile works - with the backlog of user stories feeding in from the top to the cycle of iterations at the bottom. Some important advantages of this approach: - The team addresses the highest priorities and biggest risks early. - The focus is always on what is most important at each point in the project. - We know that things will change, and this iterative approach allows the team to adjust course in response to new information. - This process demands LOTS of communication, so misunderstandings and surprises can be kept to a minimum.

What happens in an iteration?

S M T W Th F S

Iteration planning

Standup Standup Standup Standup

Demo

work in progress

testing & bugfixing

SALLY: This picture shows the flow of work in a typical Mountaineers iteration: - On Monday we had a planning meeting where we chose the user stories to work on, assigned them to developers, and clarified any questions. - Tuesday through Friday we had daily “standup” meetings where everyone gave their status: what they did yesterday, what they’ll do today, any blockers. - Remember that user stories are brief - this is where the details get fleshed out, through Q&A in these meetings. This is where the “just in time” feature definition happens - we postpone discussion until the point when we know the

most we’re ever going to know about a user story - just before we implement it. Each iteration we used a total of 80 hours:

- 50 hours were used by Jazkarta to do Plone work, the CMS. - 30 hours were used by Percolator for Salesforce CRM development and strategy advising.

The majority of the hours (65) were used to implement stories in the development week (green). The rest (15) were used for bug fixing during the testing week (orange). Now over to David to tell us more about data migration and testing.

Special Snowflakes

DAVID: If you have data in an old system that you want to move to the new one, data migration is a significant consideration. It’s hard for a few reasons:

- Every database is a special snowflake. - It takes time to run, if you have much data. - You’re not going to get everything right the first time.

Data Migration

Run migration

TestFix

DAVID: There is a tradeoff which is that you want to minimize the time during which you have to enter data into both systems, but it takes time to make data migration run smoothly. We used an incremental approach. We implemented stories for migrating particular types of data (i.e. as a member, I can access my profile copied from the old site). The outcome of each story was a form where Jeff could import data whenever he wanted, on a recurring basis.

One important affordance was that we stored the old record id from iMIS (the old system) as part of the new records imported into Plone and Salesforce, and made the migration scripts match existing records based on that id. This meant that Jeff could re-run partial imports to update some records without worrying about creating duplicates.

The result of this approach was that data migration could happen over 6 months rather than a week, and there was plenty of time to test the system with realistic data in place.

Testing

Testing is important to make sure that the finished system works without error and that it does everything it needs to. We did a few kinds of testing: - automated tests to prevent regressions in functionality (could have done more) - testing each iteration’s stories during 2nd week of iteration -- Jeff spent a ton of time doing testing… - extra testing during final 2 months of project...involving a couple dozen people coordinated by Jeff, looking for launch blockers. Jeff put together a video to introduce the project to them.

Bumps in the Road

KAREN: Every big website project includes some bumps. But there are things you can do to mitigate them.

Executive Commitment

KAREN: One of the best defenses against project challenges is executive buy-in. This is a picture of Board President Eric Linxweiller and (former) Executive Director Martinique Grigg - both were 100% committed to and involved in this project, which was critical to its success. A big project like this deserves and needs the attention and care of your executive decision makers.

Choosing Your Project Partners

KAREN: Choose your project partner like you’d choose a spouse. Experience and expertise is, of course, important. Examples of past work that you love, and great references are good indicators that you’re hiring the right people. But equally important is trust. And choose partners that you like as people, because you’ll be spending a lot of time with these folks.

Contingency Planning

KAREN: Contingencies: You may have heard of the “10 Essentials” - these are the things that you should never go on a hike without. Similarly, there are a few things that are critical to consider when you embark on a big website project. 1) Make sure you have a good discovery process that is well-documented. 2) Make sure that whatever platform you’re choosing, there’s more than one person in the world who knows about it and can work on it. 3) Make sure you have redundancy on the staff side - if someone goes on maternity leave or moves to Tahiti, who is next in line internally to manage the project and how are they kept in the loop? 4) Have a contingency fund. 5) Give yourself a little margin for launch (don’t plan to launch the day before a critical event).

What Happened in this Project?

KAREN: The Mountaineers had great executive buy-in, as I mentioned, they chose a partner with great care, and they had great practice around contingency planning. But even with all that, they had a massive project challenge. The partner consulting shop, Groundwire, which they had so carefully vetted, all but closed its doors just after completing the first round of technical discovery. Switching horses mid-stream during a big website rebuild is one of the worst things that can happen, but because the executive leadership of The Mountaineers was paying close attention to the project, they were nimble when it was time to make the decision to change consulting shops. Because they had chosen a partner team they liked and trusted, they had project team members who were committed to helping The Mountaineers transition to a new project partner (and in fact, some of us who were on the original team continued to work on the project in new capacities). They had invested in a robust technical discovery with good documentation, so the new project partner wasn’t starting from scratch, they had some contingency funding, and they had space in their launch timeline. So - definitely not ideal, but even a big challenge like losing the primary consulting partner didn’t sink the project.

The project doesn’t end at launch...

JEFF: So, on Cinco de Mayo of 2014 we officially launched the website, had a party that afternoon, and then immediately went back to work on the website the next day. It’s now March of 2016 and that work has continued.

Dealing with bugs, etc.

JEFF: Most of those improvements, right after launch, were fixing bugs. With a website as complex as this one, you expect lots of bugs even after launch and you need a system to process them. We use Github, shown here.

Collecting User Feedback

JEFF: And after you get all of the bugs fixed, it’s time to check in with your most important users and see how the site is working for them. We instituted a feedback collection system using UserVoice, which was very successful and meant that our site visitors could easily give us feedback when something wasn’t working for them. We also invested in having Percolator facilitate focus groups with our volunteer leaders, to help gather more feedback and prioritize short-term needs and phase-two enhancements. Because we had a limited budget for our initial launch, we ended up cutting a few corners that our volunteer leaders weren’t happy about. So the focus groups were not only a great way for collecting feedback, it also made our volunteer leaders know that we valued their input and assured them their needs were a priority for our ongoing work on the new site.

Does the launched website ACTUALLY work?

JEFF: Did the new site work better than the old site? The answer to that question was a resounding yes. In the first year post launch, we had 69% more unique visitors, 72% more page views, and a 23% reduction in bounce rate. The average session duration also decreased, which for us, was a really good sign. It meant that people were finding what they needed on our site instead of being hopelessly lost and that our most involved website users – our volunteers – were able to do things faster than before.

Does it continue to work over time?

JEFF: And our ongoing work is making a difference, too. Comparing this February to the previous year (removing the extra day from this year just to be fair), we are STILL seeing a 39% increase in users and a 10% increase in page views. We have about 30,000 unique visitors coming to our site each year. Our average session duration continues to decline, indicating a better experience for our most-involved members. The bounce rate continues to decrease (a good sign as well), indicating people are liking what they see on our site. All of our work has paid off in a big way, and we know that if we continue to make improvements, our stats will keep improving.

Long-term Budget

KAREN: For any of you planning a similar type of project, or for technology spending generally, this is a great graphic to consider. Credit for this graphic goes to Sam Dorman who wanted to describe what he kept seeing with organizations and technology budget. Most nonprofits, although this is changing, think about technology investments as discrete expenditures. Need a website? Get a one-time grant. Need a new database? Ask a major donor to write a check. The problem with this approach is that technology ages and an organization’s needs evolve. Everyone is happy for a short while after the project is completed, but then they become less and less happy as the tool or platform works less and less well. You spend a lot of money, and yet you’re mostly dissatisfied with your technology. Sound familiar? A better approach is to not think of your technology needs as being solved by big, Herculean efforts that happen every few years, but as an ongoing program that requires ongoing resourcing. Make sure your technology evolves with your needs. This is what The Mountaineers are doing. Since their initial launch in May of 2014, they integrated their book publishing arm, added event calendaring, and over the next few months will be launching new functionality to support their youth programs and finishing mobile development.

In Conclusion

Engagement strategy + robust technical discovery + agile

development + strong UX and visual design + the right

project partners + executive buy-in and internal leadership +

contingency planning + commitment to ongoing development

= GORGEOUS, HARDWORKING SITE

JEFF: I hope this session has given you some insight into what it takes to do a complex website project. Engagement strategy + robust technical discovery + agile development + strong UX and visual design + the right project partners + executive buy-in and internal leadership + contingency planning + commitment to ongoing development

= GORGEOUS, HARDWORKING SITE

Please Complete the Feedback Survey!

Evaluation Link: http://po.st/mxsS9Q

JEFF: You can access our feedback survey from the mobile app or from the NTC website. Here is the link.

Questions?

Jeff Bowman IT Manager The Mountaineers jeffb@mountaineers.org

Sally Kleinfeldt Director of Consulting Services Jazkarta sally@jazkarta.com

Karen Uffelman Principal Percolator Consulting karen@percolatorconsulting.com

David Glick Architect/Developer Jazkarta david@glicksoftware.com