Project Manager that wants to lock in time estimate with a signed contract

Question

At a previous employment, a project manager (PM) wasn't satisfied with the delivery time of the code on a project I was on. I was told by my project lead that that the PM was considering having me sign a contract to lock-in my time estimates I gave for tasks and delivery dates.

The situation on the project was that we were working with new technologies, codebase, coding standards, and very prone-to-change requirements. I was learning new things and applying them the best I could on requirements that kept on changing. The requirements throughout the iterations grew by 2-3 times, with my estimate-to-complete growing by roughly 5-8 times. The only things that didn't change were the estimates and delivery dates.

Yes, I did end up missing most deadlines. And I was working on some very new technologies that no one else on the entire development team could really help out on because they wouldn't be familiar with it. At least not easily.

It seemed to me then, that the PM wanted his numbers to add up-- and thus wanted me to sign a contract to "ensure" that I would always deliver working code on time. I suppose with a signed contract the PM could use it against me if I couldn't deliver on time.

I believe what happened next was that other project managers and/or project leads defended me, and didn't let this happen.

My question is, should this raise a red flag about the manager? Is it common practice for a manager to lock-in time estimates of a software developer with a signed contract? Or in this case, try to.

Please note, I was a full time employee, not an independent consultant.

Update: I want to add that I did give new estimates weekly, but it seems the original estimates and delivery dates were what the PM was fixated on.

Answer 1

My question is, should this raise a red flag about the manager?

Yes. It means it is time for you to get your resume/CV up to date and start looking for a new job. Or it means that your manager is about to start playing some very nasty games with you.

Is it common practice for a manager to lock-in time estimates of a software developer with a signed contract?

I've never heard of this being applied to an employee.

Time and effort estimation is always difficult. Especially since our profession is full of excessive optimism. There are some estimation systems that could help with estimates in the future, but they need collecting historical stats from yourself. One is PSP. Another is Function Points. Many developers like neither, and you'll find very strong opinions against both of them.

The key difficulty in estimating time and effort is the lack of feedback in our estimation heuristics. One of the keys is to write down what you think the estimate is, and what parameters you used to estimate it. Then, based on what you actually get done, compare that with what you thought you'd do. And use that to modify your estimation parameters. In engineering, we call this "feedback."

Answer 2

Yes, that should absolutely sound alarm bells.

Had I been in the position, for my personal entertainment, I would have asked the manager to sign a contract freezing all requirements. I imagine the manager would likely bail. Then I would leave.

Answer 3

Well that's simple. Just tell your manager that you'll sign to lock-in your time estimate when he will sign to lock-in the specification. Because you can't, for sure provide any estimates for something that is unknown. Full project spec before you start, no changes - and you can finish it in time :)

One change to spec => contract is void. Probably the thing will be void just after 10 minutes on your first day :)

Answer 4

Yes, this is a red flag. What it tells you is that the manager does not understand how to manage risk in software projects. What he should be doing is figuring out what exactly caused the delay in first place and then start to instrument a process to effectively manage schedule risks that will inevitable happen during a software project.

NEVER in any circumstance would I sign a contract with my manager guaranteeing a schedule. Others have mentioned having him sign a lock-in on specifications. This in my opinion is not sufficient. This does not account for unforeseen difficulties with the tools or technology, incomplete or poor designs, the performance of other team members, etc.

Answer 5

This is not a red flag, this is weapons-grade stupidity.

If estimates and deadlines are consistently blown, the rational thing to do is identify causes and improve processes.

If you blame and kick the horse because you don't know where you're going, don't be surprised if the horse bites you and runs away!

Answer 6

While the manager was out of line with his demand. He's not fully to blame. If you were working in fully unfamiliar territory, there is nothing wrong with saying "I don't know." It took me a while to realize that "I don't know" is a perfectly acceptable answer, so I know how much it stings to utter those words. But if you truly don't know then that's the answer. And if they balk at that ask them to give you an estimate of how many pennies it will take to make a stack as tall as the Sears (make it Willis) Tower. And would they be willing to sign a contract paying you every penny they were off?

Any Project Manager worth his salary should know that some things don't fit nice and pretty in a spreadsheet. Sometimes things are done when they're done. I think you're doing well by giving progress on how much you've done. Just stop giving the number updates.

Another exercise is to break the large task down into smaller more estimable units. This exercise will help you understand better what you need to do as well. Check out Steve McConnell's Software Estimation and Stephen Withall's Software Requirements Patterns for tips on breaking down tasks and discovering hidden requirements, respectively.

Don't shoot from the hip on an estimate. Take the time to break it down. Estimating a large number of small tasks will give you a better overall estimate (due to the law of averages some of your estimates will be under but some will be over and they will tend to weigh each other out) of the big task.

Answer 7

Ask your "project manager": Are we selling software or deadlines?

