1. Project basics & team work, communication

2. Topics discussed Projects Teams Communication Goals, success, mistakes
Team work
Team building
Communication
Team communication

3. Reports from other universities
A software project course, without teaching project management, is a course in how to NOT do projects

4. What is a project? Limited lifetime Defined goals Limited resources
Defined project organization
Uses project systematics
First ”modern” project: The Manhattan project??

5. Project systematics Project plan Clear responsibilities (roles)‏
Checkpoints / milestones
Defined phases
Control, risk management
Reporting

6. Terminology Processes Projects Teams Units/functions
defined ways of working
Projects
well defined isolated things to do
Teams
a group of people with a specific task / project
usually within organizational units
Units/functions
structure in the organization

7. Project lifecycle - high level
Sales
Project start
Project
follow up
Project end
Support

8. Project phases Not directly, use some kind of iterative process
Not well suitable for SW development

9. Project goals Two types of goals Stepwise feature introduction
Visionary – that is what we would like to have
Realistic – goals that you know you can achieve using your present project organization
Stepwise feature introduction
“Baby-steps to the top”

10. SMART Goals Specific Measurable Agreed upon Realistic Time-framed
well defined, clear to anyone who has basic knowledge of the project
Measurable
to know is the goal is reachable and how far away from completion we are
Agreed upon
agreement between users and project team on goals
Realistic
in relation to resources, knowledge and time
Time-framed
how much time is needed to accomplish the goal

11. Trade-off Triangle
”Select two out of three”

12. Project success In groups 1. When is a project successfull?
2. What is important?
Schedule / budget / features
3. What is required to be successfull?

13. Project success Project must meet customer requirements
Project must be under budget
Project must be on time

14. Project success
Critical Success Factors and Their Importance for System Implementation (Listed in decreasing order of correlation)‏
[Pinto (1986), See Smith (2000), p. 60]
1.Project mission. Initial clearly defined goals and general directions.
2.Top management support. Willingness of top management to provide the necessary resources and authority/power for implementation success.
3.Schedule plans. A detailed specification of the individual action steps for system implementation.
4.Client consultation. Communication, consultation, and active listening to all parties impacted by the proposed project.
5.Personnel. Recruitment, selection, and training of the necessary personnel for the implantation project team.
6.Technical tasks. Availability of the required technology and expertise to accomplish the specific technical action steps to bring the project on-line.
7.Client acceptance. The act of "selling" final product to its ultimate intended users.
8.Monitoring and feedback. Timely provision of comprehensive control information at each stage in the implementation process.
9.Communication. The provision of an appropriate network and necessary data to all key actors in the project implementation process.
10.Troubleshooting. Ability to handle unexpected crises and deviations from plan.

15. Why top management support?
Top management can help to:
Secure adequate resources
Get approval for unique project needs in a timely manner
Receive cooperation from people throughout the organization
Provide leadership guidance

16. Project succeess rate (Lewis, 2000, p. 109)
17% succeeded
50% revised
33% failed (never finished)‏
10% finished on time

17. Comparing Software Development Paradigms: 2013
The levels of success were defined as follows:
Successful. A project is considered successful if a solution has been delivered and it met its success criteria within a range acceptable to your organization.
Challenged. A project is considered challenged if a solution was delivered but the team did not fully meet all of the project's success criteria within acceptable ranges (e.g. the quality was fine, the project was pretty much on time, but ROI was too low).
Failed. The project team did not deliver a solution.
The paradigms were defined as follows:
Ad-hoc. On an ad-hoc software development project the team does not follow a defined process.
Iterative. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. NOTE: We will ask about Agile projects, which are defined as iterative projects that are performed in a highly collaborative and lightweight manner, later.
Agile. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is Scrum, XP, and Disciplined Agile Delivery (DAD).
Traditional. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes.
Lean. Lean is a label applied to a customer value-focused mindset/philosophy. A lean process continuously strives to optimize value to the end customer, while minimizing waste which may be measured in terms of time, quality, and cost. Ultimately the Lean journey is the development of a learning organization. Examples of Lean methods/processes include Kanban and Scrumban.
Success rates were calculated using the following strategy:
A weighted average for each of level of success was calculated. A selection of % was considered to be 95%, 81-90% as 85% and so on. A selection of 0 was considered as 0. Answers of Don’t Know were now counted.
A normalized value was calculated. The weighted averages didn’t always add up to 100%. For example, the weighted averages may have been 60% 30% and 20% for a total of 110%. To normalize the values we divided by the total, to report 60/110, 30/110, and 20/110.
Copyright 2014 Scott W. Ambler

18. Budget/ROI: Which is more important?
Copyright 2014 Scott W. Ambler

19. Stakeholder Value: Which is more important?
Copyright 2014 Scott W. Ambler

