As per my understanding - In waterfall, a detailed requirements is required to start a project but, in Agile there is always a flexibility in completing each goal and keep on building the project requirement parallelly in each sprint towards Project completion.
In Simple, the Client and Vendor team will work together at each level to achieve good results, implementing changes when needed instead of fixed to specific requirements. This approach influences the procurement changes in each level.
It really depends on the nature of the product or services being procured, the organization's procurement policies, and multiple other factors.
If the third party is doing something which is deeply integrated with the internal team's work, then ideally, the contract will enable both parties to collaborate together daily and share a common set of tooling to reduce waste.
As far as the type of contract goes, firm fixed price is usually not advisable for a long term engagement, but once both parties are comfortable with the scope of work and delivery approach, a release-based fixed price approach could be used.
It is advisable to pick a vendor who has experience working with a similar delivery approach to the internal team and not just go with the cheapest provider.
You can check the agile & tailoring considerations sections of the Procurement Management knowledge area in the Sixth Edition of the PMBOK Guide for more info...
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Is not a matter of agile or not agile. Is a matter of the life cycle and/or the method you will use to create the solution. There is a lot of missunderstanding outside there mainly when people use "agile vs waterfall" where they are mixing two things which are not matter of comparison: an approach (agile) with a life cycle (waterfall). So, to be successful with this matter, my recomendation is to concentrate on "the way" the solution will be deliver. You can call it "project" and it will have a life cycle associate with it that could be waterfall, sequential, iterative, incremental, iterative-incremental, etc, etc
One more resource I can point you to is the work done by Mirko Kleiner on Lean-Agile Procurement. If you Google his name, you will likely come up with a lot of good stuff...
One more resource I can point you to is the work done by Mirko Kleiner on Lean-Agile Procurement. If you Google his name, you will likely come up with a lot of good stuff...
Is not a matter of agile or not agile. Is a matter of the life cycle and/or the method you will use to create the solution. There is a lot of missunderstanding outside there mainly when people use "agile vs waterfall" where they are mixing two things which are not matter of comparison: an approach (agile) with a life cycle (waterfall). So, to be successful with this matter, my recomendation is to concentrate on "the way" the solution will be deliver. You can call it "project" and it will have a life cycle associate with it that could be waterfall, sequential, iterative, incremental, iterative-incremental, etc, etc
As per my understanding - In waterfall, a detailed requirements is required to start a project but, in Agile there is always a flexibility in completing each goal and keep on building the project requirement parallelly in each sprint towards Project completion.
In Simple, the Client and Vendor team will work together at each level to achieve good results, implementing changes when needed instead of fixed to specific requirements. This approach influences the procurement changes in each level.
Thank you Mr @SreeRamaMurthy Saving Changes...
Latha Thamma reddiSr Product and Portfolio Management (Automation Innovation)| DXC TechnologyMckinney, Tx, United States
