team neula – project plan
TRANSCRIPT
TKK
Team Neula –
Project Plan Software development project – Suunto web 2.0
team Neula
10/19/2008
Team Neula – Project Plan
Page 2
VERSION CONTROL
Version Date Author Description
beta 1.10.2009 Seppälä First draft
1.0 8.10.2008 Seppälä First Finished
1.1 16.10.2008 Häppölä A bit QA documentation and some other additions
1.2 16.10.2008 All Revisions
2.0 17.10.2008 Seppälä Made changes according to feedback
2.1 18.10.2008 Seppälä,
Palomäki Additions and revisions
2.2 19.10.2009 Seppälä Final format
CONTENTS Version control ................................................................................................................................................ 2
1. Introduction .................................................................................................................................................... 4
Background ...................................................................................................................................................... 4
Our Mission ...................................................................................................................................................... 4
The outcome .................................................................................................................................................... 5
2. Stakeholders, staffing and relations ............................................................................................................... 6
Suunto users .................................................................................................................................................... 7
Suunto .............................................................................................................................................................. 7
Neula Team ...................................................................................................................................................... 7
Web page ......................................................................................................................................................... 8
Skills, roles and commitments...................................................................................................................... 8
3. Goals .............................................................................................................................................................. 10
3.1 Project goals............................................................................................................................................. 10
3.2 Personal learning goals ............................................................................................................................ 11
4. Resources and budget ................................................................................................................................... 12
4.1 Personnel ................................................................................................................................................. 12
Team Neula – Project Plan
Page 3
4.2 Materials .................................................................................................................................................. 13
4.2.1 Hardware ........................................................................................................................................... 13
4.2.2 Software ............................................................................................................................................ 13
4.3 Budget ...................................................................................................................................................... 14
5. Work practices and tools .............................................................................................................................. 15
5.1 Practices ................................................................................................................................................... 15
5.1.1 Iterative development ....................................................................................................................... 15
5.1.2 Iteration planning .............................................................................................................................. 15
5.1.3 Documenting ..................................................................................................................................... 16
5.1.4 Risk management .............................................................................................................................. 16
5.1.5 Time tracking ..................................................................................................................................... 16
5.1.6 Communication ................................................................................................................................. 17
5.1.7 Iteration demo................................................................................................................................... 18
5.1.8 Defect tracking .................................................................................................................................. 18
5.1.9 Version control .................................................................................................................................. 18
5.1.10 Coding conventions ......................................................................................................................... 18
5.1.11 Process improvement ..................................................................................................................... 19
5.1.12 Requirements engineering .............................................................................................................. 20
5.1.13 Design .............................................................................................................................................. 21
5.2 Quality assurance plan ............................................................................................................................. 22
5.2.1 Main quality goals ............................................................................................................................. 22
5.2.2 QA methodology and practices ......................................................................................................... 23
5.2.3 QA tools and material ....................................................................................................................... 23
5.3 Tools ......................................................................................................................................................... 23
5.4 Standards .............................................................................................................................................. 24
6. Phasing .......................................................................................................................................................... 24
6.1 Schedule ................................................................................................................................................... 24
6.2 Project Planning ....................................................................................................................................... 25
6.3 Implementation 1 .................................................................................................................................... 26
6.4 Implementation 2 .................................................................................................................................... 26
7. Risk log .......................................................................................................................................................... 27
Team Neula – Project Plan
Page 4
1. INTRODUCTION
BACKGROUND
The web and the communities on the web offer new opportunities for almost all companies, especially
consumer products companies. Suunto is the world leader in sports instruments in their segments, and the
web offers ample opportunities for Suunto to increase their brand knowledge and offer value to their
customers - existing and future.
Suunto already offers its customers the ability to analyze the data collected by their Suunto device on the
computer. Suunto also has a a web community up and running (www.suuntosports.com). Now Suunto is
planning to add value to their customers and increase the knowledge on Suunto by providing web
applications and gadgets that use the collected information.
The goal is to enable the users to have a new way of accessing, sharing and presenting their information. In
addition, Suunto is also planning on offering interfaces for developers. Developers will be able to develop
their own applications and mashups that use information on sports activities collected by a Suunto device.
Top three reasons the project has been started:
Usability – Increased value for customers
Brand recognition
Development of new services
OUR MISSION
Our mission is to kick start the development of Suunto applications & gadgets. We will create several
commercial quality applications that can be used as is or developed further. We will also develop non-
commercial quality applications with working functionality to try out the possibilities of the Suunto
Team Neula – Project Plan
Page 5
interfaces and the platforms. The main objective of the applications developed by our team is for internal
marketing at Suunto, developing the first exciting applications that can be taken into use by Suunto users
and to test out the Suunto interfaces. In the same time we will also be increasing Suunto's knowledge of
the web 2.0 technologies and how they can fit their future plans.
THE OUTCOME
At the end of the project, Suunto will be the owner of applications with full documentation that can be
deployed on the web. The applications will offer users new opportunities to present, share and compare
their data. In addition, Suunto's knowledge on web technologies will be improved by documentation of the
technologies used and their requirements. After the project Suunto will be able to make better decisions on
how and where to develop their web strategy.
Team Neula – Project Plan
Page 6
2. STAKEHOLDERS , STAFFING AND RELATIONS
The following picture depicts the structure of stakeholders that influences the project. The users are
central, as they are the end users of the applications developed. There are several software vendors and
our server provider that might influence our project, but our control over their influence is minimal, which
is why their influence is left to the level of recognizing them.
Team Neula – Project Plan
Page 7
SUUNTO USERS
The most important stakeholder for the project are Suunto's users. If the project can fulfill their
requirements and we can create something successful that can be developed further, we will have reached
our goals. However, the medium through which the validation of our success in the user dimension will be
evaluated by Suunto. Thus we will be in close contact with Suunto to make sure that we are doing the right
thing. Suunto is our best contact to Suunto customers. The process can be seen as two-directional since
Suunto can leverage our experience as users and get our feedback and ideas concerning the solutions.
SUUNTO
There are three distinct departments of Suunto that contribute to the project :
User experience
Product Management
IT
Design
Suunto's organization supports our project for the whole scale of activities. Product management and User
experience support the creation of ideas and validating our prototypes. IT supports our development work
and provides the interfaces. And design supports the graphical aspect of our work.
NEULA TEAM
The Neula team consists of three Software engineering experts and five developers. The team generates
ideas with Suunto and within the team, refines the ideas to product prototypes, chooses the products to
implement and takes ownership of the implementation from designs to testing with the support of the
Suunto organization. Contact details and roles:
Team Neula – Project Plan
Page 8
WEB PAGE
The web page of the team communicates current issues we are working on and time spent on the project.
The public web page of the team can be accessed at:
https://wiki.tkk.fi/display/Neula/Neula+-+Suunto+2.0+web
In addition to this wiki, for internal communications and general project management, the team uses a
web-based project management tool, Zoho projects. The project management tool is only accessible to
Neula, Suunto and our mentor.
SKILLS , R OLES AND CO MMIT MENT S
Several of our team members have special roles on the team. The roles have been assigned according to
the skills and learning goals of the team members. In addition to being part of a primary team where the
team-member can apply his best skills, each is also part of another team, for learning purposes.
Neula has been divided into five teams:
Project Management - Riku Seppälä
Design and requirements - Dani Pärnänen
Quality assurance and testing - Paavo Häppölä
Architecture - Eero Palomäki
Infrastructure - Lauri Hukkanen
In these teams, the issues are worked on together. In addition, each team has a responsible team-member
who has been chosen according to skills and interests.
Team Neula – Project Plan
Page 9
TABLE 1 TEAMS AND ROLES
Name
Primary Learning
Goals Skills Primary Team
Learning
Team Responsible for
Riku Seppälä
Development infrastructure,
innnovation,
design
Web 2.0 Technologies,
Project Management
Project Management,
Design and
requirements Architecture
Communications,
Client's Requirements
Paavo Häppölä
Quality and testing processes,
technologies
Quality Assurance,
Testing methods, Project
Management
Quality Assurance and
Testing Architecture Testing
Eero Palomäki
Agile management, Web 2.0
architectures
Web 2.0 Technologies,
Servers, Testing Tools
and Methods
Architecture,
Infrastructure Project Management Architecture
Ville Harvala
Web 2.0 Technologies,
Server,
Requirements elicitation Technologies Architecture
Infrastructure,
Design and
requirements
Documentation of
Technologies
Lauri Hukkanen
Project management,
Requirements elicitation Web Servers Infrastructure
Project
Management, Design
and requirements Server, Infrastructure
Ohto Rainio Project management, tools Web technologies Architecture Project Management Technology choices
Lasse Hakulinen
Project management, tools,
Suunto QA practices
Quality Assurance and
Testing
Project
Management, Design
and requirements Quality practices
Dani Pärnänen
Web 2.0 Technologies, SE
practices Architectures, Design
Design and
requirements
Quality Assurance
and Testing
Communications,
Design
Team Neula – Project Plan
Page
10
3. GOALS
3.1 PROJECT GOALS
These tangible goals have been derived from the business goals of Suunto and set by Suunto for the project.
Goal Verification criteria
1. Sufficient amount of applications 5 of "commercial quality", 10 of "working
functionality" and any number of prototypes.
2. Sufficient quality
Commercial quality: Thoroughly tested, finalized
and well-documented functionality
Working functionality: Completed functionality,
can include minor documented defects
Prototypes: Incomplete functionality, can be
used to demonstrate an idea
3. Platform compatibility
At least iGoogle, Vista and OpenSocial supported
gadgets of "commercial quality"
Facebook and email signature supported gadgets
of "working functionality"
1 Other platform supported by a prototype
4. Language support
Easy localization support for "commercial
quality" and "working functionality" gadgets
No requirements for prototypes.
5. Visual
"Commercial quality" gadgets are visually
attractive and finalized and follow the Suunto
brand guidelines.
"Working functionality" gadgets are visually
attractive but don't need to be finalized
No requirements for prototypes
Team Neula – Project Plan
Page
11
3.2 PERSONAL LEARNING GOA LS
The personal learning goals have been set by the team-members according to the following table
TABLE 2 PERSONAL LEARNING GOALS
Name Personal Learning Goals
Riku Seppälä
I'm very interested in learning about what technologies and infrastructure is needed for web 2.0
development. In addition, innovating for sports is very interesting and I would like to learn how we can
tap the innovativeness of our team and use the expertise of Suunto to support this
Paavo Häppölä
I would like to learn how to efficiently run quality and testing processes that I have learnt. In addition, I'm
interested in learning more about web 2.0 technologies and the architecture of gadgets
Eero Palomäki
I am looking forward to improve my knowledge of the architectures of web2.0-applications and gadgets.
In addition I hope to improve my skills in managing and working with a group of specialists,
communicating clearly and to catch a thing or two about new tools available for software development
with agile methods.
Ville Harvala
I would like to learn at least the basics of the platforms we are going to develop on. Some of these
applications will need a server to run on, and I'm also very interested in how to deploy the servers, for
example how to install CVS, MySQL and PHP. I also want to see how requirements elicitation will work in
a project like this and I believe it will also be interesting to learn how to handle the customer relationship
well.
Lauri
Hukkanen
I hope that I will have got practical experience on how a bigger software project is handled. I'm especially
interested in the requirements and how they are turned into reality. Also the development of the work
and communications processes will be interesting to learn from.
Ohto Rainio
My goal is to develop my technical my technical skills and also my view on how IT-projects and the
problems and risks should be handled. I'm interested to learn form the work practices a team that doesn't
know each other from before develops. I believe I will learn good processes and tools that are needed in
this kind of broader project. I'm also interested to learn from the interaction between Suunto and the
team and what kind of communication can work.
Lasse
Hakulinen
Learning new techniques and frameworks and deepening my current knowledge. Learning good work
practices for working in a team. Applying software methods in practice. Getting familiar with Suunto and
how they work.
Dani Pärnänen
Developing Widget/Gadget/Application -type of small programs. Learning to use web 2.0 interfaces and
API:s, maybe even some mash-up techniques. Learning about the management of a big team (8 + key
stakeholders from the customer): How the roles are setup so that they work, how I can be efficient and
stay in my role. Using SE methods in practice: defining, designing, follow-up and iterations. Learning from
the right kind of communication between the team and the customer and inside the team.
Team Neula – Project Plan
Page
12
4. RESOURCES AND BUDGET
4.1 PERSONNEL
Word Scheduled per week per person. The vacation is held between week 50 and week 3. The planning
couldn't be made according to task since the gadgets to be implemented haven't been chosen yet and the
tasks haven’t been created.
Team Neula – Project Plan
Page
13
EXHIBIT 1A CHART OF WORK SCHEDULED AND WORK PERFORMED WHICH WILL BE FOLLOWED THROUGHOUT THE PROJECT.
4.2 MATERIALS
4.2.1 HARDWAR E
We are using computers accessible to Students at the Helsinki University of Technology. In addition to the
computers, a server has been rented by Suunto for our development use.
4.2.2 SOFTW AR E
The Software we are using is open source an readily available from the web. In order to be able to do the
development the following platforms and supports have been installed on the development server:
PHP support
Bugzilla
CVS
Java support
Debian Linux (4.0)
The development environment we use is Eclipse and the Operating System Windows. These are provided by
TKK, Helsinki University of Technology. More details in the tools section (5.3)
Team Neula – Project Plan
Page
14
4.3 BUDGET
The budget was calculated according to the discussions with Suunto.
Team Neula – Project Plan
Page
15
5. WORK PRACTICES AND TOOLS
5.1 PRACTICES
5.1.1 ITER ATIV E DEV ELOP MENT
For the team, the iterations are divided into weeks. We have working time scheduled every tuesday from
10-16 and every friday from 10-16. Every friday we also have a compulsory meeting from 8.30-10 when the
passed weeks developments, problems and further development is discussed. The team will be mostly
working in the planned working hours together in the room we have booked.
SPRIN TS
The two iterations are each divided into three sprints: Sprints 1 - 6. In the beginning of the iteration, a
ranking of the prototype description of gadgets to be developed is set with the client. On the basis of this
ranking order the architectural design is done and a tasks created. The tasks are then set for each sprint.
After each sprint we can analyze how well we have reached the targets together with the client. New
prototype descriptions are also presented, analyzed and added to the ranking. We have set meetings at the
beginning and end of each iteration and after each sprint (5 meetings per iteration). Additional
"brainstorming" meetings regarding the gadgets to be developed can and probably will also be arranged.
The requirements analysis is done at the end of each sprint and beginning of each new sprint and with the
meeting with the client will take about 6 hours of everyone’s working time. In the end of the requirements
analysis, the prototype descriptions (see exhibit 1 for an example) are updated. After, the architectural
design is updated and the coding and testing practices begin. The testing is done by Suunto and by the team
whenever a new increment is made to the gadget. This is made possible since the development platforms
allow us to publish even gadgets under development. The gadgets can be tested on the web.
5.1.2 ITER ATION P LAN NING
Iteration planning is done at the end of the previous iteration and the beginning of the new one. This
always includes the iteration demo, after which the next iteration is planned with the client. After this initial
meeting another meeting is planned in one week, when the initial backlog of gadgets is set. The scheduling
and task setting can be done at the same time, so the iteration document will always be planned and
documented for the course deadline. The iteration plan, with tasks and deadlines is then transferred to
Zoho projects.
Team Neula – Project Plan
Page
16
5.1.3 DO CUMENTIN G
The project manager is responsible for document deadlines. He is also responsible for the documentation of
technologies for the client. One review is required for each document, and usually performed by the
architect or the QA manager. The documents are all presented to the team at the weekly meetings and
most important parts also updated to the teams project management environment (zoho projects).
5.1.4 R I SK MAN AGEMENT
Risks are discussed with the client and elaborated within the team in the planning phase of each iteration
and the reflection workshops. The best risk identifiers we have used are the project reports from previous
year’s projects. Also the risks identified by our client are important. The risks are documented in a risk log
and monitored by the QA manager. For all the risks with negative impact on the project, the way to
minimize the risk is documented and implemented. In addition, a contingency plan for each risk is crafted.
5.1.5 T I ME T RACKIN G
The time tracking is done in the project management environment. There is ready support for
communication and time tracking in zoho projects. After each working phase, each team-member will
update their time log. Once per week the time log is also uploaded to the wiki. In the wiki, the time logs are
analyzed according to work realized compared to work scheduled for each team member and the whole
team. In this way it is easy for the team and all stakeholders to monitor how much effort has been made.
When the programming starts, a similar log for work performed and work scheduled will be made for tasks.
This will enable the client and the team to easily follow up on the status of the progress.
Team Neula – Project Plan
Page
17
5.1.6 CO MMUNI CATION
The team has two set working times per week, and the team will mostly be working at these times as
agreed. Communication is planned by the project manager so that all known issues can be addressed at the
meetings. In addition, each Friday starts off with a meeting where current issues are addressed, and the
most important decisions are made. We will go through what has been done, what will be done, and what
problems have occurred. After each meeting the status is reported to the mentor and the client. Other
communication channels used by the team are:
o For information that needs response for everyone on the team. Response is requested in the
mail and if it is not received the person will be approached by phone or in person.
IRC
o Mainly for communication during development, when someone wants feedback on
something.
Telephone
o For specific questions to specific persons
Forum in zoho projects
o The forum is used for general non-critical notifications that don't require responses.
The communication with the mentor is done through weekly mails and other mails on important issues. The
mentor is also always invited to the weekly meetings on Fridays at 8.30 and the other scheduled working
times. In addition, other feedback meetings with the mentor will be arranged.
The communication with the client is done mainly through email (weekly mails), the wiki and by telephone
on issues that require feedback. In the wiki we keep updated current issues, time tracking and meeting
memos. In the requirements gathering phase of the iteration, emails and meetings are used. Because the
meetings are at most separated by two weeks, the most important decisions can always be made at a
meeting.
Team Neula – Project Plan
Page
18
5.1.7 ITER ATION DEMO
The demos are prepared by the project manager in collaboration with the project management team. The
project management team takes care of ensuring the software demo.
5.1.8 DEFECT TR ACKIN G
Bugzilla bug tracking system is used to track defects. The status of a defect can be seen from the system.
The peer group is allowed access to the system, if the NDA allows it. At least a list of the existing bugs is
provided for the peer group, if possible. Only one defect is described in each defect report. The defects are
used in improving our processes and tools so that defects of the same type could be avoided.
Defect report includes following information:
defect type
description
status
priority (priority types here)
location (url, file)
steps to produce (and repeat)
date
founder
estimated time for fixing expected result
5.1.9 VERSIO N CON TR OL
CVS on our development server is used for version control. All code checked-in should be working and
coded according to the agreed coding conventions. Code should be checked in at least daily. Check-outs can
be done always before the developer starts coding.
5.1.10 CO DIN G CO NVENTIONS
Language
Coding Convention
Natural language in code and comments
English
PHP
http://framework.zend.com/
Javascript http://dojotoolkit.org/developer/StyleGuide
Java http://java.sun.com/docs/codeconv/
Team Neula – Project Plan
Page
19
The code is commented at the same time as it is done, not afterwards. If the code if changed or updated,
the comments are changed as needed. Developers write their names to the author list in each file, so that
questions can be addressed to the right person responsible.
5.1.11 PRO CES S I MPR OVEMENT
Process improvement is arranged by two meetings in each sprint: the feedback meeting with Suunto and a
reflection workshop within the team. The project manager is responsible for process improvement.
Reflection workshops are arranged at end of PP-iteration and after each sprint (three in I1 and three in I2).
The reflection workshops are organized the next tuesday or friday after the sprint meeting with the client.
The reflection workshops use a big whiteboard and everyone from the team should be present. The process
is improved according to the feedback got in the workshop. In addition the customer is asked for feedback
of the process at the meetings which are then discussed at the reflection workshop. In addition to the
workshops, everyone is actively encouraged to give feedback.
The defects from the bugzilla are reviewed at the end of each sprint and the developing practices are
updated so that the same type of bugs could be avoided in the future.
TABLE 3 REFLECTION WORKSHOP W HITEBOARD FORMAT
Team Neula – Project Plan
Page
20
5.1.12 REQUI R EMENT S EN GIN EER IN G
The gadgets to develop require several stages of development:
Ideas
Create gadget prototype descriptions (we use a common format for prototypes, see exhibit 1. for an
example)
Refine the prototype descriptions
Choose the implementable gadgets
Implement the chosen gadgets in the chosen order
Make necessary changes
Refine the design of the gadget
Implement the design of the gadget
The elicitation is done by brainstorming sessions with Suunto and by analyzing competitors' gadgets and
other gadgets not related to the domain. The analysis is done mainly in the team:
1. Discuss the most important outcomes from the brainstorming session
2. Everyone creates a prototype description of a gadget in the predefined form
3. Prototype descriptions are sent to Suunto for checking
4. The prototype descriptions are discussed with the client - changes are made
5. After the analysis phase the validation is made together with the client:
a. The set of prototype descriptions to be developed to gadgets is chosen.
As necessary changes become apparent, the changes are documented in the prototype descriptions. We
have divided the iterations into three sprints, after which we will have a meeting with the client and the
proposed changes will be discussed and documented. These meetings are preceded by communications by
mail of the most important issues regarding the gadgets. The following diagram shows how the
requirements engineering process has been planned.
Team Neula – Project Plan
Page
21
5.1.13 DESI GN
The project architect is responsible of the architectural design. He also has assistants from the architecture
team, that is working with him to design the architecture. The high-level architecture is documented and
communicated with the architecture document. The code level design is done by the developers during
implementation.
As the project is composed of many smaller gadgets, which are defined and planned during the iterations,
the architecture must also be developed constantly on the base of the requirements made for the gadgets.
In the first sprint of Iteration 1 a backlog of gadgets to be developed is set and the architectural design is
done according to work scheduled per gadget. The architecture is done so that the developers can always
easily recognize what gadget and which part should be implemented next. Some of the interface definitions
and authorization solutions will be got from the client only after the first sprint of Iteration 1 has started.
This means the architectural design of the first prototype gadgets is going to be made partly at the end of
Team Neula – Project Plan
Page
22
PP-iteration and partly at the start of I1 sprint 1.These gadgets are developed also to make sure that the
programming environment is working as planned and the coding is ready to start.
The architectural design is always based on the requirements document and the prototype descriptions. All
the concerns of the stakeholders must be considered. Based on the most important concerns, the
architectural requirements are chosen.
5.2 QUALITY ASSURANCE PLAN
THE QUALI TY ASS URANCE PL A N WILL BE EL ABO RA TED I N E ARLY ITE RATION 1, THIS IS AN EARLY
DRAF T .
5.2.1 MAIN Q UALI TY GOALS
As Suunto has large emphasis on innovativeness and our feedback concerning ideas and functional
requirements, the main quality goals in our project are qualitative and derived from business goals below:
1) Create value to existing customers. Value creation to existing customers can be guaranteed through
continious bilateral communication with Suunto and applying their marketing knowledge to practice.
Meanwhile, Suunto also wants us to give feedback as product users as well.
2) Use gadgets as marketing tool to potential new customers. Marketing dimension is achieved by
collaboration with Suunto design team and having emphasis on visualisation, attractiveness and general
usability.
3) To explore new technological possibilities and business opportunities. Development team has to
have open mind and explore different platforms. Risk is to focus too much on competitors' products and
existing solutions. Also feedback from the customer is collected.
Team Neula – Project Plan
Page
23
5.2.2 QA METHO DO LO GY AN D PR AC TI CES
As the project consists of several small mainly autonomous gadgets with simple user functionality, testing is
mainly done at the module level. Functional testing will be carried after completing function as well as at
the end of individual iterations.
After every sprint a prototype is delivered to the customer for commenting and non-formal testing. Suunto
personnel will also get access to bug database to report possible caveats immediately. Also frequent code
reviews and peer-programming will be used to guarantee quality at code level. Access to source code
repository will be given to the customer to make evaluations and give feedback after every sprint.
5.2.3 QA TOOLS AND MATERIAL
The main tool for QA is Bugzilla bug tracker with an integrated test case management suite called Testopia.'
5.3 TOOLS The following tools are used for the project
Team Neula – Project Plan
Page
24
5.4 ST AN DAR DS
Coding convetions, communication standards as described and project management standards from zoho
projects are followed.
6. PHASING
6.1 SCHEDULE
The schedule will be followed according to the following scheduling plan. All meetings for iteration 1 have
been set. The important deadlines and work processes related to requirements and testing can be followed
according to this plan. For a detailed schedule with deadlines, please see exhibit 2.
Week
Requirements
Coding & Testing
Team Workdays
Weekly meetings
Set Customers meetings
Iteration demos
Document deadlines
Peer Testing
Designs for Suunto
Delivery
4843 44 45 46 47 6 7 849 50 51 52 1 2
Sprint 6
10
Iteration 2
9
Iteration 1 Vacation
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
3 4 5
Team Neula – Project Plan
Page
25
6.2 PROJECT PLANNING
GOALS :
Creating the documents
Implementing the required infrastructure
Understanding the problem
Gathering requirements - Creating prototype descriptions
DELIVE RABLES :
project plan (except ch. 5.2 QA Plan)
requirements document without detailed functional and non-functional descriptions
progress report
Tasks:
1. Understanding the problem of the customer
a. Discussion about the problem in general
b. Gathering the ideas of the team concerning the problem
c. Kick-off Meeting with the customer l
2. Defining the requirements to an adequate level as a basis for the requirements document and the
project planning
a. Kick-off meeting with the customer
b. Refining the ideas within the team
c. Freezing the first requirements so the team define the infrastructure needed to start the
development
3. Creating the project plan
a. Finding out everything the customer needs to give input on for the creation of the project
plan
b. Getting the input from the customer for the project plan
c. Writing the document
4. Creating the requirements document except the detailed descriptions
a. Freezing the starting point requirements for the project
b. Creating the prototype descriptions
5. Preparing the iteration demo
Team Neula – Project Plan
Page
26
a. Creating the iteration demo based on the results of the iteration namely:
i. Creating the and implementing the infrastructure necessary to carry out the project
ii. Defining a set of tools and communications methods with the team and the customer
iii. Based on the requirements and the business problem of the customer, eliciting and
implementing the necessary infrastructure, hardware and software needed for the
development work
6.3 IMPLEMENTATION 1
The goals, deliverables and tasks will be set in the iteration planning for each iteration. The broad view can
be seen from the project schedule (see schedule exhibit 2)
6.4 IMPLEMENTATION 2
Team Neula – Project Plan
Page
27
7. RISK LOG
ID Risk Effect How to avoid Contingency plan Responsible Severity Probability
at start of
project
Probability
R1 The customer is not
satisfied with the
prototype descriptions
We run out of time
because it is too
difficult to innovate
good enough gadgets
Concentrate on a pre-
defined process and
rules for the prototype
descriptions and the
creation of backlog
Set a deadline for new
gadget descriptions,
demand input from
Suunto, begin to
implement after the
deadline
Paavo Häppölä 5 4 3
R2 Team cannot find
common ground for
communications and
meeting practices
Time is wasted and we
never get to the
implementation phase
Start meetings early in
the project and
discuss the issues
Split team up into
smaller parts that
have their own
meetings. Share
responsibility
Riku Seppälä 5 4 1
R3 The documentation is
not done properly, the
customer is only given
source code but no
exchange of tacit
knowledge is made
The project doesn't
benefit Suunto as
much as planned
Concentrate on the
documentation and
ask for feedback from
Suunto
Create the
documentation after
the project is finished.
Riku Seppälä 3 5 4
R4 Communication
doesn't work, Suunto
doesn't understand
what we're doing and
we don't know about
their requirements
The targets are not
met, we deliver an
unusable product
Plan enough meetings
and send clear
descriptions of
gadgets to be
implemented, not just
a description of
functions. Engage
Suunto in the
innovation process
Add meetings to
discuss
communication issues
Paavo Häppölä 5 5 2
R5 The workload is
distributed unevenly
Some members get
frustrated and others
not engaged. Quality
suffers and no one
enjoys the project
Have set times for
working together and
a weekly meeting
where everyone has
to be present or have
a legitimate reason for
not being present.
Follow up on tasks
accomplished and
concentrate on
scheduling
Remake the teams
and delegate more
responsibilites
Riku Seppälä 3 4 1
Team Neula – Project Plan
Page
28
R6 Most of the time is
spent for optimizing
for the course
requirements and not
for the actual project
outcomes
Customer and project
members are
dissatisfied
Keep documentation
light and let project
manager handle the
documentation for the
course. Everyone
doesn't have to be
involved, keep
everyone up-to-date
at meetings instead
Concentrate more on
the customer needs.
Riku Seppälä 4 5 4
R7 The needed
technologies cannot
be mastered in time.
We are not able to
make the prototype
descriptons reality
The goals cannot be
met
Concentrate on what
is most important, the
important
functionalities and
leave the most
difficult
implementations to
the end. Don't
promise too big.
Go back to the designs
and design simpler
gadgets. Use more
familiar technologies
Eero Palomäki 5 4 2
R8 Important persons
from the customer
side cannot be
reached
Time runs out. The
requirements
elicitation takes up
too much time.
Know when people
are present. Use the
telephone for
communications. Have
set practices and
deadlines for
gathering
requirements
Take more control of
requirements
Riku Seppälä 3 4 1
R9 The technologies and
support needed from
the client cannot be
delivered on time
Time runs out. The
development
becomes
unneccesarily difficult,
development effort
goes to creating
dummy interfaces etc.
Understand the
requirements, keep in
contact with the IT of
Suunto
Lower the goals Eero Palomäki 3 4 4
R10 Used tools and
technologies are
poorly supported and
development
becomes difficult
Time runs out. Use well documented
and/or familiar tools
and technologies
Switch to other tools,
lower the goals
Eero Palomäki 5 2 1
Team Neula – Project Plan
Page
29
8. EXHIBITS EXHIBIT 2 AN EXAMPLE OF A PROTOTYPE DESCRIPTION
Team Neula – Project Plan
Page
30
EXHIBIT 3 SCHEDULE WITH DEADLINES