Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, IT Project Management
Agile project management with external vendor
Anonymous
When you are managing an agile project with an external vendor and they are frequently not meeting the points planned per sprint how do you hold them accountable to ensure delivery?
The project is fixed in terms of cost and timeline however, the scope is frequently not meet or delivered within a sprint and there are only a couple more sprints to go, what is the best way to achieve more delivery and accountability?
Sort By:
Network:992



Nondelivery has nothing to do with the approach used so in my opinion what you do to resolve it won't differ. I'm not sure how critical the project/deliverables are but usually, you would have some penalty clause/s in the contract for situations like this. The first thing I would do is to escalate it to the board/committee and if you don't have one then to the project sponsor. If you have already done this or got no results I would invoke the penalty clause, few things get people moving like the prospect of losing/making money.

BTW what reasons are given during scrums for the none delivery or delays? And the outcome of retrospectives should also help to give answers about what should change. In Agile this is where issues and concerns are raised so if an Agile process is followed surely this must be on the table?
...
1 reply by anonymous
Feb 28, 2019 6:32 PM
anonymous
...
They are developing on a newer version of the software and there is a learning curve, this has caused the delays of delivery. I'm keen to share this risk with them as we are not getting much achieved each sprint.
Network:582



Why do you think the vendor isn't meeting its agreed upon points? Are its resources new to sprints, and did they overestimate the effort required to perform the work? Are the resources not fully dedicated to the project, and split their time on other projects? Once you have an idea what the root cause of the problem is, you'll have a better idea how to address it.
Network:2149



Based on the question, hard to determine a path forward. What are some challenges being faced or dysfunctions that you believe to be causing the delays?
Some thoughts - What is in the SOW or MSA? Is the vendor in control of the project, or more of a staff aug? Are the identified client-side team members doing their part in the project? It can also be just as viable that the client that is not fulfiling their end of the agreement or providing the support needed by the vendor.
Network:1398



One of the benefits of a sprint or iteration-based approach to delivery is increased transparency into variances. You should be able to forecast when the backlog for the upcoming release will be completed based on what's left and progress to date.

At this point, it sounds like you will be closing the barn door after the horse had left...

Kiron
Anonymous
Feb 25, 2019 11:41 PM
Replying to Anton Oosthuizen
...
Nondelivery has nothing to do with the approach used so in my opinion what you do to resolve it won't differ. I'm not sure how critical the project/deliverables are but usually, you would have some penalty clause/s in the contract for situations like this. The first thing I would do is to escalate it to the board/committee and if you don't have one then to the project sponsor. If you have already done this or got no results I would invoke the penalty clause, few things get people moving like the prospect of losing/making money.

BTW what reasons are given during scrums for the none delivery or delays? And the outcome of retrospectives should also help to give answers about what should change. In Agile this is where issues and concerns are raised so if an Agile process is followed surely this must be on the table?
They are developing on a newer version of the software and there is a learning curve, this has caused the delays of delivery. I'm keen to share this risk with them as we are not getting much achieved each sprint.
Network:54



You mention there is a "learning curve" and "not much achieved each sprint". So you are already facing a recurring issue. Maybe you should have sliced the elephant into even smaller pieces? On the other hand, during selection process did you have a Proof of Concept to see if they can deliver the basic/critical functionalities? Are your requirements correctly understood, translated into IT/programming language? I am just trying to understand where does your issue come from.
On the other hand, you won t be getting anywhere having sprints with non completed scope and delays etc. I would stop everything and make an analysis regarding the causes of the issues and then set an action plan. Then I would think about the project approach.
Network:241



When you say they're not delivering points, are you referring to story points, as in the type used to measure team velocity on an agile team? If you have a fixed schedule, fixed budget, and fixed scope, then you probably shouldn't shouldn't be using sprints or story points; you should be using a gantt chart.

You should not be concerned about a team's points. Like all estimates, points are inaccurate; but if done properly, points are relative and not tied to a fixed measure of time. They are useful for providing a simple form of capacity planning for a development team's sprint, but outside the team they only cause confusion. You cannot directly tie story points to a delivery date, nor can you compare one team's velocity to another.

If you're attending sprint reviews (and as the customer, you should be), don't ask about points or velocity. Don't even let them talk about it- tell them to save that for the retrospective. What you need to know is whether the product increment they produced meets your satisfaction, and whether they'll meet the deadline specified in your contract. The onus is on them to deliver. If they can't, then you need to communicate that to your stakeholders as early as possible.
Network:822



I would wonder if the team actually committed to the sprint backlog. Is the whole team external? Are they located at your premises? Do they provide full transparency during the sprints? I would look first at the basics because if they commit to the backlog and then don’t deliver in the sprint then there should be a root cause. Learning curve is something predictable but then they should be able to commit only to deliverable outcome, right? But besides working with the team and trying to understand how can improvement be reached, I would notify the stakeholders on both sides.
Network:350



It's probably too late to really get on top of this unless the contractor is inclined to be open about their progress.

Something has to be written into the contract to require them give you oversight of progress in such an environment. Without that, the fluid nature of agile development and absence of intermediate milestones, the mechanism that you would use in a more conventional plan driven project, make it impossible to gauge whether they really are closing in on something that will deliver value to you. Agile development is a great smoke screen for a contractor who wants to obscure how well they are getting on.

Please login or join to reply

Content ID:
ADVERTISEMENTS

If man could be crossed with the cat, it would improve man but deteriorate the cat.

- Mark Twain

ADVERTISEMENT

Sponsors