Section 10 - Keys to Success

DOs AND DON'Ts FOR PROJECT SUCCESS

As standard practice, the SEL records lessons learned on successful
and unsuccessful projects. The following DOs and DON'Ts, which
were derived from flight dynamics project experience, are key to
project success.

Nine DOs for Project Success

• Develop and adhere to a software development plan. At the
beginning of the project, prepare a software development plan
that sets project goals, specifies the project organization and
responsibilities, and defines the development methodology that
DOs will be used, clearly documenting any deviations from standard
procedures. Include project estimates and their rationale.
Specify intermediate and endproducts, product completion and
acceptance criteria, and mechanisms for accounting progress.
Identify risks and prepare contingency plans.

Maintain and use the plan as a "living" document. Record

updates to project estimates, risks, and approaches at key
milestones. Provide each team member with the current
software development plan. Periodically, audit the team for
adherence to the plan.

• Empower project personnel. People are a project's most

important resource. Allow people to contribute fully to the
project solution. Clearly assign responsibilities and delegate the
authority to make decisions to specific team members. Provide
the team with a precise understanding of project goals and
limitations. Be sure the team understands the development
methodology and standards to be followed on the project.
Explain any deviations from the standard development
methodology to the team.

• Minimize the bureaucracy. Establish the minimum

documentation level and meeting schedule necessary to fully
communicate status and decisions among team members and
management. Excessive meetings and paperwork slow progress
without adding value. Don't try to address difficulties by adding
more meetings and management. More meetings plus more
documentation plus more management does not equal more
success.

3
Section 10 - Keys to Success

• Establish and manage the software baseline. Stabilize

requirements and specifications as early as possible. Keep a
detailed list of all TBD items — classified by severity of impact
in terms of size, cost, and schedule — and set priorities for their DOs
resolution. Assign appropriate personnel to resolve TBD items;
follow their progress closely to ensure timely resolution.
Estimate and document the impact to costs and schedules of each
specifications change.
• Take periodic snapshots of project health and progress,
replanning when necessary. Compare the project's progress,
product, and process measures against the project's plan. Also
compare the current project with similar, past projects and with
measurement models for the organization. Replan when the
management team agrees that there is a significant deviation.
Depending on project goals and limitations, alter the staffing,
schedule, and/or scope of the project. Do not hesitate to reduce
the scope of the work when project parameters dictate.
When the project significantly exceeds defined limits for the
local environment, stop all project activity, audit the project to
determine the true project status, and identify problem areas.
Examine alternatives and devise a recovery plan before
proceeding again.
• Reestimate system size, staff effort, and schedules regularly.
As the project progresses, more information is learned about the
size and complexity of the problem. Requirements change, the
composition of the development team changes, and problems
arise. Do not insist on maintaining original estimates. Each
phase of the life cycle provides new and refined information to
improve the estimates and to plan the project more effectively.
There is nothing wrong with realizing that the size has been
underestimated or that the productivity has been overestimated.
It is wrong not to be doing something to detect this and take the
appropriate action. As a rule, system size, effort, and schedule
should be reestimated monthly.
• Define and manage phase transitions. Much time can be lost in
the transition from one phase to the next. Several weeks before
the start of each new phase, review progress to date, and set
objectives for the next phase. See that the developers receive
training in the activities of the next phase, and set intermediate
goals for the team. Clarify any changes that have been made to
the development plan. While senior developers are finishing up
the current phase, get junior members of the team started on the
next phase's activities.

4
 Section 10 - Keys to Success

• Foster a team spirit. Projects may include people from

different organizations or companies. Maximize commonality
and minimize differences among project members in all aspects
DOs of organization and management. Clearly define and
communicate the roles of individuals and teams, but provide an
overall project focus. Cross-train as much as possible. Hold
combined team meetings so that everyone gets the same story.
Have everyone follow the same rules. Report progress on a
project level as well as a team level. Struggle through
difficulties and celebrate successes together as a unit, helping
and applauding each other along the way.
• Start the project with a small senior staff. A small group of
experienced senior people, who will be team leaders during the
remainder of the project, should be involved from the beginning
to determine the approach to the project, to set priorities and
organize the work, to establish reasonable schedules, and to
prepare the software development plan. Ensure that a plan is in
place before staffing up with junior personnel.

Eight DON'Ts for Project Success

• Don't allow team members to proceed in an undisciplined

DON'Ts manner. Developing reliable, high-quality software at low cost
is not a creative art; it is a disciplined application of a set of
defined principles, methods, practices, and techniques. Be sure
the team understands the methodology they are to follow and
how they are to apply it on the project. Provide training in
specific methods and techniques.
• Don't set unreasonable goals. Setting unrealistic goals is
worse than not setting any. Likewise, it is unreasonable to hold
project personnel to commitments that have become impossible.
Either of these situations tends to demotivate the team. Work
with the team to set reasonable, yet challenging, intermediate
goals and schedules. Success leads to more success. Setting
solid reachable goals early in the project usually leads to
continued success.
• Don't implement changes without assessing their impact and
obtaining proper approval. Estimate the cost and schedule
impact of each change to requirements and specifications, even if
the project can absorb it. Little changes add up over time. Set
priorities based on budget and schedule constraints. Explore
options with the change originator. In cases where changes or
corrections are proposed during walk-throughs, document the
proposed changes in the minutes but do not implement them
until a formal approved specification modification is received.

5
Section 10 - Keys to Success

• Don't "gold plate". Implement only what is required. Often

developers and analysts think of additional "little" capabilities or
changes that would make the system better in their view. Again,
these little items add up over time and can cause a delay in the DON'Ts
schedule. In addition, deviations from the approved design may
not satisfy the requirements.

• Don't overstaff, especially early in the project. Bring people

onto the project only when there is productive work for them to
do. A small senior team is best equipped to organize and
determine the direction of the project at the beginning.
However, be careful to provide adequate staff for a thorough
requirements analysis. Early in the project, when there are
mostly 'soft' products (e.g., requirements analysis and design
reports), it is often hard to gauge the depth of understanding of
the team. Be sure the project has enough of the right people to
get off to a good start.

• Don't assume that an intermediate schedule slippage can be

absorbed later. Managers and overly optimistic developers tend
to assume that the team will be more productive later on in a
phase. The productivity of the team will not change appreciably
as the project approaches completion of a phase, especially in the
later development phases when the process is more sequential.
Since little can be done to compress the schedule during the later
life cycle phases, adjust the delivery schedule or assign
additional senior personnel to the project as soon as this problem
is detected.

Likewise, don't assume that late pieces of design or code will fit
into the system with less integration effort than the other parts of
the system required. The developers' work will not be of higher
quality later in the project than it was earlier.

• Don't relax standards in an attempt to reduce costs. Relaxing

standards in an attempt to meet a near-term deadline tends to
lower the quality of intermediate products and leads to more
rework later in the life cycle. It also sends the message to the
team that schedules are more important than quality.

• Don't assume that a large amount of documentation ensures

success. Each phase of the life cycle does not necessarily
require a formally produced document to provide a clear starting
point for the next phase. Determine the level of formality and
amount of detail required in the documentation based on the
project size, life cycle duration, and lifetime of the system.