Recently I conducted my first-ever post-mortem at the end of a long Web site redesign project. The post-mortems in which I’d participated in the past were half-hearted affairs, with a tendency to become mired in finger-pointing and nit-picky details. In this post-mortem, my client and I wanted to examine what went both right and wrong and apply those learnings to future projects. So many times after a project we’re all off and running on the next thing. This was an unusual chance to pause and reflect on everything we’d accomplished together over many months.

Admittedly, I was nervous. As the consultant, you always worry that there are unspoken dissatisfactions waiting to storm out of the closet if given the invitation. What if I had misread the success of the project, and the client was just waiting to pounce on me? But there was no pouncing. Our fortune was that we had a small, collaborative team, a few smart cooks in a very large kitchen, and we’d all worked together unusually well  — it was one of the great successes of the project. We knew each other well enough to be candid without needing to finger-point. Because of that, we could focus on an open discussion that led to many good discoveries.

Our post-mortem methodology
Before the two-hour session, I distributed a somewhat in-depth questionnaire to the team and asked them to review it. Part 1 used a 1-5 ranking system and focused on the different phases of the project. Team members were asked to rate to what extent they agreed with statements about each phase: “The discovery phase effectively informed the remainder of the project” or “Enough resources were allotted for the visual design phase.” Part II focused on success factors — teamwork, communications, etc. — and asked open-ended questions about what we did right and wrong in each area to facilitate discussion.

Rather than complete the questionnaires, team members used them as a guide to prepare for the discussion. Then we walked through each area and used the questions as a way to talk about what worked and didn’t work. At the end of the discussion, I put together a short summary of our discussion with recommendations for the future.

What we learned
It’s easy to believe that the “learnings” from a project should have already emerged after nearly a year of meetings, emails and impromptu discussions. But a focused, two-hour reflection as a team can really help to crystallize some of these discoveries into a few beautiful lightbulb moments.

Of course, we focused heavily on time and resources. I wish we’d had more time or I wish we’d had more people to help were the most-often repeated phrases during our two-hour session. These were legitimate wishes: certain phases of the project were rushed, and in some areas the burden fell on a couple of already overworked individuals. But in Web site redesigns, these complaints are par for the course. I’ve worked on redesigns that involved one person and hundreds of people, projects with $0 budgets and $2 million budgets. There’s never enough time. There’s never enough money.

But there were a few fundamental things that emerged that could have made the project more successful in spite of the time and money constraints. Here were a few of our major a-ha’s.

Requirements should become before budget. The budget-first, requirements-gathering later method rarely works. Unfortunately, it’s usually the way things are done in corporate environments, because budgeting is usually completed the year before a project can kick off. It is the way of things. But what happens is that rash decisions are made in the spirit of thriftiness — and declarations such as, “our design will be really simplistic, we won’t need that many templates” or “we can do all the content and production in-house, that’s why we have a full-time editor” can mean major danger down the road. If planning for a Web site redesign, try scheduling your discovery phase in one fiscal year, then use it to inform a realistic budgeting process for the actual design and development of the site in the next fiscal year.

Content should come first. This has been the biggest lightning bolt for me this year, and the reason that I am refocusing my entire business toward Web content strategy. What happened during this particular Web project was what almost always happens: we scheduled the content development phase for the latter third of the project, and because of lack of resources, it actually got pushed to the last fifth of the project or so. One person, in-house, was responsible for writing or cleaning up all the content, because budget for a resource to help had been one of the first things to be slashed in the project planning. But inevitably, we started to have problems as soon as we began wireframing and visual design. As the site development progressed, it became apparent that we hadn’t planned for “real” content in our page designs, resulting in having to go back to the drawing board a few times to get it just right, and still having to tweak as we were building pages near project launch. Nightmare, right? But it’s all too common — and the reason why content should be planned carefully and at least partially developed before beginning page design. I’ll be writing more about this in future posts.

Testing is good. More testing is better. I was awfully proud of our team for embracing the idea that user testing, done early, was essential and could save the entire project. And though we were crunched for time and money, we built a prototype and testing our site design, IA and navigation with a handful of users right as we were still working out visual design and before we coded anything, a move that would make Steve Krug proud. But during the post-mortem, the IT lead on the project suggested he would have benefited from testing again, later on, once the site was really working. A complex new registration process, combined with a brand new prompt for members to log in to read certain content, meant a whole new experience for site users — and made our IT folks quake in their boots before launch. Everything ended up working smoothly, but later testing would have assured us a flawless transition and helped us address any potential bumps in the road.

Recognize when schedule slippage may compromise quality. This is a tough one, because in Web redesigns there’s always a “drop-dead” launch date toward which we’re working. The dirty secret is that a site very rarely actually launches on that target date. That’s because in a project this complex, dozens of variables come in to play, and each participant must complete each task on time, or the entire project slips. When one piece is delayed, other pieces are compromised. Along the way, we all work toward the supposedly non-negotiable end, so often when the schedule slips we make the decision to make it work, to speed up the next task in line in order to make the launch — compromising the quality of the pieces that follow. In our case, when IA took four weeks instead of two because of the amount of feedback we received, we found ourselves rushing through wireframes so we could hand off design more quickly to our production vendor — but in the end that rush delayed us anyway, because we had to go back and do it right. It’s better to recognize when we need more time and realistically evaluate whether we might need to push back launch accordingly — rather than waiting until the last minute to decide to delay the go-live.

Even though each one of us was already out of the frying pan and into the fire after launch, it was so refreshing to take some time revisit the project as a whole and reflect on how we did. It was an unusual opportunity to celebrate our overall success, but also to dissect the areas where we stumbled and understand why. After all, isn’t every project just another learning experience and chance to keep growing professionally?