When developers are working on a new project, it can be tempting to overpromise to keep people happy, but that can also backfire.

When the developer in this story was moving into a new role because the previous one got fired, his friend at the company told him to never overpromise because that is what happened to the other guy.

Fortunately, he took that advice to heart and gave very realistic timelines, and more importantly, documented all discussions in detail, which ended up saving him and his team.

This is a great story that shows why you always have to protect yourself at work. Read through the full story below and see what you think of how he handled it.

Don’t overcommit? Got it new friend, thanks for the tip

Worked at BigCo for a few years as a project manager and had some good strings of project delivery.

He doesn’t want the extra work.

My manager arrives: “Hey, bad news, UnknownPM got fired, you are taking over that HR delivery team.”

Crap. Being a BPMFH, I’d heard rumors about issues with some HR projects, but Big Co never fires PM’s so really didn’t dig into my network to see what the deal was.

Understanding what he is getting into is very important.

Some poking, paying for rounds at Happy Hours, got the info that UnknownPM had failed to deliver some functions that HR wanted. OK, got it.

HR Director knows I’m coming, sets up a meeting with their next level minions managers. Smiles, team talk, greater good ideas, etc. At the end as I get ready to meet the development team, OfficiousMinion says “Welcome Kilted, let me give you some free advice, Unknown got fired for over committing on what would be delivered”.

“Thanks for the guidance!” (and confirmed what beer money had told me).

Planning a project is essential.

New project starts, we do requirements gathering. Each requirement gets assigned hours (design, development, testing (unit, system, user) and some for implementation.

Hours get turned to dollars and then the business people (HR) need to assign a value to this requirement building a business case (costs X to do, Y value, X < Y then we do it.)

He is covering all of his bases.

So, we wade through HR functions and a few of the “solve world hunger” type requirements. “World hunger” doesn’t make the business case cut and we get the list of requirements. Requirement doc goes out for final review.

But, since this isn’t my first rodeo, but it is a new corral, I create a document with everything that got cut. It also goes out for final review. I’m also clear that development will stop until both documents are signed off.

Everyone seems happy with the progress.

People involved sign off both docs. OfficiousMinion (OM) comments “This is a great idea, all projects should have this!”

We are in the last week of User Acceptance Testing. Minor stuff, team fixes and we flow them in.

Sorry, sir. That is not what was agreed upon.

I get a call from the Lead Developer “Hey, OM has filed a critical issue that we missed a function.” “Fine, what is it, and is it in the functional spec?” We trade details, but the key one is it’s not in the signed functional spec. I dig, yep it’s not in the function spec, but it IS in the “Functions that were Cut” document.

Contact OM and go “Hey the functions you want got cut in the requirements phase, we can schedule them for a future release, but we will need a business case”. “NO, it MUST be in this release, I’m going to withhold approval until I get it, make your team do it. “

How are they going to handle this?

Team meeting: “Is this possible?” murmurs of “here we go again”,”8 weeks”, “why does this always happen?”

Dig around and find that OM pulled this the last three projects, they tried, failed and Unknown PM got fired. Got it. “So we are all agreed that we can’t do this and not jeopardize the release?”

He is giving them time to discuss it.

Silence. “Ok, so we have a choice. We either all agree we are not doing this, it’s a really bad idea, or you decide you can do this and you spend the next 8 days working around the clock. I’ll back you up, and if you say no, it’s no. I need a bio break, you all decide and in 5 mins tell me what you want to do.”

(I listened into their conversation from my phone).

“You think he can tell them no?” “Don’t know, he’s old and has been here for awhile” (OLD??) “We can’t keep doing this”, “Yea my family is unhappy already with the hours”. More chat back and forth. I come back in.

The stakeholders aren’t going to like it.

“Do we have a decision” “Yes, we can do it in 6 weeks” “That’s not going to fly, so we agree, next release?” “Yes”

I set up a meeting with HR director and their team, along with the stakeholders for the project.

He has the documentation to back up his decision.

I explain current status, the new requirement and that we can do it, but it will be at least a 10 week delay. OM goes, “This is missing functionality that wasn’t implemented, needs to be in this release.”

“Actually it’s in the Cut Functions list that you all agreed to and signed off on” as I pass out the page with the requirement highlighted, and each person get’s a copy of their email where they go “I agree”.

OM frowns and goes “Well this is an error, I would never agree to this”

This guy is prepared for everything.

“Sorry, you did, as did all the people in the room. And you’ll note that while we estimated the cost, there was no estimate of the business value.”

“Well the business value should have been followed up on” “I did, and here is the email chain between you and I and your team about the status of this” Slide more papers around the room. Papers shuffle as they read.

The director knows what is happening.

I continue “So no business value, nobody opposed tabling it. And if you remember the first time we met you said ‘Do not over commit’. And according to these emails (push shove rustle) you and your team have tried to jam last moment features into the last 3 projects and caused all of them to be either late or have systems issues.” Silence as people read.

Director goes “Well, with the agreed to functions, where are we?” “I need User Sign off and we are good to go.” “Fine, all of you get your sign off to him by the end of the day, OM please come to my office so we can chat about this.”

Things worked out just perfectly.

We all nod and leave. Release goes live on schedule. OM gets moved to “Special Projects” which consists of reading the want ads until they are “departing the company on new adventures”.

And Sanjay, the lead developer for this project and the prior 3, gets a surprise bonus for keeping an awesome email trail.

This is yet another story that shows why it is so important to document everything and get all agreements in writing.

Check out what the people in the comments have to say about this story.

Last-minute demands are awful, but they are common.

Most people don’t do an out-of-scope document, though.

Good project managers are invaluable.

This commenter is going to learn from his story.

If you enjoyed this story, check out this post about a restaurant employee who decided to put the staff over customers despite the official policy.

Always document everything.

When it comes to software development, documentation is essential. This story shows that you also have to document what you won’t be doing since people’s expectations are always changing.

Having everything down in writing is the only way to ensure there is no confusion, but most people forget to do it.