Improving Your Process: Contracts, Proposals, Scopes of Work, and Complacency

Perhaps one of the most intimidating things for me personally when starting Iron to Iron was making sure we had a solid contract in place. Contracts are a unique document to me, mostly due to the stigma of distrust that comes with them. Not only distrust on our part as the service provider, but also the recognition of the possibility that the project could go poorly.

Kevin and I took a lot of time to come up with what we felt was a solid document that would prevent the worst from happening and keep us from being overly liable or under-protected. As our first few projects came to completion, we would recognize areas of the contract that were unclear or blatantly missing. Not as a result of projects going wrong, but simply recognizing that we had omitted a detail along the way. We’d compensate, make the appropriate edits to the contract, and proceed with the next job with the revision. We haven’t had to ever rely heavily on our contract to protect us or provide any sort of legal offense in invoice fulfillment and continued on schedule.

A realistic look at our contract

As we were out of town for a conference last year, we took some time to meet up with a client who was local to the area. We didn’t have an active project with them at the time, but had completed one a month or two prior. It’s rare for us to get together with clients in those circumstances because most are out of town and we don’t have the ability to meet in person casually. We took advantage and grabbed some food with our primary contact and talked shop for a while. It was great because the conversation blossomed almost to an exit interview or debrief of sorts where we asked the client for some critique.

Process has always been a big deal to me, and it continues as such with every job. I want there to be reason behind each decision that gets made, experience being the highest priority. Kevin and I talk through decisions each and every day, big and small. I value that about our business relationship and attribute the work we do to our process behind it. Hearing feedback from an applicable outside party is an opportunity I don’t want to lose though. In fact, it’s something I’d like to make more formal in our process.

Our client was pleased with the project and had a lot of good things to say, but there were two critiques that we took really seriously. The first critique was that our contract was too long, too overbearing. My pride immediately kicked in as I felt this document we put so much time and effort into was being shoved aside as being abrasive. The client continued with the other critique: that he would have preferred more phone meetings in contrast to the project management software we had set up. That was also a blow to my ego because I feel so strongly about a solid non-verbal based communication system through the life of a project. The two were heavily interrelated as our contract specified a number of times that revisions must be indicated and approved in writing. Our project management solution catered directly to that so the two critiques are a double whammy to our process in my eyes.

After a while though, we realized that he was right. To start, I’ve always wanted to avoid the phone, phone calls, and phone meetings. They’re a pain to set up and take way too much time overall, huddling around a speakerphone isn’t conducive to getting things done, and too many details get lost. I make an active effort to avoid setting up phone meetings. I much prefer a discussion-based Web platform that everyone has equal access to that therefore puts the responsibility on the individual himself as opposed to the luxury of deflecting blame to someone else. All of this may come off as disgruntled but please don’t see it as that, it’s just an effort to be as straightforward, open, and documented as possible.

I need to be more cognizant of other people, however. Other people prefer the phone and I understand why. I happen to be able to convey my thoughts best when writing, but other people need to talk things out. I shouldn’t dictate company process on my personal preference, but instead find out what works best for everybody. There are times now where I’ll spend extra time simply documenting phone calls in our project management software so as to find that final level of (documented) clarity as we move forward. Problem solved.

Revising our contract

The other critique that really hit home was that about our contract. Over the next few months Kevin and I continued to take notice of our contract being too much of a hiccup so close to the finalization of a job and it disrupted the discussion’s environment in such a way that we needed a change. I must admit that Kevin often alluded to the fact that he felt our contract was a bit over the top, but the paranoia and distrust in me persisted in “making sure our bases were covered” even though my fears had absolutely no grounding.

It was time to go back to the drawing board, so that’s just what we did. Our process involves a lengthy estimation and scope definition phase, which is definitive when it comes to the contract. We’ve come to call this the Proposal, and it includes all of the details about what needs to be done to complete the project at hand. Yes, it takes us a long time and there have been times when that work was done for naught but we see it as foundational to our process. Every project is completely and utterly unique, and we need to keep that in mind. Once we start labeling every project as ‘the same but different’ we get complacent to the work at hand and suffering begins. The work suffers because it’s not pushing your own limits, the client suffers because they’re being guided through an assembly line, and you suffer because your job will become monotonous.

