Emerging Tech

Don't doom a project to meet a deadline

In project management, it's sometimes more critical to ensure that you're successful in your launch than it is to meet your original deadline.

At Westminster College, we're implementing a new system for our Institutional Advancement (fund-raising and outreach) office. The old system, while widely considered the Cadillac of the fund-raising world, was not meeting our needs, so the College made the decision to move to a system integrated with the campus ERP. I've been directly managing this project while delegating significant chunks of the workload to others to handle.

As is the case for many new projects, a "go live" or launch date was determined based on a number of factors. Although we were relatively aggressive when it came to our initial planning, we felt that we could meet the milestone dates and launch the project on time, on budget, and in a way that ensured success. Obviously, that was all predicated on a number of assumptions, some of which didn't carry through, as I'll explain.

As is also often the case, we got about two-thirds of the way into the project and, in concert with the product vendor, it became painfully clear that meeting the deadline was going to be, well, a challenge at best for two reasons:

  • An unexpected and significant project was placed on a big chunk of the implementation team in the middle of the project.
  • A significant aspect of the project was not going well and was taking much longer than expected.

What we didn't do

At this point, there were a number of things we didn't do. Specifically, we didn't panic. Frankly, we're no worse and no better off than we were on the old product (and we're still running the old product), so the worst problem a delay would introduce was postponing a number of benefits.

We also didn't tell the people on the implementation team that we needed to double their workload to hit the launch date. I'm not sure that would have done much to motivate them given the fact that everyone involved was already giving 150 percent to work on both the project as well as other ongoing routine operational needs.

In short, we didn't try to go to superhuman efforts to meet what was a relatively arbitrary deadline. Instead, we kept our sights on the endgame, which was quality. One of the primary reasons that this project was initiated in the first place was due to data quality issues, and it would not have served us well to simply push and push and push to a point where we ended up with the same issue at launch time.

What we did do

We did have a meeting to figure out where we were and what happened. At the project outset, we were clear with management that the project timeframe was tight and that significant unexpected projects could affect our timeframe. In the midst of the project, the primary members of the team were handed a "do this yesterday" project that set us back quite a bit (weeks). I was involved in the discussion at the time of that project being initiated and indicated that it could affect our own delivery schedule, but I did agree with the need for it to go forward.

As soon as it became clear that we were not going to hit our deadline, I communicated that fact to all stakeholders and my boss. Although my boss was a bit dismayed, he understood what was going on and why it happened and had faith that we would regroup and get back on track to a successful project conclusion. In short, I didn't get dinged and neither did anyone on the implementation team.

Perhaps the most frantic part of the project came in working with the product vendor to reschedule our entire training schedule and our consultant visit and launch dates. They tend to schedule their consultants pretty tightly and all of them are in high demand, so the rescheduling process was a bit grueling, but we ended up with good result.

In one phase of the project, the implementation team did go to superhuman lengths to deliver on a critical aspect of the revised project plan. However, that has not been the norm. We've made every effort to keep workloads at reasonable levels. Obviously, however, any major project requires a lot of work.

The outcome

The outcome is still to be determined, as we're a few weeks away from launch. However, I'm confident in saying that an irrational push to meet our original deadline would have doomed the project to ultimate failure. It is more critical for us to ensure that we're successful in our launch than it is to meet our original deadline.

I've learned some valuable lessons in this project:

  • Communication needs to be consistent and constant. We didn't try to hide that we weren't going to hit our deadline. We told everyone, lived with it, and moved ahead. Further, we've kept key stakeholders apprised all along the way, so no one was really surprised when they heard that we weren't going to hit launch.
  • It will always be harder than you expect. I knew this going in, but this project has been a reminder that almost any effort will be harder work and take more effort than originally expected.
  • Expect the unexpected. I should have anticipated that we'd see a big project somewhere along the way in this month's long effort, but I didn't originally plan for it. Looking back, I see now that our real go-live date should have always been later than our original.
  • Keep the team happy and focused. I try to keep people happy. I know that, at times, the team has been very frustrated, overworked, and tired, but through it all, I've tried to keep them focused on the project's original goals, which will make everyone's lives much easier. While it's sometimes been difficult to see that, I believe everyone has given their best effort and continues to do so.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

7 comments
denisanderson07
denisanderson07

Well said! Systematic and meticulous planning is critical for the successful completion of a project. The project manager is responsible for achieving milestones and managing each task associated with the project. An effective and robust [url= http://www.microsoft.com/project/en/us/try-buy.aspx] project managing software [/url] like Microsoft Project 2010 proves to be a huge advantage for PMs. Its features like unified portfolio & project management, enhanced collaboration, user controlled scheduling, and many other capabilities assist in the successful completion of projects and achieving goals/tasks in a timely manner.

Jackraymond
Jackraymond

Hello All, Its My Pleasure to Post Comment on This Topic, To Meet deadline Every PM should Plan , The detailed planning reporting, reaching a mile stone and resources allocations each and every aspects must controlled by a PM, To Manage each task of a Project , an organization must have a Project management Software, ValleySpeak Project Server a web based Project management Software helps you reach the Time Period and helps you to achieve the productivity FREELY. http://www.valleyspeak.com/

ronitkintu87
ronitkintu87

This is the point that we have faced in our second last project.

shierod
shierod

The overall endgame does require a high degree of Quality over a deadline number. The ability to deliver solid results wins. The recipe is to break long term big projects into subsets that create milestones to produce the endgame results. This keeps employees engaged in reaching that next goal and seeing the overall big picture defined. Most people would rather tackle a well built wall today and see the tower results tomorrow. Employees feel in tuned and keep that feeling of accomplishment through out the project and not finding their contribution till the end. Just my 0.02

Marc Thibault
Marc Thibault

"It will always be harder than you expect. " How do you know this? -Because you have a history of projects that were harder than expected. How much harder? What was the impact? Your project history can give you a time and cost probability distribution for "harder" that should be in your plan. Here's a little help: http://smpro.ca/crunch/ParkinsonsUncertainty.png" "Expect the unexpected" Why? Because you have a history of projects affected by non-trivial surprises. Once again, an analysis of history can give you a probability distribution of the aggregate impacts of surprises that you can bake into your plan without needing to know which particular surprises will get this one. You probably want to do the same thing for scope creep. If your plan and the actuals don't match, there's something wrong with your plan that you want to get right next time.

Tony Hopkinson
Tony Hopkinson

the way you put it though. If you 'meet the deadline' but doom the project, you didn't meet the deadline. It's more than a mere date....

reisen55
reisen55

You can always have a totally opene-ended, non-client managed project like the horrific CITYTIME debacle that mushroomed over 10 years from a roughly $30 million project a $760 million project with no implementation in place, programmers and consultants run wild on billing hours WITHOUT CAPS and several going to jail because of a payroll fraud.

Editor's Picks