An organization pays out the nose to a designer to get a gorgeous website with all the bells and whistles. It launches to great acclaim.

Day 1 post-launch comes. Does the organization have the structural supports and processes in place to support what will be needed over time to keep the site healthy, usable, compliant and effective for the audiences it’s trying to reach? Did leadership even know to ask that question?

Admittedly, it’s not a fun question and a bit of a killjoy to ask when people are energized and excited in early planning about the bells and whistles.

Still… somebody has to be the grounding voice in the room during such discussions.

It’s possible as a web professional to effectively walk the line between promoting excitement for a new product AND keeping leaders grounded in the need for the necessary internal structural supports and processes. 99% of the time leaders simply do not know what is needed for the longterm success of a website and too many times, web professionals are hesitant to speak up (higher education, as with other industries, can have a rigid pecking order).

I see it as my responsibility to draw on my experience and provide the data that gives leaders the information they need to make informed decisions about such large expenditures while keeping that excitement for a new product. It’s possible to do!

In my current role, I took the first several months on the job to build structures and processes for a full web support system from the ground up for a unit that supported almost 37 websites (largest number at VCU for any one unit). This was a difficult sell as a priority at a time when their web properties were in significant need of aesthetic attention and badly out of compliance with WCAG standards. Despite this reality, it was necessary to take a step back to make sure the architecture for web success was in place. I was able to successfully convince leadership of the need to build atop a firm foundation rather than the shifting sands on which their operations were shakily existing at the time. As a result, I have been able to deliver consistent web service to all CHS entities in an efficient and timely manner. Furthermore, because the boundaries of service are thoughtfully designed and based in data and resource availability, clients understand and appreciate the level of service I can provide because expectations are clear.

Below are some of the tools I used to build this structure.

• Atlassian wiki documentation accessible to all content managers, faculty and staff with full details on
  • Services provided and not provided
  • Definitions
  • Web policies
  • Expectations (roles and responsibilities)
  • Onboarding web managers
  • Resources for effective site management (e.g., accessibility, image optimization, etc.)
  • How-to guides for custom plugins and other common web tasks
  • Project timelines
  • And more!
• SiteImprove for tracking and managing quality assurance, accessibility and sending monthly reports to content managers
• Kaltura Capture and Awesome Screenshot for screencasting (a tool used in how-to tutorials for the web) and screen captures
• Google Forms for managing web requests, intake of annual site reports, etc.
• Cherwell ticketing system for handling web requests from the broader university community
• Trello for managing large projects and collaborating with others
• Slack for communication and collaboration with others in the university community
• Bitbucket for managing code base