A codified project methodology serves to set expectations for the client and the team on what is happening when and in what order. However, a project methodology is not meant to be a rigid “one size fits all” set of tasks. Rather, it should be a framework for creating success in a project and should be adapted to the solution, team and client. Bringing in new techniques or refining existing processes enables the team to deliver the right solution to the client in a timely and budget-conscious manner.
A formal codified Methodology provides many benefits to both client and Agency, including:
For the Client:
- Defines the process and what is happening and in what order
- Sets expectations as to what will be delivered and when
- Provides for iterative touch-points where clients can redirect the project/program while it is on paper
- Allows clients to participate in the process and take ownership of the end-result
- Allows for incremental client exposure to the final solution, engaging the client in the end-result
For the Team:
- Provides a set of repeatable steps which allows the team to focus on the unique elements of the solution, rather than on how and why they are going to do things
- Provides a set of templates and tools enabling them to deliver quality work
- Enables teams to know their roles and what to expect of their peers and their clients
- Provides a clear set of deliverables and processes by which their success is measured
Methodology in Action
That being said, Teams need to recognize that a project methodology is not meant to a rigorous, finite set of steps that are set in stone. Rather it is meant to be a framework that Teams use and scale to fit the client problem, solution and need. At its best, the project methodology offers a safety net to the project manager and team providing the framework for the types of questions that need to be asked and answered.
The 4 Phases (Define, Design, Develop and Deploy) and the various sub-phases and tasks outline the steps that need to be taken. This framework is just that, a structure in which to construct ones thinking and to set expectations. Each project has to be mapped to this framework and scaled accordingly. Some project may go through every step in minute detail, while others may skip them. Some steps may take hours while others, may take days or weeks. However, by going through the process of thinking about each step and deliverable the team makes conscious decisions and takes action, not forgetting steps along the way.
However, not all projects can afford a team of 10+ and take months to deliver. Teams need to learn to scale both up and down according to the project. When too focused on the process, teams can forget how to be nimble which is almost as bad as teams working in a chaotic vacuum. In smaller projects with rapid turn-around and few resources the team must adapt the methodology to the problem and focus on the end-result. This can take the form of omitting a deliverable, or delivering it less formally, or spending less time. Regardless, as long as the revised process is communicated to both client and team and expectations are set the project can be delivered successfully.
In contrast, Agile teaches us to focus less on the process and more on the collaborative and iterative approach to developing the final solution. Working in short sprints allows the team and the client to see the solution as it is being built rather than in iterative steps. Agile Methodology has its proper place, but its philosophy can inform and influence a more formal iterative (waterfall) methodology. Teams can use Agile to develop functionality during the Development Phase in iterative steps allowing for the team to surface issues along the way.
Regardless of the project, teams need to know the rules so they know when to follow them and when to deviate. Knowing how and when to use the tools in the tool box is the hallmark of a solid team which will deliver value to the client and their customers. And this is the reason we are here in the first place…