20. Project failures
What causes failures?
2008
Project Course / JB / 2010

21. Project mistakes – people related
Undermined motivation
Weak personnel
Weak vs. Junior
Uncontrolled problem employees
Heroics
Adding people to a late project
Noisy, crowded offices
Customer-Developer friction
Unrealistic expectations
Politics over substance
Wishful thinking
Lack of effective project sponsorship
Lack of stakeholder buy-in
Lack of user input

22. Project mistakes – process related
Optimistic schedules
Insufficient risk management
Contractor failure
Insufficient planning
Abandonment of plan under pressure
Wasted time during fuzzy front end
Shortchanged upstream activities
Inadequate design
Shortchanged quality assurance
Insufficient management controls
Frequent convergence
Omitting necessary tasks from estimates
Planning to catch-up later
Code-like-hell programming

23. Project mistakes – product related
Requirements gold-plating
Gilding the lily
Feature creep
Developer gold-plating
Beware the pet project
Push-me, pull-me negotiation
Research-oriented development

24. Project mistakes – technology related
Silver-bullet syndrome
Overestimated savings from new tools and methods
Fad warning
Switching tools in mid-project
Lack of automated source-code control

25. Team work & Communication

26. Why work in teams? Bring together complementary skills
Problems are solved more quickly
Provides a social framework for working
Creates a fun atmosphere

27. Team forming Some physical exercise ;)
Get yourself into a team that...
2008
Project Course / JB / 2010

28. Team building High level of interdependence among team members
Team leader has good people skills and is committed to team approach
Each team member is willing to contribute
Team develops a relaxed climate for communication
Team members develop a mutual trust
Team and individuals are prepared to take risks
Team is clear about goals and establishes targets
Team member roles are defined
Team members know how to examine team and individual errors without personal attacks
Team has capacity to create new ideas
Each team member knows he can influence the team agenda

29. The Apollo syndrome (Meredith Belbin, 1981)‏
Team of people with sharp, analytical minds and high mental ability not managing to perform well
spend time in abortive or destructive debate, trying to get other to adopt their view
difficulties in decision making
act along their own favorite lines
sometimes team notice what is happening, but react by over compensating – avoid confrontation

30. Team dynamics roles Task Relationship Summarizer Harmonizer
Path-finder
Gatekeeper
Encourager
Relationship
Harmonizer
Analyzer
Fact seeker
Initiator
Best friends do not necessarily make the best team.
Sometimes this can even worsen the team work.

31. Team practical roles Team leader (=project manager) Product owner‏
Development
Planning / Design
Process
Support
Testing manager
Documentation

32. Most important comm. skill
What are the communication skills needed in a project?
What is the most important communication skill a person involved / manager should have?
Project Course / JB / 2010

33. About communication verbal communication nonverbal communication
language, quality of spoken lang. , tempo rhythm, pitch articulation
nonverbal communication
appearance, facial expressions
written
books, journals, daily papers, memos etc, s

34. Communication & Projects
Group of experts
Limited time resources
Often problem solving situation
Strong goal orientation
Responsibilities for other parties

35. Small group communication
Groupthink – we do work together
Norms – we have some rules
Agenda setting – we are organized
Roles (information giver, information seeker, elaborator, initiator, administrator)‏
Leadership (authoritarian, consultative, participative, laissez-faire, shared etc.)‏

36. Team communication tools
lists?, who is responsible, moderator?
problems with
Phone / Skype
fast problems solving
no ”automatic” documentation
no memos to the rest of the team
Chats / Facebook / etc.
history stored?, visible to all in team?
Computerized project management system (AHA, Trac, Trello, MS Excel?, Google Docs, OneDrive, Dropbox....)‏

37. Types of communication
Formal, impersonal approaches
Documents
Project milestones
Error tracking reports
Source code
Repository data
Project control tools
Formal, interpersonal procedures
Design reviews
Requirements reviews
Status reviews
Code inspections
Informal interpersonal procedures
Group meetings
Electronic communication
Electronic mail
Project bulletins
Interpersonal network
Discussions with peers

38. Effective team meetings
Use an AGENDA, distributed in advance
People should know what is to be discussed
Use team meeting for
Analyzing, reporting what has been done
Plan what should be done next
Making decisions
NOT FOR DOING THE WORK
Exception: ”brain-storming activities”

39. Simple AGENDA GROUP A MEETING, DC 3101 Nov 7. at 10.15
Present: NN, NN, NN, NN
AGENDA:
* Code status (dev manager) * Decision on testing tools
* The documentation templates (process manager)‏
* Test plan (testing manager)‏
* Next meeting
Agenda distributed 1-10 days before meeting
Or send a calendar invitation !

40. Project Course / JB / 2010