My professional background is as a software developer – I only recently became a manager (still working on that transition – so far so good!). For most of my career I have worked in technical software development – applications that deal with email, voicemail, server monitoring, database design tools…pretty geeky stuff. I have worked for AMS for five and a half years now – this has been my first job working in the business software industry, and more specifically P&C insurance software.
One of the biggest challenges I’ve faced is learning to communicate effectively with business users, both within AMS and our customer base. I’ve learned to recognize the glazed over expression when I veer off into areas like object models, XML schema, and persistence. I’m sure others recognize that same expression on my face when they talk of subrogation, tort feasor, and omnibus risk.
Chris Kanaracus of IDG News Service recently wrote an interesting article about an IAG survey rating how successful software projects are based on the composition of the team that develops the requirements for the project:
The survey results show that software projects over-run schedule and cost nearly equally when the requirements are developed only by business users, or only by technical people. The best results are obtained when business and technical users work together to create the project requirements.
This fits in well with the Agile methodology we’re starting to use here at AMS. We want to work with you, our customers, on determining the requirements for the software we write using User Stories. This is not just done at the beginning of the project. At the beginning, we can’t know (nor can you) all the requirements for the software. Even if we (or you) could, as time goes on your needs change. With the Agile approach we work together throughout the project, iteratively creating the software. We have periodic reviews of the solution, with feedback driving work of future iterations. Work is completed in priority order, so the most important features are completed first.
So…if the best results are achieved by us working together on the requirements, how can we bridge the communication chasm that exists because of our different backgrounds and areas of expertise?
I think we need to talk early, and talk often. Face to face is best, followed by WebEx, voice-only, and email. We should review what we’ve said in our conversations, to make sure we really understood each other. We should make sure any terms or acronyms we use are defined. We should use pictures and stories where words alone don’t cut it. We should be willing to speak up and say “I don’t understand what you’re saying” without fear.
What do you think?