Power > Systems Management > Workload Management

Nothing Simple About It

Critical to success, project scoping is often overlooked

Accurately scoping a project is key to its success. It sets the baseline on how a project should be measured and the expectations of everyone involved in either the project or the product that results. In a consulting or contracting scenario, it often sets the price of the contract.

Therefore, scoping is critical but not for the faint of heart. It takes project-management skills, technical expertise, experience, planning proficiency, knowledge of the participants, a dose of intuition, a healthy measure of skepticism and a touch of courage. One thing scoping is not: simple. A recent project demonstrates that point well.

The Project

I spent nine months as the primary programmer/analyst developing what we fondly—and sometimes sarcastically—refer to as “new AR.” It’s a dramatic departure from “old AR,” an arcane, code- and acronym-laced accounts-receivable system requiring extensive training and experience to develop proficiency. This high-priority project was designed to provide ease of use, because many of this particular seasonal business’ AR specialists are also seasonal. Thus, it could greatly improve AR training and administration.

I recall the day we met with accounts receivable and customer-assistance management to discuss turning a steering committee’s design into reality. One IS manager turned to the other and said, “This is an inquiry-only transaction. We don’t update any files. This should be a great way for Jim to get his feet wet in AR. It shouldn’t take more than a month or two.”

Famous last words, given I had no AR background whatsoever. It turned out far more than one transaction was involved. Inquiry-only didn’t mean it was as simple as reading a record and moving some fields to a screen. Some of the existing AR rules were changed as part of implementing this application, affecting numerous calculations. In many cases, because existing programs accessed the AR files quite differently than was necessitated for this project, the previous code couldn’t be used.

These two managers aren’t naive or uninformed; they’re experienced, proficient, talented men who know AR in depth. But they operated in a lax project-management environment. In many cases, if the project overran projected hours, the work request was simply amended to reflect a new estimate based on the new information. Users were accustomed to this, and often contributed to the issue by submitting superficial, incomplete project requirements. As it progressed, the project’s requirements were expanded. Frequently, this occurred ad hoc as programming and users interacted. When the steering committee originally created the project, the process of gathering requirements was very informal.

It’s understandable that some question the value of extensive scoping. ... Yet what we don’t know can be disasterous.

Tweet