Because they’re up against similar challenges to us custom software developers, I’ve grown a soft place in my heart for general contractors.
Recently we had to replace the roofs on the front and rear porches of our 1926 Sears home. My wife Rebekah and I met with a contractor to survey the work and come up with an estimate. After some measuring and requisite scratching of a pad with a pencil, he tossed out a number.
Prior to his arrival, Rebekah and I had played our own numbers game. We came up with a range that we thought would be needed to get the work done. It turns out we were close!
After the initial elation that we had prepared ourselves well, I asked the roofer a question that demonstrated that we – homeowners and GC – were in it together. “What kind of things might you uncover that would impact that estimate?”After some back and forth about rot and flashing and decking materials, I put a bow around our collaboration, “Surprises suck, eh?” I thought he was going to hug me.
In my 25 years of consulting, I’ve never met a business owner who loved surprises, and custom software projects (like many types of projects) are full of surprises. Sure, we all start with the best of intentions. I too can claim guilt at walking into a discovery meeting thinking, “This time will be different. This customer gets it!”
And then come the surprises. These come in many forms like, “Hey, at our next meeting can The Boss sit in? He has some ideas.” Or how about this one: “Thanks for this proposal! Now, let’s move forward, but before we do can I ask a question? What does it mean for the project if we’re about to take our business international? We’re opening a London office.” (That last one actually happened)
Ok, so – Surprises Happen. What can we do to counter this?
Years ago, I (like many in the FileMaker community) was introduced to the concept of Agile software development by Jason Mundok. Throughout all the presentations Jason gave and in my follow-on research, one component of the Agile methodology resonated with me: “Embrace Change”. I took that as “EXPECT Change” and as I surveyed FullCity’s projects, I saw that one of the things they had in common was change. And I realized that what the Agile folks were telling us about change applied to surprise as well. After all, Surprise is just Change’s less self-aware sibling. Whereas Change happens, Surprise shows up unannounced.
One way my team and I like to counter the effects of surprise and change is to establish a continuum of successes by eschewing the concept of big projects for smaller projects with more flexible plans. An extension of the concepts laid out in Agile – at a more macro level. Through this approach, we share many of the benefits of Agile: credibility built through success, more acute awareness and application of resources and genuine collaboration.
Keeping to this philosophy has yielded many tangible benefits. One of those is happiness. Customers whose projects are under control are happier. Developers whose work is hitting the mark are happier. People who don’t have to wait months (years?) for “The New System” to make their workflow less arduous/more efficient are happier.