Difference between T&M and TK

A T&M ( Time & Material) project has no definition of done and no pre-establish duration. The customer has no clear requirements, but it is clear what set of skills are useful to drive the project forward. Tipically the customer has the governance of the project and the overall accountability for the execution. On these projects we expose a rate per day for each professional profile is needed for the project.

A TK ( TurnKey) project instead has a clear definition of done, requirements are well defined or anyway is possible to reach that status. The customer want to reach a specific goal within a certain timeframe and it is not interested in the "how" that is not related to the definition of done.In this kind of project we expose the final project cost and an elapsed time for the completion of the project. We also take care of the governance of the project and we become accountable for the overall delivery.

A TK project for us is more risky than a T&M, because we know in software there is always high percentage of uncertainty. All the risks must be evaluated, covered and priced ( risk coverage ). Possible risks are:

• not enough clear requirements and definition of done
• unknown technical challenges that can drain time and effort to be solved
• unavailabily of internal resources of the customer to complete mandatory steps for the project completion ( ex. Business involvement for UAT )
• lack of budget or availability to handle change requests ( no matter if small or bigs )
• environmental challenges that is not possible to know in advance

So, TK projects are tipically more costly for the customer because we need to price governance and risk coverage costs. We love to take risks,be autonoumous and accountable, so we love TK projects.

Our rules for the customer

Pay attention because some customer will try to obtain the guarantees provided by the TK but at the cost of a T&M. Unfortunately there are no free lunchs :-)

Here a list of rules we apply during the pre sales phase:

• We need to define the project type before to start talking about costs and estimates
• Based on the customer briefs and their goals we suggest what is the best project type to achieve them. If customer is asking for a specific project type that is not consistent with goals, we kindly suggest to change it because it can damage the project results and our relationship with the customer.
• When it is a TK we never expose man days estimates neither the number of people we are going to use, we only expose project costs and elapsed timeframe for the completion.
• In order to proceed with a TK project, requirements, deliverables and definition of done must be super clear.

How to recognize the customer is trying to cheat you: Customer: "My procurement is allowing me to do only T&M but I would like to setup TK with you, don't worry about details we will arrange them". In this case the correct answer would be "better to do t&m". Because after you will provide TK economics, you will be forced to expose also estimates and daily rates to satisfy procurement forms. At this stage you will receive challenge on estimates, rates and total project cost. In reality this is just a way to don't let you add the risk coverage quota of the project. In case you will find yourself in this situation, stay calm and explain that governance and risk coverage MUST be paid, you can point them to this page as our internal policy.

If you have a pre-existing T&M agreement with specific daily rates and the customer start to ask you to switch on TK, the implicit expectation will be to have the same daily rate, to understand the team composition and man days estimations. But on TK we are playing a different game so don't follow the customer on this reasoning.

Best project type based on customer goals

T&M is the most suitable one when customer:

• Wants training on the job or team augmentation
• Keeps the governance of the project and prefers to be accountable of the delivery
• Steers the project based on evolving requirements
• Develops a product from scratch( because product management is evolutionary by definition )
• Doesn't recognize that project governance is an activity that must be paid
• Doesn't recognize that a TK needs to consider risks

TK is the most suitable one when customer wants:

• Reach a specific business goal and:
  • not interested in technical stuff
  • don't have capabilities/skills/time to keep the governance of the project
• Develop a specific feature/use case that can be well defined also from a technical standpoint as definition of done.

Step towards the offer

Here a list of steps before to issue an economic quotation and an offer:

1) Technical team involvement: Sales or Account will involve the proper BU Lead, based on the business domain the customer is belonging to. The only exception is for product and services that must be redirected to the proper circle leads. The BU lead will involve his/her people and additionally can ask help from people in community of practices. In this step the Sales or Account should brief the technical team about the overall customer context and specific strategies.

2) High level requirements gathering: The technical team understands what we need to do ( is needed also for the T&M because we need to choose the right people for the right job )

3) T&M vs TK: You need to understand if the customer prefer a T&M or a TK, and we need to assess if the customer is aware of the difference and it is able to stay consistent with this choice.

4) (TK) Deadlines: Try to figure out what is the expecation of the customer in terms of due date, if it is possible to have incremental deliverables and due dates. This could be very useful to define the team composition and scaling.

