Need a robust process? How about starting with a checklist
robust [roh-buhst]: strongly or stoutly built.
checklist [chek-list]: a list of items.
Struggling to create a process that produces a quality end product every time?
Something as simple as a checklist may be your starting point. It apparently has worked for hotels. If you’ve heard about Peter Pronovost, then you’ll know the value it has brought to healthcare.
What does a checklist accomplish? It ensures that each step of a process has been followed. In terms of the Plan-Do-Check-Act cycle, the checklist lays out the initial Plan of what to Do, and depending upon the process, can also provide all of the necessary Check elements to ensure that the process is meeting the desired outcomes.
I was not a software developer by education. So when I began developing Thrive, I had to establish a way to ensure that when I developed a new feature of Thrive that the end result was something that was created with a minimal amount of defects (bugs) and with a maximum amount of value to the end user. Nobody wants to do something twice…I don’t even want to discover a bug, and the worst scenario is when defects reach the end user. The checklist I created attempts to prevent defects from being created in the first place, but also tries to uncover them before they’re “out the doorâ€.
From a software development standpoint, my checklist involves two core elements, with sub-lists under each main area. Summarized, it looks like this:
- Database Development: create data structures to support new feature, check impacts to existing data, create data necessary to support UI elements
- User Experience: UI feature layout, interface logic and interface with data, user navigation, user security
This has worked incredibly well. It has even worked when creating custom, “one-off†applications. It ensures that everything is considered, even if it is not necessarily relevant to the current feature. The checklist doesn’t cover every possible development scenario, but it probably covers 95% of them. And when the outliers arise the checklist can get refined to ensure that the process remains solid.
While a checklist is not standard work, it can certainly be the starting point, whether in manufacturing, healthcare, government, or services. It shouldn’t be difficult to get people together to determine a basic process checklist quickly. From there, a more robust standard work can be developed.
Don’t think lean principles or standard work can be applied to the development of software or your IT department? Alan Shalloway and Tom and Mary Poppendieck would beg to differ.
UPDATE
Found some new checklist resources on Harvard Business Review: What Sort of Checklist Should You Be Using? and an interview with Dr. Atul Gawande on Using Checklists to Prevent Failure.
John Hunter says
Automated testing is a key also. Creating tests then writing the code can be good (but creating the test before you consider the code for that feature complete and push it to staging is necessary). I also did not start out in software development but the rise of agile software development has brought into the software development world a systemic view from my background (Deming based management). I write about managing and software development on my blog http://management.curiouscatblog.net/tag/software-development/
Scott Sorheim says
John,
Thanks for the comments! I have seen your blog before (and am now a subscriber). I have also seen your Management Improvement Carnival floating around the Internet also. Thanks for stopping by!
-Scott