Congratulations, you’ve finally launched a brand new technical system! After all your blood, sweat and tears, it’s time for your users to log in and discover how much easier their jobs are going to be now.
Wait… where is everyone going?
Many of us at Stanford work on small (but mighty!) teams that require the assistance of outside vendors for expertise and execution. Often finding the perfect match for your project can feel like a difficult round of The Dating Game. With so many fish in the sea it is normal to feel anxious with questions like
You will likely get many different answers if you asked any one person on a development team, designers, subject matter experts, or key stakeholders: "How do we measure the success of this project?" That can be a problem because people are working from too many directions to be considered a team effort.
How successful was your last big project? Chances are, it was a little bit off (hopefully just a little). If we take a look at dozens of projects, some patterns start to emerge. There are some common traps and habits that we all fall into, whether you’re a backend engineer, a CTO, a project manager, or anything in between. In this session, we’ll explore some common obstacles that technology teams encounter, such as:
In the dynamic landscape of decentralized organizations, effective collaboration and communication are paramount. However, establishing seamless channels between multiple teams can be a significant challenge. Coordinating meetings with all stakeholders often proves difficult, leading to undocumented decisions and information gaps for those unable to attend. Additionally, the format of meetings may not always be conducive to comprehensive understanding and thoughtful analysis.
Enter the Request For Comments (RFC) process.
“Back in the day” web development was all about Projects. Project Managers met with clients to gather requirements and then worked with designers and developers to meet those requirements within a set amount of time.
In today’s world, more people are working on web “Product” or “Platform” teams where they are serving the needs of both site editors and site visitors while running continuous integration and continuous delivery/deployment processes.
A couple of years ago, the H&S Web team split its time between running new projects and responding to support requests on live sites. Today, the support work has shifted. From a reactive place, we've moved to a more proactive model.
One of the cornerstone practices has been our maintenance reports, which we are now calling our continuous care reports. Three times a year, we reach out to our units and share a report containing what feels most relevant to their ability to keep up the health of their sites.
The contract is signed, the project team is defined, and goals are set. So you’re probably thinking, let’s kick the project off. Although it’s exciting to jump in and make progress on a new project, there’s a lot to think about before getting started.
The marketing department at Stanford Health Care is responsible for the content in an extensive and dynamic web ecosystem, including 10 websites containing about 25,000 pages of content. This session will explore the tools and processes involved in the creation, publication, and maintenance of web content within a consensus-driven organization.
“We need to think about accessibility before we start any of our work, before we write any line of code, at every step of our development lifecycle. Shifting left means thinking about accessibility at the start of every step we take when we deploy new software or services.”