5) (TK) Evaluation & Feasibility: The technical team estimates the project and assess feasibility. (see next chapter for more details).

6) (TK) Project cost: The account or sales team convert the estimates into the project cost

7) (TK) Project explanation: Don't send costs by email, organize a call, explain the offer, the assumptions and the cost structure. Do not talk of team composition, estimates or daily rates in this phase.

8) (TK) Get informal approval: When you reach this point, inform immediately the BU Lead and COO for proper activities planning

9) (TK) Send the official offer (this time also by email)

The entire process from the initial engament to the offer, shoould not last more than 3-4 weeks. Timing is really important and the technical team must prioritize this activity in the right way.

Evaluation and Feasibility

The technical team must evaluate the request to understand if our company is a good technical fit for that. If the requirement is too high, a deep dive with the customer is needed to understand the request better. In this deep dive, the technical team must be present, don't use the sales team as a bridge. Also, in this phase, it must be clear the definition of done for the customer in terms of expected deliverables.

Then we have to estimate the effort. The technical team will elaborate on the estimate, and the BU Lead or the COO will review it. Pay attention to include all the possible activities in the estimate because there will not be another window to adjust the offer.

Here a list of activities that you should consider:

• Development
• Testing ( unit, integration, performance )
• Documentation
• Project Management/Governance
• Infrastructure setup
• Security
• DevOps
• Requirements analysis
• HLD & LLD

This list could change based on the list of deliverables requested by the customer.

General tips to make a reasonable estimate:

• Look at past similar projects and real delivery speed
• Try to weigh the effort on an average level team ( at this time of the process, the team that will implement the project is still not known ), not on your skills.
• If you are in doubt, add contingency.

Contingency is a very important aspect to cover the uncertainty of the requirements and the speed of the team. It must be added at the end of the process.

Golden rules for this phase in case of TK:

• Never talk about contingency to the customers ( even if you have a strong relationaship with them), they will try to cut it, but it is needed and fair to have it
• Never talk about daily rates
• Never talk about man day estimates

Sometimes the customer will ask for a TK but the requirement is really weak. In this case the technical team needs to spend time with the customer to gather a better requirement and everything must be written down (we will see it in the offer section). In case the customer has no time or skill to provide a full requirement, don't blame it, we need to guide the process, do the right questions and make assumptions. Assumptions are your best friend in these cases, be sure to write them down alongside with the estimates and transfer them in the offer later. They will help to guide the customer in a proactive way and to refine te requirement step by step reaching a good level in the estimate.

The estimate must be done in an Excel file, splitting as much as possible the activities and documenting the numbers' reason. Remember that an estimate could be reviewed several years later when nobody will remember the context, and it should be comprehensible.

The BU Lead or the COO will try to challenge the estimate from different standpoints before to freeze it and to propose it to the Sales team. When an estimate is frozen, please archive it in an accessible place.

Based on the expected deadlines and the estimate, the BU lead will assess the feasibility in term of capacity and will define how much time they need to setup the proper team for this project. In case of missing capacity BU Lead in charge of this process will involve also the COO and other BU Leads to figure out if we can retrieve the missing capacity somewhere else. At the end of this phase, the BU Lead and the Account need to decide if he/she want to proceed with an offer or not, based on the overall fit and feasibility.

Anatomy of an offer

The offer for a project should include the following information:

• Preface about the company
• Project type ( T&M or TK)
• Project resume: Explain the business goal of the project and all the requirements, integrating all those have been inferred along the process
• Project solution: Explain the solution we designed (high level) for this project, to let the customer understand that we understood the problem and we already have a specific solution in mind. In this phase it is important to explain all the assumptions we made to estimate the project (without mentioning the estimate), to clarify what is included and what is not in the solution we are pricing
• Project deliverables: Here we introduce the definition of done, setting the expectation for the quality of the delivery, and defining a list of deliverables that are mandatory to consider the project completed.
• Project timeline: Main milestones and elapsed timeframes
• Constrains (here some example):
  • Availability of the customer to run UAT or be part of specific activities that are crucial for the success of the project
  • Explicit acceptance that in case there will be need to steer from the original requirement (no matter if small or big change) we can ask for a CR (change request).
  • Not solicitation: our employees are not for sale and we want to establish a fair relationship with our customers in bi-lateral way
• Payment terms