# CVISN Phase [Tracking]{.underline}

Tracking is the measuring aspect of project management. We prefer to say
"tracking" instead of the passive "monitoring" because tracking denotes
an [active process to seek out]{.underline} relevant information. The
Project Management Institute (PMI) \[12\] defines project control as:

> *The process of comparing actual performance with planned performance,
> analyzing variances, evaluating possible alternatives, and taking
> appropriate corrective action as needed.*

Note that "performance" is always assessed relative to the plan on the
**[three dimensions]{.underline} of the triple constraint: cost,
schedule, and technical performance** \[18\]. Fine-tuning knobs that the
Project Leader can turn to assert control are \[12\]: scope; schedule;
cost; quality; risk; and staffing. It is beyond the scope of this Guide
to deal with all the various corrective actions a Project Leader might
take, but they are readily found elsewhere; all project management
reference texts \[12, 17-21\] include extensive discussions of project
control strategies.

As shown in Figure 5--1, a tracking process is necessary to loop back to
the plan and thereby set up a management feedback system. Process
control engineers speak of "open-loop" versus "closed-loop" control
systems. In an open-loop system you take aim and hope for the best. (An
example from your home would be a log burning in a fireplace with the
room absorbing however much or little heat it happened to produce.) In a
closed-loop system the output is measured and compared to the target or
set point; then corrective action is taken to re-aim the system. (An
example from your home would be the furnace which has a thermostat that
cycles it on and off to regulate the temperature.) Phase tracking is
like the thermostat.

![](media/image1.wmf){width="5.069444444444445in"
height="3.4194444444444443in"}

Figure 5--1. Each State Deploys CVISN Capabilities Incrementally

Pre-defining the tracking process lets each team member know what is
expected of him or her. After it becomes routine, they won't complain
nearly as much as when they first hear about it!

As in the previous chapter, we first discuss **guiding principles** in
the sense of natural laws to follow. This is followed by a discussion of
**operational concepts** that are generalized from particular instances
or experience and can be applied to new situations. Next we lay out
phase tracking **process steps** which you should tailor to your unique
project environment and organizational culture and tools. We end this
chapter with a description of the types of meetings that support phase
tracking.

## Phase Tracking Guiding Principles

Figure 5--2 lists the phase tracking principles for CVISN.

![](media/image2.wmf){width="5.0in" height="2.654861111111111in"}

Figure 5--2. Phase Tracking Guiding Principles

1.  **The project can be controlled through tracking.** A closed loop
    system has measuring devices that provide feedback, and a regulator
    that uses that information. This principle says that you should run
    your project as a closed loop system with management-oriented
    measuring devices in place, including your own instincts.

2.  **You can't track or control what you can't measure.** This is why,
    for example, you want to enforce the use of meaningful
    readily-quantified milestones.

3.  **Phase tracking is a continuous process.** Recall the three
    dimensions of the triple constraint that you must track: cost,
    schedule, and technical performance. Often deviations from the
    schedule will be your first indication that interventions are
    needed. That's because defining when something is supposed to be
    completed is often easier than estimating how much it will cost.
    Cost deviations will come next. Finally, technical performance will
    be missed. To remain cognizant of all three dimensions the Project
    Leader must constantly monitor various measures of progress.

4.  **Team members are more likely to maintain status information if
    they find it useful.** In the previous chapter we talked about
    shaping the planning materials to suit multiple purposes. For
    example, if you want team leaders to keep an eye on their detailed
    schedules, make it easy for them to use that same scheduling tool to
    generate information they use for required status presentations. By
    choosing and formatting the elements of the Phase Plan such that
    they are useful in other ways, you make it more likely that those
    elements will be kept current.

5.  **Status review presentations can bring about progress by forcing
    resolution and closure**. Status presentations are the hidden hand
    of management. If for no other reason than peer pressure and fear of
    embarrassment, action items get closed and technical issues
    resolved, often on the day before the status review but, what the
    heck, at least they finally get settled.

## Phase Tracking Operational Concepts

Figure 5--3 lists the phase tracking operational concepts for CVISN.

![](media/image3.wmf){width="5.0in" height="2.8534722222222224in"}

Figure 5--3. Phase Tracking Operational Concepts

