One of the most difficult things related to software development in government is to create a solid group of people to define what the application must do, how to do it, and who has to be part of the information flow and the role they play in the whole process.
It is common that users approach the development arena asking for a new development, with only a vague idea of what they call "a system". But most of the times that initial idea it is just the merely beginning of a real information system that, in some cases, will end up as a huge one.
In the first meetings and pre-analysis stage of development, I ask my users for a flow chart diagram in which they can shape the entire process that they want to be automated. When I ask that, almost all users get a surprised look on their face-- they realize that they don't have a real knowledge of what they are asking for.
After that initial surprise, the development department takes over to generate a team formed by users and developers for start defining what is the real intention of using a software tool. This is a big opportunity for creating a relationship based on trust and cooperation going forward the development process. In this moment, it is ideal to think of the DevOps approach-- make the user be part of the game.
The development process under the agile approach looks for things like continuous meetings, dividing the process into small tasks with specific objectives, thinking of the whole information system (IS) as several parts to be delivered as they are concluded and tested by the final users, and always learning from the feedback they generate.
The more involved the users are, the better relationship they can have with the developer's team, making the entire process go much smoother. Once the final users feel that the information system is a work of their own, the compromise is higher and it generates a closer communication between all the actors. This is a fundamental element for success.
Making the users a part of the evaluating meetings and attending to what they have to say is a healthy practice for the developer's team. At the end of the day, we have to meet the information needs of the applicants, and the final approval depends on how they evaluate the information system that we will deliver.
In the road to achieving the final goal, it is important to keep the record of the meetings, requests, agreements, responsibilities and all the elements that configure the entire automated process. These elements sustain the main objective of the information system and the reasons for adjustments and corrections.
Finally, once the IS is ready to be delivered, our responsibility doesn't end. There should be some minors adjustments, and modifications as result of the use and the normal changes in the evolution of any process. Frequently, these changes are few and small and don't require more than a simple support issue.
We have great experiences using this method, and my development team still has an excellent relationship with all the final users. I strongly believe that give the final users a central role in the process, makes the things easier. Happy users means less stress.
Sergio Yorick is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.