Team Neula – Project Plan

TKK

Team Neula –

Project Plan Software development project – Suunto web 2.0

team Neula

10/19/2008

Team Neula – Project Plan

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


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


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


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.


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.


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:


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.


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


Servers, Testing Tools

and Methods

Architecture,

Infrastructure Project Management Architecture

Ville Harvala


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


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


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.


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.


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)


Page

14

4.3 BUDGET

The budget was calculated according to the discussions with Suunto.


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.


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.


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:

Email

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.


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/


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


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.


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


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.


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


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


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


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


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.


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



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.


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


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


Page

29

8. EXHIBITS EXHIBIT 2 AN EXAMPLE OF A PROTOTYPE DESCRIPTION


Page

30

EXHIBIT 3 SCHEDULE WITH DEADLINES

Team Neula – Project Plan

Documents

Transcript of Team Neula – Project Plan