I work with an organization that hires professionals with temporary contracts that last for the length of the particular projects they are working on. At the moment, these contracts are usually just a fixed rate per day.

This situation creates an incentive for these contractors to sabotage the schedule of their projects, so that the project takes longer to complete, and thereby lengthen their contracts.

It does appear that this behavior is going on. They are various techniques being used. A common one appears to be raising an "issue" or a "concern" which is actually bogus, or "making a mountain out of a molehill", but which nevertheless causes wasted time as this concern is addressed.

However, it is difficult for managers to know at the outset that an issue raised was not even worth investigation, and it could be the case that someone honestly raised a concern that turned out to not be a problem.

Although it is difficult to know for sure in any single instance that a contractor is sabotaging, it is clear from overall statistics that the practice goes on. (e.g. it happens more when the economy is down and contractors won't find another job).

So the question is this: Are there any internal controls that can be adopted to help deal with this behavior? Is anyone aware of any incentive schemes/contract terms that could replace the fixed rate per day that have worked in dealing with this problem elsewhere?

6 Answers 6


One of the best solutions is to build in incentives and penalties tied to the schedule. You can have a T&M, Cost plus, or fixed price and still have a part of their fee at risk. If they finish early, provide a bonus. If late, some type of penalty. If you are working at a daily fixed rate, you are providing an incentive for the work to continue. Whether they are doing this maliciously or not, you can bet the work will continue. Simply remove the incentive.


This problem will go away if you change your contract from fixed rate per day to fixed bid. Tell them the scope of the project they are supposed to deliver.For example : If its waterfall-After Requirement study - this much amount will be paid to them, after design - this much amount is paid to them. It will in their favor to complete it on time.

If Its Agile(fixed bid not recommended) - But you can say After every release - you can pay money.The money is on hold till things are delivered so its in their interest to complete on time.

Apart from Fixed bid , there are other models also like "outcome based" for example check the count of correct ticket resolution, you will pay this much amount.For each ticket - you have decided an amount.

If you cannot change contract type then you need to understand each and every point which they are raising and understand if its correct or not like mwan is saying.I dont think there is any other way.

  • Thanks for your suggestion. The difficulty in fixed bid here is that some of these project professionals are, for example, subject matter experts, who are needed from the start to help define the requirements in the first place. They are engaged too early in the project life to have the kind of nailed down requirements that fixed bid requires. Some kind of outcome based idea like you suggest may work, but I'm not sure what kind of metrics are needed to avoid "gaming" the system. Oct 30, 2015 at 9:06
  • @Miner_Glitch , if you have to keep fixed rate per day , you can delay payment and add the contract condition like i have said above i.e. if its agile after every release or sprint...in that case , they will also try to complete it on time so that their payment doesnot suffer
    – Roop
    Oct 30, 2015 at 9:11
  • @Miner_Glitch For outcome based : example is like High Priority Ticket as 80 dollars , Medium Priority Ticket has 60 dollars and Low Priority Ticket has 50 dollars...If they are solved and accepted...At the end of month , you check from the tool and see all the tickets and calculate the amount and pay
    – Roop
    Oct 30, 2015 at 9:15
  • Thanks, although it does seem a little geared towards developers, so I'm not sure how to apply it to, say, subject matter experts or test managers. Oct 31, 2015 at 5:16
  • @Miner_Glitch , For Testers - you can check how many tickets they have tested based on the assignment of the tickets and ticket log details and again if that ticket was accepted succefully so tester was also successful in his testing..For Test Manger - if he is doing testing - its same way but if he is just doing management then team's performance is the way to judge his performance ..For Subject Matter Expert : what type of SMEs you have in your team?
    – Roop
    Oct 31, 2015 at 5:59


Are there any internal controls that can be adopted to help deal with this behaviour?

Repeat after me: There is no silver bullet. However, most of the problems you're describing are actually a failure of corporate governance rather than a project management issue. Your senior management must become more involved in assessing and managing project risk, or no amount of self-administered project controls will solve the real underlying problem.

No amount of project controls or arbitrary incentives can solve the problem of a disengaged management team, or the lack of a corporate governance structure. These are issues the company's management team, not the project managers or Project Management Office (PMO), must take on board as part of their executive strategy.

Senior Management Always Owns the Program

The real problem here isn't the incentives or controls. The failure is in the lack of adequate corporate governance for the project. Specifically, you are delegating ownership of the schedule and risk assessment to the project managers, which is incorrect on its face.

Management Owns the Schedule

The role of a project manager is to function as a subject-matter expert in designing a schedule and implementing schedule controls, but it is the responsibility of senior management to approve the schedule, approve the controls, and set management targets for schedule. In other words, while the project manager generally builds the schedule, senior management must vet the plan for suitability for the business.

Management Owns Risk Assessment/Mitigation

Furthermore, when the plan deviates from the schedule, the project manager's job is to raise the visibility of the risks to senior management and to identify any mitigating controls or activities. However, it is once again senior management's responsibility to evaluate the risks to the project and to make strategic decisions about whether to modify the project plan to mitigate the risk, or whether to simply accept the risk and move forward with the existing plan.

In either case, the project manager is doing his or her job simply by logging the issue and communicating about it. Deciding whether or not to control the risk is a management decision, and this requires active participation by the organization's governance process.


There are many governance frameworks. Depending on the nature of your projects and your organization's market segment, you may want to look at some of the following as a starting point:

  1. ITIL
  2. COBIT
  3. BiSL

There are certainly many other governance frameworks. The one you choose is less important than the fact that you have one, as a failure to govern projects or service delivery properly is generally a recipe for disaster.


The question is essentially: "How do I keep my Time & Materials Contractors honest?"

The main point to make is, unless you have a level of expertise in the subject area you're not going to know. It's akin to going to a mechanic when you know nothing about cars - how do you know if they're "pulling the wool over your eyes" or being honest?

Simplest answer: Avoid Time and Materials Contracts as much as possible. They encourage this behaviour.

If you do need to enter into them, you have to ensure there is an incentive for the Contractor to stay honest (eg making sure to flag potential for repeat work if they're efficient, effective and highly visible with you).

Also, make sure that you're not afraid to ask "Why?" when an issue is raised and don't back down until you understand.

Contractor: "This is much harder than I expected. It's going to take a few days longer."

You: "Can you help me understand why?"

Contractor: "Well, I was originally told this was all stored in one table, and now I find it's in 10."

You: "So what are the extra steps you have to take now?"


Keep drilling down until you understand why these tasks are being pushed out. And continue to flag "repeat business" if they are efficient. Also look for some good faith on their part - if they want the repeat business they will usually try not to extend tasks, and if small problems crop up they will tend to stay back a little bit here and there "off the clock".

In short, try to make this a partnership. Make sure you set incentives for honesty and efficiency (the easiest being repeat business) and keep flagging this. To keep this in check always keep asking "Why?" when times are extended until you understand. It may be annoying for them, but it's your responsibility to understand.

  • I acknowledge that it would be good to "Make sure you set incentives for honesty and efficiency", but I was hoping for more specific examples of such incentives. Promising repeat business is practically impossible given the fluid nature of the overall project programme. Oct 30, 2015 at 3:33

Have you looked into agile contracts in general as a model for this? There's a decent amount of info out there, but the basic idea is that an initial test of delivery is done before a full commitment is made (the same way a Scrum Master might gather a few sprints' initial velocity data before trying to chunk out a backlog into more sprints), and once committed to, overages that result in financial risk are shared between parties (reduction in compensation in this case). There are even variants with a sliding scale that shift the risk over time.

Also, one very important thing to note in everyone's advice is that "you get what you measure" - hopefully you are already focusing on quality, compliance, good architecture/TDD etc. and not just time vs. scope. Because once there is direct pressure via time, people are prone to optimize around it at the expense of those other areas. :(


Look into the model of teamed.io, Those are one of the best models I have come across in managing (remote) contractors.

The site gives a lot of materials on their philosophy and methodology, which I think would be a nice recommendation for this scenario.

Disclaimer : This may not be a direct answer, but a way to reach it.

  • Hi Arun, welcome to PMSE! The main purpose of the SE network is to have the knowledge on itself, without relying on external sources. Would you be able to provide a concrete answer to the problem based on the material you found on the link provided? Cheers
    – Tiago Cardoso
    Nov 6, 2015 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.