1. Simple writing sample Carol Gunderson Harris gundersonemail@aol.com 05/13/2015
Integrating Project Management Project Phases and Tuckman’s Teamwork
Phases for Software Development Teams
This document provides a simple example of each managerial view of a typical project – the Tuckman’s
Teamwork view, and the traditional project phase view of a project for an SDLC software development
project. Project managers also refer to the motivations of the team members, based on Maslow’s Hierarchy
of needs. The reporting manager, refers to the motivations of the team members, based on the Tuckman
model phases.
When reporting managers speak with project managers about project phases and how to assist the team, the
terminology is confusing, because terms ‘phase’ and ‘motivation’ are used by each manager in a different
way. The reporting manager refers to Tuckman’s team phases, where phases are based on the interactions
between the team members, which changes with team member experience working together. The project
manager refers to project phases, determined by the ‘deliverables’, or work items that the team needs to
complete, to be successful for the project.
Tuckman’s Teamwork Phases
The reporting manager is usually referring to Tuckman’s
teamwork phases. Tuckman’s teamork phases are one view of
the current workflow for the team for a particular project, based
on the social dynamics between team members. For example,
new teams, in the Tuckman Stage of “Forming”, have
dymanics based on lack of experience between the team
members. The team members are working on defining and
negotiating their expectations with each other, based on the
team member strengths, and skill deficits. The current project
performance is improved by managing the issues, depending on
which phase the team is in at that time. A team in the
‘forming’ stage, benefits from different type of managerial
assistance, than a team in the ‘storming’phase. Tuckman’s
Teamwork phases include the Forming Phase, the Norming
Phase, the Storming Phase, the Performing Phase, and the
Mourning Phase.
The Project Management Project Phases View of a Project – An SDLC example
The project manager, in contrast, is referring to the Project managerment project phases. The project phases,
are a different managerial view of the same team, working on the same project. The project phases are
based on which deliverables the team is creating for the project. A team in the ‘requirements gathering’
project phase, benefits from different types of managerial assistance, than a team in the ‘testing’ project
phase. If the managers understand the team work phase issues and the project management phase issues for
this particular team, they can often improve team project performance by understanding the team from both
perspectives.
Project management project phases, are traditionally broken down into a list called the list of deliverables,
that are required, set on a timeline for the project to e successful. Let’s call them, work items A, B, C, and

2. 2
D. A simple timeline might have work item A, due in January, item B due in March, and items C and D
due in April. This timeline, and the related deliverables for the project, often have particular standardized
terms, depending on the type of project. We will use a typical example, to demonstrate the differenct
between the project phases, and the team work phases. This can be displayed on a traditional Gannt chart,
often in Microsoft Project.
Software Project Example using a Waterfall Software Project Management Strategy (SDLC), with a
maintenance process
Figure 1. Project Phases – Traditional Waterfall Model
This is an example of the ‘deliverables’ for the same project. Each phase listed above, may have many
deliverables – specific items that are required to complete the work for that phase.
Many project teams use a consitent set of templates or processes for similar deliverables, such as the Rational
Unified process documents, used at IBM. This is a generic list of deliverables documents. A company may
have specific requirements for exactly how each delierable must be created.
A sample list of deliverables:
Software
Specification
•Specification and
Design
Documents
Design
•Approved?
Code •Approved?
Test
•Approved?
Deploy
Maintain