1.  **Involve the entire project team in the tracking process.**
    Everyone on the team needs to feel accountable. You might want to
    hold weekly status review meetings, which could include off-site
    personnel and contractors via teleconference. What's important is
    that everyone realizes that the plan does matter, and that they are
    supposed to work to the plan. If problems arise, be sure not to
    "shoot the messenger" by reacting adversely to bad news. Instead
    figure out how to solve the problem that was identified as a result
    of the tracking process.

2.  **Use the scheduling tool's Gantt chart view for tracking, and
    record working-level notes in the tool's activity comments field.**
    Please review Figure 3--3 for a reminder of what a Gantt chart looks
    like. The Gantt chart view is automatically generated by any desktop
    project scheduling software package. Dates can be shown both as text
    in columns and as bar ends on a calendar scale. Since the activity
    descriptions are necessarily very cryptic, use the activity comments
    field for enlightening elaboration such as technical details and the
    working-level to-do list status.

3.  **Maintain a version delivery chart for each product.** A sample
    version delivery chart is shown in Figure 5--4. This chart should
    show what capability will be provided with each version of the
    product. [Describe the capabilities in end-user terms]{.underline},
    rather than in system developer terms. By annotating the chart with
    current status information the same chart can serve both as a
    vehicle for planning and for reporting. The same chart, 8 months
    later, is shown in Figure 5--5. Simply by relocating the
    highlighting arrows and updating the text, the chart shows where the
    development is at that later time.

![](media/image4.wmf){width="5.75in" height="4.0159722222222225in"}

Figure 5--4. Sample Version Delivery Chart

![](media/image5.wmf){width="5.75in" height="3.7423611111111112in"}

Figure 5--5. The Same Chart -- 8 Months Later

4.  **Keep track of action items, issues, and decisions.** These three
    categories capture the key programmatic information that project
    teams need to know. It is more economical to just record these,
    rather than full-blown meeting minutes. The objective is to provide
    structure, communication, and follow-through for topics that could
    otherwise easily "fall through the crack". We like to say that you
    assign an action item, have an issue, and make a decision. An action
    item is something that one person or a small group will work on and
    resolve in a limited period of time. "Resolving" may only mean
    gathering information so that the larger team can make a decision.
    An issue is something one is worried about but can't define well
    enough to assign as an action item. A decision is a conclusion
    agreed to by the team. There is a natural flow from a hazy issue or
    concern, to an action item, to a decision, as shown in Figure 5--6.
    Your project could record action items, issues, and decisions simply
    by creating a paper form that staff members fill out and turn in to
    a master list-keeper. Appendix G has a sample form to use. A more
    sophisticated implementation would, for example, maintain such lists
    in a Web-enabled database.

![](media/image6.wmf){width="5.45in" height="3.6444444444444444in"}

Figure 5--6. Flow of Issue to Action Item to Decision

5.  **Keep the critical set of drawings, charts, and tables up to
    date.** Make them part of your Project Manager's notebook and carry
    them with you. Spread them out on walls and tables during status
    meetings. Mark them up. Use them to remind you of the big picture,
    even when you are buried in detailed problem-solving. For example,
    sketch network connection modifications not in thin air during a
    meeting, but instead by marking up the physical design diagram
    placed on the conference table.

## Phase Tracking Process Steps

Any task involving more than one person, or lasting more than one month,
needs to be tracked. Earlier in this chapter we talked about closed-loop
versus open-loop systems. Figure 5--7 illustrates that tracking
mechanisms are used to "close the loop" in your project management
system.

![](media/image7.wmf){width="5.0in" height="3.2472222222222222in"}

Figure 5--7. Tracking Can \"Close the Loop\"\
in Your Project Management System

Tracking should be a continuous process. Below we describe several
practical and proven process steps for project tracking as illustrated
in Figure 5--8. All the methods involve people communicating with each
other, either directly or through written materials.

![](media/image8.wmf){width="6.019444444444445in" height="4.275in"}

Figure 5--8. Phase Tracking Process

Remember to track in all three areas of the **triple constraint: cost,
schedule, and technical performance**.

