Here’s one way to describe software project management:

“The responsibility for producing a desired software result within acceptable limits of resource usage.”

That probably covers everything, but it is difficult to connect with because it is such a general statement. Here are some of the more specific aspects of this responsibility:

• Control of the development process. Project management is control of the development process. But, even the simplest development methodologies are not simple and some (e.g. Rational Unified Process) are rather complex. What kind of “control” of the development process can be simple enough to understandable and practical?
• Means for achieving closure. Closure means “getting it done.” Just another way of describing a successful project, but how many times have you heard a project manager or developer say something like “it will be done when it’s done—don’t ask me to impose a deadline or a firm budget on this project.” Closure is part of the game, and is a definite obligation of project management.
• Achieving a cost-effective result. “Cost-effective” means the software works as desired, provides the expected benefits and the cost in dollars and time is justified by the benefits. Again, this is just another way of saying “get the desired result with acceptable resource usage.”

So, how do we turn these ideas about “project management” into a practical, effective method of management we can rely on for every project?

Eagle’s answer to this question begins with this definition:

Software project management is control of the transformation of requirements and resources into a successful result.

To make this meaningful, we need to answer some questions in more detail. For instance:

• what kind of “control?”
• how do we understand “requirements” and “resources?”
• what is a “successful result?”
• what specific practices are both effective and practical?

Complex methods of project management often fail in the real world. We want an approach that is practical, reliable and easy to understand. The following discussion of the economics of software development may seem overly simplified. It is. But it leads to useful conclusions, as you will see.

The development equation. Let’s begin by saying:

result = DevProcess (requirements, resources)

or, alternatively: the software development process (DevProcess) transforms “requirements” and “resources” into a “result.”

Conditions. We need to acknowledge certain conditions which apply to the terms of this equation. In particular:

• Result:
     (a) is predicted before the project starts
     (b) may be different from the predicted result
• Requirements:
     (a) are given before the project starts
     (b) are usually incomplete and at least partially invalid
• Resources:
     (a) are predicted before the project starts
     (b) vary in quality
     (c) vary in availability

When a project is approved, the stakeholders have in mind a desired result. And even if a formal requirements study has not yet occurred, nevertheless the requirements are understood by stakeholders, at least at a general level. Finally, when a budget is approved for the project, that implies commitment to a certain quantity and quality of resources.

That where we begin. Project management must be designed to face these conditions, because they are present in every project.

Definition of “success.” A project is considered a success if the following are acceptable to stakeholders:

• the results
• the cost of resources
• elapsed time of project

Although the preceding description of the “economics of software development” is deliberately spare and simplified, it is also accurate.

The question is: is there a simple, pragmatic approach to software project management that can consistently lead to successful “results” while fully accepting the reality of the abovementioned conditions?

At Eagle we think there is such an approach, and we call it “Management by Structured Task List.” Admittedly not a very imaginative name, but we think you’ll agree it’s not quite as naive as it sounds at first.

So here is a summary of “Management by Structured Task List”—the specific objectives we want to achieve through this management method, and then a discussion of the properties of the kind of “Structured Task List” (STL) on which this method is based.

Objectives. What are the specific objectives we are trying to achieve in project management? What must our method accomplish in order to succeed consistently?

• Clear and pragmatic practices. An approach to project management that is not pragmatic and not clearly understandable will not be used consistently or effectively.
• Closure. Our method must lead each project to a definitive conclusion, avoiding creeping scope changes, shifting goals, and inexplicable lack of progress.
• Cost control. Every project has the risk of costing so much that it’s not worth doing. When the cost of a project crosses this threshold, it represents an unfortunate waste of money, time and effort. On the other hand, the lower we can keep cost without sacrificing “result”, the greater the return on investment, and the greater the value of having done the project.
• Reconciliation of requirements with result. Despite the mentioned fact that initial “requirements” may be partially invalid and the final “result” may be different from the predicted “result”, nevertheless there must be throughout the project a reconciliation of (evolving) requirements with (evolving) result. Ultimately the result must have a valid relationship to requirements, and requirements must represent a beneficial proposition for the organization.
• Timely adjustments. When you send a space vehicle to Mars, the cheapest way to adjust course is “as soon as possible.” If you wait too long, it becomes very costly and eventually impossible to get back on course. It’s exactly the same with software projects. The cost of corrections in the development process is geometrically proportional to percentage completion. The success of every project—including such aspects as budget, cost-effectiveness, project duration and fit for purpose—depends on the earliest possible correction of problems in the development process. Our method of project management must make this possible.
• Measurement. It should be obvious that all of these objectives depend on “measurement.” We must be able to measure percentage completion and the rate at which we are approaching completion at any point in the project. This measurement must take into account the fact that resources vary in quality and availability, and that requirements change.
• Single focus for project mediation. Finally, we need a single, unifying tool through which we can mediate the project—in other words, a single locus of information which supports all the objectives listed above. We call this a Structured Task List (STL)—but to be effective, the STL must have certain properties and must be used in a specific way. These are discussed below.

