Projects are like roads. Projects have scenic routes, frustrating detours, and assorted road signs. Each project finds a rhythm of its own.
When I work on a project as part of a team, I try to clue into unspoken road signs. Traveling too fast or outside of what the team can handle or wants creates disruption. Choosing disruption is a reasonable option but only for a cause worth fighting for versus causing disruption due to being naïve or unaware of the project signals. When you ignore road signs, you can cause harm or be harmed.
Most projects hit one or more frustrating alternate routes. Budget constraints, hiring freezes, and rough politics create potholes and evoke road rage. Projects sometimes need to be shut down and repaired. Sometimes projects take sharp left turns when major adjustments are required. Some projects remain under repair for long stretches.
Often projects have the same signs that can be found on the road. We pass the green light when budgets get approved. We hit red lights when we find awful critical defects late in the game. And we can fall into speed traps with challenging people dynamics. There are times, when yielding is the more noble and wiser move.
When I watch the highway as I drive I see road disruptions. The driver that is too slow and unaware of what is around him. The driver that is too fast for the pack causes disruption of another kind. There are projects that desperately need someone to stand up and speak, to charter a new course. And I have twice in my career taken the kamikaze route when I felt passionately that a product or project was veering far off course and careening with my beliefs. But most projects don’t take hairpin turns. Most project move reasonably well and flow best when we clue in to the rhythm of the road.
Having the ability to read unspoken and unwritten functional requirements and ask questions is a valuable tester’s skill. Gaining the ability to decipher unspoken signs around a project and understand the flow of activities is a project skill.
All analogies risk being carried too far and becoming silly. Software projects may have existing customer bases, legacy data, upgrade and migration challenges, and an assortment of other complex variables where the road analogy is best put aside. I try to observe the rhythm and understand where I am in relation to the team, the project, the company, and the deliverable. Technical skills and sophisticated timelines aside, observing and working with the rhythm is a project behavior skill.
Have you been blocked at toll gate? Have you noticed the road sign analogies on projects? I’d be interested to hear.