For the past 6+ years, since I escaped was sent off lovingly with a diploma from college, I have been working on contracts that have all dealt with improving workflows and systems through technology. This has provided me with opportunity for many musings on the process of changing these workflows and how to make sure you can make a system that not only does what it’s supposed to, but does it better.
First and foremost, you’ve got to keep in mind the problem that has to be solved. Often you won’t be solving new problems right off the bat, but it will begin with translating a workflow from one process to another. In most cases this will mean you will be taking a paper process that has been in place for years (even decades) and replacing it with a digital process, though there are occasions where this might just be moving from an older clunky digital system to a new fancy state of the art system. Henry Ford is often quoted as saying, (which may not actually be true) "If I had asked people what they wanted, they would have said faster horses.” We can use this in how we think about transitioning from old workflows to new ones as well. Think about if Ford’s car wasn’t the Model T as we know it, but was a flying car instead. Users would still be able to travel much faster than they could on horse and could even take things (or more people) with them, but the result is so different that people who were used to horses wouldn’t know what to do with it. We need to be conscious of these same changes as we change workflows, as we want to innovate and build a more efficient version of their current workflow but we don’t want to overwhelm the users too much. We want to change how they work without too many surprises.
Why are we doing this project if not to improve? The worst feeling in the world is to know that you are wasting your time working on something that isn’t going to be used. So while you are working towards change, you need to keep in mind the major hassles that users go through with the current process. How can you make their lives easier and make the user WANT to use your new application over the way they’ve been doing it for years? Look at how they do things and how things could be better. If the user constantly has to be going to their computer or calling someone up to find the same information over and over again, think about how you can link that system into yours. Does the user have to go through the hassle of gathering up documents and mailing them off and hoping they get there in time (or at all)? How about figuring out a way for them to be able to digitally submit all of that to the recipient? What also needs to be kept in mind is that the system can’t have steps that prove to be a greater hassle as compared to how much easier it is to use as this might drive users away. You don’t want the user to feel like there is greater relative burden on them now that they are in a system that they don’t encounter on paper. The first iteration of any system is to entice and bring users into the fold of the application and to start convincing them that your system gives them more benefits vs. sticking with the old way, while not introducing new hassles.
Evolution occurs over time...
Although not biological by definition, applications are growing organisms in their own right. They change and evolve as time progresses absorbing new capabilities and losing some of now useless features that were moved over from the old processes / systems it was deemed to replace. This is an expectation that needs to be accepted from the very beginning, making sure that the initial scope is actually doable and the expected features match those of the current process. As the application is built and once it has been released, you will receive user feedback from those who actually will be using the application. During this time you find out even more about what direction the application will begin to grow as users provide feedback about what is good and what isn’t. This allows the application to adjust to its environment becoming stronger and better equipped to handle the tasks at hand.
Learn from the Phoenix...
The application you are working on now will die. It might not be soon and you might not have anything to do with it when it does, but you might wind up working on a different application to replace an existing application. In these circumstances we must remember the Phoenix in that from the ashes of the existing application a new one will be born. An application tends to die for a few different reasons:
-
It is no longer useful as the processes it was meant to cover no longer exist.
-
It is outdated, or the technology used in it is no longer relevant and it is more beneficial to rewrite from scratch than put a new coat of paint on the old one.
-
It has been replaced by something different.
In the second two situations the need still exists for the project and likely a lot of the business rules and knowledge about the application can be reused. The application might be completely different but the work and knowledge of everything can be used as a foundation to build that new application to replace the old. In the first situation, it’s hard to defeat irrelevancy so the application and its functionality won’t be replaced by anything. It is likely that the pieces of the old application could be re-purposed to other closely related areas. In any situation, keeping the application evolving with the needs and the technology of the times can maximize the duration that the application will hold its existence and the longer the application is useful the most worthwhile the application was to build in the first place. But in the end, don’t we all just want what we build to be useful?
-Adam Swift, 5AM Solutions
