1. The document discusses various topics related to software project management including project organization structures, team structures, challenges project managers may face, and methods for selecting projects. 2. It provides an overview of different project organization structures like functional, projectized, and matrix structures and how they influence projects. 3. Project team structures like isomorphic, specialty, and egoless structures are described along with their benefits and drawbacks. 4. Challenges around transitioning team members and effective communication are highlighted.

1. Software Project Management
Processes, Organization
The information contained in this presentation was obtained from the public domain

2. Quiz #1
Open book – 30 minutes
Good Project Management requires structured
software development environment, such as CMMI.
We also know that soft factors such as flextime, etc.
enable a highly productive project environment.
Doesn’t it seem to be a contradiction? As a project
manager, discuss the kind of environment you would
like to create to successfully manage your projects?

3. Project Success Rates
• The 2001 Standish Group Report Showed
significant Improvement in IT Project Success
Rates compared to 1995 stats:
– Time overruns: decreased to 63% compared to 222%
– Cost overruns were down to 45% compared to 189%
– Required features were up to 67% compared to 61%
– 78,000 U.S. projects were successful vs. to 28,000
– 28% of IT projects succeeded compared to 16%
• Why the Improvements?
• Better tools for monitoring and control
• More skilled PM’s, more process, more user involvement
• And “The fact that there are processes is significant in
itself.“

4. Why Do Projects Succeed?
• How to identify a projects success potential
– What metrics could you look at?
• Project size
• Project duration
• Project team size

5. Why Do Projects Succeed?
– Executive support
– User involvement
– Experience project manager
– Clear business objectives
– Minimized scope
– Standard software infrastructure
– Firm basic requirements
– Formal methodology
– Reliable estimates

6. Why Executive 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

7. • Define scope of project
• Identify stakeholders,
decision-makers, and
escalation procedures
• Develop detailed task list
(work breakdown structures)
• Estimate time requirements
• Develop initial project
management flow chart
• Identify required resources
and budget
• Evaluate project requirements
• Identify and evaluate risks
Prepare contingency plan
• Identify interdependencies
• Identify and track critical
milestones
• Participate in project phase
review
• Secure needed resources
• Manage the change control
process
• Report project status
15 PM Job Functions
*Northwest Center for Emerging Technologies, "Building a Foundation for Tomorrow: Skills Standards for Info
Technology,"Belleview, WA, 1999

8. PMI Framework
Source: Project Management Institute

9. The 5 PMI Process Groups
• 1. Initiating
• 2. Planning
• 3. Executing
• 4. Controlling
• 5. Closing
• Note: these can be repeated for each phase
• Each process is described by:
• Inputs
• Tools & Techniques
• Outputs

10. PMI Process Groups
Source: Project Management Institute

11. PMI: Process Links

12. PMI Phase Interactions
Initiating
Processes
Planning
Processes
Controlling
Processes
Executing
Processes
Closing
Processes
Design Phase
Initiating
Processes
Planning
Processes
Controlling
Processes
Executing
Processes
Closing
Processes
Implementation Phase

13. PMI: Initiating Process
• Inputs
– Product Description
– Strategic plan
– Project Selection
Criteria
– Historical Information
• Outputs
– Project charter
– Project Manager
assigned
– Constraints
– Assumptions

14. • Scope Planning
• Scope Definition
• Activity Definition
• Activity Sequencing
• Activity Duration
Estimating
• Resource Planning
• Cost Estimating
• Cost Budgeting
• Risk Planning
• Schedule Development
• Quality Planning
• Communications
Planning
• Organization Planning
• Staff Acquisition
• Procurement Planning
• Project Plan Development
Devising and maintaining a workable scheme to accomplish the business need that the project
was undertaken to address
PMI: Planning Process

15. PMI: Executing Process
• Project Plan Execution
• Scope Verification
• Quality Assurance
• Team Development
• Information
Distribution
• Source Selection
• Contract
Administration
Coordinating people and other resources to carry out the plan

16. PMI: Controlling Process
• Overall Change
Control
• Scope Change Control
• Schedule Control
• Cost Control
• Quality Control
• Performance Reporting
• Risk Response Control
Ensuring that project objectives are met by monitoring and measuring
progress and taking corrective measures when necessary

17. PMI: Closing Process
• Administrative Closure
• Contract Close-out
Formalizing acceptance of the project or phase
and bringing it to an orderly end

18. PMI Knowledge Areas

19. Organizational Structures
• Functional
– Engineering, Marketing, Design, etc
– P&L from production
• Project
– Project A, Project B
– Income from projects
– PM has P&L responsibility
• Matrix
– Functional and Project based
– Program Mgmt. Model
– Shorter cycles, need for rapid development process

20. Functional Organization
• Pros
– Clear definition of authority
– Eliminates duplication
– Encourages specialization
– Clear career paths
• Cons
– “Walls”: can lack customer orientation
– “Silos” create longer decisions cycles
– Conflicts across functional areas
– Project leaders have little power

21. • structure of an organization based on
functional performance; organizational
departments created to fulfill organizational
functions such as marketing, finance, and
personnel. This type of organization has
characteristics of both line and staff
functions.

22. • Over time, this approach changes an organization.
The hierarchy and bureaucracy become weaker.
Career success depends on the results of the
projects on which you work, not just time on in a
position or politics. The organization develops
executives who manage projects. They are not
necessarily technical experts, they are experts in
running many different kinds of projects. Last, the
organization becomes more agile, able to respond
to changing customer needs.

23. Project Organization
• Pros
– Unity of command
– Effective inter-project
communication
• Cons
– Duplication of facilities
– Career path
• Examples: defense avionics, construction

