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.
Come 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’t 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.
Abraic exercises an Agile approach for our internal innovation program. 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.
Another 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 in-house 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’t match our expectations or try to renegotiate – a lengthy and painful endeavor that may involve legal and oftentimes damages relationships.
A better way is to engage a vendor in an iterative Agile-like fashion. As illustrated in this 2-minute video, a vendor is only signed up for one sprint at a time, and each sprint has a clearly outlined set of user stories:
At 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.
Project 1: Implementation Requirements Definition
A Boston-based startup, Streetparkd, has a noble cause: to 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 implementation and change management requirements from their first customer, the city of Boston.
For 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. The 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.
As Shelley Steigerwald, Product Director of Streetparkd, put it, “The 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.”
Project 2: RFP Creation and Vendor Selection
For 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. 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. With many unknowns, Julia decided to bring us in to help define requirements and research options on a limited scope engagement in an Agile fashion.
The 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.
At 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.
“This 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” said Julia Shilevska as she took over the Salesforce implementation.
Project 3: Portfolio Assessment and Roadmap
Crane 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?
A 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.
At 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.
The IT project manager in charge of the project, Bruce LaBrecque, said “The 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.”
Why isn’t everyone engaging vendors in short sprints?
The advantages of an Agile-style vendor engagements are plenty:
- Lower overhead as you don’t need to involve procurement or legal
- Flexibility of scope and timeline
- Control, as all deliverables are finalized at the end of every sprint
- Shifted risk to the vendor –they must iteratively prove their value in every sprint
Given these clear benefits, why aren’t 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’t 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.
The 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.
