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
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
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.