An enlightened look at the key factors which make project teams successful. Originally written by Russ Finney for The Quality Observer.

What makes a winning technical project
team? A quick look at some of the factors which seem to be consistently present
on winning project teams is appropriate. The degree of attention paid to each
can have a distinct impact on the success of the project as well as elevating
the confidence of the business client.

System Building Competence

This is absolutely critical. The ability to succeed is established within the
minds of the clients as well as the project team members in the early stages of
the effort. An essential component of this perception is both the management
ability, the technical skills, and the sense of direction possessed by the
project leadership. Both the business clients and the team can detect fairly
quickly if the project leaders have "what it takes" to take them to a final
product. Without question this feeling has a tremendous impact on
morale.

Humphrey Watts in his book Managing the Software Process, describes a
model for measuring the maturity of a software development organization. These
ideas were further refined by the Software Engineering Institute (SEI) at
Carnegie Mellon University. A brief summary of the maturity levels of the model
(in terminology which will relate to some of the central themes of this white
paper) are presented below:

Initial Level

A team or organization at this level tends to take a chaotic, ad-hoc, "invent
as we go" approach toward every new systems building effort.

Repeatable Level

A team or organization at this level uses planning techniques, gathers
requirements in a systematic fashion, utilizes software quality assurance
techniques, and follows a patterned approach on each subsequent effort.

Defined Level

A team or organization at this level follows defined methodological steps,
uses process improvement techniques to enhance the methodological
approach, conducts regular training programs, views the entire systems
development process from an integration perspective, and utilizes more
disciplined information engineering and structured development techniques.

Managed Level

A team or organization at this level actually captures and utilizes software
development metrics for future estimation and process analysis purposes. In
addition, some of concepts of Total Quality Management (TQM) are employed to
reinforce the effectiveness of the entire development process.

Optimized Level