Answer 8

I'm a project manager and a programmer :-) I could go on a long rant about how most PMs are from outside the industry and can't handle anything that doesn't fit nicely into a production line model... but I won't, not here. Instead here's a long polemic on what to actually do (Mr Mod, if it's too long do what you will with it). I agree with the comments already made here, some you should do before others, but here's what I think would have best been your first move. Oh, and obvious answer to your question is yes, but that's elaborated in colourful & detailed language below.

Before I start though note that the PM is most likely giving you grief, because someone else further up the food chain is giving them grief. They (we) are simple creatures... There are ways to avoid the situation you described - Mike Brown covers that pretty well. There's also nothing wrong with workshopping something for 3/4/5.. hours straight before kicking off on it (actually all kinds of alarms need to go off if this doesn't happen). And if you are going into unknown territory, push back and ask for a week to research the area & technologies to be able to make a sensible estimate (you'll want to do this properly because you want new tech to learn & play with don't you?). If your PM and the management at the place you are at don't understand this... then update your resume and look for the nearest exit, leaving them to the fate they so richly deserve. That the PM would even think of getting a full time employee to sign a contract like that is a bad bad sign... the only way I could see that they might not be totally incompetent is that they were really just playing mind games with your project lead and you (from what I read they didn't put this directly to you, and didn't ultimately follow through on the threat). PMing is a haven for your standard corporate psychopath after all. It was good that others went into bat for you from what you said, so the advice below would have probably turned out positive for you in the end. I imagine they would have had a revolution on their hands if it turned out to be more than talk.

So to the actual situation/hole you described, because it's going to happen again to somebody, somewhere ( like about 5 minutes ago, and again in another 5, scheduleRepeat() ). Probably without the contract stupidity, but the basic storyline is always the same. Organise a meeting(!), they like meetings ;-) everyone can pat themselves on the back at the end like something was actually done. IMPORTANT: Make sure you include your technical project lead/team leader/architect/design manager in the meeting invite having already gone over the issue with them and gotten them on board. The higher up the hierarchy you can go for someone on your 'side', the better. Because your PM will see that and try and match your design manager with an equivalent. If not, they're dumb and you've already won. That in itself will generally pull them back into line, because now they are visible to someone who can probably sack them on the spot. If they are playing games with you, you are allowed to return the favour.

In the meeting, go through the technical details of what you are dealing with and why it takes the time it does. They should want to know this (and how they can help you get it done), but the sad fact is generally this doesn't happen... you'll probably get 10 minutes in before their eyes roll back into their head. Now what I would want done here probably isn't legal... yeah, I checked, it is highly illegal actually and you don't want to go to jail for that long. The point is you've put in a best effort to be proactive and if you've got some higher-ups present, your pain is now theirs... as it should be. You'll have to use your judgment on how things are likely to play out, because 'escalation' is what will happen. If the leadership at the place you're at is half decent they will do the right thing, and do the right thing by you as well. If not, then you would have had your resume out in the marketplace beforehand... you were going to leave at the first opportunity anyway (and looks like you did ultimately). The leadership will fall into two groups - either they are technically savvy and they will instantly see your point of view; or they aren't and what are they going to do about it other than grin and bear it? If they could do what you do, then they would already be doing so.

Keep the changing requirements issue as your trump card to use at the end... it will serve as an out for everyone. The project itself and the damn client/stakeholder will have their name taken in vain. The most painless way forward would be for a kind of reset to happen on the project, and maybe that PM would be quietly reassigned to a different area. Miracles do happen occasionally. If the contract issue was raised in the meeting by the PM, then hit back with the requirements freeze counter-contract demand - as far as I'm concerned they already burnt their bridges with you, and to the entire development team, when they started playing those kinds of mind games.

Before I sign-off: Changing scope/requirements - one of the best reasons to adopt the Agile methodology, so the clients/stakeholders are properly accountable for changing their minds about what they want...

