AgileOrganizations

Traditional outsourcing is covered by SLA’s to make sure the buyer can control everything the supplier do. The reason is to make sure the supplier delivers what is promised at the cost that is committed. If the SLA’s are very tight and detailed it leaves little room for experimentation/innovation/learning. If the service requested is easy to define and measure it may be a good approach, but as the service gets more and more complex and more and more demanding specialist skills outside the remit of the customer it gets problematic. If only lower cost is important, the service will be optimized for lower cost. If the customer wants learning/advise/innovation there must be trust enough in the vendor providing it and results that proves it.

So, therefore I have defined 4 categories of partnerships
A – Competitors ( no trust, lowest cost, buying a product)
B – Master/Slave Partners ( no trust, lowest cost, buying a service)
C – Master/Servant Partners ( increasing trust, reasonable cost, building a relationship)
D – Equal Partners ( complete trust, value sharing, monetize the relationship both ways)

Depending on what partnership is requested there are different types of contracting approaches.
A – Traditional contract buying a product with negotiations on cost/penalty
B – Traditional contract buying a service with negotiations on cost/penalty
C – Team-as-a-Service / Factory-as-a-Service buying a capacity with negotiations on available skillsets
D – Relational contracts aligning interests with negotiations on successful ways of working together

According to Agile practices and way-of-working there are no projects. Instead Agile is based on the assumption of a regular, steady cadence of work being applied to a product. The work intended is outlined on a backlog and after each Sprint the output is validated and considered while planning the next Sprint. This is very similar to old-school maintenance approaches given that the execution of work is different.
A traditional project sets out what to build in a specification and resources are allocated according to estimations of what is needed. In Agile it is the other way around where the resources are fixed and the specification is ever changing reflect what the team(s) accomplish in each Sprint. Hence the traditional Project concept is not relevant, instead it is more appropriate to talk about an Engagement where available resources are utilized under a set period of time.
Using the same word with multiple meanings are never a good thing!
Therefore, I suggest using the term Project when offering to build a solution with a fixed specification and moving capacity. When you have a situation where you offer a fixed capacity and a moving specification it should be called an Engagement.

To validate the team delivery of working code meets expected standards there are several concepts that can be used.
* Engagement Objective – Defines the EXPECTATIONS on the full delivery after the Engagement is done. These Objectives should be measurable.
* Sprint Objective – Defines the EXPECTATIONS on team delivery at the end of each Sprint/Iteration. These Objectives should be measurable.
* Definition of Done – describes WHAT ACTIONS needs to be done before an Item can be considered done, i.e. ready for evaluation.
* Acceptance Criteria – defines the EXPECTED RESULT for each Item/User Story. This must be measurable through the Definition of Done and clearly stated comparable with criteria set.
* Working code – this term is aimed at what is delivered at the end of a Sprint/Iteration. It does not have to be code, but rather that Quality of output does not conflict with what is already delivery in a working format. So, with that definition a document that meets acceptance criteria and does not contradict previous versions of that document (or what it is aimed for) is within the concept of working code.