How to manage projects the right way based on contract types

If you work in the IT industry, or similar industries, you probably have struggled with project management. Not only to execute them, but also how to define them to the customers when drafting contracts and work breakdown structures (wbs). I see this all the time, and the core reason is a misunderstanding on what a project is and when something is NOT a project. The second problem I see is that people treat everything the same in terms of responsibilities and execution, which causes a lot of problems on both sides.

3 different types of contracts

In general, we can define contract types in three categories: Fixed Price, Time and material and timeboxed. You might have different names for these, but these are the three common types of contracts and collaboration forms for projects. Let us break these down and see how they differ and then how you work with them.

Fixed Price Contract

Risk: Supplier
Success Rate: Abyssmal
Cost: Very high

A fixed priced project is a classic contract type where you define the work to be done, the time it should take and how much it should cost. This is where you get that typical Iron Triangle that all projects have. This is a difficult project form for both parties, as it demands that the scope is defined so accurate estimations can be made. As we all know, this is very rarely done, and instead people slap the Agile label on it to avoid doing the work that must be done for a fixed price project to work. Fixed price projects with an Agile label are MOD (March of death) projects, and they are pretty much guaranteed to fail.

The only way a fixed price project can work is if the three points of the triangle are well-defined. This means that for most fixed price project you should have a discovery project first to define the requirements. The more time spent on defining the scope, the more likely you are to succeed with the project. That is, assuming that the estimations are done by someone who understand how to estimate. Estimation is a dying art, and most teams don't know how to make actual estimations after decades of dysfunctional estimations using story points or just making numbers up with no learning as part of their way of working.

A fixed price project has to be limited in scope and the larger the project, the lower the chances of success become. I have successfully delivered projects between 9 months and a year in scope, but that is a lot of work as when you have projects of that length and scope, then there will be a lot of changes to handle. Anything above a year you will need to add extra time for as the amount of changes will most likely affect the project.

This brings me to the crucial part for fixed price projects, and that is that you MUST have a well-defined change process that you follow. Your team must also understand the business aspect of the project, and that is something not a lot of teams that know how to do. Every single change to the defined scope have to be carefully measured and documented. Any change resulting in an extension of time, scope or cost must go through a change board and the new impact must be accepted by both parties.

This is a very documentation heavy process, and it is frustrating for everyone involved as this slow things down significantly due to the change management process that must be dealt with.

The fixed price contract put the responsibility and the risk of the delivery on the supplier. It is their responsibility to define the contract so they do not get into trouble financially, and that is always very difficult to do. Most customers are also very bad at defining the scope and risk, so many customers lose money over a fixed price project, or end up in a long and tiresome legal dispute over contracts.

Because of the high risk and change heavy process, most customers will have a significantly higher price for a fixed price project. While it may look good on paper for the customer, then result is usually a much higher price tag and broken deadlines that can be many times longer than first expected.

I do not recommend fixed price projects unless you do the discovery and both the customer and supplier are well experienced in estimations and risk management, with 80-90% success rate over dozens of fixed price projects. You can never have a fixed price project using Agile processes, as these require project management using ways of working like Prince2.

Fixed price projects should ALWAYS have a project manager full-time on the suppliers side and a steering group connected to the project on the customers side.

Time and Material

Risk: Customer
Success Rate: High
Cost: Normal

Time and material is the opposite of a fixed price project. In a time and material project, you will not define the scope, but the cost and length of engagement. This put a lot of responsibility on the customer as they have to know what they need so they can direct the supplier to whatever value they need. Sadly, many organizations do not have the competence or experience to do this and while all deliveries are made, the customer doesn't feel that they get the full value for their money.

What is usually a good idea if this is the case is to do a discovery before the project and define the business needs, and star to define requirements before the delivery project. It is also often a good idea to have an external part helping with this, or even the supplier. The reason for this is that internally there are often implicit requirements because people know how things work. If you bring in external help for this, then they will not have this implicit knowledge, and they will ask the questions needed to deliver later on.

