1. Software Project Management :Software Project Management :
An OverviewAn Overview
Amit Dubey
Amit.dubey@me.com

2. Presentation OverviewPresentation Overview
 What is project (5 mins)
 what is project management (10 mins)
 what are the components of project management .(20-
30 mins)
 Enabling yourself for software projects.(10 mins)
 questions and answers (~15 mins)

3. What is projectWhat is project
 The first thing is to know what is a project, before learning to manage one. The way I like
to define a project is “a set of activities having a definite BEGINNING and END with a
UNIQUE RESULT”.
 If a project is repeated regularly by keeping most of the attributes same, it becomes an
operation. An example can be a setup of a soda drink plant for the first time is a project.
The manufacturing of the first batch of soda drinks is also a project. But after that,
everyday’s production becomes an operation that has a similar result every time it is
performed. So, even an operation when performed for the first time is a project.
 The project is ‘Temporary’ in nature as it has a start and an end in a specified time
period. Project being temporary doesn’t mean that it is of a short duration. The duration
of a project can be as short as a week, for example, and as long as multiple years.
Constructing a new room in the house is a project which could be completed in a week
or so depending upon the planning, budget, resources, etc., whereas, construction of a 50
stories high rise building could take years. An important thing to understand here is that
a construction company involved in the construction of different buildings considers
them as individual projects as they result in a different product every time after a specific
start and end. The company’s internal departments like procurement, debris disposal,
logistics, etc. however are running similar operations just on different sites.
 So a project is anything with a start and an end which makes it temporary and it has a
unique result which can be a product or a service.

4. What is project managementWhat is project management
 ‘what is meant by managing a project?’. If project can be considered a problem and
its result is a solution to the problem then managing it is to adopt the best suitable
way, out of many, to reach the solution by addressing the problem. In the simplest
possible words, the project management is knowing all your options and choosing
the best as per your limitations (environmental, financial, logistical, etc.) to solve
your problems. These limitation are called ‘constraints’ in project management
terms.
 Project management is an art and a science at the same time. It has both
professional and social aspects, that is why people with better social skills become
better project managers. There is no doubt about technical knowledge of project
management being the prerequisite for a project manager but the equal importance
of social skills can be judged by that fact that during a project’s life cycle, the project
manager spends 90% of his time in managing communications and dealing with the
project team, management, customers, cross functional departments, end users, etc.
collectively known as stakeholders. So I believe that the basic skill that you need to
build, before learning the project management professionally, is social skill and that’s
the very essence of project management.

5. What winners doWhat winners do
 “The winners clearly spell out what needs to be done in a project, by
whom, when, and how. For this they use an integrated toolbox, including
PM tools, methods, and techniques…If a scheduling template is developed
and used over and over, it becomes a repeatable action that leads to
higher productivity and lower uncertainty. Sure, using scheduling
templates is neither a breakthrough nor a feat. But laggards exhibited
almost no use of the templates. Rather, in constructing schedules their
project managers started with a clean sheet, a clear waste of time.”*

6. Project management groups andProject management groups and
processesprocesses
 As we all know, according to PMBOK® 5th
Edition we have
47 PM processes, and these processes are scattered among 5
process groups, and 10 knowledge areas:
 Initiating : 2 processes
 Planning: 24 processes
 Execution: 8 processes
 Monitoring & Controlling: 11 processes
 Closing: 2 processes.
 PMI Project Management Standards suggest that the 5
process control groups should be used to define these
processes within each phase of a project for a successful
implementation. These process control groups are defined as
follows: Initiating processes, planning processes,
executing processes, monitoring and controlling
processes, closing processes,

7. Process groups vs Knowledge areasProcess groups vs Knowledge areas
Process Groups
Initiating
Planning
Executing
Monitoring & Controlling
Closing
Knowledge Areas
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resources Management
Project Communications Management
Project Risk Management
Project Procurement Management
Project Stakeholder Management (newly added knowledge area in PMBOK guide 5th
edition)

8. What is software projectWhat is software project
managementmanagement

9. Detailed diagramDetailed diagram

11. Project initiationProject initiation
 Project Charter is the basic document that officially kicks off the project
