Agile is now being used far beyond its original purpose, which was software development. We see organizations apply Agile methodology to any project or program where the end result is a continual work in progress.\nCome to think of it, my son and I use an Agile approach when we go fishing. We know we want to catch a bunch of fish, but we don\u2019t know what kind or where, so we move our canoe around the lake all day based on our success in each spot, wind direction, time of day, and other factors.\nWithin my business, we are exercising an Agile approach for our internal innovation. Our R&D group is working strictly on a high-frequency trial-and-error basis in one-week sprints. This minimizes cost exposure and allows us to make adjustments based on the latest findings.\nAnother area where an Agile approach is very effective is vendor engagement. The predominant practice to date has been to take an ambitious high-level scope and hand it off to a chosen vendor by means of a complex, long, and expensive contract. Yet, there are many cases when the project requires a significant redirection, including changing the vendor, utilizing inhouse resources, re-scoping the project, putting the effort on hold, and so on. We end up having a to make a tough choice: make minor tweaks and complete as planned even if it doesn\u2019t match our expectations or try to renegotiate \u2013 a lengthy and painful endeavor that may involve legal and oftentimes damages relationships.\nA better way is to engage a vendor in an iterative Agile-like fashion. As illustrated in the short 2-minute video below, a vendor is only signed up for one sprint at a time and each sprint has a clearly outlined set of user stories.\n\n\n \n\n\nAt the end of each sprint, the next steps in the process are determined. This may include deciding what the next sprint will look like or if a sprint is needed at all. This is a highly effective concept. As a vendor, we have been privileged to practice it on a number of our client engagements. We have selected three different examples to demonstrate the approach.\nStreetparkd \u2013 defining requirements for a unique software application\nStreetparkd is a Boston-based startup with a noble cause \u2013 help local governments and institutions keep track of parking space inventory using a state-of-the-art database and visual representation of the regulations. Since this software and database are the first of its kind, Streetparkd turned to Abraic for help in defining requirements from their first customer, the city of Boston.\nFor this project, there was low visibility into the volume or the complexity of the scope and requirements. The first sprint included building a plan of attack from a set of interviews and workshops. The next few sprints developed a long list of software requirements based on interaction with Boston city officials. Since everyone seemed to have opinions and input into the project, we ended up speaking with double the number of city officials than originally estimated. \u00a0The agile process allowed us to easily adapt and deploy additional sprints to efficiently complete the requirements gathering phase. Once the requirements were set, we could seamlessly move on to the next set of sprints that focused on development cycles for the software.\nAs Shelley Steigerwald, COO of Streetparkd put it, \u201cThe iterative engagement model was a key for us to align expectations with the city of Boston and ultimately succeed with our first ever client engagement.\u201d\nP\/Kaufmann \u2013 RFP creation and vendor selection\nFor years P\/Kaufmann ran a homegrown solution to keep track of the sales process. The solution has outlived its usefulness and Julia Shilevska, their IT director, decided to explore options for a replacement.\u00a0 With all the new sales management systems now available, she was unclear whether another custom system would be required or if an off-the-shelf option could work instead. \u00a0With many unknowns, Julia decided to bring us in to help define requirements and research options on a limited scope engagement in an Agile fashion.\nThe first sprint focused on requirements. As key requirements were identified and analyzed, it became clear that a pre-packaged solution would be the best option. Once this was agreed upon, we could quickly move to the next sprint that involved generating an RFP and vendor analysis.\nAt the end of the third sprint, the data gathered revealed to P\/Kaufmann that Salesforce was clearly the best solution for their needs. Upon a successful project conclusion, they could immediately begin negotiations with Salesforce.\n\u00a0\u201cThis iterative engagement model helped us get the most out of the management consulting service and quickly obtain the data needed to make smart decisions without spending a fortune\u201d said Julia Shilevska as she took over the Salesforce implementation.\nCrane currency \u2013 portfolio assessment and roadmap\nCrane is a specialty paper manufacturer with a complex manufacturing process auditable by the US Government. Based on multiple complaints from those who support production, IT recognized an opportunity to improve the way ERP and MES systems worked together. We were called in to make an assessment. Because the depth of issues was unknown, it was difficult to predict the extent of the assessment. How do you define a scope of such an assessment engagement?\nA sprint-based engagement model was employed to address this. The first two sprints were focused on the current state of the business to verify the reported issues. If problems could not be validated, then it would make little sense to proceed with the rest of the assessment. The next sprint envisioned the future state with the final sprint centered on developing a roadmap and associated business case to achieve their objectives.\nAt the end of the assessment, Crane proceeded to evaluate its options. Once they processed all the outputs from the assessment, they moved forward with the roadmap and hired a specialist with the specific ERP and MES solutions to proceed with the improvement project.\nThe IT project manager in charge of the project, Bruce LaBrecque, said \u201cThe iterative engagement model put me in full control. After only 4 sprints, we were in a position to halt the efforts, re-assess our choices, and eventually resume the project with help of another vendor.\u201d\nWhy isn\u2019t everyone engaging vendors in short sprints?\nThe advantages of an Agile-style vendor engagements are plenty:\n\nLower overhead as you don\u2019t need to involve procurement or legal\nFlexibility of scope and timeline\nControl, as all deliverables are finalized at the end of every sprint\nShifted risk to the vendor \u2013they must iteratively prove their value in every sprint\n\nGiven these clear benefits, why aren\u2019t more businesses using this approach? To draw a parallel, the best way to ensure a contractor builds you a great house is to visit the construction site every day, ask questions and make adjustments as the project progresses. You can\u2019t just hire a contractor, put down a deposit then sit back and wait to move in. But visiting the site every day takes effort, concentration, and reprioritization of other responsibilities. The same goes for an Agile style of vendor engagement. While it makes sense to most, actually doing it requires a cultural shift that is overwhelmingly hard for many organizations.\nThe potential gains, however, are well worth the endeavor and I hope these above examples will inspire you to try this approach next time you bring in a vendor.