The best kind of project is the one you were expecting, right? One of the best things you can do to tackle a software development project is maintaining a positive, working relationship with your developer. Managing expectations helps both parties envision the same processes to achieve your goal.
As easy as that might sound, it doesn’t always go down that way. Your developer might produce exactly what you specified in the contract, but for one reason or another, it didn’t turn out the way you wanted. Perhaps your vision of the product pivoted, or you didn’t really know what you wanted in the first place. Either way, you end up dissatisfied because your developer didn’t deliver to your level of satisfaction.
Take one of our firsthand accounts as an example. When Dustin Ewan, a managing partner with illumisoft, was working in South Korea, his company decided to outsource part of a project to an overseas vendor to reduce costs on developing an online bookstore. They got the bookstore, but “it was just a trainwreck of code.”
“We couldn’t modify it without breaking anything,” Ewan said. “It wasn’t well put together. Just junk.”
Part of that lesson learned is simple: You get what you pay for. You might think you’re getting a bargain, but more expensive software will have higher quality. So whose fault is it? Yours because you don’t know the technology, or the developer’s because they failed to go above and beyond your expectations?
In Ewan’s case, the overseas company took advantage of the fact that his company didn’t explicitly define that they wanted the online bookstore to be maintainable and scalable. But on the other hand, his company also made the assumption that them being developers would hold themselves technically accountable to the product that they were making.
We recognize that technology is really, really complicated, so aligning your expectations of the project with your developer will keep things running smoothly. In fact, a good developer will acknowledge that the main goal is to build a solid, mutually beneficial relationship with you. Here are some ways to do that.
Good Planning from the Start Saves Time, Money and the Relationship With Your Vendor
Any great project starts out with great communication. In moving forward with your project, share your ideas and concerns with your developer. If that groundwork doesn’t get laid, the project might not turn out how you expected, costing time and money. Survey research backs up the fact that good planning reduces the cost and length of any software development project.
Besides losing time and money, you could end up having a soured relationship with your developer. Any relationship can get damaged by a failure to communicate. If you don’t have a plan fully lined out to your developer, that’s OK. Just let them know so they can help you flesh out your idea into something more substantive and practical.
You might feel vulnerable or make assumptions here at the beginning of your project. Don’t leave concerns unspoken during the planning phase — or, really, at any time throughout the project. Here are a few reasons why speaking up makes smooth sailing.
Make plans, not assumptions
It’s tempting to make an assumption about your project or your developer. You might be guarded or on the defense because you’ve been burned in the past by a project gone wrong. Or, this might be your first software project and you fear showing all your cards or letting on that you really don’t know anything about coding.
We recognize those pain points, but in order to align our expectations, we have to remove those [unspoken] barriers in order to hold ourselves accountable to you and develop the best product on time and on budget.
That being said, try to avoid making any assumptions about the project. After all, your developer will only be able to create a product based on what you’ve specified. Developers should nevertheless admit when they make mistakes or fail to communicate with you. And we do screw up; we’re human too.
Recently, we took for granted our communication with a client when his project kept receiving errors. He notified us right away about the first error, so we let him know we’d look into it. But after he kept receiving errors and sending them our way to notify us, we didn’t respond, thinking our initial address of the issue was enough.
Our expectations weren’t aligned with that client; we thought we were communicating everything we needed to communicate and, apparently, he did not. We continually strive to have an outstanding relationship with our clients, and we believe that communication is the key to that. And in this case, we definitely did not live up to our own standards.
It really boiled down to miscommunication, and that’s on us. Unfortunately, this can happen to you with any developer. The worst thing you can do at this point is wait until it gets to a boiling point. Don’t wait until you’re already frustrated. If you find yourself in a position where you have concerns or doubts, don’t let those remain unspoken.
You don’t have to let your guard down, but tell us why it’s up
Establishing a mutual expectation from the start is a key component to building a partnership with your developer. From our point of view, we can go a long way toward doing that. We can build our side of the bridge out quite far, but in order for us to completely bridge the gap, you’re going to have to meet us a little bit.
Be open and honest with your developer by saying, “Hey, this is where I’m at; I’ve never worked with a vendor before, so I have these concerns,” or, “Hey, I worked with a vendor before, and we had some rough patches here, so I’m a little guarded about this.”
If you let us know you have been burned in some way in the past, we can build extra padding around this rough corner so that things go a little bit more smoothly.
“We can build that bridge out so far, but you need to meet us,” Ewan said. “You don’t necessarily have to let your guard down, but you have to tell us where those those pain points are. If you don’t communicate to that to us, then it’s going to be really hard for us to move forward because you have a hidden resentment. You’re basically laying the mines for us to step on, and then when we step on one of those mines, you’re going to be like, ‘Aha, I knew it!’”
Without communication, your partnership will be founded on a false dichotomy that sets up you and your developer for failure. It’s the same thing if you go see your doctor about some health conditions that you’re having, but don’t tell them about your lifestyle, diet or habits. As a result, you could get misdiagnosed, and the doctor might treat your health issue in the wrong way because their assumptions about why you have this symptom could be wrong.
We believe constant, consistent and honest communication bridges that gap. If you’re afraid to communicate because you want to protect yourself and your business, or you expect the developer to take advantage of you because you don’t know coding, that’s a mental, emotional barrier to overcome.
Aligning Expectations is an Ongoing Process that Makes Sure You Get What You Want in the End
Developers and clients don’t always keep their expectations aligned throughout a project. Sometimes, it’s as simple as a lack of communication. Other times, the strict outlines of your contract inhibit you and/or the developer from pivoting in a different direction.
Whatever the cause, managing and aligning expectations during the project is vital to project success. It’s an ongoing process too. Your vision of the end product could change, firstly. And as your developer exposes you to new technological capabilities, you might gain a fresh perspective on the scope of the project.
You and your developer should both communicate any changes that should be made mid-project. But sometimes, your contract serves as a barrier to aligning expectations. In that case, be wary of entering a contract that restricts your ability to pivot the project, especially if your vision isn’t clearly lined out to your developer.
Why illumisoft avoids fixed bid contracts
Just to be upfront, we tend to avoid fixed bid contracts.
If you’re stuck in a fixed bid contract, it’s incredibly difficult to pivot the project because you’re locked into whatever the contract dictates. As a result, the contract often becomes the relationship in custom software development projects.
For those who don’t know, here’s how a fixed bid contract generally works: A client tells a vendor what he wants built, and they write a contract around the project. The vendor then builds exactly what’s in the contract, and it might not turn out to be what the client needs. This is possibly a result of an unknown pivot in the project, or perhaps the client didn’t have the foresight he thought he did from the beginning.
We want to be really tightly integrated with our clients; in fact, we want to feel like we’re part of your team. The contract gets in the way of building a partnership because it creates a division between you and the vendor. And once you get locked into a fixed bid contract, everything you do gets channeled through it.
With a fixed bid contract, everything’s black and white, for better or for worse — and we would say 90 percent of the time for worse, just because you can’t account for everything. In software development, your needs for the project may not be fully understood or fleshed out enough — one of many flaws of a fixed bid contract that hurt both you and the vendor.
What makes a relationship great is when a vendor goes above and beyond expectations, and there’s no incentive to do that if it’s not in the contract. When there’s a contract in place, you might have some sort of dispute with your developer, but if they haven’t violated the contract, they might say, “Sorry, man, you signed this contract; you owe me money.”
That’s why we predominantly work with time and materials contracts. It’s pay as you go, so if we’re not living up to your expectations, then you can cut us loose anytime. The risk for us, to be sure, is having no guaranteed income. But our bottom line is dependent on us delighting our customers, and we find that time and materials contracts tend to jive with our philosophy.
Time and materials contracts operate two weeks at a time; your developer will bill you every two weeks, and if you like what they’re doing, you pay the bill and the developer keeps going. If you don’t like what the developer is doing, you don’t pay and the developer halts work on the project.
A time and materials contract keeps expectations aligned and on track
When you enter a time and materials contract, it constantly keeps you in the driver’s seat of the project. It allows your developer to pivot rapidly and to scale up and scale down quickly and as needed.
Time and materials contracts are also much more agile than fixed bid. When you’re in a fixed bid contract and you want to make a change, you must put in a change request, which becomes a whole ‘nother contract on top of the original contract.
“I think the best part about it is it makes the relationship be the relationship,” Ewan said. “We have to constantly communicate and maintain this relationship. But on a fixed bid contract, now the relationship is the contract. ‘You’ve said what you needed; I said what I was gonna offer. You signed your name. I signed my name. Oh, there’s a dispute? Let’s consult the contract instead of consulting each other.’”
At the same time, time and materials contracts need continuous realignment of expectations. Therein lies the biggest risk of time and materials: Everything could go off course from the project the way you want it.
But we alleviate this problem through constant, consistent communication, always making sure that the project is aligned and that we’re breaking through any relationship barriers. These are just a few of the benefits to consistent communication, one of our four key pillars to project success.
Managing Expectations Removes Doubt and Builds Trust
Unless you know technology, there is no way you could guide a developer by saying, “Hey, I need you to build this software in a way that’s maintainable and scalable, so I can hand it off to somebody else.” If you’re not technical, it’s impossible. At the end of the day, you couldn’t even look at the code and tell if it was well put together or not.
As a non-techy client, there’s a number of questions you need to ask upfront. Their answers themselves aren’t so important; what’s important is if they can communicate it to you in a way that you can understand. Can your developer communicate on your level?
This is why it’s so important to build a relationship with your developer.
We’re all about building relationships with you so that we understand where your technical ability is, and where your concerns and passions are, and then communicating on that level. Otherwise there’s going to be a disconnect.
As we mentioned earlier, we know we dropped the ball in communication with one of our clients, all because our expectations weren’t aligned. Even though we thought we had adequately communicated, he needed a little bit more from us, so he got really frustrated and, as a result, the relationship became a little bit strained after that.
After resolving that conflict and identifying his communication needs, we are now better able to understand what other clients may need so they feel more comfortable during the project.
Our main goal in managing expectations is to remove doubt, alleviate concerns and, ultimately, build trust with our clients. By maintaining a time and materials contract, we remain grounded in a relationship that lasts every two weeks, allowing us to pivot quickly and realign expectations as needed. And constantly communicating with you shines light on any problems, allowing us to figure out together on how to maneuver around them.