Putting Us in Our Systems

Have you ever wondered why employees that use internal administrative systems are not asked what they need from the system or even better want they want from it.  I wonder about it a lot and fortunately I find myself in a position that I can influence change.  Even better, I am about to complete the DITAP course and now I know how I can influence change.  At my agency, it seems internal systems used by employees are built based on what the administrators of a program need and what they think the users of the system need.  The requirements from the program administrators are communicated to developers via lengthy requirements documents.  They think they know everything the system needs to do and even try to predict the future as to what the system will need to do two years after implementation.  The system is implemented never to be thought of again until changes are made to laws, policies, or statements made by leadership.  I wonder what life at my agency would look like if rather than using a lengthy waterfall approach we used a more agile methodology and put a minimal viable product in the hands of users and adjust based on user feedback.   There is plenty of focus on public facing IT systems my agency provides and the different ways the public interacts with the services.  The internal systems used by employees every day that always seem to be forgotten.  

So how do we go about influencing change?  I truly believe the IT development team knows there is a better way to put great products in the hands of the end user, products that are simple and intuitive that meet their needs. I plan to modify the way we think about developing our systems by educating them on the digital services playbook and ensuring they adhere to plays 1, 2, 3, and 4 of Digital Services playbook.  We should focus on these plays every time we are asked to create a new system or modify an existing system. My real challenge is getting buy in from non-IT professionals within the program office.  We need to transform the way we do business and identify a true product owner that focuses on how well the service meets the needs of its users. They need to be educated that lengthy requirements documents are a thing of the past and that perfection should not get in the way of releasing working code.  Let’s face it, releasing a system that meets their needs and never thinking about adding or removing features is a lot easier.  Let’s stop letting statements made by leadership in a meeting determine changes to our administrative systems, let’s hear from actual users and release features and improvements throughout the year based on their feedback.  We need to start looking at metrics and user stories to identify pain points in the current way users interact with the system and prioritize them to help influence change. Let’s use the voice of the many so we can put products in the hands of the users that are simple and intuitive enough that users succeed the first time, without a 50 page user manual.  Let’s face it, the average employee can’t find the user manual and if they do, who has time to read a 50 page manual especially when it’s likely outdated with old screen shots that create more confusion.

The first step is getting a product owner that realizes these are OUR systems, the employees that use them every day, and they should have a say in them!

• Uncategorized