A Method(ology) to our Madness

What’s not to understand?

Our responsibilities differ from project to project, and sometimes, even when you think you understand an aspect of a project or a client, you don’t. For many projects, you may be responsible for a single ultimate deliverable – the site launch. When that is the case, methodology is less important because you aren’t “handing off” your work for someone else to implement. However, for projects where you are only responsible for a portion of the site build and your client is responsible for the rest, it’s in your best interest to fully understand how key hand-offs will work.

I’ve been part of projects where the client and vendor thought they had a mutual understanding of each other’s work processes, but when the time came to hand off the work the wheels quickly fell off.

Several years ago, I was engaged with a project that pitted the vendor’s waterfall methodology against the client’s agile (Scrum) methodology. Based on the initial project schedule, the dates for the template hand-offs fell perfectly in line with the client’s sprint schedule. Low and behold, the day of reckoning came and what happened? Big gaps. Picture building a bridge from opposite sides of a river only to find when you meet in the middle, you both had completely different ideas about how you’d make the connection. I could list a number of management errors that led to this result, but the biggest mistake was not taking the time at the start of the project to discuss every step, system, constraint, and test required to make the hand-off work. Instead, both teams managed their projects in a vacuum and made assumptions of each others work, which led to a lot of recoding. Thankfully, it ended well, but not without a Herculean effort on the part of both project teams.

The “ah ha” moment

One of the first questions we ask clients during the first phase of a project is, “Do you have a preferred methodology or project approach?” Before we jump head first into discovery, we want to understand how our client works and if their methodology will mesh with ours. This is as much about understanding one another as it is about defining requirements, firming scope, and kicking things off. If you fail to reach a mutual understanding about your respective working styles, catastrophic failures can result.

The process of identifying the fundamental differences in methodologies and discussing ways to achieve a mutually beneficial approach truly shapes a project. Changes in task order, design and development iterations, resource planning, and testing approaches are all informed by knowing and understanding your respective processes. This discussion should occur early in the project, and because of that, you won’t know all the project’s requirements. Therefore, your first conversation about methodology should be about how you do things and how your client does things. What you’ll be building, while important, isn’t relevant at this early planning stage. You just need to determine how flexible you’ll have to be to make things work.

We recently finished a project that required us to adapt our approach for just about every phase of the project. This modification was driven by the hand-off of templates to our client’s development team, who in turn was responsible for building the content management system and integrating the site pages. When we kicked off the project, we made sure to arrange several meetings with our client’s core stakeholders and IT staff. We discussed process, system constraints, and the client’s internal project schedule. Then, we worked all of those details into the master project plan. At designated points throughout each phase, we met to assess the work and made adjustments as needed. We supplemented our normal testing approach with additional testing cycles – testing earlier and more often than usual to ensure our code married up with the client’s systems. This iterative development approach saved us a lot of heartache, and helped the team make informed decisions for downstream tasks.

You can do it

Adapting your process is not always easy, and doing it successfully requires constant communication and flexibility. You only learn from stepping out of your comfort zone. The pain you might endure along the way fosters growth in your process and the resolve of your team. When you close the books on the project, you’ll find that your client appreciates the partnership because you found a way to work in harmony.

I’ll be the first to admit that an agency’s methodology shouldn’t define their business. We want to be known for the websites we make, not the sprints or phases that lead to a launch. The quiet force behind those successes is directly tied to how you do what you do.

What’s the methodology to your madness?

Back to Top