Software is a process that’s executable by a computer. As a software developer, Gozynta is a process creation company above all else. We write code that executes business processes for our customers, we write business processes for ourselves to follow, and we write documentation to help our customers follow the right processes for using our software.

Here’s what a software (process) development life cycle looks like:

You start with Requirements Analysis: What is the goal of the process that I’m writing? Once you think you have the requirements right, then you move into the Design phase: What are the steps I need to take to reach that goal? (an outline). This quickly flows into Implementation which is turning your outline into a document that someone can follow. Lastly you test your process and then the cycle repeats.

So let’s write a process for making breakfast.

Requirements Analysis:

I want a bacon and eggs breakfast.

Design:

Ok, bacon and eggs. What else do I need to know for this process? How much? How do I want my eggs cooked? I think 3 slices of bacon and 2 eggs will probably be good, let’s try that out. Also, we’re going to need butter to cook the eggs. At this point I’m just deciding arbitrarily on quantities, we can optimize that detail easily in future versions of the process.

• Take ingredients out of fridge
• Melt butter
• Cook bacon/eggs
• Serve

Implementation:

Here we flesh out the details, and make it more clear for our readers. Photos (screenshots) would be good here if necessary.

Ingredients:

3 slices of bacon, 2 eggs, and a tablespoon of butter.

• Put bacon in a pan on low heat.
• Melt butter in the second pan, and then add eggs.
• Turn bacon when brown on the bottom.
• Turn eggs when they’re mostly cooked.
• Serve when ready.

Testing/Review/Approval:

In our software development we go through this in multiple ways. The developer writing the code tests as they’re going, when they’re done we have other developers look at it for QA and do some additional testing, then we send it to some customers to beta test it before we release it to everyone. You can/should do the same thing as you develop your process.

In our breakfast example we’ll do the same thing. We’ll try following our recipe, and make notes on things that we think we missed. In our testing we’ll probably find that we need to adjust start times (if we start everything at the same time then the bacon is done long after the eggs and then you’re stuck with cold eggs), that we forgot salt and pepper for the eggs, etc.

In software development we try to strive for the shortest possible write/test cycle times and we have techniques like unit tests that we use to make these as short as possible. In process development this can be trickier, but whenever possible find ways to “execute” small pieces of your process over and over and you’ll be able to reduce your process development cycle time and end up with a better process more quickly.

After you’ve completed your “unit testing” of pieces of your process then you’ll want to do your “integration testing” where you test the whole process from start to finish to make sure all the pieces work together.

Once we think we have all that worked out then we can give the recipe to someone else and have them try it and check their results and tweak the process some more. Every step through this chain we get to a longer and longer cycle time, but every step yields useful results.

You may think that once you’ve had multiple people test your process and it’s been used in production for a while then you can consider that process “done”? Process (and software) development is never done. Once you have a working process you still need to maintain it. You need to check on it periodically and give it a tune up or it will get stale and no longer work properly. We’re still in the SDLC cycle, the cycle has just gotten much longer.

Interested in getting your business process in line?