This article is the start of a new series. The series focus is information I've learned in my years as a technical lead for projects for businesses. I've observed business practices which didn't work as well as described in books and articles. I've told stories about my experiences and I thought I would share some of my observations.
The title of the series, "Theory versus Reality" is from a project I worked on many years ago. I worked with two college interns who wanted to apply information from class to our project. The project involved software development and they would help me with deliveries to our customer. They would ask questions and I would answer them as well as I could. At one time they asked me why we did a task, Task A, differently from how it was described in their classes.
I explained that in the classroom the ideal practices were taught. In those cases Tasks A, B, C and D would occur and they would occur in order. If there were dependencies, B couldn't happen until A completed, C would start once B completed and so on and so on. I said that was the theory of how to do tasks for a project. For our project, we were working with reality and so things were done differently. In reality sometimes C and D would have to completed for a deadline while Task A was held up waiting for an item to be completed. And B might not get done until the end of the project but we still had to deliver C and D to keep things going. I remember both of the interns looking puzzled and accepting that the way we performed Task A is just how we did things.
Over the course of the project I continued to answer their questions, at times explaining the theory and ideal practices as opposed to how we did things in reality. My explanations eventually became our inside joke as we hurried to get deliveries out in ways that didn't always seem to make sense. Eventually changes were made and we did follow standard practices more often. I moved to other projects and the interns went back to college. However, I continue to encounter situations where theory says that things should work smoothly but reality gets in the way and the process is messy.
Eventually I observed that there are assumptions for every process and how it is accomplished. Sometimes those assumptions are acknowledged but many times people take them for granted. When the assumptions aren't met, that seems to be when theory doesn't match with reality. In some cases the differences are trivial. In other cases the changes are significant and seem to require significant changes to the theoretical practices so they match reality. Some people hide the differences and act as if the tasks were accomplished in the theoretical method. When this happens, extra work is usually involved for someone on the project. In this case, lip service is paid to the processes and people focus on getting the work done as well as they can in a broken system
There are many reasons for unmet assumptions, including lack of experience or skills for project's team. That type of issue can be corrected in time. However, I think there are many times when people have built-in assumptions that are not examined and they will continue to use broken processes without recognizing why things aren't working. The phrase "The definition of insanity is doing the same thing in the same way and expecting different results" seems like a good description of this phenomenon.
I've noticed project practices that would benefit from a review of some of their unwritten and unspoken assumptions. The articles in this series will examine business practices in the following format:
- Description of the practice based on theory.
- List of assumptions I've observed that must be met for theory to work
- 'What if' scenarios for real life practices based on modifying or correctly following the assumptions.
My goal is to encourage others to observe business practices and assumptions to find ways to make improvements. By reviewing business practices and questioning their assumptions, project leaders can see if there are ways they can change how they look at the work they do. In my experience, this observation and willingness to be flexible has helped my teams and myself to complete projects in a timely manner, while taking into account budget and quality of the final product. I hope that by sharing this information it can help others to improve their projects.
Pictures taken by J.T. Harpster