24. Matrix Organization
• Pros
– Project integration across
functional lines
–Efficient use of resources
–Retains functional teams
• Cons
– Two bosses for personnel
– Complexity
– Resource & priority conflicts

25. Matrix Forms
• Weak, Strong, Balanced
• Degree of relative power
• Weak: functional-centric
• Strong: project-centric

26. Organizational Structure Influences on
Projects
MatrixOrganization Type
Project
Characteristics
Functional Weak Matrix Balanced
Matrix
Strong Matrix Projectized
Project Manager's
Authority
Little or
None
Limited Low to
Moderate
Moderate
To High
High to
Almost Total
Percent of Performing
Organization's
Personnel Assigned Full-
time to Project Work
Virtually
None
0-25% 15-60% 50-95% 85-100%
Project Manager's Role Part-time Part-time Full-time Full-time Full-time
Common Title for
Project Manager's Role
Project
Coordinator/
Project Leader
Project
Coordinator/
Project Leader
Project
Manager/
Project Officer
Project
Manager/
Program Manager
Project
Manager/
Program Manager
Project Management
Administrative Staff Part-time Part-time Part-time Full-time Full-time
PMBOK Guide, 2000, p. 19

27. Project Team
Structures

28. Isomorphic Team Structure
• If project team closely reflects the physical
structure of deliverables
• Risk of project’s quality integration
• PM functions as an integrator
• Duplication, linking, styles etc to be
standardized by the PM
• It’s a simple structure
• Best suited to independent modules

29. Isomorphic Team Structure
Chapter
1
Chapter
2
Chapter
3
Chapter
4
Chapter
5
Technical Report
Team
Member
A
Team
Member
B
Team
Member
C
Team
Member
D
Team
Member
E
Project Manager
Structure of the Deliverable
Structure of the Project Team

30. Specialty Team Structure
• Team members apply their special expertise
across a wide array of tasks
• Emphasis towards their specialty and not
deliverables
• Responsibility is more diffused and problem
diagnosis is difficult
• Integration problems are greater than those of
the isomorphic structure
• It fits in nicely with matrix system

31. Specialty Team Structure
PROJECT
MANAGER
Specialist
A
Specialist
B
Specialist
C
Chapter
1
Chapter
2
Chapter
4
Chapter
3
Chapter
5

32. Egoless Team Structure
• Egos may have ill-effects
• Ego-less team structure is a truly collaborative effort
that makes it hard to find who produced what
portion of the product
• No leader but consensus
• Team members collaborate jointly and ego problem
is minimized
• Encourages interactivity and communication
• Due to lack of leadership Ego-less team could drift
• State of the art projects

33. Team Member
A
Team Member
B
Team Member
C
Chapter
1
Chapter
2
Chapter
4
Chapter
3
Chapter
5
Egoless Team Structure

34. Software Teams
• Many organization structures …
• Political and practical consequences of
organizational change (is it within the PM
scope of responsibility?)

35. Team Types

36. Democratic Decentralized
–No team leader
–Different task assigned to different
task coordinators who are appointed
for little time
–Consensuses based problem solving
–Horizontal communication

37. Controlled Decentralized
–Team leader
–Secondary leaders
–Group based problem solving
–Horizontal & vertical communication
–Tasks and sub tasks

38. Controlled Centralized
–Team leader
–Top level problem solving
–Vertical communication

39. Some Challenges

40. Because the project is, by definition, a temporary
entity and must come to an end, the PM must be
concerned with the future of the people who serve on
the team. If the PM does not get involved in helping
project workers with the transition back to their
functional homes or to new projects, then as the
project nears completion, project workers will pay
more and more attention to protecting their own future
careers and less to completing the project on time.
(Shown by “S”Curve)
Transition Challenge

41. Communication Challenge
Two people,
one channel
Three people,
three channels
Four people,
six channels
Five people,
ten channels

42. Key Differentiator: People
• The cultivation of motivated, highly skilled
software people has been discussed since
1960. In fact this factor is so important that
in addition to process capability model the
Software Institute has also developed a
people management capability maturity
model

43. Methods for Selecting Projects
• There are usually (always?) more projects
than available time and resources to
implement them
• Therefore: It is important to follow a logical process
for selecting IT projects to work on
• Methods include
– Focusing on broad needs
– Categorizing projects
– Financial methods

44. Broad Organizational Needs
• It is often difficult to provide strong justification
for many IT projects, but everyone agrees they
have a high value
• “It is better to measure gold roughly than to count pennies
precisely”
• Three important criteria for projects:
– There is a need for the project
– There are funds available
– There’s a strong will to make the project succeed

45. Categorizing IT Projects
• One categorization: whether project addresses
– a problem
– an opportunity
– a directive
• Another: how long it will take & when it is needed
• Another: overall priority of the project

46. Procurement Management
• Procurement means acquiring goods and/or
services from an outside source
– a.k.a. purchasing or outsourcing
• Know how your project fits-into this model
– Are you building “in-house”? “for hire”?
• Thus are you the ‘outside source’?
– As a startup? (thus in-house but as basis for
the business itself)

47. Why Outsource?
• To reduce both fixed and recurrent costs
• To allow the client organization to focus on
its core business
• To access skills and technologies
• To provide flexibility
• To increase accountability

48. Procurement Tools & Techniques
• Make-or-buy analysis (build vs. buy)
• Determining whether a particular product or service
should be made or performed inside the organization
or purchased from someone else. Often involves
financial analysis
• Experts
• Both internal and external, can provide valuable
inputs in procurement decisions