Managed Mayhem

A non-disclosure agreement (NDA), also known as a confidentiality agreement, confidential disclosure agreement (CDA), proprietary information agreement (PIA), or secrecy agreement, is a legal contract between at least two parties that outlines confidential material, knowledge, or information that the parties wish to share with one another for certain purposes, but wish to restrict access to by third parties. It is a contract through which the parties agree not to disclose information covered by the agreement. An NDA creates a confidential relationship between the parties to protect any type of confidential and proprietary information or trade secrets. As such, an NDA protects non-public business information. -Wikipedia

I’ve probably signed 100 of these things since I’ve been a software developer. For the most part, I don’t have a problem signing them … so long as there is actually an equitable exchange that occurs between myself and the entity requesting that I sign one. 90% of the time, this is not the case. Frequently I’m asked to sign these agreements before anyone has even agreed to hire me for my services, before they will even begin a conversation with me about what they would like me to do for them. At the point when I sign one, I have always felt that I’m giving them something… my freedom to be able to talk creatively with anyone else about whatever this entity values about the conversation that is about to take place, which is usually very subjective… and when I’m being asked on the front end to sign one I really have no idea what the actual value is going to be if anything. I have no way of really measuring my risk of signing an NDA until after the NDA is signed and the conversation is done.

Signing an NDA for a conversation with a startup is even worse because they are usually convinced that all of what they are doing is 100% original. No offense folks, but original ideas are extremely rare… and a startup really does not have ‘trade secrets’ yet. Besides, as a startup … you need all the help and exposure you can get… be smart about sharing within your immediate network, but the benefit from help from folks you do trust far outweighs the legal benefit of protecting your ‘original’ idea from folks that you don’t. Bottom line is… if you don’t trust the person you’re talking to enough not to steal your idea, don’t share it with them at all… NDA or not.

I totally understand why companies would want to protect their interests. I just wonder if the nature of the NDA actually serves to hinder trust and creativity rather than to enhance it.

Unfortunately, the NDA has become one of those tools in the toolbox of managers and executives … and is pretty much a common way of doing business, so they are unavoidable in many circumstances if you want to do business with who-ever is requesting that you sign one.

Here are some things that I always look out for when a request to sign an NDA has been presented to me:

• What is the term?
  Make sure that there is a defined term (6 mos, 1 year) for how long you are being held to the NDA. Seriously consider the value of signing an agreement that holds you to being indefinitely gagged.
• How open / vague is the agreement?
  Is it specific to an industry? Does it specifically name the product that you’re going to discuss?
• What am I really required to keep secret?
  Are there specific things named in the agreement that you are required to hush about?
• Are there exceptions?
  Are you allowed to discuss the contents of your conversation with your partners or contractors?

In my experience, these things are such a pain that combined with the fact that you generally don’t know what you’re really risking until after you’ve signed one … It’s almost not worth it to even go through the effort of having an attorney review them and then have to manage all of the ones that you’ve signed to make sure that you’re in compliance with them. That said, if you think that there is going to be an equitable relationship, and the client is really adamant about having an NDA, I would recommend having an attorney look at the agreement.

When I go to the mechanic to have something fixed, he charges me an ‘evaluation fee’. When I need an attorney, I will usually get a first visit free, but anything after that is billable no matter what it is. If I go to the dentist or doctor, I pay for a visit (sometimes several!) before I am told what is wrong.

Why is there the expectation in custom software design and development that we should give free quotes / estimates?

I think that this expectation is the primary reason why we have such a rash of ball park estimates in this industry. If it’s only a ‘contest’ of who can come up with the best price and not the best plan… why bother coming up with a plan at all?

For projects over a certain dollar value, I will build a requirements specification / definition that includes (among other things):

• Functional Specification
• Design Specification
• Technical Specification
• Module / Component break-down
• Server Architecture (If required)
• Delivery Milestones / Schedule
• Budget

