Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Outsourced Project Procurement Example  Outsourced Project Procurement Example   Outsourced Project Delivery People   Outsourced Project Delivery People

It is important to agree what the project is going to deliver and how much each of the deliverables will cost in order to arrive at a fixed cost. The fixed cost is the budget you will use to fund the project and is the amount of money that your delivery partner will expect either at the end of the project or as the total of periodic financial transactions throughout the life of the project.

Many government organisations and a growing number of other commercial organisations are the subject of financial audits of project costs and benefits following delivery. These are therefore very important financial numbers and you want to get them right. What is more, it is important that you get maximum benefit from your budget or more bang for your buck. The Toolkit covers the area of benefits realisation and will detail it elsewhere in the Toolkit.

In outsourced project delivery, the contract is the most important influencing element in the ultimate success of the delivery. The project will undoubtedly be a success. It will deliver to time, to quality and importantly to budget. The customer and your business partners will be enjoying the promised benefits and the project team will be looking forward to the Project Celebration.

However, the perceived success, as viewed by the organisation, is established by wider, deeper and more intense parameters. The whole delivery including its entire attributable end to end costs and the payback on the investment made is the most important test of success to the organisation. No faltering of this target will be accepted. Satisfied customers are one thing but the organisational financial performance trumps that, always.

The contract and the evidence of this performance is therefore of vital importance. This contract, though it must be remembered, is the verification of performance for both parties. It is the base point to substantiate evidence of the successful execution of responsibility by one party to the other and to trigger the final completion of the venture, often releasing the final eagerly awaited payment of funds.

Therefore, the selection of the type of contract to envelop this type of project delivery approach is very important indeed. The standard contract that covers requirements based delivery is almost certainly unlikely to be appropriate. Some form of localisation or tailoring of this type of contract is certainly anticipated. More appropriate will be a specific contract crafted for an agile delivery relationship.

This relationship can take a number of different stand points. There are partnerships between customer and supplier (and therefore supporting contracts) which support a co-operative and collaborative delivery relationship and there are agile contracts that do not. These latter types of contract will support agile delivery but they will have specific delivery and financial ceilings. These ceilings define where the flexibility of the project stops and are almost universally proposed for the benefit of the supplier organisation. These are a limited throwback to the days of time and materials contracts where the supplier is guaranteed payment for all days worked but the customer is left still seeking an element of precision over the quality and relevance of the final delivery.

As you know, this precision is defined within the Toolkit and enshrined in the business relationship that defines quality and fit for purpose deliverables. Therefore, using the Toolkit to govern your projects, you will not experience this lack of precision. The precision is achieved by regular assessments of all output created by the project and instantly gauged for release by the business team members themselves. This peculiar mechanism to achieve quality outcomes is not performed within your traditional projects and so your traditional contract is most likely unsuitable.

So, let us look at a more suitable contractual arrangement. Regardless of the type of project, customers tend to prefer fixed price contracts. They are simpler to understand, simpler to sell to their own management and to their own business partners, provide a level of financial security and make the whole process of project budgeting a lot easier. Using the Toolkit, you know that you can deliver your project to an agreed cost. Therefore, this makes the selection of the type of contract a simpler process.

On your project, you will have fixed costs and you will have fixed time. Therefore, there is no point in selecting a time and materials contract. You have no intention of the project going beyond its end date. You have no intention of the project going beyond its budget. Using the Toolkit, you know that both these elements are fixed and you will not be using valuable time after the end date and you will not be burning valuable money beyond the budget. So, it is agreed then, we need some form of fixed price contract.

so, let us look at the various types of fixing that we can perform on our contract. We can fix the price, of course. We can also fix the scope. We can fix the requirements. We can fix the environments. We can fix the time. We can fix the number of people. We can fix the number of releases. We could even fix the number of assessments and the number of lines of code. Patently, some of these things will be good to fix and others will not.

We look at the various types of contracts elsewhere in the Toolkit, so we will not go into detail here. Of course, we have to state for legal reasons that you are advised to take proper legal advice before embarking upon a contract. However, using the Toolkit, there are certain contractual suggestions we would make regarding the optimum contract for this type of project. We would opt for a contract that assumes and guarantees delivery on a specific date and time. We would also opt for a contract that assumes and guarantees a fixed price for the whole delivery. Beyond that, we would not fix anything else.

It is not wise to fix the requirements. You want your embedded business team within the project to do that. It is not wise to fix the number of assessments. Again, your business team in concert with your project will determine the optimum number of assessments to perform.

We discussed scope and the complex subject of scope management elsewhere in the Toolkit. Once you have understood this topic, you will understand that it is also not wise to contractually fix scope from the outset of a project. Certainly specify what scope you intended from the outset. However, you must allow the team to define its own path. If it determines that the original scope was incorrect, it needs to change. It needs to change without the need to change contract, too. This is why we would simply not mention scope inside the contract.

Some consideration of the macro scope for the proposed project should be made, however. If the macro scope of a project goes wildly expanding, there must be a mechanism within the project and within the contract to establish whether the original venture has gone beyond its original intentions. In the instance where a customer is an international corporation with many locations across the world, conceivably a project may begin to include parts of the organisation which were not established at the outset.

This is not necessarily a scope management problem. It becomes a cost management problem, when your project team has to fly to the other end of the world and stay in hotels for weeks on end and run remote video conferencing and fly back to update the team and so on and so on. Therefore it is wise, as a safeguard, to specify the business teams and locations that are anticipated on the project. This allows you the opportunity, when the macro scope expands, to define where the expansion influences your costs.

Your project, of course, has two options. You can determine that this expansion has gone beyond the original venture and stop the project. Alternatively, you can determine that this expansion can be accommodated and you will agree inside the project which other elements of the project are going to be ditched in favour of this new scope expansion. The objective, as always, is to allow flexibility for the project team and not to introduce contractual strangleholds that limit its flexibility.

You will therefore establish two important elements in your contract. You will have a fixed time and you will have a fixed cost. Therefore, you know that the venture your organisation has planned and estimated will be delivered for a guaranteed budget on a guaranteed time. Furthermore, you and your supplier have the legal framework to ensure that happens. But remember, the contract must offer a commercial and a financial reward to the supplier. The supplier is almost certainly a commercial organisation that performs commercial operations for commercial purposes. If they do not make money out of your contract, they will take their valuable resources somewhere else.

So now we have a contract type that we can use for agile projects, we need to select a supplier to deliver on that contract. During the outsourcing selection stage, there are two areas for which specific attention needs to be made: People and Quality.


 Outsourced Project Procurement Example     Outsourced Project Procurement Example   Outsourced Project Delivery People    Outsourced Project Delivery People

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Outsourced Project Delivery Contracts


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 163  Page: 180/444  Progress: 40.5%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.