by giving the authority to the project manager to go ahead with the
project. Technically speaking, the project sponsoring authorities prepare
this document and a project manager is assigned during this phase . But, in
most cases, since the project manager is already a part of the organization,
so this document is also prepared by him. It does not really matters that
who prepared the project charter, the most important aspect of project
initiation is that this document exists. It is, however, recommended that
the project manager participates in the development of the project
charter. Project charter for a project is as important and imperative as a
graduation degree for your professional career. Project charter is
generally a 2-10 pages document but can vary according to the
requirement and size of the project. It consists of the following important
information:

12.  Project Title and Description: As per the heading, this is simply the name of
the project along with its brief description as what to do, its objectives,
etc.
 Project Manager and Authority Level: This section names the project manager
assigned for the project and his level of authority in the project.
 Statement of Work (SOW): The SOW is created by the sponsoring agency
and describes their needs (macro level requirements) and project’s scope
(what to do and what not to do).
 Business Case: This section defines the need (business need) of this project.
Now, this is a very important part and one can assess the importance of a
project by looking at this section. This is called project selection criteria,
mostly justified by conducting cost-benefit analysis of all the suggested
projects. There are several methods available to perform this analysis
including but not limited to Net Present Value (NPV), Internal Rate of
Return (IRR), Benefit-Cost Ration, Economic Value Added (EVA), etc.

13.  Project Resources: This section describes the high level resource requirements to
complete this project. Number of team members, their high level skills set,
hardware, logistics, etc. are listed in this section.. The purpose of including sections
like this and SOW, etc. in project charter is to give an overall picture of the project
in one document.
 Stakeholders and Their Needs: Anyone who takes part in the project or is effected by
the result of this project is called a stakeholder. The project team is the subset of
stakeholders. This differentiation is made for the purpose of communications
management. For example, the customers of any product, being developed in a
project, are stakeholders but we do not send them our project’s status reports, etc.
This sections also enlists the high level requirements gathered from the
stakeholders by conducting surveys, interviews and other methods of requirements
gathering.
 Project Constraints and Potential Risks: This section describes the project constraints
like deadline, budget and other high level limitations. Besides constraints, high level
potential threats and opportunities are also mentioned in this section.
 Signatures: Last but not the least, never forget to get the project charter signed by
the sponsoring authorities. The signatures are the seal of approval by the
management and make it an official document.

14. Project InitiationProject Initiation

16. PlanningPlanning
 As the name suggests, it is a plan with which one can manage the project as a
whole, not just the milestones or activities schedules. Whole project means that
this is much more than a mere schedule. You have to remember that this plan is
part of theintegration management of the project which means that it
integrates all the aspects of the project and continuously evolves during the
project duration. This plan is not just one document, rather the following individual
documents are put together to form the project management plan:
Project baseline
 Schedule baseline
 Cost performance baseline
 Scope baseline

17. Plans from each knowledge area
Scope management plan
Time/Schedule management plan
Cost management plan
Quality management plan
Human resource plan
Communications management plan
Risk management plan
Procurement management plan
Other management plans
Requirements management plan
Change management plan
Configuration management plan
Process improvement plan

18.  Often the three baselines are put together under one document generally called
project performance baseline against which the project’s integrated performance
is measured. The purpose of putting these plans under different headings is to make
it easier to remember the names which could be otherwise difficult to remember if
listed under a single heading. These individual plans will be explained in their
respective topics and areas later on.
 The conclusion is that the key to understand this topic is to remember that the
project management plan is part of the integration management knowledge area;
which means that there are always more than just one plan to integrate

19. Project PlanningProject Planning

21. Project ExecutionProject Execution
 Project execution involves managing and performing the work described
in the project management plan
 The majority of time and money is usually spent on execution
 The application area of the project directly affects project execution
because the products of the project are produced during execution
 Project planning and execution are intertwined and inseparable activities
 Those who will do the work should help to plan the work
 Project managers must solicit input from the team to develop realistic
plans

