Task Driven Teamwork Part II: Process and Performance

When we left off last time, we’d finished discussing the overall strategy behind Task-Driven Teamwork, Last Call’s answer to the uninspiring and often ineffectual traditional corporate organizational structure. We learned how top-down management of a business can lead to unnecessary peaks and valleys in the life of a project, because the system itself is not inherently task-organized. We reviewed how the task-driven team is more like a sports club than a corporation, and we discussed the potential pitfalls of relying too heavily on a top-down corporate structure in a creative/productive environment.

Imagine a soccer ball, much like the image above: instead of the military-style, top down organization that most corporations utilize, this model allows for an organic revolution of responsibility. For Last Call, Task-Driven Teamwork is the foundation from which we operate on nearly every level. Web projects, at their very core, have an astounding number of moving parts, and without a task-focused strategy, it’s easy to veer away from the plan in response to the inevitable crop of issues that spring up as the team progresses. Structuring projects, whether they’re creative or technical in nature, based on personnel role and not the task itself, lends to scope creep and has the potential to increase technical debt, which always affects the bottom line, when the project is done.

Let us show you how task driven teamwork facilitates project completion in our organization. From the very beginning, starting with the business development team, we employ the task-driven model to do everything from initiating a conversation with a new potential client to establishing the schedule upon which we’ll base production. This is simplified for the purpose of this post, as these hypothetical scenarios don’t actually reflect a specific project. It’s worth mentioning that having extremely well-defined internal roles plays a major part in the success or failure of the task-driven teamwork paradigm. If your organization has very little role definition, this might not be the best tactic for your clients. At Last Call, the business development team makes contact with a potential client, and after that initial pitch, takes the information provided back to the development team, who then has the opportunity to provide estimates, changes, and explanations about the project lifeline.

This is the first example of task-driven teamwork: business developers are often the ones who end up providing estimates of time and cost, though it’s the development team that has the best understandings of the technical implications of what is required. Who handles which aspect of the task at hand depends entirely about After that, project managers are consulted about quality assurance time, potential time management issues (such as conflicting client projects, holiday closings, etc) and makes any adjustments necessary. At this point, PMs and business development can regroup to review the scope, and if something doesn’t check out, double back if needed. Not only does this process facilitate a reasonable expectation coming out of the scope phase, but it also allows for a more complete proposal coming out of the box, without requiring more time from the client than it takes to decide who to work with. After the scoping phase is complete and the proposal is accepted, project managers step into the forefront of production to act as a liaison for the client and developers, leaving the makers to complete the making and freeing them from worrying about maintaining client communication on top of actually building a product.

Again, this is a very simplified version of how TDT would work in practice— only implementing and experimenting with this model will tell you whether or not it will work for your company. Part three of this mini-series will explore the different schedules that managers and makers should occupy, and why the distinction between the two is crucial for establishing a successful task-driven team.