I started working on the web in 1999--before there were specialists in web, like UX, Content Strategy, and even Project Management. Back then, we came up with an idea and just ran with it. We didn't get caught up in our process, and we certainly didn't create deliverables that led to a full website or product. We dove in and got it done. Were we Agile? No. That wasn't a "thing" either.Something about "how we used to do things" is really appealing to me these days. Figuring out a problem and prototyping it seemed like the best way to get to a final product. Was it ever really done? No. But that was okay, because we were okay with iterations. Maybe we were agile (with a lower case "a").
Over the last 10 years, I've worked in places that handled building websites in different ways. The one thing they all adopted was a more drawn out, waterfall process. One that relied on one decision to lead to the next in chain of events, or milestones. Sign off on one milestone meant we proceed on the next step. Projects were carefully planned and build one highly crafted, well thought out deliverables like site maps, wireframes, and user flows. Each was iterated on at least 2 times, and was discussed to no end. How could they not be? Each was going to be finished forever and would dictate the rest of the project. It made sense. We were making smart decisions. But were we over-thinking things and, in turn, not being flexible?
I've come to realize that, while I have always been invested in a smart, measured methodology to get to a final decision or product, I have always been the person to over-think things. After all, I am a project manager. I'm risk-averse. I want things to go smoothly and I want to support a process that will support that ideal. Waterfall works! Why change it?
We need to change it because we wouldn't be doing our jobs as digital project managers if we are not supporting innovation. That innovation doesn't just come through a cool technology or a feature; it comes through creating and/or supporting new methodologies, processes, and workflows. Sure, it can be a bit unnerving. But, when you work with your team to craft a process that might be a bit out of the ordinary and you understand the related risks, you'll do everything in your power to take the steps avoid those risks.
To be clear: thinking about risks is never over-thinking. Not taking on a new process because you're too worried about the risks? Well, that could be over-thinking. But, when things get real, you need to be comfortable with the work you've taken on. No matter what you do, you have to be willing to take on some risk and open to doing something new.
So jump in: skip a sitemap, deliver a design first, design in code. You're going to learn a ton of lessons the first time you do it. That's how you'll get better and evolve your own process. It will be totally worth it.