Role of the task list. The STL plays two important roles:

• It is the medium through which requirements, resource usage and results are reconciled.
• It is the means by which stakeholder expectations are reconciled with actual results.

Properties of the STL. Eagle’s “Management by Structured Task List” requires that the STL have the following properties:

• Based on structural analog of “results.” The structure of the STL must correspond to the physical structure of the project’s end product.

This end product must be defined in terms of deliverables, which may include such things as specific documents, source code, built or compiled components, an install program, third-party components, etc. Project tasks and their organization must correspond in every case to specific “parts” of the delivered result.

• Coverage. The STL must exactly “cover” the deliverables.

In other words, tasks must be chosen so that within any given phase or level of abstraction:

Nothing’s included more than once. That is, there is no redundancy among tasks, from either the point of view of the action being done or the part to which the action is applied.

Nothing’s missed. No parts of the project’s deliverables are unaccounted for in the STL.

This is not as inflexible as it sounds. Tasks can be organized within a topical structure having multiple levels of abstraction—so although individual tasks must not overlap, they can be placed at appropriate levels within a hierarchy of topics.

In Eagle’s terminology these topics are called “groups.”·

• Account for “phases.” The STL has two dimensions. One of these is the “group” dimension, which, as described above, must be a structural analog of the planned deliverables.

The second is the “phase” dimension, which is loosely related to time. It refers to stages of development, which could have names like “R&D”, “Requirements Analysis”, “External Design”, “Implementation”, “Deployment.”

Every task must belong to a specific group and a specific phase.

• Hours specified. For each task there must be an original estimated number of hours to complete, a revised estimate, and the actual number of hours worked to date.
• Assignments specified. Every task must be assigned to exactly one resource (person). Tasks should be defined so they are appropriate for one-person assignments. If it is not known who will be assigned to a task, you can temporarily assign a placeholder resource (Mr. or Ms. X, Y, Z...). They should be relatively small, say no more than 24 to 36 effort-hours, though 2 to 16 hours is probably ideal.

Benefits of the STL. If properly used, an STL with these properties can provide a number of benefits for the project management process:

• Change in scope is visible. STL snapshots at intervals during the project, say every two weeks, clearly reveal certain kinds of changes to the project, such as new groups (extensions to scope), new tasks (oversights or extensions to scope), new phases (omission of a stage of the development process).

The STL makes it possible to see clearly where the project is changing, and to immediately determine whether these changes are acceptable in terms of cost-effectiveness. Undesirable scope “creep” will be visible and corrective action can be taken.

• Incorrect resource estimates are visible. Because tasks are relatively small, are assigned to a single person, and because estimated hours are always specified for a task before it is assigned, patterns of incorrect time estimates are quickly seen.

Once the pattern is seen, the cause can be investigated. The “problem” could be a wrong estimate to begin with, a misunderstanding by the developer of the actual scope of the task, absence of appropriate skills for the task, insufficient application on the part of the assigned resource, etc. The patterns of actual time vs. estimated time can help diagnose these problems. For example, being significantly over estimated time could be related to a particular “group” of tasks and may be related to technical difficulties; it could be related to a specific individual, indicating a problem with that resource; it could be across the board, probably indicated poor estimating skills; or it could be more or less random with no particular significance.

• Early detection of problems. Because

—the STL is “complete” in the sense that it covers all deliverables,

