Clearly Defining Project Completion

My first contract as an independent consultant was with a large, multinational bank. They were attempting a processor-to-processor application that exchanged banking information nightly, and trying to implement a new IBM function called IBM Advanced Program-to-Program Communication (APPC)—something new to them, but not me. I was initially delighted to take the project. I met with the client’s programmer, and we clicked instantly. I gave him a quick tutorial on APPC, and how to implement and code the function.

The programmer briefed me on what they wanted to achieve, and together we defined details on program coding and flowcharted program logic. Next, we established compilation procedures, resolved syntax questions and tailored an application debugging and analysis tool. I went home, installed and tested dial-in access from my office, and contacted my bank partner the next morning. I talked his peers through installation and testing that verified the install. We were then in position to create and test one of the first-ever APPC applications.

I worked with my colleague to get the program coded and fixed compile-time errors. Then we stepped through the program, correcting errors and verifying logic. Next came testing APPC in a test system and two programs (one in each of two test processors) to be sure it worked. It didn’t at first, but we fixed some protocol errors, and the programs were soon in limited, then full production. The result? Happy client, happy consultant. Little did I know most of my contracts wouldn’t finish that way.

I’ve learned from long experience that most projects start alike—bidder solicitation, client and consultant interviews, a kickoff meeting to create a first-cut, sizing project plan, and proposal. Sometimes the process is shortened, but it’s pretty standard stuff. Next come negotiations, clear definition of objections and responses, and optionally, hardening the initial project plan into a working plan ready for execution. How the project ends, however, is quite another matter; it can drastically vary. I’ve experienced a plethora of scenarios that have ended with everything from smooth project completion, to premature IT project termination.

Possible Project Completion Scenarios

From my experience, here are some common ways a project can end:

• Projects can be completed on time with all objectives met, like my first one. This isn’t always the case, but it’s the most desirable outcome. Usually some unanticipated issues come up, but are relatively minor, ironed out easily and have little impact. This typically happens with small projects.
• Sometimes, projects reach completion with all objectives met, but hours are exceeded, like a software upgrade my staff and I performed for a large school system. In that case, I projected higher hours than the school vice president wanted. It took some finagling, but she released some funds she’d been holding back, allowing us to successfully complete on time.
• Projects can also be ongoing, renewing on a regular period, like semi-annually or annually. I had a contract like that with a large paper mill conglomerate where we provided all systems programming for several years. It was a dream project, but then the conglomerate changed ownership, and when our final 6-month extension expired, so did our contract.
• Sometimes projects are completed on time, but some objectives are missed. For example, a new function might not perform as expected. The projects costs might exceed allowable limits. The client personnel might resign, or priorities might change. You might even decide to base processing on a different platform. The list of factors goes on.
• A project might be terminated without notice, like a claims conversion project my staff and I were performing. The project consisted of replacing IMS/Data Communications (IMS/DC) and IMS Database Control (DBCTL) with CICS Transaction Server (CICS TS) and Db2, and convert unsupported vendor routines that interfaced between existing claims applications and IMS DB/DC, so our challenge was to remodel these vendor routines to interface to CICS TS and Db2 instead. Once we accomplished this the client terminated us, because now they could plagiarize our techniques. They broke the contract terms, but a lawsuit wasn’t feasible. Business can be a dog-eat-dog proposition.
• Projects can be completed once a specific objective is accomplished. I’ve had several projects where the client wanted to upgrade a software product to a new release. If the project is relatively small and contained, many clients agree to an hourly rate and pay on a bill-as-you-go basis.
• Sometimes projects are expanded during their execution, which changes the project scope and completion date. I’ve had a couple projects where an upgrade, conversion or new application is installed, and as a client integrates it into their installation, they find both incompatibilities and improvements in the product or facility, so the client retained one or more of my staff members to aid in the process. A consultant is always happy to accept more work.
• In some cases, projects are extended due to unexpected circumstances, like loss of staff, unforeseen problems or product insufficiencies, change of ownership, bankruptcy, etc. Events like this can increase project cost and overextend consultant and/or client. This happened in the previously-mentioned claims project; after gaining my client’s approval and being well connected to highly-qualified candidates, I added several part-time programmers and billed for their time. While I hadn’t inserted a clause in the contract—which in hindsight I’d highly recommend—my client approved this because it benefited them.
• A project might be shortened, often but not always due to budget changes (especially at year end). I contracted with a Midwestern hospital to upgrade system software (z/OS, Db2, CICS TS, RACF, etc.), and to convert a covey of flat or sequential files to relational database. All activities were a collaboration of the client and my staff; the effort’s front end was to install, test and move system software to production, perform necessary data normalization plus database design and definition, followed by loading the old files into new databases. The activity necessarily preceded application tailoring to exploit functional enhancements as year end neared, and then an austerity program was instigated. Budgets were cut, program enhancement plans came to a halt and our job was prematurely finished.
• Sometimes projects get aborted due to ownership change, financial difficulties, product failure, etc. I had a contract for staff augmentation—i.e. providing technicians to offload operational activities. I got copies of the procedures, reviewed tasks and assessed degree of effort, concluding virtually all work could be done remotely and much could be automated. When I reviewed this with the client, they realized we were far more skilled than needed. They hired less-skilled individuals, and performed the automation themselves.
• Sometimes projects start with one consultant firm, then get replaced for various reasons with another consultant. I haven’t experienced this scenario, but this is usually due to dishonesty, incompetence or inexperience on the part of either party. Good due diligence usually precludes this.

Possible Project Endings

To summarize, here are termination or completion related alterations that merit contract clauses to anticipate their occurrence:

• Planned or scheduled completion
• Extension
• Revision of tasks
• Revision of terms
• Revision of schedule
• Expansion of scope
• Reduction of scope
• Renewal
• Termination prior to completion

As time elapsed, when I authored a contract or negotiated a client contact, I built increasingly more termination clauses into the agreement based on outcomes I experienced, designed to protect both parties.

Why Are Project Termination Scenarios Important?

Once a project is approved and enabled—regardless of how well planned, staffed and funded—it invariably takes a path that diverges what was anticipated by its creators. I always added some time and money for showstoppers and task omissions, because I knew there’d be delays, omissions, miscalculations, product shortcomings or random variations.

An estimate is an educated, well-researched prediction. Having good project completion knowledge can provide a project manager with the wherewithal to structure a project proposal that will minimize what goes awry. Hope for the best, plan for the worst. Only once did I ever get “fired” (i.e. a project was canceled by a client well before completion), and I survived it by assuming and anticipating the worst.

---