If I’ve taken anything away from years of software development efforts I’ve witnessed it’s this: know thy customer .  And I’m not speaking strictly about packaged software for the masses, I mean ANY project, ANY size, for ANY market.  Software and systems architectures are developed by engineers who in most cases are not vertical industry subject matter experts.  Customers (users, stakeholders, pick your own term or endearment) bring that all important knowledge of their business processes and their industry.  And since they pay the bills, it probably makes sense to get to know them and their needs very well!

Software development methods have evolved over the last decade or so. For years the waterfall method relied on gathering user input at the front end of a project and hoped to hit the target weeks, months, or *gasp* years later.  This approach routinely yielded overly complex user interfaces, missing functionality, or products that just never materialized.  Fortunately, enough unmet expectations collided with the emergence of the Web to give us iterative development methods.  While there are many approaches to iterative development the key take-aways are short development cycles and tight integration of user feedback repeated throughout the project lifecycle.  Shorter cycles mean that engineers can focus on getting a few things done well, the customer can provide input on proposed designs and workflows, and minor adjustments can be made along the way to product delivery.  The iterative process honors each side’s respective role and contribution and keeps the communication lines open.  In the end the engineers are happier, the customers are engaged, and the end product is just what everyone had in mind (even if, as is often the case, they had no idea when the project started!)

Geospatial projects are inherantly and unavoidably complex.  All too often I’ve seen how easy it is for engineers and customers alike to fall into one of many traps involving data management, interoperability, portrayal, security, metadata, versioning… and so on.  These conversations inevitably take place between technical stakeholders from both sides of the project.  And its frequently at these junctions where user-engagement is lost or weakened.  Let’s face it we are in this business because we like the intellectual challenges it presents.  But we in this industry could all stand to remember the lessons learned from the iterative process.  We need to continually ask ourselves if our efforts directly support the goals of our customer.  It never hurts to ask because in the end, they’re always right.

In future articles I will taking a deeper dive into this and other issues related to user-centered development and product management. I look forward to your comments.