Contracts in General, Statements of Work, and Time and Materials

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Hello and welcome back. We are between seasons. I wrapped up 13 and we're looking forward to season 14 somewhere in the future. Maybe next episode, maybe not. Still figuring that one out. Trying to decide how far we want to go in these between season topics. First couple of ones were lessons learned. This will be a continuation of that. We talked about the idea of writing a book, the idea of starting a podcast. This one's going to get a little more specific. I'm going to talk about, it's essentially the contract side of consulting and agreements and things of that nature. Because these are things that I think that are pervasive. They show up all the time. You're going to run into them. At the same time, they're very simple to deal with and sometimes very intimidating. The world of non-disclosure agreements and statements of work and master services agreements and all those kinds of things can be very scary and intimidating to those that are just programmers, that are just developers. We don't spend a lot of time thinking about agreements and contracts and legalities and things like that. We just sort of want to work. However, there are some people out there that are not terribly honest, we'll just say. You need to make sure that you protect yourself and protect them so that everybody can be in a comfortable situation when you're doing some work for them. When you're an employee, you are limited but not. There are going to be agreements that you'll be asked to sign usually when you start a job and you may or may not like them. Probably you're not going to think about them, but you do need to pay attention. Non-disclosure, you're pretty likely, you're going to have to sort of go with what they have. Now, there may be something that's overreaching in an NDA, or there may be some information that you already have that you'll have to somehow declare as part of that NDA to say, this is something I know that has nothing to do with your organization. So if I have shared that or if I share that, then that can't be covered under that clause because you guys haven't really disclosed anything to me that I didn't already know. So you want to look at them. They're usually going to be boilerplate and pretty straightforward, but just in case there's something odd about it. If you've got a legal resource of some sort, then it never hurts to do that or maybe a mentor or something like that that can just sort of give another set of eyes to make sure that there's not anything in there that's going to be bad or that's going to impact you negatively. Same thing goes for non-competes. Non-competes are a little more tricky, and so I would definitely take a close look at non-compete agreements. I have seen situations where people have tried to push a non-compete agreement that says that employees will not compete or will not even work in that industry for five years after the end of employment. In some cases, that could be devastating, and it depends on what the line of business is. industry doing programming and maybe it's business programming for, I don't know, let's say a niche widget manufacturer. They say you can't work for any other widget manufacturers of this type for a couple of years. That's probably fine because you're going to go end up working for maybe in another area. You end up in healthcare or you end up in finance or something like that. But I have been in situations where maybe you're building software and they say that the stuff that you do, maybe you're building software, you're building libraries for your favorite language, C-sharp libraries or Java. They could write the non-compete in a way that basically says you cannot go write Java code as an employee for somebody else for X amount of time. So you've got to take a look at what they're really restricting you to do before you sign on to one of those. Whether or not they chase you down is a different after employment, but your best bet is to take care of this upfront. That brings me to the bulk of what I wanted to cover and that is contracts in general. Statements of work. We've talked about a couple of times and I've definitely written on the two main types of contracts, which are basically time and materials or fixed bid. If you're not an employee, if you're a contractor, those are basically the two things you're going to fall under. You're either going to say, you pay me X amount of money and I provide you something or you pay me X amount of money per bill of blower or whatever it is and then we quit when we decide we're done. Fixed bid is, in my experience, I know some people do it all the time and I know people that I trust and admire and things like that, that they use them a lot, but I think that they are always a losing proposition. That you can limit stuff. You can go in and say, I'm going to work X, I'm going to work 20 to 25 hours to get this thing done and that's basically what it's going to be. But you collude in there and say, hey, if I'm working off of X assumptions and if those aren't true, then we're going to have to talk about additional hours. And of course, you can also just say, well, I'm basically going to cap it at X amount. I think this is a reasonable estimate to get it done, but you want to leave yourself open so that you can come back and say, wait a minute, this is going to take a lot longer than we thought. We've changed scope of what I originally bid on and this needs to be adjusted. You can do that with a fixed bid, but then you, I think too often, end up in change management hell, basically, where you're having to argue things like, is this a feature? Should this have been included? Should it not? Is it a bug? Is it this? Is it that? And you also end up in a basically a competitive situation with your customer because if it's a fixed bid, your goal logically is going to be get the thing done in as few hours as possible because you make the most money off of that. Their job is going to be to push, their goal is going to be to push as much as possible into the project. So basically while they're pushing in, you're pushing out, you're trying to pull stuff out. And that ends up being, unless it's something you can agree on in detail from the start, you're going to run into issues. So I highly recommend wherever you can do time and materials, you can always do budget limiting things and stuff like that and say, hey, well, we won't go over this or once we get to this point, we'll revisit and we'll see where we want to be. You may want to tie some part of payment to milestones. So we'll work X amount of hours. We think we're going to get this done, but maybe you take 10% off of what you would have earned and say, we'll only get that last 10% if we hit our deadline or deals like that where you can start maybe making some adjustments if you need to, to help make sure that everybody's covered. Because I guess technically if it's time and materials, what you could end up doing is just dragging stuff out, dragging stuff out, dragging stuff out, and you're just billing, billing, billing, billing. But the vendor does have at any time basically the ability to cut it short. Even if they think that it's getting out of hand and they don't want you to basically just drop everything and for them to lose some progress, then they can always put some stuff together. And I've seen this. I've seen, I've been on both sides of that, situations where either it's somebody's running out of funding or whoever the provider is, is not providing what is needed or is in over their head or there's just a bunch of different things that can go wrong or that can change that would put you in a situation where you would want to essentially cut ties. And the goal should be that from the start, from both sides, that when you cut ties, it will be a positive situation. That's not always true. I've definitely run into more than a few that are happy to, and this is on both sides of the equation as well. I've dealt with people that are more than happy to bilk a customer all day long and I've dealt with customers that are more than happy to pay nothing and walk away with whatever the blood, sweat and tears are from the provider. So like everything else, be clear, communicate and set expectations. Now I've spent some time here talking about time and materials as opposed to fixed bid. That does not mean that I think that you should go into a project wide open, open ended. I think that every project you go into, even if it's time and materials, even if it is, hey, we need you to write code for us, we need you to develop systems for us for an undetermined amount of time, you should come in with some expectations. It may be there's maybe there's certain projects or certain applications that they're working on within those. Hopefully there's going to be either requirements or you help them with requirements. Maybe you do something that's a multifaceted, multi-phased approach where you maybe have period of time that you're doing design and that's going to inform some other piece doing an estimate and things like that. So while you're not necessarily doing fixed bid, I think you need to, for your sanity and your customer, is to have goals and milestones and tie that to actual numbers as far as maybe hours worked and things like that. Now the agile world makes it a little different because from sprint to sprint things can change and that's sort of the nature of it. But even then it makes sense to put together, have some sort of a roadmap to say, we're going to attempt this thing, we're going to try to get this thing done and we think it's going to take five sprints, 10 sprints, 100 sprints, whatever it is. And then you should be tracking towards that on a regular basis. If you say it's going to take 10 sprints, then each sprint you should be looking at how are we 10% further along the way towards that solution. And if not, put yourself in a situation where you can discuss with the, where everybody can discuss what are we doing? Do we need to eject some stuff from scope? Do we need to make adjustments? Are we okay with where we're at? Do we need to extend all the other things that can go into it? So even, and probably even I would say more so when it is essentially a situation where you don't really have a set ending, a sort of loose, hey, you're going to come in and you're going to do some coding for us, is make sure that you have regular feedback, that you have some goals, you have plans and you're working on achieving those goals. Whatever it is, you're writing that code, building out that functionality, solving that problem because this is this situation where you can very easily find yourself deep in a hole and nobody happy with how you got there. This is a situation that I've seen go sour just way too many times. It's basically because you, as a developer, you're just, you're in the groove. You get in there, you're getting work done, you're writing code, you're making whatever progress it is and sometimes you're not progressing in the right way. You're somehow, things are not meeting expectations and you're sort of quiet. Essentially you go silent for a while, they're silent for a while. The next thing you know, you've got a couple of weeks have passed or maybe more so and you get somebody who comes back and says, hey, wait, you're totally not where you need to be. Now, if this is a, that's a project management and maybe a management itself issue in a lot of cases, but if you don't essentially push your side of it and maybe help them manage you, then you can find yourself in a very not fun situation. I have run into that on more than a few occasions, particularly where you have a multi-tiered management situation where you've got some senior person and they're not directly relating with you, interacting with you. They've got some, call them an underling, somebody that works under them that is your direct boss and maybe a direct boss isn't, maybe isn't reporting stuff to the level they need to, or maybe they aren't keeping enough of an idea of what you're doing and they're not keeping up with that. And so at some point their boss comes in and says, hey, how are we doing on that project? Or why are we spending this money? Or some question like that. And then suddenly you're on the hot seat because you've, you maybe have to go back and justify your existence for the last weeks or months. That happens and that's reasonable to ask, but it's very difficult if you haven't been doing it along the way. Yeah, it's one of those things you want to be in a situation where you say, well, okay, here's what we've been doing and here's what we knocked out. Here's what we said we're going to do. Here's what we got done. Here's maybe some of the issues that we overcame or ran into that slowed us down or that we overcame in an effort to make sure that we hit our targets and our deadlines. And then basically say, well, yeah, either we've got a really good track record and it would make sense for you to keep working with us or we've struggled a lot and we can understand where you want to part ways. Or we understand it's expensive to keep us on and so we're part of your budget cuts. That is what it is. But the key here is to make sure that you're communicating, that you're planning, that you are not, it's not really completely a CYA, but it goes back to the contractual side of it. What are you, what did you agree to do? What are you tasked to do? And then is that being moved forward? And this is a challenge that I've run into several times where you come in with your work order, the thing that you're supposed to be doing. And the next thing you know, you're getting pulled aside into other stuff. And on a time of materials, if you're getting paid by the hour, you're sort of okay with that because like, okay, well, you're paying me to do some work. You want me to do some other work. That's fine. I'll do that. But if your success basically is graded on whether that primary project got done, then you want to make sure you don't end up in a situation where you get to when that thing should be done and it's not. And you say, well, you know, I got pulled aside and all this other stuff. And they, somebody says, well, wait, you weren't supposed to get pulled aside. You were supposed to focus on this project and why were you doing those things, those other things? So be very clear on what is expected of you. What are the goals? And make sure whatever the work is that you say you're going to get done, that you become a champion of that basically and say, okay, this needs to move forward until they say otherwise. And if they do, then that's maybe where you say, okay, well, wait a minute. This is the contract that I'm working under. If you guys don't want to do that, then we need to adjust the contract. We need to maybe just close out that statement of work and write another one or an addendum or something like that. Now that's part of why a lot of SOWs are fairly generic, but some are not. Some can be very specific. Now in the closing minutes, because I hate to close on a sour note or whatever, but from a fixed bid point of view, if you were doing a fixed bid project, I don't care how small it is, be very, very specific about what is going to be included. Do not assume anything. The biggest way to get burned, the most common way I think you can get burned, particularly in the side hustle work for hire world of your gurus and your Upworks and fibers and stuff like that, is you get somebody that says, hey, I'll pay whatever it is. I'll pay $500 for a five page website. I just need somebody to build a website. It's going to have five pages. It's going to have some content. It's just going to be a basic website. I don't know how many times I've walked into a project like that. As I talk to them, it's not really five pages, it's 10 pages. They're not basic pages. They're pages that are maybe integrating with a financial system or taking credit cards. They've got security things to allow people to register or not. It's got to validate passwords or it's got to do encryption or it's got to go call some APIs. People look at it and say, oh, well, it's just five pages. But sometimes those pages are applications in themselves and websites in particular, the whole design stuff. Sometimes people are going to come in, they're going to expect you to create a logo for them and all these colors and fonts and all the little things that are the user experience that are the look and feel. Although people are getting more knowledgeable about that and mentioning user experience as part of the project, there's still some that don't. You don't want to get in a situation where you put something together and say, okay, here you go. You're sort of off and running and they say, oh, wait a minute, this looks horrible. You say, well, that's not my job. I've put together what you gave me, wireframes. I put those together. We've got what we agreed to. And they say, no, no, no, you're supposed to make this user friendly or whatever it is. You're supposed to make this flashy or whatever the word is that they use. Do whatever you can to make sure that when there's those little adjectives of make it look cool or make it look businessy or some people even say, well, make it, it just needs to look like this site. And they give you a link and you say, okay, even there, do you mean you just want me to reproduce that site? Which may not even be legal. Do you want this functionality that they have built into this thing? Do you want this sort of navigation or you just want something that sort of looks like it? And if it sort of looks like it, then what is it that to you is, would be the traits of sort of looking like? This stuff is just, it's crazy. The scope that can be out there and it's really easy to get sucked into something thinking it's going to be a quick and dirty little website. You can get done. You know, you just put some pages together. They say, yeah, they'll make it look better. Fine. And then you find out that no, no, no, no, there's a huge amount of extra work that's involved in it. I've been in projects that have literally gone, oh gosh, probably 10 times what the fixed bid was. Usually because I'm a nice guy and I just keep working for them when I really shouldn't have. I probably should have locked it down earlier and said, okay, this is what this is going to be. And then, you know, we're going to do that. We're going to assume this, but it's going to be a time and materials, you know, or I'll work until, you know, this budget runs out and then we'll talk about where we can be. And we're going to talk along the way to make sure if possible, we can get all the key features in within your budget. It's all about setting expectations. just whatever you do, do not let them and do not yourself allow for vagaries because you would be amazed at how often you will end up getting bit by those. And the next thing you know, you're either deciding that you've got to get a lawyer or is it even worth it? Maybe you write it off and if you do this enough, you will write off work at some point. I know companies, I know individuals, I know personal experience of stuff where you're just going to get in situations just like, look, I would rather write it off or we're going to have to, or you bail out on a project early and say, okay, obviously you guys aren't going to pay, then you need to walk away, which like I said, it's never a situation you want to be in. But hopefully the situation you are in is one that you want to be in. And when you get into these things, like I said, if you set expectations and you communicate them properly, then that's going to be your best chance for success and making sure that the vendor that likes you and selects you initially is one that will refer others to you when you get done. And that being said, I'm not even going to bother with a challenge this time because I think the challenge is just sort of absorbing this and moving forward. And when this impacts you, hopefully that you've learned a couple of things here. You've got a couple of things to consider when you're putting together, when you're signing that document or putting one together. And until then, go out there and have yourself a great day, a great week, and we will talk to you next. Thank you for listening to Building Better Developers, the Developer Nord podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developer.com. Just a step forward a day is still progress. So let's keep moving forward together.