22. Figure 6-1. Executing Processes and OutputsFigure 6-1. Executing Processes and Outputs
22
Knowledge area Executing process Outputs
Project integration management Direct and manage project
execution
Deliverables
Work performance data
Change requests
Project management plan updates
Project document updates
Project quality management Perform quality assurance Organizational process asset updates
Change requests
Project management plan updates
Project document updates
Project human resource
management
Acquire project team
Develop project team
Manage project team
Project staff assignments
Resource calendars
Project management plan updates
Team performance assessment
Enterprise environmental factors updates
Change request
Project management plan updates
Enterprise environmental factors updates
Organizational process assets updates
Project communications
management
Distribute information
Manage stakeholder expectations
Organizational process assets updates
Organizational process assets updates
Change requests
Project management plan
updates
Project document updates
Project procurement management Conduct procurements Selected sellers
Procurement award
Resource calendars
Change requests
Project management plan updates
Project documents updates

25. Project Monitoring and controlProject Monitoring and control
 Monitoring and Controlling progress of a project’s implementation plays a
very important role in the successful implementation of a project
 Tracking action items : The Action Items list is initially created from the
Work Breakdown Structure (WBS). Weekly team meetings are held to
review/update listed action items as well as to add additional items as the
need arises. This is done to ensure that activities in the critical path are
completed on time so that the timeline of the project does not slip. These
meetings also serve the purpose of protecting the project from
unintentional scope creep.
 Tracking of issues :Throughout the project implementation, there will be
times when action items turn into irresolvable issues at the project team
level. These action items are then escalated into issues to be engaged and
resolved by the Project Sponsor and other stakeholders of the specific
process in question.

26.  Status reports: The Project Office distributes electronic status reports of
all technology-related projects on a bi-weekly basis. These reports are
sent to all Project Sponsors, Team Members, and the Technology Steering
Committee; primarily to show the health of each of the projects
currently being implemented.
 Change control : Any change within a project that affects the Scope,
Timeline, or Budget of the project is subject to the change
request process. The Project Manager submits the change request to the
Project Sponsor on behalf of the Project Team. Once the change has
been approved, it can be added to the scope of the project.
 Move to Production:As a project moves to completion and the new
service or process has been moved into a production environment, there
are safeguards that need to be in place to ensure uninterrupted service to
the end-users.

27.  Review Gate
 Before the project can move into the Close Out phase of the Project
Lifecycle, it must pass through. The Review Gate is a serious of questions
that need to be addressed. Routing and signatures of the Review Gate
Document may be required depending upon the Classification Level of the
project (see below).
 Review Gate Document needs to be completed and submitted to the CIO
of the implementing institution for approval

29. Project closureProject closure
 As a project moves into the Close Out there are several things that occur
to ensure the longevity & sustainability of the newly implemented service.
 Transfer of Ownership
 Throughout the implementation of a project, the Information Technology
Department often works alongside the functional team and plays a very
critical role in the setup and roleout of a service. Once the service is
operational and stable, there comes a need to transfer ownership of many
of the processes IT has helped the Functional Team set up throughout the
project. Many of these transitional item become part of the Functional
Team’s daily routine once the project has been closed out.
 The Objectives Met/Not Met is a document in which the objectives listed
within the Business Justification document are reviewed to determine
which were met, which were NOT possible due to incorrect assumptions
concerning the project implementation and which still need to be met but
were not included in phase I of the project.

30.  Lessons Learned
 The Lessons Learned document allows the project team to provide
feedback to the project office concerning the Project Implementation
process. This allows Project Managers of future projects, to learn from
past experiences.
 Review Gate
 Before the project can be completed, it must pass through the review.
 Level 1 Review Gate Document needs to be completed and submitted to
the CIO of the implementing institution for approval
 Level 2 Review Gate Document needs to be completed and submitted to
the Project office of the implementing institution for approval
 Level 3 Review Gate Document needs to be completed by the project PM
and saved within the project file of the implementing institution.
 The project is now Complete.

31. ClosureClosure

33. Enabling yourself for projectEnabling yourself for project
managementmanagement
What is expected from you to be:
1. Passionate
2. Determined
3. Team Player
4. Confident
5. Up-to-date
6. Efficient Time Management
7. Coolheaded and Open Minded

34. 8. Competitive
9. Creative
10. Strategist
11. Original
12. Industrious
13. Realist
14. Independent
15. Nerves of Steel

35. Effective SW project managementEffective SW project management
focuses on 3 Pfocuses on 3 P’’s:s:
people
problem
process

36. 1.1. peoplepeople
• must be organized into effective teams
• motivated to do high-quality work
• coordinated to achieve effective
communication and results