3. 3
Specify and
Design the
Software
Write and
Debug the
Software
Test the
Software
Deliver the
Software
Prioritize
updates
needed
1. Software Specification Documents (‘’User Stories” is an example.)
2. Software Design Documents
3. Stage gate: Stakeholder Approval Document
4. Software Development and Documentation (software deliverables)
5. Software Testing (Test plans, Tests, and Test results documents)
6. Stakeholder approval for roll out to Select clients (Beta clients)
7. Beta roll out to test clients (Implementation Plans and Lessons Learned)
8. User Acceptance Testing Documents (at the Beta sites)
9. Software Maintenance Plans and List of defects
10. Gap analysis: New Features List - What new features are possible?
11. List of selected items from Step 9 and 10, defects and features, called the Backlog list
12. Set priorities for the backlog from Step 11. Select a list of items to address, and return to Step 1,
for development to start for this set of items. (This Set of items is for the next release of the
software).
In waterfall software development, theoretically, each phase is completed before the next phase starts. For
example, all of the design and specifications, are completed before the software development begins. In
production, this rarely happens. The model, does not really include all that happens in a real company, really
delivering software. The model is still useful, because it provides a framework to understand the needs of
the people currently working on that phase, and provides a framework to create and improve the processes at
the company, for each phase.
In practice, the rule that all software design preceeds all development, usually applies only if you look at a
single software feature. For example, if the goal is to complete two new features, such as 1) add new fields
to our invoices, and 2) add new reports about
customer use of our website not related to invoices,
these are two independent features. They can be
completed in any order. The work for each feature
is designed, in the ‘Software Specification and
Design’ phase, before the software is written.
Different features of the software may be in
different phases, at any given time. Test cases,
can be written before the software is developed,
and can help identify problems with the
specifications. This is because a test case can only
be written if the specification is complete,
including the details that will be needed by the
software developers to complete the software
development.
In pure Agile development, there are short development cycles, called sprints, where a small set of features
is developed and tested, and added to the current software development project. This partial solution is used
to get feedback from the user, early in the development cycle. Features are developed and added to the
current softare, in priority order. The software team can quickly change from one software goal to another,
because the sprints are short.
Since IT Software development projects have a very high level of failure, based on success criteria, of
delivering the software within the project timeline, and on budget, project managers have studied the project
management processes and the team work management processes. Project managers also consider the
motivation for each individual’s behavior, for the project.
This is usually described with Maslow’s hierachy of needs. (See Figure 3).
Figure 2 Concurrent Software Development

4. 4
Performing
High Performing
Announce End
Mourning
0
50
100
150
200
250
300
Self Actualization
Esteem
Social
Security
Physical
When a project manager joins a software development team, they assess the project team phase. According
to the Tuckman view, the team is in one of the following phases:
1. The Forming Teamwork Phase
2. The Norming Teamwork Phase
3. The Performing Teamwork Phase
4. The Storming Teamwork Phase
5. The Mourning Teamwork Phase
Each team, may have a different mix of motivations for the team members. For one example, please see
figure 3. Software development teams often gain or lose team members across the lifetime of the project. A
project, in the ‘performing’ phase, may loose team members, as the project scales down. This is one
example, of how the Maslow motivational hierarchy and project performance, may change as the project
loses team members near the end of the project.
In the Forming stage, the team is new. The team members are starting to understand what the team must
accomplish for the project to be successful.
Because the team has not worked together before, each member is forming expectations. “What can I expect
when these people are assigned work that needs to be completed? Will it be high quality? Will it arrive on
time?’ Each team member, has different feelings, motivations, and background that he brings to the team.
In the Norming Stage, the team members have some experience with working together. From this limited
experience, they trust the other team members for those items they have seen the team members complete
effectively. They have worked out the communication plans for the team, and understand who is assigned
which work items. Even if a team member is not happy with the assignements, or results, there is an
acceptance of the status quo - “this is how this process works at this company at this time’’.
In the performing stage, the team has started working together to accomplish the work items for the project.
Since the processes they follow are now familiar, they put most of their effort in completing work items.
Team performance varies, from high performing teams, to poorly performing teams. There are a variety of
reasons for the difference in team performance.
In the Teamwork Storming Phase, there is conflict, within the team. This can happen at any time, for the
team. Often, the conflicts occur as members of the team work out new compromises, about team task
assignments, and team processes. Simply put, they argue over who is responsible for what tasks and
processes, and the methods they will use to work together.
Figure 3 Tuckman's Team Phases versus Maslow's Performance

5. 5
In some corporate and world cultures, there is a negative association with conflict, and team storming.
Conflict is not confortable for all team members. During team storming, sometimes performance is not as
high. After storming, the team often makes changes. This may result in better or worse, team performance.
A classic example, is a team member who is very quiet, and hesitant to bring up changes to the team, even
though these changes would save money and effort, for the project. The team member has a reason for this,
such as roles - ‘it is not my job to change the project assignments – I am not a manager’. When the quiet
team member finally shares the useful information, the change makes the project more successful, but the
resulting changes may upset other people on the team. Another source of conflict is the acceptable methods
of conflict. For Asian teams, some cultures believe that a loud, direct conflict causes the team member to
‘lose face’ and status on the team, based on intercultural corporate training. The savvy manager will be
aware of this, and provide the opportunity for all team members to provide feedback to the team.
(This is a partial document, to illustrate some basic topics for project managers in Software development.)
Appendix
Table of Figures
Figure 1. Project Phases – Traditional Waterfall Model.........................................................................................2
Figure 2 Concurrent Software Development..........................................................................................................3
Figure 3 Tuckman's Team Phases versus Maslow's Performance ..........................................................................4