I’ve worked on several projects this year where the big goal is pretty complex and everyone involved knows it will take a lot of work. The typical way to approach something like this is to understand the requirements for the entire project and then build, test and declare the project finished. Most consulting companies can’t be financially successful unless they approach projects this way.
I get hired pretty regularly to clean up behind this approach, and so I tend to think it doesn’t work very well. Of course, I’m working with very skewed data. If you’re already happy with your system, you’d never contact me!
The big goal for any system should be that it works for the all humans involved. Sometimes the requirements as communicated early on reflect that, and sometimes they don’t. Every time I go to the doctor and watch everyone there struggle with their Epic implementation, I think about how when these health systems purchased it, the billing team gave really clear instructions about what they wanted, and the doctors and nurses didn’t, probably because billing people had lots of experience writing software requirements and doctors and nurses had none.
A new system almost always demand that those humans change some behavior they’re very accustomed to. The technology part is the easy part. If you’re not acknowledging this in your process, I’m a lot more likely to get hired to clean up behind you.
I really like to start projects of any scope with a simple step that puts something concrete in front of the staffers, who are typically the first group of humans who will interact with the system. For a data migration, this might be just migrating the contact information and the organization or household information, and sometimes just a portion of it! For a from-scratch system, it might be a bit of data to solve a single problem they’ve brought to me, ignoring the other project goals for the moment. For a feature like moves management, it might be the simplest possible template for moves they’d like to track.
Advantages of this approach
Uncover the real requirements
I’ve found that once I put something real in front of people, the whole conversation becomes a lot more productive, and users often change their mind about what they want! Then I’ve gotten to the real requirements, which might not have been clear to anyone involved. This can be a huge time and money saver for the organization, both because you do things once instead of several times, and because organizations often realize they don’t actually want something complicated and expensive they thought they wanted!
This approach also gives everyone time and space to get to the reason the requirements are the requirements. Particularly at organizations where a system has been dysfunctional for a while, people start to ask for things that no one should need. If you’ve got a 10 step process for sending out thank you notes and the requirements specify that step 7 needs to be fixed, we should really talk about why there’s a 10 step process, and probably throw it out and replace it with something radically simpler.
Build trust with your users
Particularly if I’m cleaning up a failed project, building trust is the first thing that has to happen. The people who failed might have been quite polite about it, but sometimes they’re real jerks about it, and the longer the organization has tolerated that, the harder it is to build trust. Putting one good thing in front of users is a good first step to building trust, but you’re not going to get their full participation until you’ve earned their trust.
Give your users a way to communicate with you
When those of us who design and setup systems ask users to collaborate with us, we’re asking them to think like us. If they could really do this, we wouldn’t be in the room! By putting something real in front of them and letting them kick the tires a bit, we’re giving them a way in.
Build one step at a time
Once you’ve got the first simple thing in front of users, you can start adding more simple things bit by bit. This lets people handle the change more comfortably, and lets you fix things before they’re sprawling messes.
Better user adoption
With this approach, we’re having users make more tiny changes rather than a few giant changes. I once worked with a Salesforce admin who had started her career as a social worker, and she reminded me that changing human behavior is HARD. Think about how annoyed you are when some tool you use daily changes the UI. Think about how hard it is to start going to the gym or quit smoking. That’s behavior change, and it isn’t that different from asking people to stop using a spreadsheet and start using a database!
Disadvantages
You start with a lot of unknowns
You can’t predict at the beginning how long the whole project will take or how much it will cost. This by itself usually makes it impossible for consulting companies to engage in it, because if they do, managing their people and payroll is nearly impossible.
Staffers have to be very open and involved
Staffers who are going to use this system have to be both open to this iterative process, and they have to have the time to commit to reviewing new features and providing feedback. I’d argue no approach can work if the staffers aren’t open and spending time on the project, but people sure do keep trying.
The provider has to practice empathy and listen a lot
I don’t personally consider this a disadvantage, but not everyone finds this kind of thing rewarding. Technology should serve humans, not the other way around. You can’t build something that serves people if you just assume you know what they want, rather than actually finding out.
Sometimes extra listening and empathy and time is required because the technologists who came before you were such jerks that the users can’t bring themselves to trust you.
The provider has to say no sometimes
When I was in high school and college I waitressed at a restaurant where we all wore buttons that said, “Yes is the answer, now what is the question?”
When you’re selling something, you want to say yes! But if you’re building something, you’ve got to stop selling it. Building trust doesn’t mean saying yes all the time. Sometimes users ask for things that aren’t going to work out the way they think it will. Sometimes the users’ bosses ask for things that aren’t going to work at all. If you’re really partnering with an organization to build a system to serve them, you’ve got to be willing to say, “based on my experience, I don’t think this thing you’re asking for is going to serve you well, and I think ultimately you’ll be sorry you paid me to do it.” This is uncomfortable, and most people would rather just build with the organization is asking for. Even more uncomfortable is to say, “that’s not work I’m willing to do, but I’m sure there are other folks out there who would be happy to do it.” Just like in the rest of our lives, having uncomfortable conversations is important, and more likely to result in good outcomes for everyone than saying things you don’t mean.
Artisanal Data 