37. 2.2. problemproblem
• must be communicated from customer to
developer
• decomposed into its parts
• positioned for work by SW team

38. 3.3. processprocess
• must be adapted to the people and
problem
to get the SW developed:
• common process framework is selected
• appropriate SWE paradigm is applied
• set of work tasks chosen

39. PeoplePeople

40. 3.2 People3.2 People
very important component to success of
SW project
players:
• senior managers - define business issues that
impact project
• project (technical) managers - must plan,
motivate, organize and control the project
team
• customers - specify requirements
• end users - use the sw

41. 3.2 People3.2 People
team leaders:
• lead the sw development team
• MOI model of leadership
• motivation
• organization - of processes
• ideas or innovation - encourage creativity

42. 3.2 People3.2 People
• Another view - 4 key traits of effective
project manager
• problem solving skills
• managerial identity - take charge of the
project
• achievement - reward initiative and controlled
risk taking
• influence and team building - ability to read
people

43. Organization of SW teamsOrganization of SW teams

44. A.A. The team structuresThe team structures
SW teams can be organized into number
of different team structures
appropriate team structure depends on
type of problem task
3 generic team organizations

45. 1.1.democratic decentralized (DD)democratic decentralized (DD)
(fig. 1)(fig. 1)
• no permanent leader
• task coordinators appointed for short
time and then replaced
• decisions made by group consensus
• horizontal communication

46. 2.2.controlled decentralized (CD) (fig.controlled decentralized (CD) (fig.
3)3)
• leader who coordinates tasks
• secondary leaders responsible for
subtasks
• group problem solving
• horizontal communication among
subgroups
• vertical communication along control
hierarchy

47. 3.3. controlled centralized (CC) - i.e. chiefcontrolled centralized (CC) - i.e. chief
programmer team (fig. 2)programmer team (fig. 2)
• top-level problem solving and team
coordination managed by team leader
• vertical communication between leader
and team members

48. 7 project structures to consider when7 project structures to consider when
planning structure of swe teams:planning structure of swe teams:
1. difficulty of problem to be solved
2. size of programs (LOC and function points)
3. lifetime of team
4. degree to which problem can be modularized
(and structured)
5. required quality and reliability of system being
built
6. rigidity of delivery date
7. degree of communication required for project

49. Project structuresProject structures
table 3.1 in text - summarizes impact of
project characteristics on team structure
(Mantei81)
centralized structure completes tasks
faster - better at handling simple
problems
decentralized structure - generates more
and better solutions so better at more
difficult problems

50. B.B. ConstantineConstantine organizationorganization
structuresstructures
discusses four organizational paradigms
for SWE teams
Projects or other tasks can be
coordinated by:

51. 1.1. Traditional Hierarchy ofTraditional Hierarchy of
AuthorityAuthority
closed paradigm
standards and rules
stability valued (no deviation from norm
allowed)
pyramid or hierarchical organizational
structures
collective interests come first
demonstrate loyalty and defer to group
 examples: military or government

52. 2.Innovative Individualism2.Innovative Individualism
random paradigm (opposite of closed paradigm)
independent individual initiative
innovation and change through creative
autonomy
individual has freedom to create and act
independently
individual more important than group
◦ examples: breakthrough project teams developing new
technology

53. 3.3. Adaptive CollaborationAdaptive Collaboration
open paradigm
integrates innovation with stability and
individual with collective
interests through negotiation and
discussion
roles and responsibilities are flexibly
shared

54. 4.4. Harmonious AlignmentHarmonious Alignment
synchronous paradigm (antithesis of open
paradigm)
alignment with a common vision or
direction (channeless communication)
unified, parallel action through agreement
and shared knowledge
example: Amish barn raising

55. Strengths and WeaknessesStrengths and Weaknesses (Refer to(Refer to
Table 2)Table 2)
1. Traditional hierarchies
◦ strengths: stability and predictable
performance
◦ weaknesses: lack of innovation
2. Random paradigm organizations
◦ strength: creative invention
◦ weakness: not highly stable or efficient

56. Strengths and WeaknessesStrengths and Weaknesses (Refer to(Refer to
Table 2)Table 2)
3. Open paradigm organizations
◦ strengths: complex problem solving (sharing
of diverse opinions)
◦ weakness: slow due to debating issues.
4. Synchronous paradigm
◦ strength: efficiently perform established
procedures
◦ weakness: may not be highly responsive or
adaptive to change.