Oh, one other thing: on the "I don't know" statement, has always been my personal benchmark on how to gauge the worth of a fellow technologist or member in one of my project teams. I find the only people who are able to say that straight to your face are the best there are, primarily because someone who knows they are out of their depth will never say that - opens them up to being clearly exposed by someone with actual ability in a heartbeat. On the other hand someone who will front up and say it, will also have a basic plan (even if it hasn't been thought thru) on how to tackle the unknowns so that in 24 hours there'll be a more useful answer, and in a week's time an even better one. When Apollo 13 was flying around the dark side of the Moon, there were a whole bunch of "I don't knows" happening. If you can't deal with that sort of thing, you're in the wrong game.

Answer 9

Yes, this should raise a red flag, especially if you're a full-time employee. What were the conditions of the contract? Would you actually be fired if you'd missed deadlines? Or would you just miss a bonus? What would they do?

The flag this raises is that the manager has no idea how to manage a project dealing with new/unfamiliar technologies and shifting requirements that directly affect estimated effort. While hard deadlines sometimes happen, a manager who knows the situation shouldn't be trying to get employees to sign contracts to enforce them. Late nights and crunch times will be bad but that's probably par for the course. And still sometimes the deadline will slip. It happens, and like someone else posted, the only way to stick to the schedule is to freeze the requirements EARLY ON so that there's still enough room to keep the timeline.

Answer 10

From what you've said, the alarm bells are a few months too late. It's normally risky to base a time-sensitive project on technologies the staff is not already familiar with. It's foolhardy to do so if you have no grasp of requirements gathering and scope management.

That said, I agree with the other answers. Also, you may want to update your resume if you haven't already done so.

Answer 11

Just like all the other respondents, I couldn't agree more that this should raise a red flag.

It seems like the PM doesn't want to be involved in the development process.

In my personal practice I've long moved away from dealing with detailed up-front specifications, sign-offs, full project estimate, or fixed-bid pricing (from a consulting perspective).

The reason for this is the realization, which many of the Agile and Lean Software gurus talk about, that software is not a fixed manufacturable entity, but it is mostly a process of discovery.

Many people still have trouble with this notion, and it sounds like your PM did too. It comes down to a simple understanding of trade-offs.

Rigid up-front specs and fixed estimates work for systems where the cost of change is high. Like building a high-rise. If you forgot to spec out the elevator shafts up-front, then it'll be really hard to retrofit the building once it's been erected. High cost of change requires a lot of up-front planning, learning the unknowns of components and technologies, and up-front experimentation. Only once you have done all this homework, can you estimate budget and cost.

In software people have grown very accustomed to the idea that the cost of change is low, and so they like to take advantage of being able to change things once they see a release, incorporate new understanding of the application, the business, the customer on an on-going basis. All of this is good and a huge opportunity when leveraged correctly. Most software people I've met and worked with actually don't enjoy spending a lot of time planning or investigating; most of us (PM's included) want to see on-going traction. This is where iterative development came from with its small, incremental releases of functionality. There are other practices that can be used, such as test-driven development to guarantee that the cost of change stays low and technical debt is contained.

Making this work involves a "contract" between both sides, the product owner (Agile speak for your PM or customers or QA team) and developers. Developers agree to only work on stuff that has been prioritized as most important for the given iteration and to not take forever with that, but strive to release fully integrated chunks of functionality frequently (e.g. weekly or monthly). Product owners, conversely, agree to continuously review the incremental releases and provide prompt feedback. They also agree to set the priorities for the next iteration and once set to not change their minds for the duration of the iteration.

This latter part of the agreement is something that your PM likely doesn't understand. Many traditional PM's actually don't. Some of them think their work is done when they drop off the spec; they don't want to hear about problems, alternatives, better ways, etc. The downside is that this is not only counter the flow of software development but also hurts the organization by leaving many opportunities on the table.

Take a look at the Agile Manifesto: http://agilemanifesto.org/ It may resonate with you. A good book to read is also Mary Poppendieck's "Lean Software Development"

Good luck.

Answer 12

Sounds like the manager is looking for someone to blame when he reports to his superior.

I find if you have an unreasonable manager who thinks an 'estimate' is the same as a 'fixed period', the best thing to do is to think of a very generous estimate period and then double it!

Also, force the manager to ensure the requirements are fully detailed and fixed. Any changes from then on will not be addressed without a 'formal renegotiation' with the project manager of the new completion time.

Eventually the project manager gets the idea and plans accordingly.

Answer 13

My personal experience with this sort of thing is that the project manager is trying to set up a paper trail to dispose of you while making your termination your own fault. That would make it a very red flag. Your mileage may, of course, vary somewhat.

Answer 14

Good answers all around, but let me add my 2 cents.

If you ever study probability, there is such a thing as a "random variable". That is a number whose value you don't know, but you may describe your not knowing with a distribution, like a normal (bell curve) distribution or another.

The point is, the job will take some amount of time, but any prior estimate will be wrong, by a little or a lot, on the negative side or positive, so there is risk, and somebody has to take the risk. Generally, if people take risk, they get paid for it. Insurance costs money.

When I was a consultant, I usually had a choice of signing a time-and-materials contract versus a fixed-price contract. With time-and-materials the client bears the risk. With fixed-price, I bear the risk. With fixed-price, I build in a margin of safety, because if I fail to meet the target, nobody wins.

Asking you to commit to a fixed delivery date, especially without fixed requirements, sounds like trying to transfer the risk to you, even though it's not clear what you're actually risking. In any case, one response is simply to put in a really generous margin of safety.

P.S. You see this all the time with government contracts. There's an initial request for proposals, bids get made, a low bid gets accepted, and then the change requests start coming in, so the cost balloons, and the contractor gets blamed. Things work much better if there's a teamwork relationship between client and contractor, rather than an adversarial one.

Answer 15

Yes, of course this raises a flag about the experience and competence of your former boss. Yes, as most people suggested, this would be a good time to update your CV.

Yes, as the other answers state, in most situations you wouldn't want to sign that agreement. However, I want to suggest that there might be some situations where you might consider signing it.

Most developers and managers are aware of the constant friction between the functionality, deadline and budget. Many would also nominate quality as a fourth dimension ("I can deliver any set of requirements you like, by tomorrow for a low budget, as long as you are willing to accept that it won't work!")

But there is yet another dimension: risk. If I only need to deliver successfully 50% of the time, I can lower my estimates immensely; they are padded to handle a much higher delivery rate.

We can address risk in a number of ways (and padding estimates is one of them). The manager isn't willing to accept any risk, and wants to put the risk on your shoulders. Normally, you should decline such a move... unless you are being well recompensed.

If you are able to nominate your deadline, with a mutually acceptable amount of padding to deal with unexpected delays, and are able to negotiate a (very large) bonus if you hit it, and are in a financial position to be able to handle the penalties (e.g. being fired) if you can't, you may find it is a worthwhile "gamble" to accept that risk yourself and sign the contract - with suitable clauses to handle requirement changes.

Answer 16

This is straight-on stupidity. I don't know what the ultimate goal was, but every halfway decent project manager responsible for software products should be aware that estimates are exactly what they are called: estimates. They are not promises and they can't be made such without either draining the software developer of all their energy or forcing them to break their "promise" anyway.

If you want to show how ridiculous such a contract is, here could be two suggestions:

a) Highly overestimate to the point where the project takes five or ten times as long as you would estimate without a contract. If the project manager asks why the estimates are so high simply say that you are just making sure that you can fulfill your contract.

b) This has already been suggested: Ask for a contract that makes sure that not a single requirement changes and make sure that this includes correcting spelling mistakes. In my experience there's not a single software project where requirements don't change at some point during development. The project manager is more likely to have to break their contract than you are.

