How to Mitigate Risk During Software Development

, , , , , , , ,

Brett Miller is the president of Custom Software by Preston (CSP). For more than 10 years, CSP has impressed clients with highly effective software solutions and teams of multi-talented software engineers.

A software development client should complete a thorough “due diligence” before selecting a developer for his critical project. Then, he must complete the finalization process by drafting and executing the legal contract/agreement.

Contracts attempt to define the responsibilities and duties of each party; however, people often overlook whether a contract covers certain risks associated with non-performance.

Take a look at the eight scenarios below. These tips can help your company cover its legal bases when contracting a software developer, or vice versa.

1. Time & Material (T&M) or Fixed-Price Contracts

In a “time and materials” contract, the client assumes the burden of cost overruns, whereas in a “fixed-price” scenario, the developer assumes this risk. Weighing the two, many clients assume they are ahead of the game by passing the potential for cost overruns to the developer. However, they but fail to consider that the developer must add that cost-potential into their fixed-bid up front. So in a fixed-price contract, the client pays the extra cost, even if it proves to be unnecessary.

Fixed-price contracts also have the potential to create disputes. Often, deliverables that were implicitly intended might not be included in the original project scope. Both parties should be very aware of what exactly is included in the project. Fixed-price means there is a fixed scope of work, unless additional moneys are paid.

In a time and materials contract, the developer gets paid on an hourly basis. The motivation to finish quickly may be diminished by the opportunity to bill more hours. In this case, the client takes the risk that the developer will prioritize his own desire to profit on the project.

2. General Note on Contracts and Non-Disclosures (NDAs)

Contracts and NDAs are legal instruments which establish the rights, duties and privileges of those who are a party to the agreement. These instruments protect both parties to the extent that they are willing to pursue them in a court of law.

Here is a simple rule of thumb, although I encourage you to also check with legal counsel. Unless the dispute is over $10,000, most attorneys won’t take the case. And even if they do, they usually keep one-third of any money they collect. It can take several years to win in court, and the problem is further exacerbated by the fact that the losing party may no longer be in business or have assets from which to pay. One last note, many contracts call for the losing party to pay the legal costs for the winning party, which can save you money if you win, but cost dearly if you don’t.

3. Advanced Payment – The Industry Standard

Many contracts call for advanced payments or retainers. Essentially that means the developer works on the client’s money, and therefore, the client bears the risk for the developer’s potential lack of performance. This is the norm in the information technology field. Very few developers will take money out of their own pockets to build a client projects (in the hopes that the client will pay).

An improvement to this model would be to limit the retainer to two week’s worth (or less) of development time/labor (weighing the progress of deliverables). Upon client acceptance, the retainer can be replenished for the next cycle. Sending a wire or paying via credit card allows for instantaneous payment. Client risk is bit more limited when using this approach.

4. Phased Payments – The Other Industry Standard

Some projects are divided into three or more segments. The first phase is paid up-front (client risk); the second is paid at some pre-arranged interval (equal risk); and the last payment is made upon project “completion and acceptance” (developer’s risk). In this scenario the last payment can be problematic to collect, as subjective issues can arise regarding quality and scope.

One minor modification to the phased payment method specifies that the developer finish the final deliverable in their own environment, to which the client has access for testing. Upon client acceptance, the final payment is made and the vendor transfers ownership of the application and all code to the client. This is a very solid, technique balancing risk.

5. Warning! Warning! Kill Switches

Some unscrupulous software vendors build a kill switch into their applications. In the event of a dispute (and the client refuses to pay), the vendor can remotely shut down the application. I recommend that your contract include language that prohibits this “extortion like” practice.

6. Disappearing Freelancers

Many IT Professionals have heard this story before: A company finds what appears to be a knowledgeable (and affordable) freelancer on the Internet. Initial contacts with the individual indicate great responsiveness. Payment is made, a few conversations take place, some small progress is shown — then all communication goes dark and the freelancer disappears.

I believe this most often occurs when, with the best of intentions, a freelancer takes on a project and finds out he bit off more than he could chew. He believe his efforts were substantial, but things just didn’t work out (in other words, “not their fault”). Even more important, as a freelancer he is simply not in a position to refund any money. It’s easier to disappear than to deal with the conflict, so he runs.

