The Mountaineers is the premier outdoor education nonprofit in the Pacific Northwest, with over 10,000 members and over 2,000 volunteer-led courses and activities every year. Their website, mountaineers.org, is the critical link between their members and volunteers and the outdoor learning that the organization offers. When they embarked on a major upgrade project, they took a holistic view of how they had used technology in the past and how they wanted to use it in the future. They had a clear vision to guide them: the website had to be deeply engaging for their target audiences, and easy for volunteers and members to use; and it had to simplify and improve as many of their processes as possible. In this session from the 2016 Nonprofit Technology Conference, we’ll describe the life cycle of this major website redesign project: - Defining the strategy driving The Mountaineers mission and website - The requirements discovery process, including a huge community engagement effort - The technology choices we made and why - The importance of user experience (UX) design - The agile process used to manage development - Managing data and content migration, testing, and site launch - Website support and ongoing evolution Along the way, we’ll highlight the practices that made this project so successful.

1. 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.

2. 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!

3. 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.

4. 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?

5. 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.

6. 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.

7. 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...

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

9. 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.

10. 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!

11. 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.

12. 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.

13. 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.

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

15. 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.

16. 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.

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

18. 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.

19. 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.

20. 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

21. 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.

22. The Strategy & Vision
KAREN: The Mountaineers started by investing in a strategy process.

23. 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:

24. 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.

25. 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.

26. 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.

27. 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

28. 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.

29. 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.

30. 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.

31. 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?

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. 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.

42. 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.

43. 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?

44. 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.

45. 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?

46. 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.

47. 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.

48. 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.

49. 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)

50. 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.

51. 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.

52. 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

53. 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.

54. 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.

55. 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.

56. 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.

57. 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.

58. 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.

59. The Build:
Timeline, Process
& Shifting Priorities
SALLY: Now we’re going to talk about actually building the site, the implementation phase.

60. 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.

61. ● 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.

62. 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

63. 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.

64. 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.

65. 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.

66. 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.

67. 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.

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

69. 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.

70. 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.

71. 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).

72. 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.

73. 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.

74. 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.

75. 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.

76. 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.

77. 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.

78. 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.

79. 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

80. 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.

81. 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