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 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.
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 with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at firstname.lastname@example.org.