Freelance software developers do offer expertise, experience and cheaper rates due to lower overhead, but the clear risk is a lack of any substantial backing. Therefore, this model does have more risk for the end client.

7. Payment via PayPal or Credit Card Carriers

Many developers accept payment via PayPal, and some even accept credit cards. These credit carriers offer “dispute” mechanisms that allow the payee to challenge any charge which was not delivered as promised or described. This method should be encouraged by the client (even if they need to pay the credit card processing fees), as it provides additional protection.

Vendors have an opportunity to respond to any dispute. Carriers to a certain degree are arbitrators and if they receive enough complaints, a vendor’s account can be canceled.

8. Risk Assessment

Software development projects carry financial risk factors for both parties. These risk factors need to be considered seriously and should be discussed with an attorney. Clients and developers alike need to know what they are getting into and prepare for scenarios that don’t work out as planned.

Image courtesy of iStockphoto, OtmarW, Flickr, quaziefoto, slimmer_jimmer

More About: contracts, contributor, dev, features, freelance, law, legal, software development, Web Development

For more Dev & Design coverage:

How to Communicate Your Software Needs to a Developer

, , , ,

Brett Miller is the president of Custom Software by Preston (CSP). For more than 10 years, CSP has impressed clients with highly effective software solutions and teams of multi-talented software engineers.

It might seem obvious, but effectively communicating your project needs to software developers is more than just important. It could actually mean the difference between a project that achieves its objectives and one that does not.

Having an idea in mind and being able to discuss it intelligently isn’t always enough to efficiently communicate all the critical nuances and required details. I strongly recommend that clients produce a requirements document to facilitate agreement among stakeholders, and in turn, to communicate that information to members of the development team.

SEE ALSO: HOW TO: Hire a Designer or Developer

Below are some techniques and exercises that can be used to help you document the vision for your software project.  Chances are you’ll discover new details and potentials that you hadn’t even considered before.

The good news is that you can’t do this wrong.  The key to success is to take the time to thoroughly dig into your thoughts, identify vital details and pinpoint the scenarios you need to account for. Spending the time to be thorough at this juncture could end up saving many hours of development, which translates into fewer headaches and lower costs.

Let’s Get Started

  • List a few websites you like. Is it the aesthetics or the functionality? Is there something you do not like about any of the websites?
  • List a few competitors. What do you like and not like about their websites?
  • List three adjectives. Give the developer three adjectives to describe the look and feel of the user interface that you would like built — for example, sophisticated, modern and edgy.
  • Input and Output of the application: Identify the information that’s entered into the application, manually or automatically. Also identify the information that the application produces.

Existing Applications

  • Documentation: Wherever possible, gather all the documentation (development codes, executable app, notes, documentation, etc.) and have it available for the developer.
  • Process Detailing: Your developer will need access to a live account to better understanding existing software. Even if the process is currently handled manually, providing details (and examples) on the specifics will give your development team a solid point of reference.

Application Users

  • Planned System Users: Categorize them into types when needing certain application capabilities wherever possible.
  • Features Needed: Describe the major features you want.