**Cost** reviews are usually most effective if accomplished in the
smallest possible group, often one-on-one. In addition to staffing costs
look ahead for procurement, travel, and other lump expenses. Beware of
delayed lump expenses that haven't hit the books yet.

**Schedule** reviews usually involve the team. What one task is
experiencing may affect other tasks. Often schedule slips can be avoided
by applying different resources to a problem. Reassignment of priorities
or tasking is best accomplished with the concurrence of the whole team.

**Technical performance** is usually assessed through testing. Different
kinds of tests are performed by different teams, and at different points
in the development process. In each phase, some kind of testing should
be performed to demonstrate that the phase objectives were met. Analysis
of test results should be completed promptly to assess the success or
failure of the testing process. Factor in the calendar time that is
inevitably required for repairs and rework to address the problems found
during testing. Please see the *CVISN Guide to Integration and Test*
\[6\] for a complete discussion of test planning and conduct.

The next several sections discuss ways of assessing cost, schedule, and
technical performance.

### Hold Team Meetings (Step 1)

People sometimes complain about "time wasted in meetings" but surely
even more time would be wasted if there were never team meetings, due to
the lack of communication and coordination that would arise. You need to
seek the right balance for the frequency and duration of meetings.
Different kinds of meetings accomplish different objectives; all require
an agenda in advance. The kinds of meetings that are typically useful
are summarized below, and discussed in more detail in Section 5.4:

-   Weekly project team meetings are held to discuss progress and
    problems with product development and integration. Schedules are
    reviewed. Special "issues" meetings are called as needed to address
    a particularly thorny topic, often involving only a subset of the
    team.

-   Monthly program team meetings are held to review the status of each
    project. Schedule changes for intermediate deliveries from one
    project to another within the program are identified and discussed
    at program team meetings. Separate meetings are held as needed to
    discuss issues and/or make decisions about areas that affect more
    than one project.

-   Quarterly state meetings are held to exchange ideas and status
    information with executive management and advisory groups.

-   Test review meetings are held to discuss plans for tests, and to
    discuss test results.

Not every meeting needs to be face-to-face -- some can be accomplished
via telephone. Long-distance carriers offer teleconference bridge
services: everyone calls in to one number and can then talk to and hear
everyone else. Participants can also share computer terminals for real
time review and modification of documents. Software packages such as
Microsoft® NetMeeting make this relatively easy over the Internet.
Security modifications are typically required -- your network firewall
administrator will have to open up certain ports. You might want to
purchase a headset so that you can be on the phone with your hands free
for the computer terminal.

### Review Schedules and Progress (Step 2)

At the program level, you set phase objectives and milestones that are
usually related to project integration. At the project level the
objectives are limited to the scope of the project, and the milestones
are usually related to product integration. At the product level,
version delivery schedules are set. Review whichever schedule is at the
appropriate level during your team meetings. Give ample time to address
areas where progress is slower than planned. Help, don't punish, areas
that are behind schedule. Reward openness. All of this will try your
patience! Keep a sense of humor and perspective.

It is customary to ask about percent completion on tasks. Reference
\[17\] advises *"Don't ask \[first\] what percent complete their current
task is. This is a very ineffective question in software and technology
projects. Instead, [ask them what is left to do in the
task]{.underline}."* Only after that, assess completion on a percentage
basis.

### Review Costs and Cash Flow (Step 3)

It is customary to plot three curves on one report: planned
expenditures, actual expenditures, and funding. Beware that comparing
actual expenditures to planned expenditures is adequate only if nothing
is behind schedule. The monthly expenditure "burn rate" is relatively
stable; if the team is behind schedule then monthly costs will continue
to accumulate over the additional time periods required to finish -- and
you will end up over budget at the end.

### Review and Maintain Lists of Action Items, Issues, and Decisions (Step 4)

In all team meetings, you should make written action item assignments as
needed, and then follow up on them. By convention action items need
"formal" closure via memo or e-mail. It's especially important to reach
closure soon for action items that affect the current phase. Decisions
that affect the delivered baseline should be handled through your
configuration management processes. When new issues arise, note them. If
old issues disappear, note that too. As an issue matures it typically
transforms into an action item. When decisions are made, make a note and
be sure the team is aware of the decision. Some decisions may be later
rescinded or overtaken by event. Periodically review these lists to keep
them tidy and current.