When I build a requirements definition that leads into a proposal, there is sometimes research involved for the specific technology or need that the client has, primarily because they are looking for specific solutions and someone to solve problems for them.

I once had this client who wanted to setup fax on demand via the web and via an 800#. I had never worked with fax on demand, but I spent the time and researched it, found a vendor for them, talked with the vendor about the project and the customizations we’d need for their software, negotiated with the vendor on price and added that to the project budget along with information about the vendor and their technology in the technical specification.

Many clients I have worked with had a very basic idea that after several brainstorming sessions turned into something much more lucrative and easier to accomplish than what they had originally set out to do.

Yet another prospect of mine wanted to have the ability to make (not just take) online payments via ACH. I’ve never done this before… but after about an hour of research and some phone tag, I got it figured out.

Many times I can’t meet 100% of the client’s needs myself or even with my immediate team, and so I need to step outside of that and find someone who can help. Sometimes I don’t even know if what the client is wanting to do is possible!

My point is that all of this consulting effort prior to proposal to ‘get it right’ takes time, and there is value during this process when it is done properly.

Early on in my business, I found myself building out proposals and coming up with sometimes great ideas that prospects would then take and use with someone else who outbid me. During the interview process and initial relationship forming, it is inevitable that there is an exchange of knowledge / value from our side to the client’s side. This business of business, systems and software analysis is primarily a consulting role that we take on particularly early in a project… and knowledge that we’ve developed over the course of our careers is frequently freely given away while we go through the bidding process.

I’ve gotten to the point where I’ve realized that rather than needing to feel protective about these things, to make sure that I can give accurate estimates, and to avoid the tendency to just lazily ‘ball-park’ projects, I decided that I would build proposals over a certain dollar value out of actual requirements by spending the time interviewing the client for as long as it takes, researching about their needs, and expecting that I get paid for properly building out a schedule and budget for them. That consulting process is now a part of my product / service, and I give them an up-front estimate of how long I think it will take / cost based on the initial information that I get from them. Reviewing client material and interviewing them over a period of time prior to forming an estimate or proposal helps to develop a realistic schedule and budget and develops a true relationship of trust with clients who are serious about working with me because they respect what I do, and are not just looking for free consulting and a bid for work that may never come. It allows us both to take each other seriously and develop a solid and realistic plan together.

I will openly admit that this ‘rule’ has resulted in lost ‘opportunities’ because many others do not follow it, and so many prospect’s expectations are improperly set by other developers or firms. I’m ok with that. My intention is not to have a large number of opportunities, but rather… a small number of strong relationships that I’m purposed to be involved in. It is in this sense, my ‘Purple Cow’ method.

After going through this process with a client, I’ve never had them take the result and go somewhere else with it because I’ve been able to take the time to prove to them that I’m an asset to their team. If they do ever decide to go elsewhere because of price, they have a well defined requirements specification / scope that they can take with them, and I got paid for my time. I would have rather gotten the gig, but both of us are (relatively) happy. When I haven’t gone through this process with a client, 90% of the time, they go elsewhere for a lower bid because they were only after price, and my pessimism skews my ball-park estimates high. Or if I do go through the process with them, they don’t buy,  and I don’t get paid for it, 100% of the risk is on me and I feel like I’ve been ripped off. That is a waste of everyone’s time. I don’t compete based only on price, I compete based on quality, honesty, and experience. Some of these folks have come back to me after going out on their own without going through this process in order to start over.

The company I just left went through that same thing where they did not want to hire me on the front end to help them through the dream and define process… and as a result, they spent $50,000 and lost a year of effort, and still came back to hire me and one other guy (who i interviewed) in order to rebuild their application from the ground up because it was insecure, not highly available, not ready for production, and ugly. They had a huge opportunity cost because they effectively lost almost 2 years where the product wasn’t taken to market due to a failure to plan or set expectations properly on the front end with the developer they were working with. That’s not the first time I’ve been pulled in after the damage has been done.

