I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.
My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.
You can read or view all the posts in this series through this link.
Insight: The primary sources of imprecision are Communication, Thinking, and Execution
I believe there are three primary areas in which we can find imprecision in software projects:
- Communication
- Thinking
- Execution
Communication
I have observed that common software engineering terms used on projects such as Requirements, Engineering, Quality, Design, Architecture, Testing, Schedule, Plan, Risk can be misunderstood or misused by various stakeholders. Imprecision and sloppiness in our language contributes to faulty actions and poor outcomes. I have observed several instances when I have confused Quality Assurance with Testing, Risk with Issues, and Plan with Schedule.
We cannot deliver Quality products on the foundation of weak communication. Our language must represent the preciseness that software demands from the teams. During my exploration to understand the word requirement, I found that there are several competing definitions and each one of the definitions highlights a particular aspect of the term. There is a lot of nuance and significance surrounding this deceptively simple term. This holds true for the other terms I listed out as well.
Let us say we do a quick survey of the project team and ask them to define the word requirement. Are we confident that all of them would provide an answer that is in the same ballpark? What are the effects on the project if various stakeholders and team members hold divergent opinions on what constitutes a requirement? It is important to be aware of such divergent viewpoints and determine ways in which we can precisely communicate our thoughts and ideas.
Thinking
A lesson I have learned from Jerry Weinberg is that our mental models shape our actions and communication. Let us think about the word defect. What does it mean? We can think about defect as any deviation from the requirements document. We can also think about defect as a deviation from stakeholder expectations. I believe we can observe demonstrable differences between testers who hold these different beliefs. Each one will approach their work and craft differently based on these beliefs. Their actions and communication will reflect their different mental models.
The same applies to other aspects of Software Projects. What are our mental models around Leadership, Project Management, Design, and Architecture?
Execution
I have observed that it is easy to fall in love with technology and forget the end goal of a project. The goal for projects is to deliver a product that stakeholders find valuable. Once we lose sight of the goal, it is easy to fall into certain traps – We may start equating “code complete” to “complete”. Once we fall into such a trap, our plans and communication of status will not be credible. “Code complete” by itself does not add any value. The value is in delivering the product!
We need to estimate, plan and prepare schedules keeping the end goal in mind. We need to keep asking ourselves, what does done truly mean for this particular project? Is it done after we complete writing the code? Is it done after we run our automated suite of unit tests? Is it done after testers have evaluated the product? These questions help us evaluate and understand if we are closer to achieving our goals or farther away.