Iterative Elements in Project Tasks

Suppose your project is creating a multiscreen client/server system whose back end is a relational database management system (RDBMS) like Microsoft SQL Server, Oracle, Sybase, Informix, or DB2. When performing a quick, in-your-head decomposition of the tasks involved in creating this project's deliverables, you might spot some iterative processes:

■ Placement of certain elements on any of the screens (e.g., help button, common background graphic)

■ Development of certain database tables, regardless of the kind of data contained (e.g., lookup tables)

■ Installation of several RDBMS servers in various sites throughout your corporate enterprise and setting up database replication between the servers

There are probably others that you could glean simply by going through a WBS brainstorming session with the team members responsible for each of the components of the deliverables. But you get the idea—certain tasks are going to require an element that was performed previously or will need to be performed again in an ensuing task. This is an iterative element, one that you'll need to specially plan for.

The problem with iterative elements is that, try as you might, there is little you can do to keep a team member from having to repeat steps a previous team member has already performed. So iterative processes show up as added costs in a project plan. You should do your best to reduce repetitive project steps. For example, if your screens all have some common elements, is there a way that you can develop a single master screen that contains the common elements, then allow the developer to copy this master screen and then place his task's elements on the screen? In this way, you've managed to cut down a bit on the iterative aspect of the project, though you need to recognize that the first person who develops the master screen will take some extra time to do so carefully and completely.

Lookup tables are commonly used in application systems. Good table definition might recognize that one developer's lookup tables are quite similar to another person's and, with some tweaking, you can cut down some of the iterative processes.

Reuse of common code modules helps eliminate iterative processes.

Installing servers that do a common job can be accomplished within one task simply by applying several team members to the job in order to install them all and configure replication at one time. The cost of the team members' time must be judged against the longer project duration from having servers installed and replication configured one after the other in several project steps.

Some iterative processes can be minimized a bit, but not enough to make a big difference. Testing is something that usually requires lots of unavoidable iteration —unless, that is, you don't mind sacrificing a deliverable's quality.

A Highly Iterative Process: Packaging

A Highly Iterative Process: Packaging

Packaging may require some iterative elements you hadn't thought about. Have you ever installed some software and marveled at how smoothly it put itself in place? That's a fine packaging job—one in which the software installs where it's supposed to, with a minimum of user interaction, putting Registry entries and other goodies where they belong.

Packaging doesn' t happen by accident, even with the most senior of package developers. Packaging is an extremely iterative process, where you develop your package, test it on a reference computer (a computer with a standard installation —one that mimics what' s likely to be found out "in the wild," in the user world), find problems, rebuild the reference computer (to get rid of the bad stuff the previous package left), then retest. Very time- consuming, mundane, and often boring. It takes a real talent to be a good packager, and you have to like what you do.

People who install Microsoft Systems Management Server, CA Unicenter, IBM Tivoli, or Novell Zenworks can develop software packages that they can push to their user base. Often these package developers get a black eye (more accurately, the management software gets one) because they don't understand the iterative process of packaging. They simply develop the package and "Yoicks, and away!" they push it out the door. Without a clear understanding of iterative processes, a systems management software push such as this is doomed for failure, because you don 't have a grasp on the quality control aspect of packaging. People who are new to packaging are tempted to push the package the first time it appears to work, without further testing and retesting in order to make sure it works. The quality control problem surfaces when an admin sends out the package to an operating system that he hadn 't thought to test it on, and the package fails almost immediately. Oops! Back to the drawing board. An iterative QC process would' ve eliminated this problem.

Because of the possibly "hidden" nature of iterative processes (that is, tasks must happen, regardless of whether they' re recognized as repeating), you have the choice of whether you want to reflect this information in your project ' s documents. Personally, I think it ' s worth the time to examine iterative processes to see where you can make some cuts and thus save money and time in your project ' s steps. The larger the project, the more important it' s going to be to identify iteration in your project ' s actions.

0 0

Post a comment