Trust us, you need process.

Many companies we work with think they have a process for producing digital work. In reality, what they usually have is a loose workflow.

There is a big difference between having a workflow — a series of steps you generally take to achieve an outcome — and a process — documented, trackable, and repeatable series of steps that always achieve the same result.

While there are applications for general workflows, they are hazardous when it comes to building and scaling your business or department, because steps that are “known” but not articulated can disappear with personnel or disintegrate at the level of individual interpretation.

So [before we get gritty about some of our favorite tools and systems,] here are the top three reasons you need process and two major beliefs that lead to its resistance.

Processes can be repeated

A key part of having a process is writing it down. Writing things down forces you, the author, to translate nebulous ideas into specific steps and events that are clear and precise. Once the steps are specific and documented, they can be repeated by different team members.

“Repeatability” tends to break down most often when a new requirement or team member is introduced into the mix. When there is no documentation to begin with, the impact of change is not readily understood. Work moves from repetitious to “ad hoc” as individuals begin to apply their own solutions.

A truly repeatable process provisions for changes. Not only is the process itself documented, but it includes steps to take when a change is introduced that is not part of the process. An open policy for “raising flags” actually gives team members the comfort they need to identify problems early and openly, and helps to ensure issues are addressed as best as possible.

Changes that are tracked this way can later be adopted into the governing process if they prove to be more than edge case circumstances.

Processes can be communicated clearly to others

Another benefit to having a documented and repeatable process is that individuals can communicate much more easily. It provides a common vocabulary for team members and managers.

A quick example from web development is the process of converting a creative concept into a web page. When a team member indicates this task as “complete” does it also mean that it has been tested in all required browsers? Does it mean that animations have been implemented? Have all breakpoints for different screen sizes and devices been addressed?

Even if these steps are implicitly understood between certain developers (usually senior ones) that have been working together for some time, new or less experienced team members may not be familiar with tacit expectations. After all, “converting a PSD to HTML” could be construed as complete by virtue of the HTML file existing!

This kind of misunderstanding has the greatest impact when deliverables are tied to project milestones — such as client reviews. Imagine your client is expecting to the see a preview today of their new web page but cannot view it in Safari, their preferred browser?

Was it communicated to client that cross-browser performance would not be included in the preview? If not, was it communicated to the developer that cross-browser performance was a requirement of the ticket itself?

These problems don’t just go away when you write them down, they actually forge a consistent two-way understanding between production and account services for setting and managing expectations.

Processes produce the same results

The truest measure of having a process versus a workflow, is whether you produce the same result each time you execute it.

When you have a documented and repeatable process that everyone on the team understands and can communicate easily, it greatly increases the chances of producing consistent results.

Documented process is the opposite of a “black box.” It makes the inner workings of a task or project explicit, rather than mysterious. It clearly maps inputs and outputs and convergence points and allows for team members to be swapped in and out with little interruption to the work.

“Head Trash”

As a manager or business owner you might not be connected to just how desperately your team needs process.

One way to evaluate this is by honestly assessing the nature of your current internal problems.

Do any of these situations sound familiar?

I keep losing great employees because they are tired of “always being the one who solves problems.”

My team’s morale is low due to constant “firefighting.” (putting out fires small and large on a daily basis)

Delivery timelines and the quality of output differs drastically when different team members perform the same type of work.

While implementing a process-driven approach can be a benefit for anyone doing any type of business, it is exponentially more important when you are in web or software development. If you’re battling inconsistent results, bad attitudes and high turnover, it’s a sure sign that you need process.

Perhaps you’ve already determined that a process-driven approach is necessary, yet you still have reservations?

Human beings are expert at translating emotional resistance into rational reasons why process (change) won’t work. Two of the most common objections we’ve encountered are: the thought that putting work into a specific process reduces or removes creativity from the equation, and that process doesn’t really add more value, it simply adds more paperwork.

Let’s take a deeper look at both.

Process stifles creativity

It’s a misconception in general that software or web development is not a creative exercise. Nothing can be further from the truth. Programming inherently deals with solving problems, and whenever you solve a problem you need to be creative.

While process means documentation and repeatability, it does not mean removing creativity in performing the work. Process is about defining boundaries and being specific about the nature of the work being performed, the documentation required in doing the work, and the results the work should generate.

Putting boundaries around creative work is easier than it sounds. A good example in web development is the necessity of creating wireframes or system workflow diagrams — an exercise that is both creative and consultative. While process cannot define exactly how this work is done, it can necessitate its importance (setting out to build a database without a map is a very bad idea) and insist on it as a precursor to other steps (i.e. before a developer spends days coding only to discover they missed a critical validation or data capture requirement). Process can also establish boundaries for time allocation (do not spend more than x hours at this phase without express approval) and introduce standard questions / requirements checklists to guide the upfront information gathering consistently.

Process only adds more work

Another common objection to process is that it interferes with actual work, or adds more work vis-a-vis the requirement of documentation, communication, or progress updates.

Quite often when developers think about performing work they think about it in the best case scenario — where there are no unknowns, where the work is not hindered by feedback, where there is no change introduced. Thinking about our own previous projects, it’s difficult to recall a scenario where one, if not all, of these complications did not come up.

While all work is started with best of intentions, new requests come up, unclear concepts emerge as significant changes when they become more clearly defined, delays are introduced. Simple tasks invariably become slippery slopes and with important deadlines looming overhead, pressure mounts quickly and mistakes get made that only compound the issues.

Consistent and clear processes prevent problems by accounting for problem areas. A relevant example would be a documented coding standards process. Most programmers would agree they spend significantly more time reading and interpreting code than actually coding within any given assignment. This is especially true when developers are introduced into a project mid-stream, or need to go back at a much later stage in the project and make changes to lines of code that were written early on (think: what did I eat for breakfast three weeks ago?). Having a clear coding standards process can significantly reduce the amount of time needed to make changes or perform maintenance or updates to a project that has been completed, and removes the dependency on any single developer on the team (no single point of failure).

So while it’s true there may, in fact, be more work upfront, more documentation, or more midstream communication required, in the end, these checkpoints actually consume less time (and cost less) than redoing work altogether.

In Conclusion

Process is not just a mechanism for making things work better consistently. It’s also the lynchpin to scaling a business or department without inheriting more headaches and, ultimately, it’s a one-way ticket to freedom (or in the least, better work-life balance).

Probably you already have established processes in other areas of the business. For example, HR and employee onboarding protocol has likely been well-documented. Maybe there’s even some relic of a new employee training “handbook” at a department level?

But it’s precisely this “process for some things but not for all” approach that leads to problems. Because the absence of process in end of itself suggests that no standards are required when approaching that task (otherwise, wouldn’t there be a process like there is for other stuff?).

Speaking as employers, there’s almost no circumstance when standards don’t factor. Most of us sell the value of our services based on our standards. And yet, what are they if they aren’t written down, communicable and reliably delivered by our own team?

While it can be a big change (and initially a big effort) to move to a process-for-everything approach, the benefits realized once implemented pay off big in dividends. Team members are clear on how the work should be done, progress can be easily measured, and results can always be relied upon. Additionally, team morale goes up, new employees of all skill levels can be easily introduced, and seasoned team members are much less likely to burn out and leave. And what price can you put on happier clients, a relaxed team and a harmonious working environment?

written by @suzanneabate and @andrewbodis for The Development Factory.

This read is an advance chapter from the forthcoming book How to Build a Digital Department: Practical Steps for Insourcing Web Development.