Most companies have long-standing traditions in the way they buy consulting services for software projects. Even though nearly all the best practices of software development have changed over the last decade, too many companies are trying to buy agile projects using \u201crules of the road\u201d that feel like 1990 or even earlier.\n[Related: Agile Project Management Lessons Learned From Texas Hold'em ]\nI\u2019m a consultant and I fully admit my bias. But the point of this article isn\u2019t my self-interest: It\u2019s yours. So let\u2019s look at what you want at the end of the project, and optimize that from the outset. It\u2019s easy to say \u201cI just want the project done as cheaply as possible and as early as possible.\u201d Yeah, right. And the problem?\n\nThe word \u201cproject\u201d is ill-defined, even if you think you\u2019ve got solid project requirement documents (PRD) and RFP documents. Actually nailing down exactly what you want the project to be\u2014and exactly what you don\u2019t want it to be\u2014before the project has begun? It\u2019s an amazingly time-consuming and painful experience. And the decades-long track record of clairvoyance in software projects is pretty poor, because too many business realities change over the life of the project, and too many things you thought you needed at the beginning turn out to be wild-goose chases.\nNot only is your rock-solid project definition going to cause building some stuff that\u2019s a waste, it\u2019s going to miss doing some things that are important. Projects involve discovery of process issues, business rules, and tradeoffs that were hidden when you were writing all those specs before it began. Any interesting project is going to involve exploratory surgery, and perhaps some soul=searching.\nOver the life of the software you\u2019re creating\u2014in the years after the project is over\u2014you may well spend more modifying and maintaining that code than you did building it. So creating internal capabilities to support and evolve the \u201cproject\u201d are a key factor in responsiveness and TCO. But most \u201cproject\u201d definitions do not include this. Same thing with internationalization, architectural future-proofing, and other oft-neglected areas of infrastructure.\n\nThe bottom line is that the project outcome you actually want is not what you can specify in advance. But most procurement processes still focus on fixed-price, fixed-deliverable, fixed-schedule projects. Works for commodities, works for hardware. But for custom software projects, it\u2019s a classic case of magical thinking, the kind endlessly documented in Dilbert.\n[Related: How to Use Agile Development to Avoid Project Failures ]\nSo let\u2019s dig into the effects of the PRD\/RFP\/fixed-price process on your project outcomes. The intelligent consulting firm knows that they don\u2019t know what the requirements really are any better than you do, but they have to pretend that (1) they do, and (2) that they can deliver with predictability. So they must pad their bids to deal with that uncertainty.\nThe intelligent client collects several bids and has to trade off price for quality and delivery risk, but unintelligently wastes time speculating in an effort to answer the wrong question. And that question is, \u201cwhat\u2019s going to be cheapest and make me look good at the time we sign the contract?\u201d\nBut the right question is, \u201cwhat\u2019s going to produce the best long-term outcome for my company?\u201d\n[Related: How to Make Your Enterprise as Agile as a Startup ]\nWell then, the contract gets signed and about 34 milliseconds later (the time it takes for the synapses to process \u201cit\u2019s signed\u201d) a contractuallyenforced adversarial relationship begins. Sure, you both want to finish the project and avoid unpleasantness \u2026 but the consultant needs to minimize costs and you need to maximize output. So for the life of the project, your incentives are diametrically opposed to the consultant\u2019s. And trust? Well, the only thing you can really trust is that the other side is incented to behave like the other side.\n\n\t\n\nLet\u2019s freeze the frame to see what\u2019s going on. You bought a consulting project because you didn\u2019t want to buy more employees. Fine. You\u2019re willing to pay more because you get expertise and schedule advantages. Cool. But with an employee, the team\u2019s incentives are almost completely aligned (absent the effect of political squabbling). Plus, with an employee there\u2019s little issue of technology transfer: the builders are the maintainers.\nThe result of the adversarial relationship? Consultants deliver software that isn\u2019t well fit for purpose, is typically formulaic (which means you don\u2019t get any competitive advantage from it), and isn\u2019t flexible over time. This goes double for \u201cquick start\u201d projects that your users will hate from the day they are deployed.\nSo how do we get a project that is optimized for what your business really needs? How do we get the incentives of consultants aligned as well as they would be with employees? This is the hidden strength of agile, when done in a meaningful way.\nWe all know that the mechanics of agile involve incremental delivery of features, sprints, continuous integration, scrum teams, and high user involvement.\u00a0\u00a0 Those mechanics are easy to teach, but they do little to align incentives.\nGetting All Left-Coast on You\nI admit it, I\u2019m a child of the \u201860s. I lived in San Francisco in the Summer of Love and my dad hung out in a Marin County commune for a while. But I\u2019m no more an advocate of Flower Power than Pyramid Power or even Wind Power. And I\u2019m here to tell you that nearly all the \u201860s music was trash: still is. And don\u2019t get me started on tie-dye.\nThe true magic of agile comes not from its mechanics, but from its foundation: The only way to get requirements right is to get them directly from the users during the course of the project. That means there are no specs, only stories which may expand, divide, merge, contract or even be abandoned as useless at any time during the project. The magical incantation of Agile: \u201cstop pretending you know.\u201d\nAnd that means, you have to depend on trust. Every management discussion and action has to build trust across the team, so that users believe IT is on their side and everyone thinks the consultants are doing what\u2019s best for your company. Yeah, trust.\nYou can still have fixed price and fixed schedule, but what Agile says is you can\u2019t have that at the same time as fixed-deliverable. Because if you live that assumption \u2013 you don\u2019t know what you need until the project is in process \u2013 the project team needs to focus on \u201cwhat\u2019s most important for the business now\u201d instead of \u201cwhat\u2019s on the checklist.\u201d\nFor agile to do its magic, you have to trust the team to do the right thing. Which means you need to put your very best people\u2014users and IT\u2014on the team for real. And your CFO needs to be briefed about why this is the best way, and how it will reduce waste. Any command-and-control management needs to release the team to do what\u2019s best, rather than focusing on spreadsheets and what\u2019s easily (and falsely) measured.\nCan\u2019t get past this? Maybe you\u2019re not really ready for agile.