Now, I’m not talking about your average contact form, CMS installation, wordpress theme / customization… or ecommerce website using existing technology. I’m not talking about web site design. Systematic, Cookie cutter, packaged, or single feature type requests don’t even need to be estimated. I have a default price list for almost anything you can think of when it comes to these ‘one off’ type requests, and even website design is standardized enough that you can easily quote it based on the number of layout revisions and pages being laid out. I’m not even talking about feature requests made during maintenance of existing applications… though that can be another beast in itself.

It’s the larger, new custom projects that I’m really addressing. Think about it like this… traditionally, planning for any project should be about 10-20% of your project time. If you have a 1000 man hour project, that is 100 to 200 man hours worth in planning. This planning is going to need to be done at some point no matter what. Why not at least do some of it BEFORE you have already developed a budget and schedule so that you can be more confident in what your budget and schedule will be? It just seems backwards to me to trust a developer (or firm) who is motivated primarily by making the sale and getting a proposal done quickly … to spend the time necessary to form a solid plan required to give you an accurate budget and schedule without paying them to do it. Pay them to do it right, and make sure that they clearly understand your needs before you accept a budget or schedule from them. If you’re unhappy with the price afterwards, at least you (hopefully) have a well documented functional specification that you can take to another developer and you can get an accurate quote from them using it.

I frequently run into the request for a ‘ball-park’ estimate for software development projects. I loathe to give these type of estimates. They are inherently dishonest from the very start because they are a ‘promise’ based on incomplete and sometimes incorrect information.

I love to give a free one hour consultation for my clients. It gives us a chance to get to know each other, introduces me to their product or idea … and begins the process of figuring out ways that I am able to help them. I can usually tell rather quickly within this one hour period if I’m going to be an asset to their team or not. In most cases, clients have a very basic idea of what they are really wanting to accomplish. A loose set of ideas, sometimes scribbled on a notepad or napkin while you watch. Other times, clients will actually have some prior education and will have something a little more organized… perhaps some storyboards or a diagram showing what they want to do. This is better, but honestly… still not enough to give a proper estimate.

The problem that I have with ball-park estimates is that they are too subjective and emotional. I might be hungry that day, or I might not be hungry at all. I might be really excited about working with this particular project or client, or perhaps I’m not really interested in what they are doing but still want to help. Maybe I just want the client to like me. Maybe I’m without work at the moment, or I might be swamped. None of these things should really matter when building project estimates because they are subjective, emotional, and variable. We have all been in that position where we were without work, underbid a project (usually as a ball-park estimate) and then half-way through the gig we’re late, overbudget, swamped with new work feeling taken advantage of, and no longer really motivated to do a good job. Why do we do this?

When I have given them, my ball-park estimates for custom software development swing manic depressively between polly-anna optimism and grinch like pessimism. This is never good because either way, someone is going to be unhappy with the end result. If I am pessimistic and shoot high, clients get skittish or I automatically lose to moderates and optimists without the opportunity to close. If I am optimistic and shoot low, inevitably the client is disappointed anyhow because:

• Time lines are missed
• Market opportunities are missed
• Budgets are missed
• Rush to release results in mistakes

Some clients have been thinking about and developing their product / idea for years… it’s only reasonable to expect that we are given the time needed to study their product / idea thouroughly in order to do our jobs properly. There are a lot of software development firms out there who  with respect to setting budgets…they hedge on margin / volume, or occasionally getting lucky. They figure ’some we win, some we lose’.

I don’t like to lose… I like both the client and me to win every time.

The analysis portion of our jobs as software developers is primarily about reducing risk. I see gambling with incomplete / inaccurate project estimates as a risk that is deadly to projects, and one of the primary reasons why they fail. Get as much information about the project up-front. Spend the time that it takes to get as accurate an estimate as possible. Don’t worry about being perfect, but at least make the attempt.

I promise to write an article about how I estimate software projects soon. For now, feel free to comment about some of the project estimation tools you’ve used that have worked for you!