Add details to the major features categories identified above:

  • Where is this feature accessed and how is it used?
  • What are the different scenarios of usage, and if this happens, then what else can occur)?
  • Who is the capability designed for?
  • Why do they need to be able to do this?
  • Is this capability optional, due to cost or some other factor?
  • What additional details can you add to the feature list?

    • Internal vs. External: Which project responsibilities will be handled internally instead of having a development team work on it? (examples: drafting requirements, writing verbiage, testing, hosting, marketing, graphic design, etc.)
    • Internal Staff Capabilities: How technical is your staff to use the advanced features of the application?
    • Defining Success: What defines success on this project — affordability, user friendliness, aesthetics, simplicity, information organization or some measured combination of those factors?

    Final Check

    Has everything of importance been identified, categorized and explored in your documentation?

    Seasoned software developers have been through this analysis process many times. Your efforts to produce as much of this information as possible in advance will aid their efforts to reach your project’s goals. Complete this documentation as thoroughly as possible and you will find yourself well on the road to project success.

    Image courtesy of iStockphoto, TommL

    More About: Business, contributor, developers, features, software development

    For more Dev & Design coverage:

    7 Ways to Know if a Development Project Is Worth Your Time

    , , , , , ,

    Brett Miller is the president of Custom Software by Preston (CSP). For more than 10 years, CSP has impressed clients with highly effective software solutions and teams of multi-talented software engineers.

    Remember the old 80/20 rule? The same applies to software development inquiries, as in 20% of sales inquiries result in 80% of new sales volume. The challenge is being able to identify which inquiries will be fruitful, and which will only cost you time and effort.

    Potential clients expect accurate estimates — clearly a reasonable request. For any developer, accurate estimates are a time consuming and challenging task because custom software development and technology are constantly changing, and it’s not the same as buying an off-the-shelf item.

    Even worse, many prospects decide not to move forward with their project at all (with any vendor). It’s not because the bidders did anything wrong, but because the client did not realize the full extent of the commitment required (usually defined by cost).

    I have spent 15 years of my career in software development, both as a freelance developer and as a business owner. That practical experience has taught me to quickly recognize which potential projects are going to move forward and which are just not worth pursuing. There are Seven Axioms I use to help identify the solid opportunities.

    1. Documented Requirements

    If the client took the time to write down what they want, it is a strong indicator that they are serious. Otherwise, you will need to do this for them. Then time and documentation flows back and forth until a project’s parameters are finalized.

    Rule: Lean toward clients who have taken the initiative in identifying and drafting their own software project requirements.

    2. Urgent Need

    This goes right to the heart of the matter. Is software development a logical next step in their growth or does it seem more whimsical/experimental in nature? For example, does the software project tie in to the launch of a new product without which, they might falter?

    Rule: Lean toward projects that have an immediate nature, where the client absolutely needs it done.

    3. Deal With the Decision Makers

    Many times decision makers send underlings to gather the initial project information and specifications. In my experience, information gathering usually results in little else. Decision makers are involved when projects are deemed critical.

    Rule: Lean toward projects where you work directly with the decision makers — the ones who steer the project and identify priorities.

    4. Budgeted Project

    Could anything be more critical than having realistic expectations about the cost of development? Many prospects may have misconceptions about cost, which is further exacerbated by vendors who shy away from early discussion on the subject. Sales professionals consider rough estimates to be an important applied mechanism of the trial close, potentially saving many hours of time and effort.

    Rule: Use rough estimates to measure a client’s continuing interest. You could say something like, “Based on these preliminary estimates, does it make sense for us to take the next step?”

    5. Process and Timeframe

    Questions about the bidding process and timeframe should be addressed up front to uncover internal processes (like board reviews) or external influences (like venture capital availability). If the process seems extensive or the time frame is not well-defined, there is good reason to question if the project will ever happen.

    Rule: Realize that the quality of your work and the accuracy of your estimate will not win the project if their timeframes or processes are inhibited by roadblocks. Lean toward projects that have appropriate funding, immediate need and the attention of decision makers.

    6. How do I Earn the Business?

    Asking about the client’s selection criteria make sense. If they haven’t already done so, they need to think about these things now and you need to know the rules of the game. Their processes and criteria may even play into the overall desirability of the project.

    Rule: Understanding what is required to get the job reveals a lot about what it might be like to have the job. Do you even want to work within the structure and environment the client creates?

    7. Show Me Some Money!

    Your time and expertise has value. It is not that unusual for a potential client to be looking for a free consultation, which may only be used internally (if at all). If possible, ask the client for a small amount to put together the initial requirements and specifications for the project. If they are willing to spend real hard cash on developing the specifications, they are really serious about the project (and you as a potential vendor).

    Rule: Initial project analysis, documentation drafting and identifying deliverables take considerable time and effort. Describe the process to the client and don’t be afraid to ask for payment for these services.

    Sophistication, Process and Specifics

    Legitimately qualified software development opportunities can be summarized in three words: sophistication, process and specifics. You need all three in your approach to the sales cycle and should expect all three in return.

    Sophistication is about the approach to the project, indicating that available information and outcomes have been given thorough consideration upfront. Process relates to both parties understanding the steps and effort it will take to achieve success. Specifics have to do with identifying and sharing the salient properties of all project parameters — before, during, and after the project.

    Approach every potential project with these factors in mind and you will know which ones are worthy of your attention, leading you down the path to a sale.

    Image courtesy of iStockphoto, peepo

    More About: Business, contributor, developers, features, How-To, List, software development

    For more Dev & Design coverage: