As I said last time, too many companies are selecting and procuring software consulting projects the way they did in 1990. Time for a re-think, particularly for customer-facing and CRM software projects.\nThe discussion from last time was about definition and measurement\u2014the foundation of the project. Now it\u2019s time to look at other phases of your procurement process with a skeptical eye.\nHeresy No.1: Why Are You Talking to a Sales Rep?\nYou know the joke: how do you know when a sales rep is lying\u2014whenever his lips move. There\u2019s a more profound joke embodied in Seth Godin\u2019s book \u201cAll Marketers Are Liars,\u201d in which he states that marketers never lie, they simply create the conditions under which the consumer can make up believable fictions. The power of narrative and \u201cthe customer journey.\u201d Ugh.\nThere\u2019s a little book you might have noticed, \u201cLying\u201d by Sam Harris, that makes a simple but profound point: all lies have costs, and adults spend too much of their time lying to coworkers, vendors, bosses, family, and even themselves. Dan Ariely\u2019s work in behavioral economics indicates that most adults lie several times a day, and any \u201csavings\u201d involved with lying are a false economy.\nIf a sales rep\u2019s incentives are \u201cto get the deal\u201d and get the most money they can out of you, how exactly does a conversation with them help you? Really good sales reps provide actionable information that help you make a reasonable decision\u2026but those are really rare. Most sales reps are too busy creating an information bubble around you to cause a favorable decision before the quarter-end.\nAt my firm, we took Thomas Watson\u2019s maxim \u201ceverybody sells\u201d to its logical extreme: since everybody sells, there\u2019s no reason to have anybody in the organization who only sells. I want the guy who dreams up a ridiculous project plan to have to deliver on it. So, the project lead writes the proposal. And everyone on the team works with the customer to come up with a plan that can be executed.\nI will get tons of hate mail from sales reps of all kinds and from consultancies that\u2014for scalability and growth reasons\u2014have sales organizations. But clients, ask yourselves: how is it in your interest to promote the scalability and growth of your consultants?\nSo, heresy No. 1 is\u2026don\u2019t take a meeting with sales. Insist that your pre-contract meetings be with the team that\u2019s going to deliver your project. Which brings us to\u2026\nHeresy No. 2: Why Are You Accepting Interchangeable Parts?\nConsultants are individuals, with technical talents and \u201csoft skills\u201d that vary widely. Consultants are only interchangeable to an extent, and each transition involves learning-curve effects for both you and the consultant. This goes double for any project involving industry expertise: experience with your competitors and supply chain, and knowledge of business processes and regulatory realities of your marketplace.\nSo in making your decision about which consultancy to use, nail down the individuals who will be on the team at each phase. It should never be \u201cdeveloper 3 in Hyderabad,\u201d but a specific name with a particular resume. Understand in advance when the transitions will occur, and bake them into the project plan. Get commitments in the contract about talent swap-outs, and make reasonable allowances for the unforeseeable (illness, family crisis, etc.).\nThink Hollywood: there are specific penalty clauses if a star flakes out.\nI will get even more hate mail from conventional consultancies that\u2014for scalability, cost control, and growth reasons\u2014use talent pools and swap individuals in and out of the team. But clients, ask yourselves how that is in your interest.\nThat said, be flexible about \u201cemployees vs. subs\u201d from your consultancies. If the individuals who are willing to truly commit to a project happen to be subcontractors, who cares as long as they are excellent? I\u2019ve seen million-dollar projects where none of the people on the team actually worked for the consulting firm. A little weird, but definitely manageable.\nHeresy No. 3: Why Are You Doing Discovery After the Project is Approved?\nYour project approval and procurement process almost certainly assumes that the budget and schedule are fixed. During the initial phase of the project, you are going to discover requirements and business process implications. If you\u2019re lucky, you won\u2019t discover much new after the first 10% of the project funds are expended. (If you\u2019re unlucky or are in a rapidly evolving organization, you may be in process discovery all the way through the project. Yummy.)\nOther than bureaucratic simplicity, why are you doing approval of the whole project in one pass? Doesn\u2019t this just beg for an incremental ($10 word: tranche-based) approval system? The project (and its political implications) will be much better understood after all the user interviews, business process analysis, and existing-system assessment have been done. It\u2019ll save you money (and reduce the risk of embarrassment) if you spend seriously on discovery, assessments, and architecture before you approve the budget for the whole project.\nThat\u2019s the way it works with building construction: you will spend easily 15% of your budget before you select the general contractor or even think about breaking ground. At any time during that pre-natal stage, you may choose to re-define or entirely abandon the project. And that\u2019s in the highly predictable, repeatable domain of hardware (really big iron). In tricky software projects, be willing to over-invest in discovery.\nThis is not to say you can cut off discovery after the first phase. New things will inevitably crop up during the project, and it\u2019s in your interest to do mid-course corrections. Which brings us to the final heresy\u2026\nHeresy No. 4: Why Are You Focusing on the Bid Price?\nIf your project is basically a commodity, or you\u2019re really just \u201ccontracting out\u201d some tasks, the project bid price is meaningful. But if your software project is intended to give your company a competitive advantage in a core business process, it must be managed as a one-of-a-kind, never-done-it-before project. Because that\u2019s what it will be.\nFor strategic projects, the bid price is just a bunch of negotiated guesses. With manifold unknowns and evolving business realities, \u201cthe project\u201d is just the first phase of a journey. And the total cost of ownership (particularly when your crummy UI wastes user time and irritates users) will dwarf that initial project bid. Lowering TCO is why we push clients toward Agile: lose all the \u201cnice to haves\u201d and do only the highest-priority things with excellence and user responsiveness.\n[Related: How to Use Agile Development to Avoid Project Failures ]\nThe uncertainty of Agile may scare your management, but it\u2019s much preferable to the certainty of bloatware and high TCO produced by traditional procurement and management processes.