Three days after Stanford’s commencement on June 12th this year, we quietly launched a completely new website for Stanford’s School of Engineering. From start to finish, the web project took 10 weeks. This project included new design, new feature development, content migration, and feature and browser testing. In the end, the site launched smoothly with no downtime.
Its success with an aggressive timeline can largely be attributed to two factors: 1) the agility and dedication of a high-performance project team; 2) the conscientious design and technical architecture decisions that Stanford Web Services made previously on the product on which the new site is based: Jumpstart Engineering.
Previous School of Engineering homepage
Addressing The Need
The previous Stanford School of Engineering (SoE) website used Drupal 6 as its CMS, which reached end-of-life on February 24th, 2016. With no active development on a replacement website, each passing day the School of Engineering's previous site presented a growing security liability and technical debt. Furthermore, the previous website had an outdated design -- it first launched approximately 6 years ago -- that was not mobile friendly in an era where currently 30% of the website’s traffic comes from mobile devices.
To address the immediate, practical concerns of the website, the project team within Stanford Web Services (SWS) collaborated with School of Engineering stakeholders to develop the “Quick Strike” plan: to leverage a website product previously developed for the School of Engineering and launch a new school website in less than 3 months.
Stanford Web Services has a core product line known as Jumpstart, a Drupal 7-based “website-in-a-box” that is available to Stanford organizations, such as departments, labs, centers, and programs. In Spring 2015, Stanford Web Services formed a partnership with Stanford’s School of Engineering to develop a Jumpstart product that would cater towards SoE “PICAL” groups -- Programs, Institutes, Centers, Affiliates, and Labs -- to address a growing need in the SoE community for a scalable, secure, mobile responsive, and Stanford Engineering-branded web platform.
JSE was designed and developed with PICALs in mind, with features and a site architecture structured around people, courses, publications, research, and resources -- content that is very different than what would be the focus on a school’s website: news, events, admissions, alumni relations, and more.
To meet the aggressive timeline of Quick Strike, we knew that we could and should leverage the existing framework that JSE already provides: data models, features, mobile responsive homepage and page layouts, branding and styles, authoring roles, security (through upgrading to Drupal 7) and more. After an evaluation of the gaps, we estimated that JSE would fulfill over 80% of the needs for a minimum viable product (MVP) for a school site.
New School of Engineering homepage
To fill the remaining 20% gap between what JSE offered and what the stakeholders envisioned for a new, launchable school website, the project team defined areas of improvement that offered the highest return on investment, segmented into “Minimum Viable Product” (MVP), defined as a site launchable with 0-days notice:
- New custom website theme that focused on color and typography changes
- New masthead design on top of an existing JSE homepage layout
- Integration with the Community Academic Profiles (CAP) system for automatic people information management for 275 faculty profiles on the website
- Streamlined and simplified site architecture, and culled over 230 outdated pages
- Separation of intranet onto its own site, simplifying permissions, maintenance, and navigation
- Migration of all core school site content: homepage, news stories, faculty profiles, admissions information
and “Minimum Lovable Product” (MLP) reach goals:
- New design and features for news, which affected over 900 news stories
- Implemented an improved search solution, Apache Solr
- Migration of secondary school site content: faculty awards, student programs, and other tertiary pages
The Quick Strike process embodied the essence of agile and scrum. In addition to the standard sprint framework of scrum (with sprint kickoffs, reviews, and backlog grooming), the team also embraced the tenet of self-organizing sub-teams to quickly tackle tickets and smash blockers. As project manager and scrummaster, it was my responsibility to communicate clearly and closely with the project team to understand and remove all impediments, including reprioritizing their other commitments and removing them from any meetings they weren’t necessary to attend, and to also maximize their focus/productive time.
New news listing page
Because we operate on a 2-week sprint cycle, there were only 5 sprints available for the project from kickoff to launch and therefore intra-sprint meetings within the team were essential to move and communicate quickly. In addition to daily team morning scrums, we also added an end-of-day scrum on our “focus days”/”no meeting days” (Wednesdays). Furthermore, we had dedicated working meetings on Mondays and Tuesdays to facilitate communication and quick resolution of questions or issues that arose mid-sprint.
At the end of each sprint, I evaluated our progress and coordinated with the product owner to adjust priorities as necessary. And once we were 1.5 sprints (3 weeks) away from launch, the requirements for bringing into a ticket into a sprint became more stringent: each ticket had to pass validation: “Is this a blocker to launch?” or it would not make it into the sprint.
Prior to launch, we conducted cross browser and mobile testing, accessibility testing, and quality checked the content several times. Our developer handling the launch coordinated with the various other IT infrastructure and administration groups around campus to ensure that the necessary people were on standby during the launch in case any mishaps occurred, and that a contingency plan was in place for each point of failure.
During the launch, there was an issue with securing and transferring the virtual host (vhost) for the site, and we followed our contingency plan successfully with no downtime. After the vhost issue was resolved, our developer quickly re-coordinated the teams to reattempt the launch.
Three hours after the originally scheduled launch time, we smoothly launched the new School of Engineering website to the world.
Redesigned news story page
Since launch, we’ve had over 16,000 visitors with 42,000 pageviews and to our pleasant surprise, have not received any notice of complaints and issues. Anecdotally, the reception of the new site by the SoE community has been positive.
Our mobile device visitor ratio has increased by 15% since launch (from just under 30% to now over 34%), which reflects positively on our improved mobile experience.
We plan to continue to monitor the traffic and stability of the site, and will compare the analytics pre-launch vs post-launch to look for trends. Having accomplished everything we had planned to address with Quick Strike MVP and MLP (security, stability, mobile-responsive design, improved search, improved faculty profiles), the stakeholders and development team can dream big from scratch for Phase Two work on the school site, and also rest assured that Drupal 6 end-of-life risks have been mitigated in the meantime.
Quick Strike was the quintessential result of agile, scrum, lean startup, and MVP practices, and was also one of our team’s most ambitious and aggressively timed project to date. There were many firsts accomplished with the project that came as a result of not just “failing fast,” but also “recovering fast,” and the success of Quick Strike reinforced the benefit of our team’s early investment in developing a scalable product and platform.
Look forward to our next big projects leveraged from Jumpstart!