### Mark Deployment on Technical Diagrams (Step 5)

Make it obvious which elements of the design baseline have been
deployed. Update diagrams accordingly, for example by color-coding those
items already functioning. Check off the phase deliverables. Utilizing
staff-produced diagrams as part of the tracking process makes it
meaningful for both staff and for management.

### Ask Penetrating Questions (Step 6)

Ask team members open-ended questions like "What is your next step?", or
"After you get that data how will you analyze it?", or "What if that
approach doesn't work?" Ask even the seemingly obvious such as "When you
get it, do you know where you will put it?", or "Did you actually open
the box and count the units, because the last time we ordered two and
only received one!"

Rosenau \[18\] asserts that if you don't ask questions some people won't
volunteer critical information. He suggests asking (in a non-threatening
manner) these particular non-directive questions:

-   *What is your greatest concern?*

-   *Do you anticipate any problems that we haven't talked about yet?*

-   *What persistent problems do you have, and what is being done to
    correct them?*

-   *Do you need any resources you do not yet have?*

-   *Do you know of anything that will give you schedule difficulties?*

-   *What kind of help would increase your confidence in the schedule?*

-   *Is there anything I can do to help?*

### Make or Modify Task Assignments (Step 7)

Unassigned tasks need to be assigned, and under-performing tasks may
need to be reassigned. Staff will continue to need coaching and personal
contact that can best be handled via "management by walking around".
Keep an eye on the availability of personnel. Individuals may be
juggling tasks on multiple projects. Have backup personnel available to
carry on tasks during short-term absences such as vacation; this not
only keeps the project on track but also provides valuable
cross-training and skill-building for the backup personnel. Work with
line supervisors to resolve problems. For your contractors this requires
a degree of formality: at the minimum, written instruction via e-mail or
fax. Be sure staff receive training when they are asked to tackle new
technical areas.

### Conduct Tests (Step 8)

Genuine product testing demonstrates whether or not individual products
and integrated products perform according to user needs, within design
parameters, and toward program objectives. Developers usually perform
product-level [performance testing]{.underline}. End-users usually
perform project-level [acceptance testing]{.underline}. Program-level
testing is often performed by [independent test and
evaluation]{.underline} organizations.

Please consult the *CVISN Guide to Integration and Test* \[6\] for a
full discussion of principles, techniques, and tips about integrating
and testing components. Be sure to document test results; often enough
problems supposedly fixed earlier reappear in subsequent releases. A
test results package should include:

-   Test input and output (archived data files, printouts, screen
    captures, etc.)

-   Test procedures

-   Problems found

-   Corrective action planned

Ensure there is sufficient information captured as part of a test
results package such that those tests could be re-run months later
(called [regression testing]{.underline}) to make sure that a
formerly-existing capability hasn't been clobbered.

## Meetings to Support Phase Tracking

The next several subsections discuss in more detail the different types
of meetings mentioned earlier. They are opportunities to apply the phase
tracking processes described in Section 5.3.

### Weekly Project Team Meetings

A weekly review of the activity schedule is one of the most powerful
tools available to a Project Leader. As part of the weekly team meeting,
you should:

-   Mark up the detailed schedule to capture the work getting
    accomplished. Either one-on-one, or as a team, update percent
    completion on activities and add detailed notes within each
    activity's comments field.

-   Keep both the activity network (see Figure 3-2) and Gantt chart (see
    Figure 3-3) in front of you.

-   Be prepared to dynamically alter priorities and assignments to work
    around problems.

-   Review each product's version chart (see Figure 5--4) as a reminder
    of the capabilities scheduled for the current version.

-   Watch out for slips in the schedule that will affect other projects
    and, conversely, slips in other projects that will affect yours.

-   Review technical drawings such as thread diagrams and note what
    functions and system elements have been deployed (see Figure 5--9).
    Review the physical design and indicate what components now
    communicate, or to highlight problem areas (see Figure 5--10).

-   Check on the status of open action items and configuration change
    requests.

-   Listen for new issues, and for progress on old ones.

-   Make sure task assignments are clear. Identify where new resources
    are needed, or where someone is underutilized.

