You might have heard about different frameworks for managing projects, like your website redesign. Let’s break these down and understand the distinctions and advantages of each.
First came the Waterfall
You’re probably already familiar with a waterfall project management framework. If you ever worked with, or even seen a Gannt chart, this is your clue. Gantt charts, spreadsheets, anything of this nature indicates a waterfall structure. This framework has many advantages and has the benefit of being intuitive. It is built on project phases and dependencies, so that phase one should come first, then at some point phase 2 begins, then phase 3, etc. This system relies on a certain portion of work being completed before another dependent portion, and progress continues chart wise from left to right, top to bottom as tasks are completed (thus the name waterfall). This is an intuitive way to work, as tasks one month out depend on the results of work being done now - and there’s no sense getting resources (people and their time) engaged in work that can change as the project progresses. And, resources can enter or exit the project at predetermined times, so teams members have a better feel for their commitment and can schedule their time accordingly.
The downside of this approach is that in the real world projects don’t progress in a linear, smooth fashion. Despite best laid plans, objectives, criteria, and even purpose change over time. It's dangerous to assume that you’ll know what phase 6 needs to do 6 months before it starts - decisions are made today that change what happens tomorrow, next week, etc. Software engineers that used the waterfall approach found that something was happening with their projects - assumptions were made, users weren’t consulted, requirements were updated while changes choked their workflow, and timeframes and budgets blew up.
Enter Agile
During the 1990s a group of software engineers started to develop a new framework. They developed a set of core principles and oriented their projects around objectives that prioritized speed, experimentation, collaboration and empathy with user needs. Rather than develop requirements around a fictional understanding of objectives, they spent time with users, understanding needs and expectations, and then set about working very quickly to design and build prototypes that satisfied those needs. These prototypes don't solve the entire problem, just a part of it. It prioritizes speed over completeness or polish, trying to get a version in front of users quickly. Work is performed simultaneously with other work, not waiting for something to be completed. Feedback from users is gathered regularly, developing a deeper understanding of the product, lessons are learned, and and iteration continues. The amount of time that can be spent on phase is restricted – unlike the waterfall approach that devotes weeks or month to a phase, an agile phase is typically 1-2 weeks. This accelerated pace is known as a scrum or sprint, depending on your preference. It can be a sense-making sprint (research), a design sprint (sketching/building rough mockups), or a development sprint to build a rough prototype. The priority is on speed - rapid development of ideas leads to testing, learning from mistakes, refining and prototyping again to get a better version. Proponents of this framework are convinced that it saves time, budget, and leads to massive improvements in their deliverables.
Are there downsides? Sure. In my experience, teams that aren’t well-versed in agile struggle to stay focused on the present – they obsess over what happens later. If they’re used to a more deliberate pace, the speed of agile can leave them behind. But most problems associated with agile development have to do with management, not process. An experienced, functioning agile team can execute on time and on budget and deliver results that are better suited to user needs. Also, software engineers typically work in a culture that accepted agile long ago. So those working outside of the development team must trust the process, even if they don’t fully understand it. Your IT team might be well versed in agile, but what about everyone else? Will your organization embrace the perceived uncertainty of agile? Will they go along with your assurances that where we end up will be great, but no one on the team can explicitly define what that is?
So, which is best for your website redesign? Well, it depends.
My view is agile is clearly best for experienced teams. But what if your team isn’t experienced? I don’t think it's a good idea to impose a new framework on a team for project that needs to start now, leaving no time for initiation or practice. Website projects are very large undertakings, and for many schools they are infrequent So, no time to prepare, learn to work in different way, with roles, responsibilities and a pace that seem foreign. Many team members will have no experience with a project like this, and may not work on one again. But the benefits of agile are significant - what to do?
I’ve developed a preference for a hybrid approach. My hybrid assumes that what people like about the waterfall - the ability to see the length of each phase, and understand what is happening in those phases – is essential and needs to be preserved. That means an execution plan is developed and updated as the project moves forward. It can even resemble the beloved Gantt chart. So far, so good.
But inside of those phases some things are different: we implement an agile approach to speed up the phases, reaching milestones that are centered around evaluation and iteration over refinement. We re-orient the traditional focus groups into a design thinking workshop and explore user needs, moving through ideation and simple paper prototyping with our users. We shorten the time available for design and review, preferring to see quantity over quality. We move laterally initially before moving longitudinally.
And we decouple phases so that we’re free to let the process evolve and change. Dependencies exist but remain flexible - the UI flows out of the UX organically, through the experiences of our workshops with actual users. We know what works early (we used to do user testing only after the concept and mockup had been approved and front-end fully built – madness!).
Is this the best way forward? For a particular kind of project it can be. A higher ed website project is a mix of one-time events, serendipitous moments, and standard, predictable steps, overseen by people with straightforward expectations about timelines, budgets, and deliverables. Combining the best of both worlds could be the best framework for you.