You have to be flexible as a software development consultant. You can parachute in at any part of a project, into vastly different company cultures. You have to learn fast, adapt, and sometimes just bite your lip and get the job done.
Looking back, some of my favourite projects were the ones that made good use of prototyping. Not only did this help crystallize requirements, it was also an excellent communications aid for the development team. The saying “a picture speaks a thousand words” is certainly true – a visual prototype is far more effective (and fun) than a 5000 word requirements spec (yes, they still exist).
As a developer, I tend to enjoy projects that use mock-ups, prototypes and proof-of-concepts because these help users get engaged, visualize, challenge preconceptions and (most importantly for me) prevent unnecessary re-work further down the line.
I’ve observed that spending time researching users, speaking with them, and shadowing them helps build good relationships, and a prototype helps show that you’ve gained an understanding through these activities.
As a consultant developer I prefer to be part of an agile, lean delivery process that promotes regular communication with stakeholders, though regular releases of working software. This means customers can see the software early, and reduces the risk of rework.
Where possible, prototyping should be the start of this journey.