Minimizing Project Plan Delays With Debugging

Project planning has been a way of life for me since my career’s early days, learned from an IBM senior systems engineer who was my comrade providing support to a large, leading edge insurance company, driven by their appetite for CICS First Customer Shipment, then Early Support Programs as IBM’s early introduction programs evolved. Project plans—at least for IT departments—were also in their infancy, so the plans were pretty basic. The ones I constructed were hand-written on coding sheets consisting of task name and description, the assigned technician, a projected completion date, and maybe a comment enclosed in brackets.

To put it mildly, project plans have advanced so much that the old, hand-written project plans aren’t even recognizable compared to today’s automated project plans displayed in columns with colors, lettering, lining,  grids, icons, charts and pictorial format showing task interconnections, interrelationships, estimated hours, percentage complete, dates, milestones, and a wealth of other information. Icons are usually provided containing links to supporting documentation, other related projects or any conceivable project attribute, let alone the wide variety of reports, charts, and forecasts most project planning tools offer today.

Those of us with a long history of project planning have had to scramble to keep up with the explosive progress project management tools and methodology have made, progress as exhilarating as the advancement technology traversed over the last half-century. Not only have the tools improved dramatically, but so have installation techniques built into the product. Vendor software installation—especially system software—has drastically improved in integrity and function, and application development has become simpler and more capable, all of which allows debugging—particularly quality assurance (QA)—to become germane earlier in a project’s process.

Traditionally, most development projects I’ve organized have a number of phases:

1. Gain approval for the project
2. Obtain funding for the project
3. Determine project staff members
4. Develop a project plan via kickoff meeting and extensive research
5. Begin and perform the development and installation process as defined and tracked by the project plan
6. Install software and/or hardware products, perform installation verification procedures
7. Produce/code programs and/or modules
8. Compile, resolve coding errors, and test programs, vendor products, and hardware
9. Begin logic testing and program adherence to design specifications, a process also known as debugging

Debugging Defined

Debugging—or problem resolution—is a process that applies to all aspects of an IT operation, including program and application development, software and hardware implementation, network design and deployment, and all upgrade processes. In many change scenarios, the traditional approach has been to make the change, then do the debugging, but in many cases it can be more productive and efficacious to debug as the work progresses, and the larger the project, the greater the positive impact the incremental method of debugging can be.

Debugging is multi-step process, starting with the location of errors, failures, improper functioning or abnormalities, followed with the making of additions, deletions, or changes to code, logic, parameters, or other program or hardware objects, in order to cause them to work correctly in the intended way for the object in question. This process is often performed in a structured and planned manner through QA, but is also performed via a problem resolution methodology called troubleshooting that addresses problems that have just arisen and are negatively impacting some aspect of the IT operation.

QA Versus Troubleshooting

The difference between troubleshooting and QA is:

• In troubleshooting, a problem has revealed itself through a dysfunction or failure and an analyst needs to locate and determine the problem, then make changes that eliminate the defect. It’s reactive.
• QA seeks to reveal unknown defects, determine the nature and location of the problem, and take actions to correct the malfunction. These defects are revealed in most forms by developing test cases—predetermining what outputs should be produced by logic or hardware based on specific inputs that are processed through predetermined logic—then verifying whether the expected outputs are correct. If not, steps are taken to locate or replace offending logic or hardware, and resolve the problem. It’s proactive.

Task Relationships Mean Interdependencies

In my early projects, the project plan usually deferred most debugging into an undertaking’s late stages, and this sort of “straight-line installation” methodology was how we implemented new products, procedures or changes. Especially in product upgrades or simple projects, it worked well, but in larger projects or implementations, interdependencies—situations where tasks competed for a common resource or one depended on the other—could require a task be suspended until the other completed a step or released a resource. We called it “putting a chore in hibernation,” and usually met to review the impasse for damage assessment and management’s signoff.

These interdependencies weren’t commonplace, but they were cause for concern, especially after I left IBM whereupon contracts were involved. We invariably found ways around the situation and one never caused any serious damage, but I was never comfortable when it happened. We always examined the deadlock to determine ways of avoiding a repeat or work around it, usually finding other things to do so everyone stayed busy. I always built time into the project plan to account for such situations; I never liked it but accepted it as a necessary evil. Most people accepted it as business as usual because no one had any reasonable alternative.

But as projects have grown in size, so have project plans and their components: Tasks, hours, phases, participants, products and most significantly, interdependencies that have proportionally increased downtime. Thus, achieving better time utilization has become mandatory, leading to a greater focus on task interdependency avoidance with the objective of eliminating every possible delay. Debugging—especially QA—has applicability in all project phases, serving as a sponge for idle time, thus improving utilization, making it an ideal facility to reduce interdependencies in a project plan and preemptively resolve defects.

Projects usually have phases they traverse as the project progresses; there are phases that must be completed before other phases can start or complete. But in most cases there is a degree of overlap, and often work on multiple phases is not only possible, but also desirable. A project plan can be structured to not only accommodate, but also facilitate “parallel processing,” whereby task dependencies are organized such that certain tasks can be executed concurrently. Care must be taken, however, to avoid dependency conflicts, not only of the tasks under immediate consideration, but also of preceding dependencies that may cause conflicts.

It Comes Down to Results, not Utilization

Care is foremost when identifying interdependencies, because mistaking them can cause lost time or delays; false alarms can misdirect technicians to suspend current work and begin debugging. Moreover, most technicians are quite capable of managing their time, so redirecting work should be viewed more as a suggestion than directive. I’ve heard there are now tools to ferret interdependencies out, but I doubt there will ever be a complete solution for lost time. Project plans are living, ebb-and-flow entities, so interdependencies—and attention to detail for that matter (which can be positive and constructive)—will always be a source of delay, but progress in built-in delay reduction is always welcome and will enhance productivity.

Debugging isn’t the only project plan phase that can fill downtime, it’s just the most commonplace, general-purpose activity that permeates the majority of IT tasks, because the production of documentation and code/procedure creation achieve the same goal and thus should also be built into the project plan. Similarly, providing bonuses for working longer shifts, incenting participants with recognition and awards, and providing
other incentives like challenges or group outings can inspire staff members and serve to accelerate a project’s progress.

While minimizing a project’s duration is a laudable objective, the primary objective is to make a project plan an effective catalyst to a successful project. That requires leadership, guidance, motivation, teamwork and provision of the necessary resources to do the job, coupled with skills and an environment where participants can excel. Perhaps the most important consideration related to optimizing time usage is for the project plan’s creator to be alert to task interdependencies, make relevant members of the project team aware of possible consequences and document those aspects in the project plan while scheduling around them where possible.

---