Agile Sprints for Better Vendor Management

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.

Originally published on CIO.com

Read More
Prix Fixe Menu

Organizational Culture Eats Agile for Breakfast, Lunch, and Dinner!

“Culture eats strategy for breakfast,” is a famous quotation attributed to the late business management guru Peter Drucker. While a debate continues as to whether Mr. Drucker actually said it, the statement itself merits further exploration.  I believe it means that any great strategy regardless of the depth of research, hard work, number of paid consultants, and even its own brilliance, will not achieve its intended future state if it fails to take an organization’s culture into consideration.

For part three in my Agile journey series, I will examine the importance of addressing cultural elements to achieve a successful Agile transformation. (more…)

Read More

Before Starting Any Agile Journey, Know Your Destination

The promise of Agile is speed to market for delivering incremental value to the customer, but why is the adoption of Agile in organizations so difficult and slow? As addressed in my recent blog post, “Are you Using, Doing, or Being Agile?” Agile adoption takes more than just checking boxes, but rather is a complex, multi-phase journey. And any unfamiliar journey requires the navigator to know the destination. Have you tried using GPS without entering an address? Understanding where you are headed is a key component of any successful endeavor. (more…)

Read More
agile adoption - changing shapes

How Amica Reshaped Its IT Processes: An Agile Adoption Case Study

Rhode Island-based Amica Insurance provides auto, home and life insurance nationwide and employs more than 3,800 people in 44 offices across the U.S.

Amica was looking to upgrade its web and mobile applications. To reach its goal, the IT team established a digital program and decided to pilot an Agile SDLC framework for rapid and iterative delivery of customer value.

The Agile implementation worked for Amica because the organization from top to bottom accepted a bit of discomfort in the short-term to give the change effort a chance. Management agreed to support decisions made on the front line. Product owners, SMEs, and developers were game to try new approaches and grew professionally. In return, they achieved a level of productivity and speed they had not seen before. Here’s how we helped.


Read More

Improving Delivery Through Empowerment: 4 Steps to Empower an Agile Team

Your company is moving to Agile from waterfall, and you want to ensure a smooth transformation that keeps projects healthy. As a scrum master working to transform a traditional waterfall SDLC process into an Agile one, I have learned a few pointers when navigating this transformation. An important concept to keep in mind during this transformation is empowerment.

One of Agile’s core tenets is the value of “individuals and interactions” over “processes and tools”. The idea is to foster a high-velocity decision making process, which hinges on open and honest communication in a co-located environment. However, implementing this change can be very difficult for team members who have previously worked on waterfall projects. You may find employees reluctant to volunteer for work, or hesitant to take on new challenges. Why is this so?


Read More

Change Management: 3 Success Factors for Faster Buy-In

TWEETTweet: How does change happen on an #ITProject? Inspiration, Personal Buy-In & Quality #Abraic https://ctt.ec/VjUfd+

IT organizations generally pride themselves on their ability to embrace change. Their project execution methodologies are built around an assumed ability to rapidly identify, respond, and adapt to change.

PMOs establish standardized development lifecycles and a comprehensive governance process for change management.

The Agile framework along with its variations and flavors acknowledge change as a fact of life. Rather than seeing change as a nuisance or a risk to be avoided, agile PM and SDLC models offer a specific methodology and tools to be successful in a shifting environment.

Even traditional waterfall approaches acknowledge the need for controlled governance related to change management. Standardized practices such as Lessons Learned, Post-Mortems, Issue Management, Continuous Improvement, or a formal Change Control process all revolve around the basic concepts for dealing with change:

  • know your current state or expected scenario
  • identify the deviation
  • evaluate the impact
  • define the future state or new scenario
  • make the change
  • analyze the results
  • repeat as necessary

These methodologies provide valuable, step-by-step instructions to practitioners.

But simply following the steps or implementing specific processes does not ensure buy-in throughout the organization. Beyond the methodology and processes, there are less tangible aspects which need to be addressed to produce the desired results.

Dissent is natural. Universal, undisputed acceptance is unlikely. Therefore, don’t expect everyone to just fall in line and be their usual, enthusiastic, productive selves in this new reality. There will surely be a few who push back on the change and are vocal about it.

But it’s a mistake to equate this resistance to not being “a team player.” Getting naysayers on your side will allow you to harness their outspokenness, channel their energy, and create a collaborative environment which will ultimately benefit the endeavour.

Fast buy-in for any endeavor, but especially for technology projects, depends on winning the hearts and minds of those most impacted by the change.


Read More

Why We Are Afraid of Failing in IT, and How to Get Over It

IT executives, IT managers and other techies: I am coming at you!

It’s time to embrace the concept of failing fast. (If you already have, how is it working for you? Please feel free to comment below and share your lessons learned.)

This doesn’t come naturally to a lot of people. We in the IT industry have baggage. So let’s process that baggage together.


Read More

IT Governance Must Evolve or Die

Bureaucratic, static IT governance models of the past no longer work in organizations where the IT function is to enable business innovation and customer engagement. For IT governance models to be effective in today’s evolving marketplace, they must be more closely linked with business governance.

What concrete benefits and tangible value are you receiving today from your IT governance processes?


Read More
Everyone Is Moving to Agile. Should I

Everyone Is Moving to Agile. Should I?

Ever since the Manifesto for Agile Software Development was introduced back in 2001, organizations have questioned whether the newer alternative methodologies would be a good fit for their business.

Meanwhile, as Agile’s popularity grows, there is increasing pressure on IT departments to adopt the approach.

While the benefits of Agile can be compelling, those benefits are contingent on a specific set of pre-existing organizational characteristics. The presence or absence of those characteristics will determine whether the Agile approach will result in success or failure.


Read More