—all tasks have estimated times, so that the estimate for the complete project is known,

—the STL is updated frequently with actual times and estimated times to go for each task,

it is possible to compute percentage completion vs. percentage of budgeted time used to date. (Tasks with zero time to go are considered complete). Based on this information we can estimate, beginning very early in the project, the following:

—projected final size of the project based on the increase in estimated times for certain tasks and the rate at which these estimates are increasing;

—percent completion in relation to original estimates, revised estimates, and projected estimates of total project hours.

We know the percentage of budgeted resource utilization so we can determine at any point in the project the ratio of percentage completion to percentage resource utilization. Of course it is a red flag with resource utilization outpaces rate of completion. Management by STL allows this issue to be seen early and corrective actions taken. In extreme cases, this may even reveal unanticipated problems that make the project unviable. In this eventuality, the benefit is that the project can be stopped early, minimizing the waste of valuable resources.

• Team members can be more self-managing. The STL gives each team member a view of the entire project and their place in it. They can see the importance of their contribution and their rate of closure compared to other team members. It is always clear what tasks are available for them to work on.
• Reasons for change are easy to describe. By looking at the STL at different stages of a project, it is extremely easy to see where and how a project has changed during development. This facilitates accurate communication among stakeholders and team members about project status and development issues.
• Stakeholders can easily distinguish between “changes in requirements” (scope) and “problems with the development process.” Changes in scope appear as new groups or new tasks. Problems with the development process generally reveal themselves in the form of across-the-board failure to complete tasks within the estimated time.

Requirements for effective use of the STL. In order for “Project Management by Structured Task List” to be effective, there are some simple but essential requirements governing the use of the STL.

To be effective:

• Must have the required properties. The STL must have the properties described earlier in this section.
• Keep current with project structure. If the structure of the project—meaning the structure of the deliverables—changes, then the STL must be kept up to date with those changes. The STL must always be a valid “structural analog” of the deliverables of the project.
• Keep current with time estimates. Task time estimates must be reviewed regularly (at least weekly) and revised as needed.
• Update progress at least weekly. Percentage completion and hours worked to-date should be updated at least weekly for all active tasks.
• Team work assignments must always be related to specific tasks on the STL. All project effort, without exception, must be related to specific tasks on the STL. No work of any kind can be billed to the project unless it is related to a task on the STL.

An effective method of project management is essential for successful projects, but it is not sufficient. Also needed is the commitment of team members to the methodology and to each others’ success.

Here are a few of the specific responsibilities of team members which are required for this approach to project management to be effective:

• Do official tasks only. Work only on tasks assigned to you on the STL; do not do any work on the project unless it is part of an explicit task.
• Know the expected effort. Do not begin work on a task until you know how long it is expected to take. The estimated time for a task is often a “message” which indicates a specific approach to the task. If your personal estimate for the task differs from the estimate in the STL, come to an agreement on the estimated time before you begin the task.
• Report changes in estimated effort. If it becomes apparent that a task will take significantly longer than the time estimated, immediately bring it to the attention of the project leader; agree on a new estimated time before continuing.
• Report problems with task list. If you become aware of any problem with the task list (e.g. required work which has been left off the task list, bad time estimates, items on the task list which are no longer required by the project, etc.), inform the project leader immediately.
• Report bad news. Always report bad news as soon as you become aware of it.
• Ask for help. Always ask for help if you feel your time is not being spent effectively (e.g. if confronting a difficult bug, confusing requirements, problems with 3rd-party components, etc.)
• Report a better way. If you know a better way to accomplish a given task, suggest it to the project leader. Once the project leader has decided on an approach, do it the way he/she asks.
• Be honest. Be absolutely candid about your own progress.
• Speak up. If you have suggestions or questions during a project team meeting, always speak up.

This has been a summary of Eagle’s approach to project management. We have found it to be very effective in controlling costs and gaining closure for software projects.

A number of years ago we developed a proprietary project management system to support our teams in this methodology, relieving them of some of the bookkeeping chores of project management. This system is called “Manage!” It integrates the project STL, resource assignments, and customer billing into a single system, insuring that client, management and team member views of the project are all based on a common set of data.