Planning for Agile Project Success–a Vendor Perspective

with contributions from Zin Kortebi

Much of the current rhetoric around agile best practices–and there is a lot–focuses on how organizational teams that are accountable for successful project delivery must adapt their processes to be agile. But, what about the vendor–the professional services providers that need to align to customers’ preferred method of running its projects–whether waterfall or agile (or watergile)? In cases where clients that have adopted an agile / iterative/incremental approach, what are some of the things vendors must consider to ensure fair, mutual success?

We posed this question to Zin Kortebi who currently leads a professional services consulting group, having spent most of his career managing professional services teams for Tier 1 organizations. In response, Zin provided this Top 5 List of vendor considerations when working with clients using an agile approach:

1. The solution scope, including all functionality to be configured / implemented must be clearly defined from the beginning.

This is required for any project regardless of the approach ; but, in some cases I have seen, because the client was using an agile approach, they thought defining the scope at the beginning of the engagement was not required–that the scope would be defined as the project evolves. Obviously, this creates a big gap between what can be delivered within schedule/cost constraints and end users’ expectations; and often results in client frustration, if these constraints don’t budge; or increased cost and delays as the project spins out of control when they do.

2. Limit the duration of the project.

Large projects should be divided into phases with each phase not exceeding 6 months to implement, starting with core design/build iterations that validate requirements and demonstrate value. The challenges we faced with a waterfall approach are mostly due to gaps between what we, as the vendor, delivered and the expectations of the end users. Most of the time, they told us “This is not what I wanted.” You refer them to the signed BFRD, but they would say yes but the intent of the wording has changed since we started. So an incremental/iterative approach is important to getting agreement on what’s required to be useful, and the look-and-feel (through demonstrations at the end of each iteration) with users before you start working on the underlying components (infrastructure, integrations, customizations, etc.).

3. Limit the number (and duration) of iterations.

Whether waterfall or agile, all projects typically include the same, core stages of Requirement Definition, Design, Configuration / Build, Test, Training and Deployment. The difference with many agile projects is, the Requirement Definition, Design, Configuration / Build stages repeat over multiple iterations. Unless the number of iterations is agreed upon in the Statement Of Work (SOW), controlling the project becomes a high risk –not a good situation for the vendor in a fixed-price SOW. On the other hand, if the SOW is Time & Materials, the schedule and budget extensions are often a concern to the clients. Based on my experience, for each six-month project phase, I recommend working with clients to limit the number of iterations to three prior to one-time activities such as training, production deployment, integration, etc. Additionally, it’s important to have a common understanding of the “Acceptance Criteria” for the deliverables.

4. Define the business areas and profile of the key users to be involved during the iterations.

This will help to better scope the project as well as the iterations. Ensure this group gets involved in testing as well as the change management activities.

5. The environment/tools being used to build the solution must enable rapid configuration.

The development team must be able to, in a very short period of time, turn requirements gathered during the workshops of an iteration into a demonstrable component of the solution for presentation / review with business users prior to start the next iteration. We should always check if the selected product / tools to build the solution “fits” with an agile methodology to deliver the project.

Leave a Reply

Close Menu