The question of efficiency or quality seems to come up a great deal in the digital creative business. It is routinely asked by both clients and agency management and is not an easy one to answer. There is a deceptive amount to learn about what these two concepts really mean and how they affect the way agencies are run and the way clients make decisions. For most of my career, I was unaware that I was even making a choice between these two approaches and have recently begun to think very critically about this question. At Playground, this has become a central question to our business, one that is reshaping the way we are structured and how we build projects.
In this first of a two part series on this topic, I will cover the question from the perspective of an agency like mine. I will identify why the question is important and how it manifests in process and management. I will also try and answer the question and discuss the direction we at Playground have chosen to take.
For an agency there are two established ways of organizing, and this choice is at the heart of the question I’ve posed. Many agencies use what is known as a matrixed model of organization that seeks to provide maximum efficiency and utilization of employee and company time. It does this by having employees only organized by department rather than teams and each employee works only when their phase is being conducted. In the matrixed approach an employee will quickly move from one project to another not seeing any through to completion rather only contributing for a short time. If needed again the employee is brought back for short stints and bounced between projects quickly as needed. It creates a situation where an employee is working on multiple projects at once and their time is prioritized by management.
Without knowing it, most managers and agencies adopt this model not really knowing why and assuming it to be the most logical. In fact this model largely comes from industrial thinking, where a company treats each employee as a machine in their factory. The conclusion managers come to is to run each machine at its maximum capacity at all times thinking this will yield optimal results. Unfortunately, this has the effect of maximizing the efficiency of the employee while decreasing the efficiency of the overall project and company. In this model managers focus on local optimization of employee time rather than overall optimization of project and company goals. The advantage of this model is it will often lead to reduced costs for clients upfront and allow employees to experience multiple projects in a short period of time. The disadvantage is a lack of focus, time, teamwork and commitment that greatly hurts the overall quality of a project.
The second model, and I would argue the far more effective approach, is to use dedicated teams. In this model employees are focused on only one project at a time and see it through from start to finish. The immediate negative that many clients and managers see here is that at each phase of the project there isn’t always enough work for each employee to do. This appears to create downtime where the employee would not be working or would be able to choose to not maximize their time. Using the dedicated model explicitly demands a greater respect and trust for each employee. Rather than assuming employees want to reduce output because they “don’t care”, the assumption becomes that employees have the same business goals as the clients and agency owners, which is to build the best product and therefore result in the success of the agency. This shared goal leads each employee to seek out any problems in the project or process and regardless of their position feel empowered to help solve them. It leads people to focus on the end result rather than appearing busy at all times. This model is inherently more expensive as a team must be booked for the entire duration rather than individuals for short durations. The argument is that increase in overall time paired with the focus and teamwork this model allows creates vastly better results with less overall risk to the client.
It is important to see how these concepts look when they are moved beyond conceptual thinking and into real projects. Although the case for quality is strong when examined through the lens of a project, the choice becomes more complicated due to the large increase in project price. Below I will explore the same project and team through from the perspective of both models.
Our fictional team has been tasked with creating a an e-commerce site for a well known clothing company. This will be the client’s first online store and the agency will need to design and build the complete project from start to finish. The agency will have 5 people work on the project in total, a project manager, UX designer, visual designer, frontend engineer and software engineer. I will describe each phase of the project below, what team members are working, and an approximate amount of time required.
In this phase the Project Manager and and UX Designer work with the client to create a detailed understanding of the requirements for the project. They come to understand the client’s business and the competitive landscape. Together they plan out the project and the UX designer builds a wireframe of the site for review with the client. Once approved the UX designer moves onto another project within the agency checking in from time to time on the progress of this client when she has time.
In this phase the Project Manager and Visual Designer work together to establish the design direction for the new site. Once approved the designer then works with the wireframes to create all the necessary pages and assets for the site. When this phase is complete the designer moves onto another project within the agency.
At this phase the Project Manager works with the frontend engineer to begin building out the site based on the designs provided. Reviews are done with the client to show progress as pages are created. Part way through this phase the Backend Phase may begin and overlap to save time. Once all the pages have been created the Frontend Engineer moves onto another project leaving the Software Engineer to complete the development.
In this phase the Project Manager works with the Software Engineer to build out the major systems and 3rd-party integrations. The engineer works from the spec outlined in the discovery step as well as from the available frontend work to create all the necessary systems. Once complete the Software Engineer continues into the next phase.
In this phase the Project Manager and Software Engineer work with the client to deploy the site and get all the necessary content in and ready. During this time many issues with the systems may be found and fixed by the Software Engineer. As this is the first opportunity for the client to go hands on with the system it is not uncommon for major oversights to be found.
During the beta phase detailed testing is done by the client as well as the Project Manager and Software Engineer. Issues are found and fixed prior to the site going live to the public. As this is the first real beta period it is likely that many issues will be found and this phase can be very unpredictable. Although assistance from previous team members may be required to make changes at this step it may be difficult for them to move back to this project, even for a short duration.
In this phase the Project Manager works with the client to ensure a smooth transition of assets and control of the project from the agency to the client and their technical team thus concluding the project.
In this example the project took around 28 weeks from start to finish and used 34 billable weeks plus project management costs. The difference in weeks is accounted for in the potential overlap of the development phases as outlined above. This model appears to be an efficient use of time and it likely saved the client money upfront. If no major issues or oversights happened it may even have resulted in a good final product. In this example many things could have gone wrong that would have in the end cost the client a great deal more. For example a lack of upfront assessment by all disciplines often creates oversights or issues with the concept. Additionally a lack of teamwork prevents any real collaboration and makes it difficult for people down the waterfall to suggest ideas. This lack of teamwork fosters a lack of personal investment on the part of employees leading to lackluster work that is prone to problems. This model also prevents any iteration and feedback until the very end. These issues create a high potential for the deployment and beta phases to dramatically increase in time to allow for large scale changes, additions and fixes. It also may not be possible to get the team members back who originally worked on the project to conduct those changes as they may be on another project. Overall this model decreases quality while increasing risk, providing clients with a better price upfront but at a serious cost to project quality and assurance.
In this sample our team is tasked with creating the same project as above. Again the agency will have the same 5 people work on the project in total, a project manager, UX designer, visual designer, frontend engineer and software engineer. The difference here is all team members will be present from start to finish and will follow a more agile methodology.
During the discovery phase the project team takes on different responsibilities. While the Project Manager and UX Designer may still work together to understand the business and market, the rest of the team can conduct other helpful research. The visual designer can evaluate the company’s design language and existing material while working with key members to discuss ideas. The engineers can work with the client’s technical team to outline the options and test different tools and approaches. In the end the project team as a whole is well-versed in the project’s goals and client information, and has received valuable feedback. Additionally, the client is more engaged and is better prepared to start the project with clear expectations.
In the concept phase the team works together to rapidly prototype early ideas. Rather than creating the project solely as wireframes or design mocks, a functional prototype easily conveys to the client the proposed solution. Technical challenges or opportunities can also be identified early on to prevent future issues. The end of this phase is a clear direction for the team to move in on both design and technical fronts. Again the client has had hands-on experience with the product and can provide valuable feedback and insight.
During the build phase, team members work together to design, implement, test and get feedback from the client. This agile approach has the benefit of allowing for iteration and collaboration between team members and the client. If the team follows test driven development it also mitigates the need for a dedicated beta phase later. In addition, by providing the client with a working version of the project as they go, much of the deployment phase and content entry can happen during the build phase.
A final deployment and testing phase allows the team and client to evaluate the final product prior to going live. This phase should be much shorter than in the matrixed model and with fewer surprises.
In the handoff phase the entire team works to ensure a smooth transition from the agency to the client team. This allows the teams experts to train and help the clients teams to takeover operations.
This example project took 24 weeks to complete and used 96 billable weeks plus project management. While the project is completed a month sooner than the previous example it used roughly 3 times the number of billable hours. This would likely result in a considerable increase in price for the client over the other model. It also has the effect of decreasing the projects risk and increasing the quality of the end result a great deal. It is difficult to quantify just how much better the end result is in this example, but in my experience it is fair to say that it is vastly better. Surprisingly it is the reduced risk and not the quality that I find many clients are interested in. In this case risk covers a few major categories: effectiveness, stability, deadlines, scope increases and brand reputation. Using this model ensures a more usable end product for users and admins. Through testing and iterating a more effective product can be created — in this case that may be one that converts better and is easier to manage. Test driven development and focus can lead to greater technical stability. Better upfront assessment and prototyping leads to fewer scope increases and a product that makes its deadlines. Finally the overall quality preserves and increases the reputation of the client’s brand which is often the most critical risk for a large company.
While I would have hoped that the answer was clear to this question, the vast increase in cost for the dedicated model makes this much more difficult. What I do know is that for Playground, quality is the clear answer. From our perspective, building the best products with the least risk and with a more enjoyable process is an obvious choice. From the perspective of our clients the answer is more complicated as many of them simply do not have the budget or experience to choose quality over efficiency. In my next article I hope to outline the question from the client’s perspective and answer if quality is always what is right for them.