March 15th, 2016
“The customer is always right” can lead to a disaster if followed too literally. Obviously, software developers shouldn’t try to override their client’s needs or ignore requests, but there’s always a reason for a business to hire outside IT assistance. It’s typically because the staff at that business have reached a problem that lies outside their scope of expertise, and they want someone with software development expertise to help them solve it.
A developer should trust that the client knows what they want on a high-level, but it’s unfair to assume that they know all the details or best-practices of how they need to get there. They wouldn’t have called for help if they did!
We recently spoke with a client about their experience with a large systems integrator company whose technicians made that exact assumption.
These technicians did the bare minimum work in order to achieve exactly what the client requested. So, for example, when the client asked for a form with fields for different entries, the developers did just that. They didn’t talk with the clients about the options of how to achieve that end result, or make any suggestions for slight variations that could mean a much more efficient system.
When these clients asked their former IT team why the fields didn’t autofill any repeat entries, the developers responded that since they weren’t asked specifically to do that, they didn’t do it. Their mission was to fulfill requirements at a minimum effort and nothing more, offering no innovation or suggestions.
Here’s why this is so problematic: IT is the expertise of the software development team, not their client’s expertise. Even when a client has a substantial background in new system development, their reasonable expectation is that they’ve hired experienced professionals to do the work. They shouldn’t have to explain user-interface best-practices to them!
Another way to look at it is thinking about a different type of work. If someone hires me to paint their room blue, there are some questions that I will ask them and some assumptions that I will make because of my experience. I’ll ask them what color blue and if they want anything special done, and then I will use my own best judgment on how to do that best.
If I painted a room with a toothbrush and didn’t use painter’s tape or a tarp on the floor, it would be silly of me to object that you didn’t tell me to use a roller and tape or protect your floor! Those things fall under the realm of expertise that can reasonably be expected.
The most striking part of our conversation with our clients about the team that they worked with in the past came out in a meeting. One of the staff members made a great point, saying “We didn’t know what they didn’t know!”
The bottom line is, no one can read minds. When you hire a developer, programmer, or an entire IT team, that starts a conversation between all parties. Everyone needs to be transparent about the decisions that are made, but also take ownership for those decisions.
When both parties put themselves in the shoes of the other party, good communication will occur and that’s how problems get solved.
March 1st, 2016
Usually, clients have some kind of stereotype in their minds when they hire a team to do software development for them. Even IT professionals who don’t specifically do software development have assumptions about those of us who do!
As common as those expectations are, they aren’t always helpful for building clear communication between a business and the software developers they’ve hired. Here are 5 myths that we see pretty often-and the truths behind them.
1. Once the site is ‘up’ or the software application is now in production, the software developer’s work is done.
Your software is never done. Enhancements and fixes are ongoing because the system is never perfect upon ‘go-live’. Think about the iPhone, or Google. Those technologies aren’t really ever “finished” because developers are providing updates to fix bugs and add even better features.
2. Software developers should be given as much freedom as possible. Direction will only halt their creativity.
From a creativity standpoint, having unlimited time and resources for a project would be a luxury, but even then some direction from the client’s Project Manager is necessary to make sure the design and development fits within the budgets of time, feasibility and money. Every software development project LSG drives, there are constraints, so total freedom isn’t realistic. It’s important to discuss the boundaries for a project so all parties know what’s expected.
3. The customer’s the expert on their project, not the developer. They should be able to explain what they want so the developer doesn’t have to ask questions or make suggestions.
The majority of our customers will tell us some version of: “Look, if you can think of a better way to do this, please tell us and help us find the best solution.” Businesses should definitely know what their high-level needs are, but it’s the developer’s expertise that will help them get there. Open communication between both parties is crucial here.
4. If you don’t like interacting with people, you should do software development.
Anyone above a junior level programmer should be able to make suggestions about how to do things better in a respectful way. Programmers regularly need to run ideas by clients, discuss budget and technology, and have conversations about what’s actually reasonable for each project. Good people skills will help developers do those things with tact and respect. By the way, the junior-level programmer should be collaborating with the senior-level staff.
5. The shiniest, newest, most exciting technical system is always the best solution.
Most of the time, it’s the simplest system that wins the day. That’s the system that is the easiest to maintain and the one that improves morale. The goal is not for developers to impress their clients with IT glitter, but to help businesses have systems that operate well even when the developers are not physically there.
Good software developers know that they’re providing a service to their clients by sharing their expertise to solve IT problems. Communication between developers and their clients will help debunk some of these myths so that everyone can do their work well.