Don’t Go Chasing Waterfalls: Project Management Standards
There are many different approaches to project management, and it can be hard to know which is right for your team. Whichever approach you choose to take, it’s important that everyone understands and is committed to the methodology.
Waterfall: Works Great until Something Changes
For years, the state of the art in project management was the Waterfall. In a Waterfall project, the scope of the entire project is laid out in advance. Charts show what pieces are contingent on other pieces, to show the order in which tasks must be completed. The focus is on a predictable process with little to no room for change in goals or timeline.
If you have perfect planning and set-in-stone scope, Waterfall might work for you. More often than not, though, Waterfall projects tend to deliver what the customer thought they wanted six months ago. Which very, very rarely is what they actually need.
Agile: Zen and the Art of Web Development
In contrast to Waterfall’s strict pre-planning, Agile methodologies take a more Zen view of things. It recognizes that projects change, and that change can be positive. These changes can be driven by evolving market dynamics, new client requests, and the agency technical discoveries. Most importantly it recognizes that the implementation process is a learning process—build, measure, learn.
Instead of seeking to eliminate change, Agile emphasizes being able to react quickly to changes in parameters or scope. Teams work in periods of concentrated effort (usually called “sprints”) to deliver a minimum viable product.
At the end of each sprint, the team should have a complete product to show the client. Then the client can make suggestions to iterate on the product for the next sprint.
For example, at the end of your first sprint you might deliver a bare-bones version of the client site. It’s fully functional, but missing features. Then you can work together with the client to plan what will be implemented in the next sprint. This creates a climate of constant feedback and adaptation.
Ken Rickard, Director of Professional Services, Palantir
Our most successful projects are the ones where our clients are involved throughout the design and development process, working alongside our team as true collaborative partners. That’s why we use Agile project methodologies whenever possible. The Agile process focuses on delivering maximum value over the course of a project’s lifecycle, and prioritizes engagement, collaboration, and transparency in service to that goal.
Often, agencies will feel frustrated that the client is changing their mind all the time. And it's true, sometimes clients can be fickle (the customer is always right) but what's more often the case is that the client, or you, the agency, learned something important in the process of implementation. Rather than having this blow up your waterfall timeline, why not embrace this reality and make the most of these learning opportunities?
Angela Smith, Support Project Manager, Message Agency
At Message Agency, we provide support for the sites that we build for a period of time post-launch. We also have a dedicated support team for clients that wish to purchase continued support for their sites, whether built by us or not. Process is key—it’s what enables us to consistently create solutions that address a client's organizational and user needs.
We’ve found the Agile approach to development to be particularly effective during our support cycle. Agile workflows are also well-suited for clients with whom we have firmly established relationships. The short turnaround times and clearly defined goals afforded by the Agile approach help us respond to client needs quickly and deliver new features that satisfy their needs in a timely manner. Agile workflows also keep our solutions lean and targeted, avoiding feature-bloated solutions that the client doesn’t need or want.
The Yin and Yang of Agile
There are two dominant schools of thought for Agile. They’re similar, but with some key differences.
Scrum is a more controlled working environment. Each team member has a role (product owner, scrum master, etc.) and works in short sprints, usually two weeks. Work is prioritized and determined by what will fit within the sprint. This approach is best for scheduled delivery of promised work.
Kanban is less structured, giving the team more ability to focus on single tasks. A product owner maintains and prioritizes a backlog, undisruptive to what the team is currently working on (WIP). When an item is completed, the team moves on to the next project in the backlog. This approach is best for non time-sensitive iterative improvements.
There are many tools to help your team follow a standard project management methodology. Drupal development agency Four Kitchens uses the following:
Harvest for time tracking.
HUBPlanner for people time planning (resource planning).
JIRA for task definition and tracking.
Google Docs for spreadsheets, documents, sharing of documents.
Periscope for amalgamation of Harvest, HubPlanner and Budget data in a database.
Carly Strelzik, Director of Project Management, Modern Tribe
Our approach to project management allows us to progress through our projects in a disciplined way, keeping our internal teams efficient, and our clients confident that we can successfully deliver their projects. The goal is ‘No Surprises’ and we have shaped our workflows around accountability and transparency. We have three teams and need to create consistency of workflow so that people and projects can move gracefully throughout the company.
Our methodology is an ever evolving process. We started with no methodology, applied classic waterfall after the owners took PMI courses, and gradually evolved to a flexible, “wagile” methodology. Our process was defined as we tried various strategies, noted what worked and what didn’t, and tried to improve our efficiency and work product. Today, we tend toward a mostly Agile process when we can, but modify our process to best work with our client’s needs and their internal teams. And we’re still learning and evolving our processes.
Start with a process with which you feel comfortable, and figure out how to measure its success. Measure overhead/non-billable hours, time in meetings, time it takes to complete tasks. Ask the non-PM teams, like your designers and developers, and even your clients, how you can help them be more efficient and happier. Then continue to work, track success metrics, get feedback, and modify so it works for you and your clients. Your outcomes are predicated by your daily habits.