Face WashExercise 3 – Part 1

T-76.612 Software Project Management

Jenni HäyrenKarri Karanko

Mikko Laine

20.4.2005 Exercise 3 - Part 1 2

Problems & mistakes

Different viewpoints on classifying problems and mistakes• Project management “areas” or “practices”• Classic mistakes

Process

Information not available

Do not seem to be a

problem

Seems to be a problem

Seems to be a serious

problem

Overly optimistic schedules. X

Insufficient risk management. X

Contractor failure. X

Insufficient planning. X

Abandonment of planning under pressure. X

...

20.4.2005 Exercise 3 - Part 1 3

Project start-up

The reason to start the project was based on feelingsManagement did not define clear objectives for the projectManagement did not see the importance of planningNo decent requirements specification was ever madeThe customer-oriented viewpoint lackedThere was no defined process

20.4.2005 Exercise 3 - Part 1 4

Subcontracting

An inexperienced subcontractor was chosenThe skills and knowledge of the subcontractors were not fully certifiedThe cheapest subcontractor was chosenThe subcontractors were chosen without inviting proper bidsA subcontractor that even subcontracted itself was chosen

20.4.2005 Exercise 3 - Part 1 5

Communication

No communication media or methods were definedThere were no predefined contact personsThe full content of the project was not communicatedThe exact personnel tasks were not communicatedCritical tacit information was not even tried to be documented

20.4.2005 Exercise 3 - Part 1 6

Scheduling

The schedule of doing the screens was based on the number of screensThe dependencies of the tasks were not understoodThe duration of the whole project was pressurized by market needsTime needed for learning was not notedThe deadlines were consequently extended

20.4.2005 Exercise 3 - Part 1 7

Organizing team

The management in general was too weak or not existingThe division of the roles was not clearThe developers were not committed to the projectThere was not enough knowledge on the issues some members worked withNo concrete activities to increase the motivation and team spiritThe compensations were wrongly directed

20.4.2005 Exercise 3 - Part 1 8

Monitoring and control

No effective management decisions were made in order to control the projectThere was no team leader in the same place than the distant teamsSome members saw the lack of progress, but no one intervenedThe reported progress did not happened in real lifeThe definition of “complete” was not done

20.4.2005 Exercise 3 - Part 1 9

Quality management

Some members had not even seen a testing plan.Testing was done by several people with different roles, such as the Hungarian developers themselves.

20.4.2005 Exercise 3 - Part 1 10

Change management

Regarding the screens, the architect and the developers could implement their own changes without decent change managementThe changes were not documented or communicated to othersThe few change requests were made ambiguously by email

20.4.2005 Exercise 3 - Part 1 11

Scope definition

Extra work was added after the project was started, but no plans were made for that workWork that was not necessarily important was added

20.4.2005 Exercise 3 - Part 1 12

Effort estimation

The initial planning was mostly based on one person’s estimatesThe developers were not taken along to estimate the workload and the schedule

20.4.2005 Exercise 3 - Part 1 13

Risk management

A risk management plan was not madeAs a result, no risk management procedures were carried outEven though some risks were notified through quality system, no actions were taken

Face WashExercise 3 – Part 2

T-76.612 Software Project Management

Jenni HäyrenKarri Karanko

Mikko Laine

20.4.2005 Exercise 3 - Part 1 15

Unclear team roles

Having no clear role division between project members causes role conflicts, confusion and stress

The roles should have been clearly defined• Senior management• Project managers• Technical responsible• Coders• Subcontractor• Testers

20.4.2005 Exercise 3 - Part 1 16

Ambiguous subcontracting

Subcontracters were chosen hastily and launched without any proper methodology

Invitation of bidsProper screening of alternativesCheapest alternative is not always the bestDo not select inexperienced subcontractor that uses subcontracting itselfGoals, costs, communication methods and supervision should be agreed upon

20.4.2005 Exercise 3 - Part 1 17

Lack of communication methods

The full content of the project should have been communicatedResponsibility areas of project members should have been communicatedContact persons should have been predefinedThe Framework should have been properly documentedCultural differences should have been understoodThe meetings should have been planned and led professionallyThe Q & A database was not that necessary

20.4.2005 Exercise 3 - Part 1 18

Goals/scope not defined

Having no clear goals, employees become unmotivated and in turn schedules and costs are exeeded

Scope of the project should be defined• Deliverables, milestones, etc.

Goals should be divided individuallyIf extra work is added, it should be justified, planned and documented

20.4.2005 Exercise 3 - Part 1 19

Schedule not defined

As the duration of the project and tasks are vaguely defined, deadlines constantly extend

-> Rough estimation already before the bidding-> The knowledge of team members should be used-> Various methods have to be used-> Also non-productive tasks have to be taken into

account-> The idea of iterations could be utilized-> Every-day work becomes easier

20.4.2005 Exercise 3 - Part 1 20

Lack of documentation

The lack of a project plan and other documentation cause difficulties in communicating

-> Define what is needed in the beginningFeasibility study, project plan, requirements

specifications...

-> Define what is needed during the projectMinutes, reports of the progress, test plans, test reports...

Who is responsible, how to distribute?

20.4.2005 Exercise 3 - Part 1 21

No change management method defined

The rate and order of change should be managedSome kind of change management tool should have been usedSame tool for changes and bug fixesEvery request should have ID, state, and priority

20.4.2005 Exercise 3 - Part 1 22

Weak monitoring/control

Management should have planned monitoring/control strategyCustomers interest was not overseen at remote officesThe version control system should have been used for monitoringTesting reports should have been required and analyzedTesting should have been done outside the developer communityProject members should have done hour based reportingPrioritized change management will also help to meet the business-oriented goals and not only to weight the technical issues