If the project manager would agree to anyone of these two suggestions you'd know for sure that they're out of their mind.

By the way, how would a contract for a full-time employee work anyhow? I don't know about work regulations in other countries, but as a full-time employee in a company I don't think that anyone could force you to sign a binding contract to meet a deadline and have a valid case. Sure, they could give you hell if you don't meet the deadline, but they don't need a contract for that. Nobody could fire you or give you less money. They could cut your agreed bonus at worst. So, unless this is different in other countries this seems more like an empty threat than anything you should take seriously.

Answer 17

I'm going to go against the grain here.

The situation you describe is not all that unusual at the Engineering team level, especially following a particularly late project/release. In many situations, your management and your whole organization may in fact have have signed up for a particular release date, and other parts of the organization will be geared up for that date. There can be tremendous pressure on your management chain to hit that date.

This is where a general engineering process comes in. You've probably heard of the waterfall model. There are other models, but the end goal of all of them is to consistently deliver something when it is expected and containing what was agreed to. Functional specifications, designs, task lists, etc. all go towards making this a predictable process. Communication, risk analysis, and (as you said) regularly updating expectations about schedule reduce surprises and make information available as soon as possible so plans can be adjusted. And yes, there should be adjustments to the plan whenever features are added or removed.

In some of the teams I have worked with, I would not hesitate to treat to my estimates as signed commitments, but that reflects the quality of the teams and the management, and not any particular skill at estimating. A team that is willing to sign a contract for delivering on time is an indicator of a well-working team, not a red flag.

Answer 18

I say put yourself in his/her shoes and try to understand what motivated that. From Managers/Accountants prospective they need a number to justify what is been happening and how things are going.

It might be that being ridiculed in the board room for shifting deadlines, missing too many dead line, he tried the simplest possible way to have them locked in. Give me a number and sign here! You being on the other end, could have only perceived that it is something against you. How ever making estimates and as going along realizing that they need to be adjusted is what he is more useful for him. If you understand what motivated the request and what is the real problem he is facing, you might be able to help him and yourself. As programmers we solve problems. This is no different, understand and solve his problem and he will be your best friend. There are so much work to be done that nobody has the time to plot a personal vendetta! He needs help with his work, the simplest solution was to have somebody sign a paper! Probably he got that from a management for dummies book, "Get your workers to sign and be help accountable for a number." Funny but sad

Answer 19

"Walking on water and developing software from a specification are easy if both are frozen."

-Edward V. Berard

If your requirements are changing, then it's unreasonable to expect your initial estimates to be accurate. Yes, this should be a red flag.

Answer 20

Does the contract specify a penalty for not meeting the deadline? If it doesn't, it's not a problem at all-- you're merely signing off on an estimate based on your knowledge at the time.