By Joe Danenza
While your first reaction might be panic if you’re put in charge of a huge project with a tight deadline, a calm approach and a solid plan will get you farther in the long run. After giving in to my first instinct and panicking, I figured out how to handle such a situation. We developed a detailed plan complete with deadlines, a budget, documentation, and a dedicated staff. These factors made the difference in a major programming and development project to produce 350,000 tax forms in six months. The lessons I learned from this project include:
- The value of developing a comprehensive plan.
- How to delegate tasks and determine what to outsource.
- The importance of independent quality assurance.
It’s back: Dealing with an outsourced project that returned
I knew from the start that our regular staff meeting one August Monday was going to be different. As the Information Systems vice president for a large bank’s pension-disbursing operation, I was present as usual, along with the other vice presidents for the department. When I saw the look on our director’s face, however, I could tell something was coming down. I noticed more people than usual in the room, including the senior vice president for the entire division.
The senior VP got right to the point. We had outsourced the production of just under 300,000 tax forms the previous year to an industry leader in this field. We were late in identifying, producing, and reconciling the data. Consequently, the outsourced vendor was also late in printing, finishing, and mailing our tax forms because they could not adjust their schedules accordingly. Although I had produced the data for the vendor, I knew that none of problems with the project was directly my fault. Nevertheless, I braced for the inevitable management line of, “This is unacceptable; we must work faster to get the data to the vendor on time, yada, yada, yada….”
These comments never came. Instead, the senior vice president dropped a bomb: the production and processing for upwards of 350,000 tax forms was coming backin-house. This directive meant that everything from researching the laws to mailing the completed forms to taxpayers must be completed by Jan. 31, only six months away. This senior VP also reminded us that our bank could be heavily fined if we were late and that, as fiduciaries, we could theoretically be held personally liable. He also let us know that, if we failed, “Not everyone sitting in this room would be sitting here again next year.” All eyes fell on me when he announced who was responsible for pulling this off.
First I panicked, and I then tried pleading. Since neither tactic worked, I decided I had to spring into action.
At first, I started making misguided decisions because I knew that Jan. 31 was an immovable date that added new meaning to the word “deadline.” I reasoned—too simplistically, it turned out—that the major deliverables were fairly straightforward: a standard tax form for individuals and tapes for the various government agencies.
Of course, that was too easy. Not only did we have a major programming project but we had to order forms, find high-end laser printers, hire forms finishers and mailers, produce control reports, and a whole host of other torturous tasks. I panicked again and then regrouped to launch the project.
Formed a dedicated team
I insisted that the project team be the best we could muster. It also had to be under my control and, most importantly, be solely dedicated to the project.
I had an extremely experienced analyst to do conceptual and detailed specifications.
Two good programmers were assigned to code full-time. The team had no experience using IBM advanced function printing on 3800 printers, so we quickly contracted another programmer.
I assigned dedicated data center operators to job runs and print production. I had other staff members find forms vendors and other suppliers for materials and services. The dedicated staff concept was tough to enforce on a day-to-day basis but proved to be crucial as the project progressed.
Followed the project life cycle
My instincts as a programmer were initially very strong, and I almost went along with the general consensus to cut corners. I bit the bullet and said that we needed to do the necessary up-front work, albeit at an accelerated pace.
We did full conceptual and detailed designs. During and after coding, we did rigorous testing. I even made provision for—shudder—documentation and follow-up work. I also mistakenly tried to manage quality assurance.
Kept it simple
The deliverables were mundane. There was no need to make them exciting. We chose to print on standard size letter stock with micro perforations. If we ran out of stock, we would print on plain paper. The bulk of the forms were either 1099s or W2Ps, so we elected to type (yes, type) the few required W2s.
We chose COBOL as the programming language, as the data was on a midrange machine on a legacy system. Control reports were made comprehensive yet simple.
Keeping the focus on the deliverables and curtailing scope creep kept this project doable.
Developed a plan and a budget
No one expected me to have a budget, but I decided that we should at least have a rudimentary understanding of the cost of the project. This proved to be an extremely important decision because we completed the project for approximately $60,000 less than the prior year.
The most obvious yet most important part of the project was a written plan that included milestones. According to the timetable in our plan, we finished specs by the end of September on time. Our coding fell behind by about two weeks and stretched until the first week of December. Testing and revisions took us through the end of December and were completed about two weeks late. At least when we were late, we knew how late we were running and were able to adjust our work to catch up.
Ultimately, we delivered the finished product during the first week of January and, happily, the required forms went out one week before the deadline of January 31. The electronic and paper filings went to the respective federal and state tax agencies on time, as well.
Reviewed our mistakes
We came close to doing everything right, but there were several tasks we could have handled differently.
First, we overlooked errors early on because the same team that was doing the work was checking the work. When quality assurance was segregated, the independent auditors more readily found mistakes the project team had overlooked. Secondly, we did not plan for anything less than perfection. We started too late on a system to replace lost tax forms and consequently redid the final replacement system several times.
Overall, the project ended well, and I was in the conference room for the next year-end tax planning kickoff meeting. This time the divisional senior vice president did not find it necessary to attend as we now had a functioning in-house tax system. The other main difference was that the heat was on instead of the air conditioning because it was March instead of August.
Here are a few reasons to share your project success story with TechRepublic:
- If you publish your accomplishments, it provides more proof of performance when it's time for your review or when you want to change jobs.
- If you brag about the work of your staff members, you'll show them that you appreciate their hard work.
- If you share the details of a tough project you've tackled, your peers can benefit from the lessons you've learned.