57. Team BuildingTeam Building (Refer to Table 3)(Refer to Table 3)
• activities to build group cohesive
• Effective team building helps a team establish an
appropriate organization and work culture
• means of increasing performance levels
• activities should be selected based on the organization,
management, and culture of the team

58. Want to achieve a cohesive team:Want to achieve a cohesive team:
objective for every project team
• synergy, jelled team (DeMarco and Lister)
• jelled teams:
• more productive and motivated
• share common goal and culture
• sense of eliteness

59. Project LeadershipProject Leadership
ideally, style of leadership should fit team
paradigm

60. Characteristics of managers by typeCharacteristics of managers by type
of team:of team:
1. Random teams - a respected member
of the team; a
charismatic leader; does not give orders
2. Open teams - supply structure that
helps keep team focused;
team players but also facilitators

61. Characteristics of managers by typeCharacteristics of managers by type
of team:of team:
3. Closed teams - strong leaders who
give clear directions;
manage by results
4. Synchronous teams - visionary
leaders; observe and monitor
performance and watch for changing
trends

62. None of the paradigms is ideal for softwareNone of the paradigms is ideal for software
development.development.
SW development requires
- complex analysis
- innovation
- predictable, routine tasks

63. Structured Open teams are:Structured Open teams are:
a hybrid of team paradigms
 a combination of closed (formal, fixed, or
hierarchical) and open (shared, flexible,
egalitarian) paradigms
 uses formal structures to promote flexibility
and efficient problem solving
catalog of essential team roles
formal specification of functional roles
default assignment of roles to assure essential
functions are performed

64. Structured Open teams are:Structured Open teams are:
rotation of roles
organized continuous record of what the
group does (structured,
externalized group memory)
clear and simple external accountability
technical consensus building
promotion of personal ownership

65. Problems in SW developmentProblems in SW development

66. layered behavioral model consists of thelayered behavioral model consists of the
following levels:following levels:
 1. Individual - analyzed as an intellectual task, subject to
the effects of motivational and cognitive processes.
 2. Team - social processes interact with cognitive and
motivational processes.
 3. Project - several teams integrating their work on
different parts of the same system.
 4. Company - analyzing how company goals, corporate
politics, culture and procedures affect the project.
 5. Business Milieu - looking at the overall business
environment such as other corporations, co-contractors,
customers, etc.

67. Implications for ProjectImplications for Project
ManagementManagement
Recruiting and training must be coupled
with team building to translate individual
talent into project success.

68. Project coordination techniques used:Project coordination techniques used:
Formal information exchange procedures
were used more when the projects were
certain and were in the planning stages.
Informal -interpersonal communication was
used frequently regardless of project size,
certainty, or life cycle stage.
Electronic communication was used when
projects were heavily dependent on input
from other groups in the company.

69. ImplicationsImplications
Personal communication is important for
successful coordination, but it may be too
expensive to be an effective communication
mechanism.
Software engineers must acquire information
from those who are remote
communication tools for conferences or
distributed meetings are likely to prove
more beneficial than FtF meetings

70. 3.33.3 ProblemProblem
dilemma of project manager
at beginning of project, quantitative
estimates and a project plan are needed
no detailed analysis of requirements at
this point to base these on
need to examine the problem to establish
scope and boundaries of problem

71. determine software scopedetermine software scope
first project management activity
to determine scope, make a high-level
surveillance of:
◦ context - how does sw fit into the larger
context of systems or business, what are the
constraints
◦ information objectives - what data objects are
required for input and produced as output
(analysis of inputs and outputs)
◦ functionality of sw

72. project decompositionproject decomposition
decompose complex problem into
smaller pieces
trying to put some structure to the
problem in order to make estimates and
complete high-level planning

73. ProcessProcess

74. 3.43.4 ProcessProcess
must select the process model that is
appropriate for the project at hand
refer to your process model

75. project managerproject manager
• decide on process model
• define preliminary plan based on process
model
• decompose process (add details to the
plan)

76. Resources and useful links:Resources and useful links:
www.pmi.org

77. Questions/AnswersQuestions/Answers
Thank you.