With our focus being so pinpointed on defining the scope of work for a job, we began to think about how that should correlate with our contract. As it stood, our contract covered a wide range of circumstance. It defined the parties involved, the project definition, the payment terms, the technical environment details, refund policy, support policy, and more. It was overwhelming. It was eight pages of legalese that made it sound like a peace treaty between warring nations. That’s no way to finalize an agreement meant to invoke joy in starting an exciting project. We needed something new.

Of course we’ve all read great recollections on this very issue like Contract Killer from 2008, but that wasn’t what we were going for either. We wanted our contract to be simple, but serious. We had that client feedback about the contract being “fine” but overbearing at the forefront of our mind as something occurred to us. We’ve simply overcomplicated our process.

I’d venture to guess that 35% of our old contract surrounded payment terms, something we found to be commonly overlooked by our clients. The section was so long because there are three types of jobs we work with:

1. Design and development
2. Design only
3. Development only

While we always prefer to take on jobs that will retain the balance of work between the two of us, there are times where it doesn’t work out that way and Kevin’s workload will outweigh mine or vice versa. We also further broke things down on the level of payment terms contingent on the overall cost of a project. There were three tiers based on the project price that would determine percentages and milestones for invoicing. As you can imagine, it needed to be quite wordy and full of conditions. We quickly realized that it makes more sense to include payment details in the scope of work instead of trying to accommodate every circumstance in our contract.

That lead us to the reformational thought about the process as a whole. While we were using the estimation process as a reference for our contract from day one, we decided to integrate that even further by appending things like payment details, technical environment details, and other project-specific information to the project Proposal itself. Once a Proposal has these details, the document becomes a Scope of Work. Naturally the payment terms, milestones, and other project specific details have been at least discussed informally prior to the inclusion in the Scope of Work, so there’s no surprise factor for the client. All of the project-specific information is now encompassed in a single document as opposed to split up between a proposal and a contract.

With this change we were able to further refine our contract to be even more generic and easy to understand. Naturally a number of sections remained, but the language used was streamlined into something more easily digested. We ended up condensing a bloated eight pages to a seemingly paltry two pages, and we loved it. When we read and re-read the new document it felt equally encompassing but exponentially more straightforward. Instead of coming off as an overbearing final step to project inception, it was an easy to read confirmation of all the steps leading up to it.

We’re much more comfortable with our contract today in comparison to the first version, we like that our process is ingrained in the physical combination of two documents we’ve come to call the Scope of Work (which is a descendant of a Proposal) and our Contract. Creating that divide between the two makes a lot of sense concerning the way we work. The Scope of Work is all project-specific details including payment terms and milestones while the Contract describes persistent details such as our support & refund policies. Our goal was to ensure that our Contract was no longer a potential stumbling block but instead a starting pistol for a great project.

Don’t get stuck in your ways

The lesson we learned here isn’t necessarily about contract writing. A contract is something that shouldn’t be cookie cutter or boilerplate, it needs to support what you do and how you do it. It needs to accommodate your process instead of your process facilitating a contract. While it makes sense to reference other contracts, it doesn’t make sense to base your business on someone else’s ideas and implementation, not completely.

A major reason Kevin and I started Iron to Iron was to make sure we were putting our abilities to the best use possible. We want to provide awesome work for awesome clients backed by an awesome process. We want everyone to enjoy the project from start to finish. To do that we need to be both respectful and responsive to feedback. Make sure you’re doing the same. While you’re going to find things that work best for you (and that’s extremely vital) those decisions don’t need to be the end-all-be-all. Ensure you’re keeping an eye open for what can be improved, even if that involves flat out asking your clients what frustrates them about you.

I can only imagine we’re going to take some sort of exit interview more seriously as time goes on, so as to obtain some truly useful critique that we can discuss and possibly put to use immediately. I can’t help but reiterate the importance of not becoming stagnant in your ways, even when it comes to something like your contract.