Power > Systems Management > Workload Management

Nothing Simple About It

Critical to success, project scoping is often overlooked

Here’s how to avoid those pitfalls:

Take some time. Having scoped numerous projects, a handful of which took thousands of hours (the largest in excess of 5,000 hours, spanning two and a half years and involving as many as a dozen people), I’ve learned some painful lessons. It’s normal to want to start quickly and view the time spent producing an in-depth estimate as a costly delay—so it’s understandable why some question the value of extensive scoping. The same is true of project management in general.

Yet what we don’t know can be disastrous. In my example, many “mini-projects” cropped up, none of which were identified when the project estimates were established. They included:

• Painting two parts of a screen from two different transactions
• Deciphering and determining the structure of data to be passed from a new to an existing program
• Invoking transactions outside the requirements
• Displaying data that didn’t exist and couldn’t be produced without substantial modification to existing AR
• Changing AR rules and relationships

And then there were several functions and facilities that weren’t part of the initial requirements, but that users pleaded to have included, or that were ambiguous enough that either side could argue were or weren’t implied. We call this scope creep.

From the users’ perspective, they felt they had communicated these needs clearly, but because IT missed the significance of some verbal statements, they were not included in the time estimate. This leads to the second recommendation.

Define requirements thoroughly. Requirements must be defined in as much detail as possible. They’re the blueprints from which the whole project is built, including the time estimate. It’s helpful to hold a joint meeting of users and IT to go through a proposed set of requirements, line by line, item by item, detail by detail.

In this case, the requirements came primarily in the form of screen images. In retrospect, it would have been valuable to go through those screens field by field, asking the users what each field represented, and how the data could be extracted, calculated or produced. In many cases, the users would lack those answers, since they don’t have knowledge of file structure, etc., but IT would possess that information. The point is, this kind of discussion would have uncovered a wealth of useful details.

Instead, inconsistencies or impossibilities were discovered, one at a time, as the code was created. Discrepancies had to be resolved individually along the way, usually through discussions or meetings, followed by a period of consideration by the users, and eventually a decision—hardly a productive process.

Know your resources. As mentioned, I had no background in either the AR business process or the programs, files, screens and other computerized objects that provided AR support. Additionally, I was the only person assigned to the project, and the person who had previously supported the system had left the company. A couple of staff members had some AR knowledge, but much of it was out-of-date.

This lack of application knowledge wasn’t taken into account when the time estimate was constructed, yet after having completed the project I would suggest it increased the hours between 75 and 100 percent. It’s amazing how quickly I could resolve an issue by the end of the project, when early on a few problems took up to a week. What a difference knowing an application can make!

Tweet