Where most processes go sideways isn’t lost somewhere in the weeds between step 3 and 33— it’s simply setting proper boundaries for the scope of the process in the first place.
It’s not hard to understand why…
Go too wide, and you’ll end up with a seemingly endless list of hundreds to-do’s that are more likely to be ignored altogether than ever completed.
Too narrow and you’ll be drowning in a sea of processes management.
And this, my WordPress loving friends, is where most processes go to die.
The solution to this problem is quite simple— and in the next couple minutes you’ll understand why every process you create needs to start with two simple steps.
Each Process Needs a Beginning and an End
Before you put pen to paper (or fingers to keys) it’s crucial to define the overall scope of your process.
This starts with defining the trigger and the goal.
Withing making a clear distinction on when your process should begin and end, you’re likely to never start, never finish, or miss everything in between.
As you begin to develop a process, it’s important to start with both the beginning (trigger) and end (goal) in mind. These need to be the first two things you define.
It also helps you put things into perspective— keeping you from creating processes with far too many steps (typically you don’t want to go past 30) or so few that they can be easily ignored as insignificant.
When you know both where you’re starting from, and where you’re trying to get, bridging those two points with logical and reasonable steps becomes an easier task.
Your trigger is the signifier that you need to begin your process— like when your doorbell rings; it alerts you to put pants on, look through the peephole, and ignore the unwanted solicitor. Without the trigger (the doorbell) you’d still be sitting comfortably (and pantless) unaware of the outside world.
In order for your process to actually get used, you’ll need to have a clear trigger that tells you when it’s time to start.
An effective trigger cannot be ambiguous— they should be the direct result of a specific condition (or conditions) being met.
Effective Trigger Examples
- Client paid invoice
- Obtained login to DNS records
- Received written approval & final payment
In each of these examples you would be able to indisputably answer if the conditions have been met. If your trigger isn’t something that can be easily answered, then you need to define it more specifically.
Your goal is the milestone you are trying to achieve based on specific actions and tasks.
Whether it’s publishing a blog post, launching a website, or completing routine maintenance— each step of your process should be in support of your ultimate goal.
By starting with the end (your goal) in mind, all the steps that need to be taken and the conditions that need to be met becomes much easier to define.
For a real world example of writing a process without a specific goal in mind, imagine trying to write out driving directions without first knowing what the destination is.
As silly as that sounds, that’s exactly what you’re trying to do if you simply start writing your processes in order from first to last. Before you know it, you’ll be lost.
Putting it Into Practice
Instead of writing out processes in linear order from step 1, to step 2, to step 3 (and so on), try first writing down your trigger, and your goal.
By having clearly defined start and end points, you’ll be able to evenly divide the work up into a set of processes that allow you to travel from the beginning to end in a way that will continue to build on itself with each step, continually pushing you towards a single goal.
Creating a specific routine you can repeat on each and every project you’ll become more efficient, make fewer mistakes, and make better use of your time.
Here are a few common duties web developers could benefit from having a process for:
- Handling prospect inquiries
- Discovery meetings
- Project onboarding
- Setting up a starter site
- Proofing & Feedback
- Website Launch
- Care & Maintenance
To start writing any of these processes for yourself, start with what would trigger you needing to start that process, and what the goal would be at the end of the process.
Some of these processes will feed into each other (like Website Launch to Offboarding to Care & Maintenance). In those cases the goal for the preceding process can serve as the trigger for the next process.