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

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

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

PerformingHigh Performing

Announce EndMourning

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

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