We see it all the time: a company has a long-established software system that's either fully custom or has been customized to fit just right. It's perfect, or as nearly perfect as software can be. And then the company grows. It evolves with the changing marketplace. Little by little, that perfect fit starts to pinch here and sag there. You know you'll need to do something about that legacy software eventually, but not now. When does "eventually" become "now"? How can you tell when it's time to overhaul your legacy system?
More and more health care providers are using web and mobile applications to communicate with their patients. In 2016, for example, the American Hospital Association reported that 92% of their hospitals provided patients with access to their health data via patient portal applications. These portals offer significant benefits to patients, providers, and administrative teams.
Writing software requirements should be easy, right? Right? Of course we know exactly what we need and can tell you exactly what the software should do.
Unfortunately, it's not always so easy. Writing software requirements well takes detailed, deep thought about business requirements. It also takes clear communication between the people who will use the software and the people who will write it.
It isn't always easy to translate between business-speak or industry-speak and developer-speak. This can cause costly confusion. Fortunately, there is a language called Gherkin to help bridge the gap.
So what makes a good set of software requirements, and how can we develop those requirements?
Legacy system conversion projects are always challenging. Rollout strategy can make a huge difference in successful user adoption and overall project success.
Only when I began writing them down did I realize that I had recurring dreams. I had believed that my dreams were largely random and varied, but instead I learned that I had many frequently recurring themes. Similarly, the process of writing down my thoughts on software development has shown me that there are also recurring themes.
One of these themes is the impact of rollout methodology on a project's success. More specifically, rollouts of legacy system conversion projects. Rollouts of brand new systems into an organization are typically less painful, as you are often automating a paper process, or inventing a new process that improves productivity. However, legacy system conversions are almost always painful, as there are many processes that have emerged around this system. People have developed a form of muscle-memory with the old system that even they themselves scarcely understand.
We have successfully replaced dozens of legacy systems where everyone was happy and all was good with the world. But it's not those projects I want to talk about. I am going to talk about the projects where things went awry, because I don't want to make the same mistakes again. Hopefully, these words will also help the reader to avoid similar problems in their projects.
Now that your company has rolled out its shiny new CRM system, you’ll want to make sure your team is fully on board. How can you track Salesforce user adoption? What are the signs you don’t have full buy-in from your organization on using Salesforce?
Of course, there are many useful reports available in the Salesforce Adoption Dashboards. To get the most benefit from those dashboards and reports, you'll need to quantify your expectations. How should your team use the system?
Working with Salesforce relationships is a little different from traditional relational database structures, but Salesforce has great tools for building custom data relationships and most people can adapt quickly to the SOQL model. As with any other system, though, there are a few "gotchas" to watch for when designing Salesforce relationships. I ran into one of these gotchas just recently. I needed a lookup relationship from our custom object to the standard Product table, Product2. No problem, right? Create the lookup field in the custom table, and there it is. Not so fast!
It's a funny thing about Salesforce developers. Many of us really dislike change, even when we know very well it's necessary and worthwhile.
Why? Too often, changing an application is like re-routing plumbing after the house is built: making a change that looks small can take a whole lot of effort with a whole lot of risk for collateral damage.
Can software replace my job? It's a concern with roots going back centuries to the arrival of the first automated power looms in 18th-century England, continuing into more modern times with the large claw-like robots that build automobiles. Today it seems there are hundreds of websites making their living pushing clickbait headlines describing the perils of the coming Robopocalypse of software automation replacing human workers, and I often see those fears bubbling to the surface when working with clients. Fortunately, in my experience, those fears are often overblown, and I'm not alone in thinking so. Wired's James Surowieck agrees that we have nothing to fear.
The automation jitters usually start to come out during discovery. I talk with clients to clarify the business logic, workflow rules, or other automated features, and I'll use the term "robot" to describe the software we're building. After all, "if I can't tell the robot what to do, how will it know how what to do?" It's somewhere around here when we're asking somebody to explain their whole job function that somebody on the client's team will mutter, half-jokingly, "So I guess I better start looking for another job, huh?" It's not hard to understand where that thought is coming from. After all, if we can completely strip away the human layer and turn their job into a series of rote, mechanical steps, what role is left for them? I quickly try to assuage their fears.
It's easy to assume that someone needing user support is not using the application correctly. What if there really is a bug?
We've all seen the acronyms from user support techs: ID-10-T errors, PICNIC, PEBKAC, and so on.
On the one hand, they're pretty mean-spirited (but kinda funny). On the other hand, who can blame user support techs for being exasperated when rude, frustrated users scream at them to solve problems that aren't their fault. Yes, some support techs really do have to walk users through the most basic of operations. REALLY basic, like making sure the computer and monitor are plugged in and powered on. On the OTHER other hand, it is the job of support techs to bridge that knowledge gap.
As consultants, we are often called upon to support our own or someone else's software. We have to be the opposite of that acronymic stereotype. Users aren't idiots; they're experts in something we are not proficient in and vice versa.
Once in a while, we are on the receiving end of user support, and these experiences can be real eye-openers. I remember one instance where we found an undocumented limitation of a mature third-party application.