A team or organization at this level utilizes continuous organizational
change management techniques to optimize its own operations (as well as the
company's), emphasizes defect prevention rather than defect detection, and
constantly seeks technological innovation opportunities.

Project Team Experience

Even within organizations with high success rates, one factor which never
changes on each new effort is the amount of experience possessed by the chosen
project team members. Will the project team include a business expert? If not,
will the assigned members be able to effectively comprehend and discuss
the business requirements and issues in the client terminology? Having someone
on the team (even if only in the initial phases) who understands the business is
a great confidence builder! It allows the analysts and designers to ask the dumb
or simplistic questions to someone other than the client. This actually makes
more effective use of everyone's time and it adds an subsequent level of
security. In addition, it puts someone in the position of making sure that
"creative thinking" stays within reasonable boundaries.

What about technical expertise? Is the project entering uncharted waters
without a guide? Having someone on the team who is familiar with the specialized
knowledge surrounding a selected technological environment provides the same
confidence creating benefits as those listed above. A technical expert can
assist others, make suggestions, develop standards, and prevent time consuming
mistakes. In addition, he or she can provide leadership by example. By
spearheading the work and creating examples for others, a technical expert can
transfer knowledge and experience in a timely and effective manner. The prevents
the "invent as we go" situation teams often find themselves in when embarking on
a new technology.

Project Control and Coordination

Large, complex undertakings which require the participation of many people
throughout the development process, demand both high-level and detailed
guidelines to assist in the channeling of the individual results into an
integrated final product. As each person focuses on his or her's part of
the system, a clearly defined set of standards and specifications must exist
insure that the final result will "mesh" with the results being produced by
others. In many ways, a systems building project can be thought of a series of
specifications, each level spiraling from broad requirements into highly
detailed procedural instructions. The collection of these efforts into a unified
whole presents the ultimate challenge for the group. What are some of the ways
to successfully make this happen?

Ultimately, three major factors contribute to the level of success that
systems building team will enjoy at each of the required integration points. One
of these factors is the creation of "consistency" standards. During each phase,
guidelines should be developed for both the content as well as the
format of the final work products. A second important factor is
cross-team communication. Common requirements, similar issues, shared
data, and reusable functionality all should be openly discussed and coordinated.
Sub-teams should participate in the development of overall high level
shared goals and objectives which encourage cross-team interaction and
decision making. A third factor is the insistence on the part of the top team
leadership that individual and sub-team successes be innertwined.
Consistent deliverable, quality assurance, methodological, and review standards
must apply to all team members equally.

Team Goals and Individual Objectives

A project team seems to develop a unique "personality" over time. It becomes
a reflection of everyone involved, radiating confidence and certainty if spirits
are high, seething with doubts and confusion when direction is lacking. How can
project dynamics be so different from one team to the next? Leadership certainly
plays a vital role, but individual team member attitudes make the
difference.

Two fundamental questions illuminate the spirit of the group effort. First,
is everyone on the team driving toward a well defined and articulative
objective? Second, whose objective is it? An amazing thing can happen on
development projects; everyone is busily working away on whatever it is that
they individually perceive as his or her's most important tasks.
Hopefully, each person's work will mesh with the rest of the group's results.
This will probably happen if everyone clearly and precisely understands the
ultimate phase objectives. But what if they don't?

This is where human nature begins to step in and things can begin to get
interesting. If the attitudes of the team members tend to be goal driven (which
is good) but the team leadership is fuzzy about what the objectives really are
(which is bad), individual and sometimes scattered goals begin to pop up. Unique
and potentially conflicting agendas take shape. Before you know it everyone is
busily working away and the atmosphere appears to be productive. But an
time of reconciliation lies ahead. At some point the individual results must be
combined, and depending on the fit, the attitude of the team will ultimately be
affected. The group's mission or purpose at this point becomes very real,
because it is at this moment that the team realizes that there may not have
really been a common direction in the first place, and that fact is painfully
obvious.

Why even take this risk? Insuring that goals and objectives are clearly
spelled out, and the activities and tasks which will be followed to ultimately
reach them are uniformly understood, will only give the team a shared sense
of purpose. Everyone needs to have a stake in, and a share of, the
responsibility for the outcome of each phase. Doing this can have an incredible
impact on people's attitudes. Clearly comprehending the relevance of the work
and how it will contribute to the final product, is a powerful motivator for
creating an air of cooperation and open channels of communication between team
members. Individual goals can be visualized as a part of the larger team
objectives. The goal driven attitude of the team will truly be reflected
in the quality of the results.

Systems Building Vision

A "vision" doesn't do anyone any good if it is only in one person's head.
Only when it has been absorbed and adopted by the team does its usefulness begin
to emerge. A business or system "visionary" plays an important yet sometimes
unenviable role in making this happen. His or her willingness to share insight
and understanding of a situation, and the necessary steps he or she envisions to
arrive at a desired outcome, tend to be dependant on two factors: the level of
confidence he or she has in the ideas, and his or her tolerance for scrutiny and
criticism. Regardless of these personal risks, a professional system
builder must strive to be a system "visionary". With each passing phase of the
project, he or she must constantly develop and communicate his or her vision of
both the system functionality and the project approach.

Putting forward this vision assists in accomplishing two important results.
First, it creates a baseline foundation for continuing discussion. In
many cases, the original system/approach vision may not survive for long as
better ideas are presented and improvement discussions occur. Second, the vision
promotes constructive, critical thinking.

People tend to provide more input in a "review and improve" mode rather than
a "create from scratch" mode. The presentation of a baseline vision stimulates
this process. In addition, if the "visionary" can relinquish ownership of the
original idea, and subsequently encourage it to become the property of the
group, the effectiveness of the process can be even more enhanced. The system
builder serves to plant the "starting point" ideas, and the team members and
business clients assist with, and take responsibility for, the ultimate
direction and composition of the shared vision.

Project Team Confidence

Another important team attitude is confidence. The development of a complex
system presents tremendous challenges to a project team. Sometimes it can even
feel like an act of faith. An enormous amount of detail is collected,
analyzed, organized, and assimilated into a functional "whole". On very large
efforts, only a few key individuals may possess the total "big picture", and
this may be at varying levels of completeness. This ambiguity can from time to
time test the confidence of the project team members. Given these uncertainties,
how does a team feel assured and confident of success throughout the process,
and have this reflected in the individual team member attitudes?

Clearly, the realization on the part of the team, that a system design is
formed as a gradually evolving solution, from a process which tends to be
iterative in nature, helps everyone to be patient with the slowly disappearing
level of ambiguity. The more team members who participate on the project who
have been through the complete system building life cycle, the more
likely the overall team awareness will be that everything will come together at
each major milestone. This is an important confidence builder for the less
experienced members of the team. The higher the level of confidence possessed by
the team, the more secure the business clients feel, and the more likely the
team will actually "see" themselves succeeding, even in the face of the unknown.