Unlike fixed price projects that should never use Agile processes, they are a great choice for a Time and Material project. Using an Agile process for Time and Material will allow for quick changes when new or better value is discovered. As Time and Material require less formal change management and instead rely on communication as changes occur, this will speed up value creation and make things easier and less frustrated in times of formality (red tape).

As will all things related to Agile, it requires structure though, so the benefits of agility are not countered with a chaotic ad-hoc approach.

From a supplier's perspective, this is almost always the preferred contract type, as no responsibility or risk fall on them. From the customers side this is not so well liked and if they agree to it or not will depend heavily on their trust in their own capabilities to lead a project to create the value they wish to have. It also requires trust in the supplier, and this can sometimes be hard to achieve, especially if you are just starting out.

Because the risk is all on the customers side, prices are generally lower for time and material projects. While it can look terrifying from the customer side, this is by far the most beneficial type of contract for them, assuming they can manage the project from their side.

For most cases this is my recommended contract form as it provides the greatest value to the customer and with proper preparations and in some cases external help, it has the lowest risk of failure.

Timeboxed

Risk: Customer
Success Rate: Unknown
Cost: Low

Timeboxed is similar to Time and Material, but rather than having defined deliveries, a timeboxed contract just defined the time and cost and not the outcome. This is common for design projects, for example, or for R&D and exploration project where the value is not known, but best effort is made within an allocated time. This is also the type of contract you would use for staffing, where you hire a person to help with certain tasks like support or configurations as part of the customer's team.

This kind of project do not execute based on a defined value, but from a hypothesis. This means that value can actually sometimes not be generated, and the entire time can result in nothing more than a learning experience. This is a common contract type when you work with conversion rate optimization (CRO) or when you prototype new services or products in a Research and development (R&D) setting. Sometimes you strike gold, sometimes you strike coal.

From a customer's perspective, this type of contract depends entirely on the customer's ability to direct and provide feedback to the customer. From a supplier's perspective, there is no risk involved here, beyond perhaps disputes of competence and experience.

For staffing and creative work with unknown value, this is the only contract type I would recommend.

Most Common mistake - Fixed Price handled as Time & Material

The absolute most common mistake I see is to use a Fixed Price project and trying to work as it is a Time and Material project. I would say 80% of all failed projects are because of this mistake. Often I see that customers slap that Agile stamp on the project as a way to avoid defining the scope and many suppliers go along with it as they know that means that the project will never be done in time. While that will cause conflict, the suppliers will make a lot more money from the customer's inability to define requirements. I don't say that all suppliers think this way, but many do. Sadly many customers have a similar agenda and they will purposely fail projects to get better pricing long term.

Make sure that if you have a Fixed Price contract that you have:

• A Project Manager on Suppliers side

• A Project Management process like Prince2 (NEVER Agile!!!)

• A Defined Change process

• A Steering Committee on the Customers side

• A well-defined Scope with realistic estimates based on actual risks.

If you don't have this, then you are just marching towards failure...

Choose the correct contract type for the correct project type

The main goal when starting to collaborate with a new customer, or with a new supplier is to be open with what type of need there is to be delivered. As a customer be open if you are aware then your organization are not strong in project management or requiremement management so the supplier can take that into accout. If you as a customer need help with these two critical disciplines, then ask the supplier for help, or hire someone external to help out with this.

Trying to hide competence or experience on either side is just going to errode trust and make collaboration more difficult. This leads to loss of value on both sides, regardless how smart you think you are playing the other part.

Work smart and long term to build relations is always the better deal than trying to F people over for short term financial gain...

So when you decide on a contract form here is a short check list for you.

Customer Questions:

1. Do you know what you want and have you defined those in requirements?

2. Do you know how to work with a change process for scope changes?

3. Do you have a group of stakeholders that can guide and hold the supplier accountable?

4. Do you have someone that can lead the project and work with the changes that may come up?

5. Do you work according to a project management process or Agile processes?

If the answer is Yes to 1-4 and you work according to a project management process, then you can go for a Fixed Price contract. Otherwise you should go for Time and Material. Anytime the value created is unknown in a R&D, design or discovery setting then you always go for Timboxed contracts. Timeboxed is also the only choice for staffing.