I’m just starting to approach 1 and 1/2 years as a software consultant after 12 years at product development companies. Making the switch has been an invigorating, at times frustrating, job. Here are some random things I’ve learned while making the switch. Some of these statements don’t apply universally (of course) but I think in general they are pretty accurate.

  • Don’t settle for vague requirements

    At product companies there is less accountability, more risk taking, and budgets are looked at more loosely. In consulting these same companies will hold you accountable, look hard before taking on risk, and watch your billing like a hawk. In this environment you can not afford to have vague requirements. Even if it means taking longer than you anticipated for the requirements/analysis phase of your waterfall or agile project iterations, its worth it. Capture business rules, alternate paths, default values, and mock up user interfaces with Visio or Balsamiq to get client confirmation.

  • You can’t always deliver the best solution

    At product companies your goal is to create world class products. In consulting your goal is to create value for the client within a budget they can afford. This more often than not means choosing the more cost effective but less robust solution.

  • Don’t execute on verbal agreements

    If a client tells you something, get it written down and get them to agree to it via a email, signature, or other tangible, trackable asset. This helps to ensure that both parties are kept honest and that you don’t lose track of important statements made that affected your decisions later in the process.

  • If you can’t redo it all, learn how it was done

    Product companies and consulting clients alike are often replacing existing systems with new technology. If you can’t get a client to sign up for a vision of replacing the entire system, it’s often better to learn how the existing system works, even with its faults, and build new pieces with the limitations of the existing system (but with new technology) first instead of rolling out a radically different new implementation, even with better usability. If you don’t do this, you run the risk of having the client more focused on (and worried about) what they perceive as missing from the new code base instead of how the old features you didn’t port yet need to work in the new system.

  • Minimize distributed teams

    In a nod to agile and extreme programming, get stakeholders in the room. If gathering requirements and doing design, this means domain experts AND technical leads with a stake in the project. It’s too expensive to reset expectations later in the game. Occasional meetings don’t cut it.

  • Don’t co-develop architecture

    If you are creating a new framework upon which to build an application, don’t have some parts designed by another team than the other. This goes for database schemas as well. These critical pieces should be done with both team’s stakeholders in the room (see above) or by only one team at a time. It’s too costly to try to sync things up later, and no matter how hard you try to set guidelines for both teams to follow, you will leave something out that causes rework later. Rework is much more expensive to a core architectural component than in code artifacts at a layer of the architecture itself.

  • Keep it casual

    Try to have fun when you work with the client. Nobody likes someone who is serious all the time and you can work through a difficult situation easier when people are disarmed (including yourself).