I’ve seen project management tool reports where the team bragged “and we finished early!”  Kind of like it was a badge of honor or something.  Here are three good reasons we’ve found for not finishing a project early.

Personally, my experience is that finishing early — truly early — often messes others up.  More often for me, finishing early — which should, I thought, earn awards and recognition — just guaranteed that the final product was late!

1.  Don’t Finish Early If The Request Is Just Talk

We had to do the annual performance reports.  We were always late in the past and we never felt real good about the quality of the reporting.  It was just too rushed and not well thought out.  The folks we evaluated deserved better.

My boss decided to take action.  On the next reporting cycle, he insisted that all performance reports be turned in to him 30 days in advance.  Ugh.  I would have to start on them now.  OK, I’m a good troop.  I spend evening hours doing my performance reports.  I get them done and for the first time, feel pretty good about them.  I turn them in 30 days early.  My boss looks at me and says “these are done?”  I say yes.   He doesn’t look very happy.

A week goes by, no feedback.  Normally, I’d get feedback within a day — but that was usually because they were due by the end of the week.  A second week goes by, no feedback.  Well, they were pretty good this time.  The notion of starting early really seemed to help.  I don’t worry about it.

The organizational due date for the performance reports arrives.  I see everyone scrambling, making changes, passing back and forth performance reports.  I’m pretty smug.  I’m finished.  Finished on time and no need to scramble!  I see my boss.  He is sure to give me an atta-boy.  Instead, he yells “where are your performance reports?!”  I tell him he got them 30 days ago.  His response?  “How could they be complete if they were turned in 30 days ago?”  He tells me to update them fast and give them to him.

I’m perplexed.  Nevertheless, I look them over, tweak a few things, and then turn them in, again.  His response?  “It is about time!  Everyone else gave me their drafts days ago!”  I’m confused but still confident.  He asks “did you change anything?”  I say yes.  His response: “see, they weren’t done were they?”  He stalks off seeming more satisfied.

Our unit turned in our performance reports late, just like we always did.  Just like, in fact, all the units did.

Did my boss really want the reports early?  Probably not.  The demand for them to be early was probably more for “show” then a serious attempt to get this paperwork issue under control.  He could always tell his bosses, when we were again late, of how he made the attempt of getting started early but still no one was able to get them to him on time.

2.  Don’t Deliver Your Part Early If No One Else Will Be Early

We had about four weeks to complete the project.  My part was not difficult, but I had another half dozen or so projects and they were all demanding my time and I had committed to them before this project.

Nevertheless, I saw an opportunity to clear my plate of one project real fast.  So I took a chance and cranked on my portion of the project over the next week.  I completed it without putting off too much.  Good.  Now I’ll be able to get back to the other projects and not have to worry about this one.

I turn in my part of the project.  The project leader looks surprised and even a bit lost.  She takes the material and just sets it on the corner of her desk.  I would have figured she had her typical cabinet and system of folders to hold this material.  Well, not my problem any longer, I leave and say thanks.

Four weeks later I see a report on the project.  There is a list of people who have not turned in their portion of the project yet, so it will be at least a week late.  I scan through the list of people … and I’m on the list!  How is that possible?  No problem. Off to see the project lead.  This is a good thing to talk with her in person and not with a phone call.

She tells me she vaguely remembers that I did turn something in.  Was that for this project?  Yes, I say.  She looks through her now established system of files for this project.  She can’t seem to find anything.  Could I please go recreate the materials and get her another copy?  It should not be too hard she says since I had already done it before.  Thank goodness for the (almost) paperless office I think.

I do have to recreate some of the material in a finished form, but I complete it quickly.  I get the materials to her and she seems relieved.  She says she just has a few more to get and she’ll be done.  My name gets removed from the “not completed yet” list on the next report.  No mention, of course, that my materials had been lost.  Why mention that?

The problem with getting things in too soon is that the organization (or project manager) might not yet be ready to deal with them.  It is often better that if we are done early, to hang on to things until everyone else is ready.  This way we don’t put demands on the project ahead of when they are ready for them.

3.  Don’t Deliver Your Project Early If It Is Not Important

We would get a lot of requests to support other organizations.  Some of the requests had high visibility, but others were things we know we just need to get done as a matter of course.  For many of these “matter of course” projects we knew that it was more important to turn something in then it was to spend too much time on them.

I got in one of those “this is our annual request for information and it needs to be submitted in 60 days.”  Ok, we had done this before.  In the past this request (and others like it) had always been handled as last minute fire drills.  I had volunteered my department to take on all these odds and ends and bring some order to this chaos.  I was going to eliminate this source of uncertainty — which often was dumped in my lap, but always at the last minute.

We cranked through getting all the needed information from the people and systems we needed information from.   People were getting use to our requests and we helped them by often pulling and formatting data for them, so all they had to do was review it and sign off on it.  Talk about good service and good relations!  We were a headquarters function and so we were in position to demand action from departments.  Instead, we focused on making it easier for them to help us, rather than using our authority to drive fast compliance (for more examples, see: project management tools as a service).

We finished up in about two weeks.  Quick and efficient.  Just like we liked it.  Boy, we were good!

I sent off the final package to my boss’s administrative assistant (AA) who tracked all these requests and who would take the package, certify it as official and controlled and send it off to the requesting organization.

The eventual problem appeared to be be that it was turned in early.  The AA, seeing no rush on what was a routine and generally minor effort, decided she would ship the data using a new method.  Apparently our organization was experimenting with a shipping technique that took advantage of shipments already going to certain locations.  Leveraging upon these already planned equipment movements, allowed us to piggy back on the arranged transportation’s excess capacity.  Did I mention this was a new thing?  Our oh-so-efficient, ground breaking, new-way-of-getting-things-done-quickly process was then connected to an experimental, working-the-bugs-out, never-been-used-for-this-purpose, transportation process.  The AA later explained that she had sent it this way because we had plenty of time and it was a fairly routine, minor project.  The data had disappeared and was never coughed up by the transportation process.

While this was a minor effort, that simply meant we didn’t get any real recognition for getting it done.  The only thing that could happen was to get a highly visible black mark for not completing it on time (especially when just about everyone else did).  We got pinged.  So much for Bruce’s vaunted efficiency and ability to improve any process!  Of course, I couldn’t highlight the “glitch” in the process, because I always preached that we owned the process, end-to-end.  I should have known better.  While I probably could have known about a new transportation experiment, it was clear that if I had just turned the product in on time — instead of very early — it would have traveled by conventional and predictable transportation.

Delivering a project or task early is often a much ballyhooed event.  We’ve found that this is true primarily for organizations that rarely deliver projects on time.  For those who consistently achieve on-time projects (and for those that don’t!), completing a project early is often recognized as being as much an undesirable situation as does completing the project late.

Do you have any examples where delivering something early caused more harm than good?