-   Discuss procurement items. Find out if paperwork is stuck in the
    approval chain, and who is working to break it loose.

-   Ask questions. Encourage conversations. Especially make sure you
    give everyone a chance to talk.

Make no mistake -- this is painstaking, detailed work. But the payoffs
are significant, real, and immediate.

![](media/image9.wmf){width="6.0in" height="4.5in"}

Figure 5--9. Use Your Thread Diagrams to Mark Progress and Problems

![](media/image10.wmf){width="5.509722222222222in"
height="4.136111111111111in"}

Figure 5--10. Use Your Physical Diagrams To Visualize Where Problems Are

Figure 5--11 is an illustrative photo taken at a Maryland schedule
review meeting, showing the tools placed out on the conference table to
assess progress and technical issues for the Maryland CVISN deployment.

![](media/image11.wmf){width="5.0in" height="3.7423611111111112in"}

Figure 5--11. Maryland System Architect and Director of\
Computing Services Meet Weekly To Track Progress

### Monthly Program Status Meetings

Monthly somewhat-formal status presentations will be informative to
management, and perhaps more importantly have a magic way of coalescing
issues and forging progress. Ask each Project Leader to make a 5--15
minute presentation on the status of their project. Get into a routine
of using standard templates and updating them from month-to-month. This
is a helpful discipline for the program team, and even a non-technical
audience (e.g., a steering or oversight committee) soon becomes expert
at reading and understanding the status reports. A good set of material
for each Project Leader to present is:

-   Project News Bulletins

-   Project Phase Charts (focused on the current phase)

-   Major Milestone Schedule

-   Product Version Charts (optional)

-   Accomplishments & Highlights Last Month

-   Key Objectives & Activities Next Month

-   Issues

-   Design Diagrams to Illustrate Key Points

-   Work Breakdown Structure annotated with cost, schedule, and
    technical status

Appendix C is an example of a recommended presentation format for use by
a single project to make a presentation at a regular monthly program
status review.

### Quarterly State-Level Meetings

Quarterly fairly-formal presentations to executive management and
steering committee members will be informative and also serve to
reinforce commitment to the program from these highest levels. At such a
quarterly meeting, the CVISN Program Manager (and perhaps the System
Architect) makes an approximately 30 minute presentation on the status
of the CVISN program. Sometimes, nearby states present status to each
other as a way of benefiting from lessons learned, and keeping track of
progress on program elements that are shared. A good set of material for
each Program Manager to present is:

-   Program News Bulletins

-   Program Phase Charts (focused on the current phase)

-   For each project:

    -   Accomplishments & Highlights Last Quarter

    -   Key Objectives & Activities Next Quarter

    -   Issues

-   Design Diagrams to Illustrate Key Points

-   Work Breakdown Structure annotated red/yellow/green

-   Capability summary

Appendix D is an example of a recommended presentation format for a
quarterly program status report.

### Test Review Meetings

Test review meetings are held initially to discuss [plans]{.underline}
for tests, and later to review test [results]{.underline}. Participants
include the developers of the components under test, the test
conductors, and the analysts.

In a [test plan review]{.underline} meeting, the focus is on what is to
be tested, the configuration of the items under test, when the tests
will be run, who is responsible for each aspect of testing, and how the
tests will be accomplished. Test plans, procedures, data, and tools are
examined.

In a [test results review]{.underline} meeting, the focus is on the test
after-the-fact. Test reports or real-time results are reviewed, problems
identified, and remedy plans made. Remember that testing is intended to
find errors. Be happy when errors are discovered during testing because
the alternative is that they won't be discovered until the system is
being used operationally.

### Issues Meetings

Sometimes special "issues" meetings are called [as needed]{.underline}
to address a particularly thorny topic, often involving only a subset of
the team. For an issues meeting to be effective you should set clear
objectives, define what you need from each participant in advance, and
lay out an agenda. Allot adequate time to each aspect of the issue, and
make sure the conversation doesn't stray too far off track. Establish an
atmosphere of open, non-judgmental exchange, so that everyone feels that
they are being heard, and that their inputs are valued. Look beyond
symptoms to root causes; ask "why" three times. Assign action items with
due dates, and record decisions.

For all meetings, keep track of the discussions, and distribute minutes
as necessary.