INTRODUCTION TO

SOFTWARE PROJECT MANAGEMENT

BY PANKAJ KAMTHAN

1. INTRODUCTION

Be Quick, Be Quiet, and Be On Time.

— Kelly Johnson

The significance of managing a project cannot be underscored enough. There is need for
proper project management in both educational and professional contexts [Kruchten,
2011; Bavota, De Lucia, Fasano, Oliveto, Zottoli, 2012; Villafiorita, 2014; Peters,
Moreno, 2015; Kittlaus, Fricker, 2017, Chapter 2; Jia, Xin, 2018; Ralph, 2018;
Sedelmaier, Landes, 2018; Fioravanti, Barbosa, 2019; Fioravanti, Maximiano, Barbosa,
2019; Johansen, Colomo-Palacios, Kristiansen, Samuelsen, 2019; Rojas, Mejía-Moncayo,
2019; Blair, 2020; Kasser, 2020; Mas, Mesquida, Colomo-Palacios, 2021; O’Regan,
2022, Chapter 4; Kuster, Bachmann, Hubmann, Lippmann, Schneider, 2023]. (For
example, project management is an essential component of the PMP Certification
Examination [Whitaker, 2016a; Whitaker, 2016b; Hunt, 2021].)

This document explores basic concepts and tenets of software project management. It
also discusses the changing nature of ‘conventional’ software project management due
to the continuing ascent and acceptance of agile methodologies.

2. BASIC DEFINITIONS

The meaning of ‘project’ and related terms must be clarified prior to making any
commitments based on these terms.

Definition [Organization] [ISO/IEC/IEEE, 2010; IEEE, 2014b]. [A] group of people

and facilities with an arrangement of responsibilities, authorities, and relationships.

1
For example, company, corporation, firm, enterprise, or institution, is an organization1.

For example, an organization could be a very small entity (VSE), which has ≤ 25
people, or a small-and-medium enterprise (SME), which has ≤ 250 people [ISO/IEC,
2016].

DEFINITION OF PROJECT

There are a number of definitions of a project, including the following:

Definition 1 [Project] [IEEE, 2011; PMI, 2013a]. A temporary endeavor undertaken

to create a unique product or service.

The Definition 1 is in common use [Maley, 2012].

Definition 2 [Project] [Wysocki, 2014]. A sequence of unique, complex, and connected

activities that have one goal or purpose and that must be completed by a specific time,
within budget, and according to specification.

The Definition 2 is a refinement of the Definition 1.

EXPLANATION

 Innovation. The project is supposed to pursue something new and useful [Kuster,
Bachmann, Hubmann, Lippmann, Schneider, 2023, Section 1.2].

 Delivery. The project’s end result is a demonstrable product or a service [Villafiorita,

2014].

 Temporary. The project has an end date. (This is being challenged in continuous
software engineering [Bosch, 2014].)

 Unique. The project’s end result is different than the results of other functions of the
organization.

 Resource-Constrained. The project is subject to constraints, such as time, budget,

and specification [Villafiorita, 2014].

1
There are a number of different terms in use: ‘Aktiebolag (AB)’ (Sweden), ‘company’ (Canada, U.S.A),
‘firm’ (U.S.A.), ‘corporation’ (Canada, U.S.A), ‘enterprise’, ‘Gesellschaft mit beschränkter Haftung
(GmbH)’ (Germany), and so on. The term ‘organization’ is used as a single overarching ‘umbrella’ term.

2
REMARKS

In an organization, a project must be aligned with its strategic objectives and be

delivering value, both of which are part of governance [Ebert, Vizcaíno, Manjavacas,
2020; Haes, Grembergen, Joshi, Huygh, 2020; Smallwood, 2020].

DEFINITION OF SOFTWARE PROJECT AND RELATED TERMS

Definition [Acquirer] [IEEE, 1998]. A stakeholder that acquires one or more project
deliverables from a supplier.

The acquirer is also known as client.

Definition [Supplier] [IEEE, 1998]. A stakeholder that develops one or more of the
project deliverables for an acquirer.

In other words, acquirer and supplier have a reciprocal binary relationship (that is, a
relationship in which one does not exist without the other).

Definition [Work Product] [IEEE, 1998]. A tangible item produced during the process
of developing or modifying software.

For example, software project plan, meeting minutes, software test plan, and defect
reports are work products. For example, test strategy developed before a software
project is initiated and applies to multiple software projects is not a work product.

The work products could be of two types: (1) those that will be baselined, and (2) those
that will form software project deliverables.

Definition [Baseline] [IEEE, 1998]. A work product that has been formally reviewed
and accepted by the involved parties.

For example, software project plan is a baseline. For another example, meeting minutes
is not a baseline.

Definition [Software Project Deliverable] [IEEE, 1998]. A work product to be

delivered by the supplier to the acquirer.

3
For example, software architecture description could be a software project deliverable.
For a non-example, a user survey questionnaire, a stakeholder mind map, or a UML
Class Diagram representing a part of the solution domain is usually not a software
project deliverable.

The delivery dates and delivery locations of a software project deliverable are specified
in a software project agreement. (If a software project deliverable is electronic, then, in a
software project agreement, it is not necessary to specify quantity of that software
project deliverable.)

Definition [Software Project Agreement] [IEEE, 1998]. A set of one or more

documents baselined by the acquirer and the supplier that specifies the conditions under
which the project will be conducted.

For example, a software project agreement may include items such as scope, objectives,
assumptions, schedule, resource and budget allocations, list of software project
deliverables, and acceptance criteria for the software project deliverables listed.

The software project agreement is usually part of the software project plan.

Definition [Milestone] [IEEE, 1998]. A scheduled event used to measure progress.

For example, acquirer sign-off, conclusion of integration testing, and completion of a

chapter of user manual are milestones.

Definition [Work Task] [IEEE, 1998]. The smallest unit of work subject to
management accountability.

For example, a one-on-one meeting between the project manager and a programmer
assigned to work on the software project is a work task.

A work task must be small enough to allow adequate planning and control of a software
project, but large enough to avoid micro-management. The work tasks that are related in
some way (say, semantically) are grouped to form work activities.

(In the context of software engineering, there can be different types of tasks. It is
important to distinguish between work task and user task.)

4
Mobile Intermezzo!

Use the Web to search for the meaning of “quark”.

Definition [Work Activity] [IEEE, 1998]. A collection of work tasks spanning a fixed
duration within the schedule of a software project.

For example, project planning, requirements elicitation, software design, implementation,

and testing are typical work activities.

A work activity may contain other work activities, as in a Work Breakdown Structure
(WBS). The lowest-level work activities in a hierarchy of activities are work tasks.

Definition [Supporting Process] [IEEE, 1998]. A collection of work activities that span
the entire duration of a software project.

For example, configuration management process, software documentation process,

and quality assurance process are supporting processes.

There are a number of definitions of a software project, including the following:

Definition [Software Project] [IEEE, 1998]. The set of work activities, both technical
and managerial, required to satisfy the terms and conditions of a project agreement. A
software project should have specific starting and ending dates, well-defined objectives
and constraints, established responsibilities, and a budget and schedule.

OBSERVATIONS

 A software project is governed.

 A software project has a goal. (The terms ‘goal’ and ‘requirement’ are not
synonymous.)
 A software project is monetarily bound.
 A software project is temporally bound.

5
Board Time!
Give a difference between goal and requirement.

DEFINITION OF PROJECT MANAGEMENT

There are a number of definitions of project management, including the following:

Definition [Project Management] [IEEE, 2011; PMI, 2013a]. The application of

knowledge, skills, tools, and techniques to project activities to meet the project
requirements.

It is important to distinguish between management of a project and management of a

software project [ISO/IEC/IEEE, 2009, Section 6.1; ISO/IEC/IEEE, 2019, Section 6.1;
Ahmed, 2012, Sections 1.3 and 1.5].

DEFINITION OF SOFTWARE PROJECT MANAGEMENT

There are a number of definitions of software project management. The following

definition relates (specifically, situates) software project management to project
management:

Definition [Software Project Management] [Greene, Stellman, 2005; Wikipedia].

The art and science of planning and leading software projects. It is a sub-discipline of
project management in which software projects are planned, implemented, monitored,
and controlled.

DEFINITION OF SOFTWARE ENGINEERING MANAGEMENT

There are a number of definitions of software engineering, including the following:

Definition [Software Engineering] [IEEE, 1990; ISO/IEC/IEEE, 2010].

(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software.
(2) The study of approaches as in (1).

6
Definition [Software Engineering Management] [ISO/IEC, 2005]. The application of
management activities—planning, coordinating, measuring, monitoring, controlling, and
reporting—to ensure that the development and maintenance of software is systematic,
disciplined, and quantified.

OBSERVATIONS

 The abovementioned definitions are mutually related.

 It follows that software engineering management is operationalization of software
engineering (that is, the practice of putting software engineering into operation).

2. MOTIVATION FOR COURSE SOFTWARE PROJECT IN A TEAM

ENVIRONMENT

The purpose of a course software project in a team is manifold [Hayes, Lethbridge, Port,
2003; Mohan, Merle, Jackson, Lannin, 2010; Hazzan, Lapidot, Ragonis, 2011; Kamthan,
2014; Li, Ko, Zhu, 2015; Kamthan, 2022], including the following:

 From Theory to Practice, and Back: To allow students to practice what they
learned in theory, which, in some cases, may even lead to revision of theory.

 Instillation of Soft Skills: To allow students to learn soft skills (such as to

communicate, collaborate, and negotiate) that are often not part of regular
curriculum, while working with the others, whom they may or may not know.

 Active and Collective Learning: To encourage students to learn in a social context:

to develop a habit of working with the others, to learn from each other, to motivate
each other, and to rely on each other.

 Collaborative Development: To help students learn critical aspects and typical

practices of current software development based inherently on collective work, such
as understanding the problem domain or developing a glossary.

 Improvement in Scale: To enable students to develop larger or more complex

software systems than would otherwise be possible.

 Parity with Industry: To provide students with an opportunity to gain experience in

working as part of a team, as is normally the case in an industrial environment.

7
 Alignment with Professional Organizations: To satisfy the recommendations of
accreditation boards and/or curriculum guidelines of a professional organization, such
as the ACM or the IEEE.

3. GOALS OF A SOFTWARE PROJECT

The following are non-mutually exclusive goals of a project:

1. Provability.
(a) To complete a project, successfully, in a team environment, that results in a ‘high-
quality’ product, within the stipulated constraints.
(b) To learn how to execute a process, effectively and efficiently, in order to
complete a project. This includes refinement of what works, and elimination of
what does not.

2. Posterity. To learn how to approach similar projects (in the future). (It is assumed
that the given project is not the last project a person is involved in.)

It could be noted that the goals are not only about completion but also about replication.
If the goals are unclear or impractical, then they should be revisited and modified
accordingly.

3. HISTORY AND EVOLUTION OF SOFTWARE PROJECT MANAGEMENT

In [Berkun, 2008; Ensmenger, 2010; Mistrík, Grundy, Hoek, Whitehead, 2010, Section
1.3.5; Stober, Hansmann, 2010, Section 2.1; Ruhe, Wohlin, 2014, Chapter 11;
Slaughter, 2014, Chapter 2; Cline, 2015, Chapter 1; Newton, 2018; Cortada, 2019], a
brief historical account of software project management as a sub-discipline of project
management is given. It forms, in part, the basis for Table 1.

Decade (Circa) Event

1940s Gantt Chart
1950s  Program Evaluation and Review Technique (PERT)
 Critical Path Method (CPM)
1960s  Establishment of the Project Management Institute
 Rise of Software Industry
1970s  “The Mythical Man-Month: Essays on Software Engineering”
 “Elements of Software Science”
1980s  “Software Engineering Economics”
 “Peopleware: Productive Projects and Teams”
 The Capability Maturity Model for Software (CMM)

8
 1990s  The Standish Group CHAOS Reports
 IEEE Standards for Software Project Management
2000s  Convergence of the Software Project Management Initiatives of
Standards Organizations
 Emergence/Prominence of Specific Areas (Change
Management, Configuration Management, Defect Management,
Requirements Management, Risk Management, Other)
 Models for Agile Project Management
 (More) Factors related to Success, Failure, and Recovery of
Software Projects
 (Calibration of) Metrics based on Actual Data
 Models for Software as a Business
 Increasing Attention on Variability among Stakeholders
 Studies on Cognitive and Behavioral Psychology of the
Members of Software Project Teams
2010s  Increasing Attention on Soft Skills
 Studies on Sociology of the Members of Software Project Teams
 Increasing Awareness of Social Responsibility (Impact of
Software on Society)
 Increasing Awareness of Equity, Diversity, and Inclusivity in
Software Project Teams

Table 1. A brief time line of significant events related to (software) project management.

4. ORGANIZATIONAL SUPPORT FOR SOFTWARE PROJECT

MANAGEMENT

There is support for software project management at national and international levels,
albeit with varying degrees.

IEEE

The Institute of Electrical and Electronics Engineers (IEEE) is “a professional

association for the advancement of the theory and practice of Electrical, Electronics,
Communications and Computer Engineering, as well as Computer Science, the allied
branches of engineering and the related arts and sciences”.

9
The standards from IEEE related directly to software project management include the
following:

 IEEE Standard 1058-1998

 IEEE Standard 1062-1998
 IEEE Standard 1490-2011

IIBA

The International Institute of Business Analysis (IIBA) is “a non-profit professional

association with the purpose of supporting and promoting the discipline of business
analysis” [Wikipedia].

The standards from IIBA related directly to software project management include the
following:

 BABOK®
 Agile Extension to the BABOK® Guide

IPMA

The International Project Management Association (IPMA)2 is “a non-profit,

registered organization for the promotion of project management internationally. The
IPMA is a federation of more than 50 national and internationally oriented project
management associations [...] It provides standards and establishes guidelines for the
work of project management professionals [...]”.

ISO/IEC

2
URL: [Link] .

10
The International Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC) are “international standard-setting bodies
composed of representatives from various national standards organizations”.

The standards from the ISO and the IEC related directly to software project management
include the following:

 ISO/IEC 9000-3
 ISO/IEC 16085
 ISO/IEC TR 19759
 ISO/IEC/IEEE 16326

PMI

The Project Management Institute (PMI) is “a not-for-profit professional organization

for the project management profession with the purpose of advancing project
management” [Wikipedia].

[It] “offers a range of services to the project management profession such as the
development of standards, research, education, publication, local chapters, hosting
conferences, and training seminars, and credentials in project management” [Wikipedia].

The standards from PMI related directly to software project management include the
following:

 PMBOK Guide
 Agile Practice Guide

5. SOURCES OF KNOWLEDGE ON SOFTWARE PROJECT MANAGEMENT

There are a number of sources of knowledge on software project management [Marques,

Ochoa, 2013a; Kuster, Bachmann, Hubmann, Lippmann, Schneider, 2023, Section 1.8].

11
5.1. BODIES OF KNOWLEDGE ON SOFTWARE PROJECT MANAGEMENT

The term Body of Knowledge (BOK or BoK) is used to “represent the complete set of
concepts, terms and activities that make up a professional domain, as defined by the
relevant professional association”.

There are several BOKs for (software) project management [Dinsmore, Cabanis-Brewin,
2014, Chapter 2], originating from different organizations, in different countries.

BABOK®

The Guide to the Business Analysis Body of Knowledge (BABOK) is “the collection
of business analysis knowledge reflecting current best practice, providing a framework
that describes the areas of knowledge, with associated activities and tasks and techniques
required” [IIBA, 2009].

The Agile Extension to the BABOK® Guide “describes business analysis areas of
knowledge, their associated activities and tasks, and the skills necessary to be effective in
their execution within the framework of agile software development” [IIBA, 2013].

PMBOK®

12
The Guide to the Project Management Body of Knowledge (PMBOK® Guide)
“presents a set of standard terminology and guidelines for project management”
[Wikipedia]. The PMBOK® Guide, Fourth Edition [PMI, 2008], has been adopted by the
IEEE as the IEEE Standard 1490 [IEEE, 2011]. The current version of the PMBOK®
Guide is [PMI, 2021].

The Software Extension to the PMBOK® Guide Fifth Edition [PMI, 2013b] provides
readers “a balanced view of methods, tools, and techniques for managing software
projects across the life cycle continuum from highly predictive life cycles to highly
adaptive life cycles”.

The Agile Practice Guide [PMI, 2017b] is a collaborative effort by the Project
Management Institute (PMI) and Agile Alliance® [and] provides “practical guidance
geared toward project leaders and team members adapting to an agile approach in
planning and executing projects”.

13
SWEBOK

The Guide to the Software Engineering Body of Knowledge (SWEBOK)3 [ISO/IEC,

2005] “describes the sum of knowledge within the profession of software engineering”.

SWEBOK continues to evolve. The latest version of SWEBOK is SWEBOK3 [IEEE,

2014a].

The purpose of the SWEBOK3 is “to describe what portion of the Body of Knowledge is
generally accepted, to organize that portion, and to provide a topical access to it”.
SWEBOK can be used for software project management education [Farooq, Omer,
Tehseen, Nisah, 2021].

5.2. PRINCIPLES FOR SOFTWARE PROJECT MANAGEMENT

To manage a software-intensive business, it has been suggested that certain (software)

(project) management principles be observed [Gilb, Finzi, 1988; Humphrey, 2002;
Endres, Rombach, 2003; Humphrey, Over, 2011; Wallace, 2016; Jones, 2017]. These
principles may seem obvious, but they are not platitudinous.

Principle 1: Recognize that you are in the Software Business

The software delivery schedule affects software delivery dates, and software delivery
dates drive cost, revenue, and profit [Kittlaus, Fricker, 2017, Section 2.3.1]. It is not
possible to manage a business unless one can manage revenue and profit.

3
URL: [Link] .

14
Principle 2: A Project Without Clear Goals Will Not Achieve its Goals Clearly

This principle underscores the importance of the clarity of product vision and product
requirements.

Principle 3: Quality must be the Top Priority

In carrying out a software project, the quality-related problems overwhelm all other
kinds of problems. It is important to make an explicit commitment to quality. For
example, such commitment can come in form of proper training4, adopting proper
techniques and tools, and making quality forethought.

Principle 4: Quality Software is Developed by Disciplined and Motivated People

It is known that software development is intellectual work, and undisciplined or

unmotivated people cannot do timely or predictable intellectual work [Martin, 2011,
Chapter 1; Kittlaus, Fricker, 2017, Section 2.2].

However, one of the challenges in software engineering is that the speed at which
knowledge changes is greater than the speed at which knowledge is acquired. This
prompts the need for continuous learning.

Principle 5: The Software Project Schedules have a Fixed Point of Maximum

Compressibility

This principle suggests that beyond a certain point, schedules can no longer be
shortened and still be able to preserve the same level of scope and quality, no matter how
many or what kinds of resources are applied. (The schedules, if shortened beyond
necessary, can come at an unacceptable cost, such as sacrificing one of the
requirements engineering principles [Pinheiro, 2002; Pinheiro, 2003].) (The specifics
of such a point are given by the “Paul Masson Point”.)

Principle 6: The Structure of Software reflects the Structure of the Organization

This principle suggests that organizations that are (not) well-organized will produce
software that is also (not) well-organized. (This is a variant of the “Conway’s Law”.)

4
URL: [Link] .

15
Principle 7: Be Humble

This principle acknowledges that no single individual knows everything or can predict
everything, and that software development can be holistic (that is, the whole is greater
than the sum of parts). It, again, advocates the need for continuous learning. Finally,
credit for other people’s work should be given where it is due.

Principle 8: The Fail-Safe Minimization Principle

“If you do not know what you are doing, do not do it on a large scale.” This principle
aims to mitigate risk, and is an incentive for iterative and incremental development,
and prototyping.

Board Time!
 Give a reason for making quality forethought.
 Give a situation in software development when a software engineer does not know
what he or she is doing. Explain.

Mobile Intermezzo!
Use the Web to search for “Conway’s Law”.

5.3. PATTERNS AND ANTI-PATTERNS FOR SOFTWARE PROJECT

MANAGEMENT

The software project management could be viewed as the following collection:

{(Problemm , Solutionm, n), m ≥ 1, n ≥ 0},

where m and n are indices.

16
Indeed, Project Management Is Problem Management is among the 97 Things Every
Project Manager Should Know [Unger, 2009].

It is assumed that the problems and their solutions are based upon and elicited from
extrospection (say, experience), not introspection or speculation.

For a given problem in some context, certain solutions are ‘good’ and certain solutions
are ‘bad’.

For example, if one has to go from Montreal to Ottawa, and be there in 2 hours, then
seeking a random hitch is ‘bad’ solution.

The ‘good’ problem-solution combinations are candidates for patterns, and the ‘bad’
problem-solution combinations are candidates for anti-patterns.

There are collections of patterns [Coplien, Harrison, 2005; Välimäki, 2011, Appendix
C] and anti-patterns [Brown, Malveau, McCormick, Mowbray, 1998; Brown,
McCormick, Thomas, 2000; Laplante, Neill, 2006; Stamelos, 2010] for software project
management.

The notion of anti-pattern has motivated similar bodies of knowledge5.

5.4. PITFALLS OF (SOFTWARE) PROJECT MANAGEMENT

In [Wiefling, 2007], the following 12 pitfalls of (software) project management have

been highlighted and detailed, somewhat wittingly, even humorously, but convincingly:

1. Be Completely and Unrepentantly Obsessed with the Customer

2. Provide Shared, Measurable, Challenging, and Achievable Goals as Clear as

Sunlight

5
There are a number of thinklets related to software project management [Marques, Ochoa, 2013b]. A
thinklet is similar to an anti-pattern in its statement of a problem, but is different from an anti-pattern in its
style of a solution. A thinklet consists of a problem, corrective action, and one or more practices to realize
that corrective action.

17
3. Engage in Effective, Vociferous, Unrelenting Communication with All
Stakeholders

4. Ensure that Roles and Responsibilities are Unmistakably Understood and Agreed
Upon by All

5. Create Viable Plans and Schedules that Enjoy the Team’s Hearty Commitment

6. Mitigate Big, Hairy, Abominable Risks, and Implement Innovative Accelerators

7. Prioritize Ruthlessly, Choosing Between Heart, Lungs, and Kidneys if Necessary

8. Anticipate and Accommodate Necessary and Inevitable Change

9. Challenge Assumptions and Beliefs, Especially Insidious Self-Imposed Limitations

10. Manage the Expectations of All Stakeholders: Under-Promise and Over-Deliver

11. Learn from Experience. Make New and More Exciting Mistakes Each Time!

12. Attitude of Gratitude: Celebrate Project Success... And Some Failures6, Too!

REMARKS

The ‘pitfalls’ are the opposite of the above.

Board Time!
 Explain why the goals should be measurable.
 Give a negative side-effect of being obsessed with the customer.
 Give a negative side-effect of under-promise and over-deliver.

6
(There are merits of failure [McGrath, 2011].)

18
5.5. OTHER

There are a number of common problems and solutions related to project management,
made available publicly in the form of 101 Project Management Problems and How to
Solve Them: Practical Advice for Handling Real-World Project Challenges
[Kendrick, 2011].

There are a number of lessons related to software project management, made available
publicly in the form of 97 Things Every Project Manager Should Know [Unger, 2009]
and 97 Things Every Engineering Manager Should Know [Fournier, 2020].

Mobile Intermezzo!
Use the Web to access “Kelly’s 14 Rules and Practices”7, and check which rules are
applicable to software projects.

7
URL: [Link]
[Link] .

19
6. CHARACTERISTICS OF A SOFTWARE PROJECT

Let X be a thing. In order to understand the management of X, it is necessary to

understand X.

6.1. REASONS FOR UNIQUENESS OF SOFTWARE PROJECT MANAGEMENT

From a project management perspective, software project management is a specialized

sub-discipline.

However, there are certain aspects that make the management of software projects
unique, and these aspects can be determinants in the success of these projects [Jones,
1998; McDonald, 2001; ISO/IEC, 2005; Stepanek, 2012; Ahmed, 2012, Sections 1.3 and
1.5; Sudhakar, 2012; Ruhe, Wohlin, 2014, Section 1.2; Fioravanti, Barbosa, 2019]:

 Nature of Software
 Piecemeal Growth
 Creativity
 Controllability

6.1.1. NATURE OF SOFTWARE

There are certain characteristics of a software system that are different, even unique,
across engineering inventions [Brooks, 1987; Hughes, Cotterell, 2009, Section 1.4;
Monson-Haefel, 2009; Srikantaiah, Koenig, Hawamdeh, 2010, Table 4.1; Basili, 2011;
Reifer, 2014, Chapter 1; Ruhe, Wohlin, 2014, Section 11.6; Kittlaus, Fricker, 2017,
Section 2.2].

EXAMPLE

For example, a software system is virtual, malleable, intangible, requires continuous

supply of electricity, can be geographically dispersed, can be copied at essentially no
cost, can be reused (simultaneously by multiple different software systems, and
simultaneously by multiple users), can be extended (even merely by virtue of usage, not
to mention the possibility of real-time upgrades), does not have physical properties, is
not subject to physical laws, and so on.

Therefore, evidently, management of software also has its unique characteristics and
challenges.

20
Board Time!
Give a consequence of software being malleable. (Hint: Software in itself is neither
‘good’ nor ‘bad’!)

6.1.2. PIECEMEAL GROWTH

In many cases, the boundary of the problem, of which the software is the solution,
cannot be ascertained a priori, at the beginning of the software project. For example, a
software project that aims to produce an interactive software system is such a project.

EXAMPLE

For the sake of argument, consider the case of software requirements. It is almost
inevitable that the software engineering processes, themselves, will generate the need for
new or changed client requirements. (For example, prototyping is one means to elicit
requirements, thereby leading to an understanding of the boundary [Ochodek,
Kopczyńska, 2018].)

In other words, the requirements of many software systems are inherently dynamic.
(The collection of software requirements is not a shopping list, assuming even that stays
static.)

The requirements are usually unclear and incomplete in the beginning, and become
increasingly clear and increasingly complete over time, as illustrated in Figure 1. This
results in a piecemeal growth of the software system.

Figure 1. The nature of requirement engineering processes for typical interactive

software systems.

21
REMARKS

 The inevitable change in software requirements [Berry, 2002] calls for attention to
(software requirements) change management [Jayatilleke, Lai, 2018]. Indeed, much
of change management pertains to requirements management [Hull, Jackson, Dick,
2011, Section 8.2].

 For software projects that are prone to change due to external circumstances, the
software engineering processes need to be reactive, adaptive, and iterative. In some
cases, such processes can also be recursive. (For example, software engineering
processes inherent to agile methodologies are supposed to have these capabilities.)

Board Time!
Give an example of a process that are reactive, adaptive, iterative, and recursive.

6.1.3. CREATIVITY

In general, software engineering processes cannot be completely automated

(mechanized).

There is a necessary human and/or social element of innovativeness (or inventiveness).

EXAMPLE

It is understood that many software engineering activities are collaborative in nature, and
require creativity to be successful [Kliem, 2014]. For example, game software
development, (problem and solution) domain modeling, description of user stories,
and user experience (UX) design, are all creative processes.

6.1.4. CONTROLLABILITY

It is important for a project manager to separate aspects of the project that are
controllable from that are non-controllable [Reifer, 2014, Chapter 1].

The most significant, and possibly the most difficult, change for most organizations is
to give up the need for control [Armour, 2001]. This is because, at least to some degree,
most organizations cannot control the outcome most of the time. Trying to control is not
the same thing as being in control [Kua, 2009].

22
Indeed, Scope Change Happens; Get Used to It [Simsa, 2009] and the Fallacy of the
Big Round Ball8 [Wood, 2009] are among the 97 Things Every Project Manager
Should Know.

EXAMPLE 1

The governmental laws could be unanticipated, and usually not within the control of
project managers. For example, to abide by a new law, the next release of a product may
need to satisfy certain accessibility requirements.

EXAMPLE 2

The requirements, especially those originating from customers or users, are not
always within the control of project managers, and are prone to change.

An obsolete software requirement is a software requirement (implemented or not) that

is no longer required for the current release or future releases and has little or no business
value [Harris, 2018] for the potential customers or users of a software product [Wnuka,
Gorschek, Zahda, 2013]. It has been pointed out in an empirical study that change in
software requirements can be unusually expensive, and that customers or user
software requirements are among those that are prone to change [Wnuka, Gorschek,
Zahda, 2013].

EXAMPLE 3

Usually, new industrial software is not built from scratch, starting from nothing. For
example, industrial software depends on existing technology: programming languages,
markup languages, application programming interfaces (APIs), libraries, and so on.

The technology underlying design or implementation is usually not within the control
of software engineers, and is prone to change, sometimes unannounced and rather
quickly (as opposed to other engineering disciplines). Furthermore, a complete
insulation against variability in technology may not be possible. (For example,
application software resides on the top of system software, such as an operating system.
Therefore, if there is a change in the operating system, then that change may affect the
application software.)

8
The Fallacy of the Big Round Ball is the “delusion that software requirements do not change
appreciably after delivery or, worse, that they can be controlled”.

23
If there is a change in the foundation, then any development resting on that foundation
needs to adapt accordingly. This is neither trivial, nor automatic. The result can have a
cascading effect. For example, removing an implementation of a technology construct
deemed obsolete in one place, can adversely impact the parts that depends on it at another
place. (This propagation is similar to regression.)

6.2. A CLASSIFICATION OF SOFTWARE PROJECTS

The nature of a software project determines how that project should be pursued. Figure 2
shows one possible classification of projects. This two-dimensional classification is
inspired by the Stacey’s Complexity Model [Appelo, 2011, Chapter 3; PMI, 2017b,
Section 2.4].

Figure 2. A two-dimensional classification of software projects.

The two dimensions are:

1. Problem Domain Uncertainty (Uncertainty in “What”): This is about uncertainty

in the knowledge of the problem domain, specifically uncertainty in requirements.

2. Solution Domain Uncertainty (Uncertainty in “How”): This is about uncertainty in

the knowledge of the solution domain, specifically uncertainty in technique or
technology.

24
The four classes of software projects are:

1. Simple: For these software projects, it is easy to understand at the outset what is to be
done and how it to be done. The level of uncertainty is relatively low. For example,
such a software project could be about developing an e-mail client.

2. Complicated: For these software projects, it is not easy to understand at the outset
what is to be done and/or how it to be done. The level of uncertainty is medium. For
example, such a software project could be about developing a Web user agent.

3. Complex: For these software projects, it is not only not easy to understand at the
outset what is to be done and/or how it to be done, but also whatever is understood
can itself change frequently and unexpectedly over time. The level of uncertainty is
relatively high. For example, such a software project could be about developing a
public social network.

4. Chaotic: For these software projects, it is preferable not to pursue them unless
absolutely necessary, because such projects are very risky. The level of uncertainty
is relatively very high. For example, such a software project could be a ‘Death
March’ [Yourdon, 2003]. There have been reports of such software projects9.

6.2.1. TYPES OF COMPLEXITY IN SOFTWARE PROJECTS

There can be at least three types of complexities in software projects [Maylor, Turner,
Murray-Webster, 2013]:

1. Structural Complexity: This is about the size, scope, and interdependence of tasks
and personnel.

2. Sociopolitical Complexity: This is about the importance of the project to the

organization, people, power, and politics within and outside of the organization, and
conflicting agendas within the stakeholder community [Wendorff, 2022].

3. Emergent Complexity: This is about the uncertainty of the outcome, lack of

experience with the problem (application) domain or technology, lack of information,
or some combination of these.

9
URL: [Link] .

25
Board Time!

Ask ChatGPT: “Explain what emergent phenomenon is. Give examples of emergent
phenomena in a software engineering context.”.

6.3. THE ‘EQUILIBRIUM TRIANGLE’

The biggest difference between time and space is that you can’t reuse time.
― Merrick Furst

The following five constraints apply to every project [Wiegers, 1996; Wysocki, 2014,
Chapter 1], and therefore to a software project:

1. Scope: This is about the boundary of the software project. This mean the scope not
only makes it clear what is inside the boundary, but also what is outside that
boundary.

2. Quality: This is about process quality as well as product quality.

3. Cost: This is about the cost of the software project in monetary terms, and usually
considered equivalent to the budget available to complete the project. In some cases,
the client has a predetermined budget; in other cases, the software project manager
proposes an estimate of cost. This is one of the constraints that determine whether the
software project is to be initiated at all.

4. Time: This is about the window of time within which the project must be completed.
A unique aspect of time is that it cannot be inventoried, meaning it is consumed
whether it is used or not.

5. Resources: This is about the consumables (including techniques, technologies, tools,

and so on) used on the software project. (In some cases, people are also considered as
resources.) The resources could be physical or digital. The resources for the software
project could be leased if necessary.

26
Board Time!
Give another constraint that determines whether the software project is to be launched at
all.

The notion of ‘equilibrium’ means that a software project is viewed as a dynamic rather
than a static entity.

The abovementioned constraints form an interdependent set in the sense that a change in
one constraint can require a change in another constraint in order to restore the
equilibrium of the project [Ford, Parsons, Kua, 2017, Chapter 1].

In this context, the set of five constraints form a system that must remain in balance for
the project to be in balance. It is this balance (or imbalance) that is important to the
success (or failure, respectively) of the project.

The constraints and the notion of balance can be represented as an equilateral triangle,
as shown in Figure 3.

Figure 3. A conceptual model depicted as an equilateral triangle to represent the need for
balance among the indispensable, minimal, constraints of a project.

EXPLANATION

 Area: The shaded area inside the triangle represents the scope and quality of the
project.
 Lines: They represent time, cost, and resource availability, and bound scope and
quality.

27
The following is one example of the negation of the above mentioned constraints:

 Over Scope or Under Scope

 ‘Poor’ Quality
 Over Allocated Time (Delayed)
 Over Budget
 Waste of Resources

Definition [Boondoggle] [Wikipedia]. A project that is considered a waste of both time

and money, yet is often continued due to extraneous policy or political motivations.

REMARKS

 The origins of the (aforementioned) equilibrium triangle go back to late 1960s [Ruhe,
Wohlin, 2014, Chapter 2]. (The triangle was not specific to software projects, and the
labels used for constraints were different.)

 The equilibrium triangle is simplistic [Ruhe, Wohlin, 2014, Chapter 2].

 The equilibrium triangle is the Holy Trinity of Project Management, and is one of
the 97 Things Every Project Manager Should Know [Waggoner, 2009].

 The significance (say, weight) associated with each constraint in the equilibrium
triangle can vary during a software development life cycle [Kerzner, 2014, Chapter 1;
Ruhe, Wohlin, 2014, Chapter 2].

 The equilibrium triangle can have a number of possible variations (for example,
quality could be considered a part of scope) [Cobb, 2011; Trendowicz, Jeffery,
2014, Section 2.2.1]. If scope and quality are separated, or if risk is added as
another constraint, then the result is the equilibrium diamond.

 In rigid software development, the equilibrium triangle is known as the Iron

Triangle10. In agile software development, the equilibrium triangle is known as the
Elastic Triangle11.

10
URL: [Link] .
11
URL: [Link] .

28
6.3. THE GOOD, THE BAD, AND THE UGLY

There are political and promotional aspects of (software) project management [Glass,
2002; IEEE, 2011; Rost, Glass, 2011; Langer, 2012; Lopp, 2021]. However, discussion
of these is beyond the scope of this document.

7. UNDERSTANDING SOFTWARE ENGINEERING MANAGEMENT

The purpose of a conceptual model of a thing is to provide an understanding of that

thing. The formulation of a conceptual model of a thing is especially useful if that thing is
non-trivial.

7.1. SOFTWARE ENGINEERING MANAGEMENT: MODEL I

Figure 4(a) provides an early idea of the context of software project management. Figure
4(b) presents a conceptual model for software engineering management.

(a)

29
 (b)

Figure 4. The elements of software engineering management, shown in (b), can be

derived from the elements of software engineering, shown in (a).

The elements, along with their interrelationships, are inspired by the different viewpoints
of software engineering given by the IEEE Software and Systems Engineering
Standards Committee.

The conceptual model of Figure 4 is rather abstract. However, as seen later, a conceptual
model can reveal other, more detailed (or more granular), aspects of software
engineering management.

7.2. SOFTWARE ENGINEERING MANAGEMENT: MODEL II

In SWEBOK, there are a number of Knowledge Areas (KAs). Software Engineering

Management is one of the KA, as illustrated in Figure 5.

30
Figure 5. Software Engineering Management is a Knowledge Area in the Guide to the
Software Engineering Body of Knowledge (SWEBOK). (Source: SWEBOK3 [IEEE,
2014a].)

The Software Engineering Management KA is further decomposed into sub-areas.

SWEBOK3 has seven sub-areas:

1. Initiation and Scope Definition. This sub-area addresses issues related to the
decision to initiate a software engineering project.

2. Software Project Planning. This sub-area addresses issues related to the activities
undertaken to prepare for successful software engineering from a management
perspective.

3. Software Project Enactment. This sub-area addresses issues related to the generally
accepted software engineering management activities that occur during software
engineering.

31
4. Review and Evaluation. This sub-area addresses issues related to the assurance that
the software is satisfactory.

5. Closure. This sub-area addresses issues related to the post-completion activities of a

software engineering project.

6. Software Engineering Measurement. This sub-area addresses issues related to the

effective development and implementation of measurement programs in software
engineering organization. It has been pointed out in SWEBOK2 [ISO/IEC, 2005] that,
“in essence, management without measurement, qualitative and quantitative,
suggests a lack of rigor; measurement without management suggests a lack of
purpose or context”. Therefore, measurement-informed management is an
assumed principle of software engineering management.

7. Software Engineering Management Tools. This sub-area addresses issues related to

the selection and use of tools to manage a software engineering project.

OBSERVATIONS

 The sub-areas 1-6 are part of SWEBOK2. The sub-area 7 is part of SWEBOK3.

 There is no Software Project Management KA or sub-area per se. Software Project

Management is subsumed by a union of multiple sub-areas in Software
Engineering Management KA.

 The organization is spatial, but, to a certain extent, also temporal. In particular, the
activities pertaining to the sub-areas 1-5 are conducted in a sequential order.

8. AGILE (SOFTWARE) PROJECT MANAGEMENT

In the past decade or so, agile methodologies have brought notable changes to software
engineering. This movement has given rise to agile (software) project management
[Chin, 2004; Nerur, Mahapatra, Mangalaraj, 2005; Augustine, Payne, Sencindiver,
Woodcock, 2005; Gómez, Núñez, 2008; Highsmith, 2009; Wysocki, 2009, Chapter 11;,
2011; Moreira, 2013; Ruhe, Wohlin, 2014, Chapter 11; Wysocki, 2014, Chapter 10;
Cline, 2015; Cobb, 2015; Crowder, Friess, 2015; Layton, Ostermiller, 2017; Kuster,
Bachmann, Hubmann, Lippmann, Schneider, 2023, Section 1.4].

32
8.1. AGILE (SOFTWARE) PROJECT MANAGEMENT AND PMBOK

For more than a decade following the announcement of the Agile Manifesto, there was
no explicit “official” support for software development methodologies or for the
agile methodologies in the PMBOK Guide, although there were a number of efforts to
align the understanding of software project management as per PMBOK Guide and agile
methodologies [Chin, 2004; Fitsilis, 2008; Sliger, Broderick, 2008; Cobb, 2011, Pages
124-130].

This situation changed in two ways.

INITIATIVE 1: FROM GENERAL PROJECT MANAGEMENT TO SOFTWARE

PROJECT MANAGEMENT

In theory, the PMBOK Guide is applicable to any project, and therefore its principles and
practices should apply to any software project. However, in practice, software is unique
and therefore the management of software projects is also unique.

The Software Extension to the PMBOK [PMI, 2013b] is an attempt to ‘tailor’

established project management body of knowledge so that it becomes suitable for
software project management.

The PMBOK Guide along with its Software Extension advocate predictive over
generative approach to (software) development, and is (therefore) oriented towards rigid
methodologies.

Board Time!
Give a difference between predictive and generative approach to software development.

INITIATIVE 2: FROM SOFTWARE PROJECT MANAGEMENT TO AGILE

SOFTWARE PROJECT MANAGEMENT

The Agile Practice Guide [PMI, 2017b] is an attempt to ‘tailor’ established project
management body of knowledge so that it becomes suitable for agile project management
for products including, but not limited to, software.

33
8.2. AN AGILE (SOFTWARE) PROJECT MANAGEMENT MODEL

In [Highsmith, 2009; Cobb, 2011, Pages 120-123], a conceptual model for agile project
management (abbreviated as APM) is proposed. The APM provides an Envision-
Speculate-Explore-Adapt-Close structure of execution and adaptation, as shown in
Figure 6.

Figure 6. A conceptual model for the agile (software) project management (APM).
(Source: [Highsmith, 2009, Chapter 5].)

1. Envision12. The objective of the Envision Phase is to determine the product vision
and product objectives and constraints, the project community, and how the team will
work together.

2. Speculate. The objective of the Speculate Phase is to develop a plan for how the
vision will be delivered. The plan might be based on releases, features, or
capabilities.

12
To establish a shared vision for the project is one of the most important practices agile requirements
engineering practices, as reported by empirical studies [Ochodek, Kopczyńska, 2018].

34
 The features and capabilities might be expressed in a variety of different forms such
as user stories (or lightweight use cases), but, in this phase, will typically be limited
only to high-level descriptions sufficient

(a) to identify what is required, and

(b) to develop a rough estimate of the level of effort associated with it.

These features and capabilities will normally become the Product Backlog. This
phase will be revisited after the completion of each iteration (during Explore/Adapt
Phase) to refine, redefine, and reprioritize the Product Backlog and the Release
Plan based on the results of the previous iteration.

3. Explore. The objective of the Explore Phase is to plan and deliver running, tested
features (user stories) in a short iteration. That effort consists of further defining the
detailed requirements associated with each feature or story, as well as designing
developing, and testing, the functionality required.

4. Adapt. The objective of the Adapt Phase is to review the delivered results, the current
situation, and the team’s performance and adapt as necessary [Dingsøyr, 2021].

5. Close. The objective of the Close Phase is to conclude the project, (optionally)
perform a retrospective13, and summarize lessons learned.

Board Time!
Give an aspect of APM that makes it relevant to agile methodologies.

8.3. PRINCIPLES OF AGILE PROJECT MANAGEMENT

It is interesting to note that APM aligns well with a collection of socio-technical

principles of agile (software) project management [Ruhe, Wohlin, 2014, Section 11.6;
Alami, Krancher, Paasivaara, 2022; Doglio, 2022, Section 8.5]:

 Minimum Critical Specification: The team members understand that no more

should be specified than is absolutely essential and critical to overall success.

13
URL: [Link] .

35
 Autonomous Teams: The teams are autonomous (meaning, self-managing team with
shared leadership and shared decision making), and are responsible for managing and
monitoring their own processes and executing tasks.

 Redundancy: The team members are skilled in more than one function.

 Feedback and Learning: The team members understand feedback and learning (say,
through daily stand-up and retrospective meetings, and knowledge sharing) are
integral to project execution and the project’s interaction with the environment.

 Technical Excellence: The team members are encouraged to aim for technical
excellence through continual attention to learning, team, and sustainable code.

Board Time!
Give a reason for redundancy.

8.4. AGILE METHODOLOGIES IN CONTEXT

From a project management perspective, there are advantages as well as disadvantages

of adopting agile methodologies.

EXAMPLE

For example, in [Ceschi, Sillitti, Succi, Panfilis, 2005], the context and results of a survey
of 20 software projects, 10 deploying agile methodologies, are reported. Figure 7 depicts
a portion of the results.

(a)

36
 (b)

Figure 7. (a) The primary software development problems versus the % of companies.
(b) The typical problems versus the % of companies. (Source: [Ceschi, Sillitti, Succi,
Panfilis, 2005].)

Legend for Figure 7:

DSWAFOT Difficulty to Deliver the Software With All Required Functions On Time
LQS Lack of Qualified Staff
HC High Competition
RWC Relationship With Customers
EDC Excessive Documentation of Code
DMRWD Difficulty in Managing Relationships Within the Development Group
HTE High Turnover of Employees
VR Variable Requirements
RDPTQ Request to Deliver Product Too Quickly
UC Unsatisfied Clients
UF Too Many Useless Features
O Other

It can be observed from Figure 7 that the problems of Lack of Qualified Staff (LQS)
and Useless Features (UF) are more severe in agile methodologies than in rigid
methodologies.

37
9. MANAGEMENT ROLES AND RESPONSIBILITIES IN SOFTWARE
ENGINEERING

9.1. ROLES

In the context of software projects, there can be different types of roles. The labels
associated with these roles can vary between ‘traditional’ project management and agile
project management.

Examples of Methodology-Independent Roles:

 Software Project Manager

 Software Quality Assurance Coordinator
 Team Lead (or Team Leader)

Examples of Methodology-Specific Roles:

 Product Owner
 Scrum Master

(It is evident that above examples are not exhaustive.) The set of roles is a subset of the
set of stakeholders of a software project.

9.2. RESPONSIBILITIES

The responsibilities associated with the roles are, evidently, different, but may overlap.

EXAMPLE

For example, in the context of Scrum project management, both Product Owner and
Scrum Master are responsible for daily meetings, albeit in different ways. For another
example, both Product Owner and Scrum Master are responsible for user stories for a
software system, albeit in different ways.

10. SOFTWARE PROJECT MANAGER

It could be noted that ‘software project manager’ may or may not be a title. Indeed,
broadly-defined, any person involved in a project management activity can play the
‘role’ of a software project manager [Rivera-Ibarra, Rodríguez-Jacobo, Fernández-
Zepeda, Serrano-Vargas, 2010].

38
EXAMPLE

A project management activity could be any of the following [Berkun, 2008]: leading
the team in figuring the project out (planning, scheduling, and requirements eliciting),
shepherding the project through design and development (communication, decision
making, and mid-game strategy), and driving the project through to completion
(leadership, crisis management, and end-game strategy).

10.1. SOFTWARE PROJECT MANAGER: “WHAT’S IN A NAME?”

In recent years, other roles similar to ‘project manager’ have emerged [Pranam, 2018,
Chapter 1; Tennant, 2022, Chapter 1]. Table 2 provides a preliminary, high-level,
comparison.

Program Manager Project Manager Product Manager

 Responsible for  Responsible for a single  Responsible for a single
multiple projects of project of an project of an
an organization that organization. organization.
have a common goal.  Responsible for  Responsible for success
specifying project or failure of a product.
constraints14.  Responsible for
 Responsible for creating representing the
a work breakdown customer.
structure.
 Responsible for
identifying and
allocating tasks.
 Responsible for
scheduling.
 Responsible for being a
custodian and looking
out for the welfare of
the team members15.
 Responsible for
monitoring the progress
of the project.

14
This usually is a shared responsibility.
15
This usually is a shared responsibility.

39
  Responsible for the
outcome of the project.

Table 2. A comparison between program manager, project manager, and product

manager.

10.2. SKILLS OF A SOFTWARE PROJECT MANAGER

We lead not by the example of our power, but by the power of our example.
― Joseph R. Biden, Jr.

I am not young enough to know everything.

― Scott Berkun

Human beings’ cognitive limits mean that no manager can understand all aspects of the
business—but many refuse to acknowledge those limits.
— Gökçe Sargut and Rita Gunther McGrath

To be successful, a software project manager must possess a suitable combination of

number of hard skills as well as soft skills [Katz, 2005; Sukhoo, Barnard, Eloff, Poll,
Motah, 2005; Rothman, 2007, Section 7.6; Fitzpatrick, Collins-Sussman, 2012;
Finkelstein, 2015; Peters, 2015; Capretz, Ahmed, Silva, 2017; Goleman, 2017; Kittlaus,
Fricker, 2017, Chapter 2; PMI, 2017a, Section 3.4; Fioravanti, Barbosa, 2019; Fioravanti,
Maximiano, Barbosa, 2019; Kalliamvakou, Bird, Zimmermann, Begel, DeLine, German,
2019; Stanier, 2020; Peters, 2021; Rovida, Zafferri, 2022].

The skills desired of a software project manager are not identical as, for example, that of
a programmer. For example, a programmer needs to have certain skills in order to do
certain work properly; a software project manager needs to have certain skills in order to
ensure that the programmer in question does his or her certain work properly. In other
words, some of the skills desired of a software project manager need to be at a meta-level
(that is, higher-level).

In the end, one of the most important skills of a software project manager could be to
understand: Your Job Is Not to Be Liked is one of the 97 Things Every Engineering
Manager Should Know [Fournier, 2020]. This requires the Courage to be Disliked
[Kishimi, Koga, 2018].

40
10.2.1. MODEL 1

The psychological profiling of software project managers has revealed the following
desirable skills [Peters, 2015]:

 Planning: This is about detailing the tasks and subtasks that must be executed in
order to proceed from one milestone to the next.

 Scheduling: This is about laying out a list of milestones and dates consistent with the
contract.

 Staffing: This is about acquiring the human resources needed to successfully execute
the project plan.

 Motivating: This is about creating and maintaining a physical and psychological

environment that ensures the development team works at its full potential.

 Controlling: This is about monitoring the project’s progress, and taking action to
recover deviations from the project plan, as necessary.

These skills are interrelated, as shown in Figure 8. Each arrow can be read as “has-
influence-on”.

Figure 8. A model of skills of a software project manager. (Source: [Peters, 2015].)

41
Board Time!
 Give a reason for a bidirectional arrow between Scheduling and Staffing.
 Give a software project manager skill not mentioned previously.

10.2.2. MODEL 2

A critical attribute of leadership is the avoidance of overpromising.

― Geoffrey Kabaservice

It is hard to find good project managers because they need to maintain a balance of conflicting
attitudes [dilemmas].
― Oscar Wilde

In [PMI, 2017a, Section 3.4], The PMI Talent Triangle is introduced. It has three
dimensions, where each dimension corresponds to a particular skill set, as shown16 in
Figure 9. To be effective, a project manager needs to have a balance of these three skill
sets.

Figure 9. The PMI Talent Triangle [PMI, 2017a, Section 3.4].

A software manager who cannot program is akin to a managing editor who cannot write.
― John C. Reynolds

16
The original triangle has been modified for the purposes of this document.

42
Technical Skills: These skills are about applying project management knowledge
effectively to deliver the desired outcomes for projects, and include:

 Understand Critical Success Factors for the Project

 Tailor (Development) Processes and Techniques for the Project
 Plan Thoroughly
 Schedule Properly
 Prioritize Diligently

Strategic and Business Management Skills: These skills are about the ability to see the
high-level overview of the organization and effectively negotiate and implement
decisions and actions that support strategic alignment and innovation, and include:

 Communicate Essential Business Aspects of the Project

 Work Collaboratively to Develop an Appropriate Project Delivery Strategy
 Implement Project Delivery Strategy to Maximizes the Business Value of the Project
 Assess Risks
 Conduct Cost versus Benefits Analysis
 Understand the Market
 Be Aware of the Competition

Leadership Skills: These skills are about the ability to guide, motivate, and direct a
team, and include:

 Creative
 Visionary
 Optimistic
 Patience
 Resilience
 Fortitude
 Proactive
 Communication (Asking and Listening, Giving Feedback and Accepting Feedback)
 Negotiating
 Consensus Seeking
 Managing Expectations
 Exhibiting Integrity
 Thinking Critically
 Persuasive
 Crisis Management
 Conflict Resolving

43
10.2.3. MODEL 3

In an empirical study at Google17, a number of characteristics of a ‘great’ manager have

been identified:

10.2.4. MODEL 4

In [Kalliamvakou, Bird, Zimmermann, Begel, DeLine, German, 2019], based on an

empirical study of software engineering management at Microsoft, a conceptual
framework of manager attributes is proposed. The results of the empirical study are
compared with that conducted by Google [Garvin, Wagonfeld, Kind, 2013].

In the proposed conceptual framework, a ‘great’ software engineering manager

17
URL: [Link]
about-googles-manager-research/ .

44
Is Available
Is Technical

and

Cultivates, Motivates, and Mediates at both Individual Level and Communal

(Team/Organizational) Level, as shown in Table 3.

Individual Level Communal Level

Cultivates  Enables Autonomy  Builds Team Culture
 Supports Experimentation  Guides the Team
 Grows Talent

Motivates  Promotes Fairness  Maintains Positive Working

 Builds Relationship with Team Environment
Members  Inspires the Team
 Recognized Individuality

Mediates  Clears Path to Execution  Facilitates External

Communication
 Drives Alignment

Table 3. A conceptual framework of manager attributes.

Mobile Intermezzo!
Use the Web to search for examples and non-examples of the following:

 The Peter Principle: The Peter Principle is a social observation that in a hierarchical
system, such as that of a corporation, people tend to rise to their “levels of
incompetence” [Peter, Hull, 2009].

 The Dilbert Principle: The Dilbert Principle states that corporations tend to
systematically promote incompetent employees to management to get them out of the
workflow [Adams, 1996; Wikipedia].

45
11. SOFTWARE PROJECT MANAGEMENT TOOLS

Good management motivates people to do their best. Poor management demotivates people. All
the great technology […] will not compensate for poor management.
— Alan M. Davis

It can be expected that a software project management tool (such as a software project
management system) has the following characteristics [Kasser, 2019]:

 Supports Processes: It enables carrying out typical software project management-

related activities, such as budgeting and scheduling, and provides means for archiving
and retrieving software project management-related artifacts, such as reports.

 Supports Problem Domain (Not Solution Domain): It supports problem-related,

but not necessarily solution-related, aspects of a software system. For example, a
software project management system may not have support for a programming
language processor (compiler and/or interpreter), for a debugger, and so on.

11.1. FROM PROJECT MANAGEMENT TO KNOWLEDGE MANAGEMENT

The significance of managing knowledge that is created, communicated, and

consumed during a software project has led to the convergence and integration of
knowledge management and project management [Srikantaiah, Koenig, Hawamdeh,
2010; Ruhe, Wohlin, 2014, Chapter 7; Wastian, Rosenstiel, West, Braumandl, 2015,
Chapter 10; Dionisio, 2018; Dionisio, 2023].

It has been observed that projects are social systems [Kuster, Bachmann, Hubmann,
Lippmann, Schneider, 2023, Section 1.6]. The rise of the Social Web, in general, and
Wiki, in particular, has opened new vistas for supporting a knowledge-centered project
management [Sutton, 2010; Keyes, 2013; Furnell, Scott, 2014; Ruhe, Wohlin, 2014,
Chapter 16; Kamthan, 2015; Ninan, 2022]. However, the perceived benefits come at a
cost [Furnell, Scott, 2014].

12. SOFTWARE PROJECT MANAGEMENT MATURITY

There are a number of characteristics of ‘maturity’, including the following [Schaefer,

2009]:

 Aware (Procedures, Laws)

 Accountable

46
 Cooperates and Collaborates
 Open Minded
 Strives for Balance (Over Perfection)
 Understands Causality

12.1. MOTIVATION

Continuous improvement is better than delayed perfection.

— Mark Twain

The assumption underlying the maturity of (software) project management is that

organizations are not all the same in terms of how they carry out a project.

The purpose of studying the maturity of (software) project management is typing (as in
computer languages), that is, to distinguish (and therefore classify) organizations
according to activities they conduct and artifacts they produce in their (software) projects.

The idea behind a maturity model is the following:

(1) A Collection of Maturity Levels

 Experience-Based
(2) Expected Activities (and Artifacts) at Each Maturity Level
 Feasible
(3) An Ordering of Maturity Levels (in (1))

Figure 10 shows an example of how a (software) project management maturity model

could be organized.

The maturity increases with the increase in the levels. The earlier levels are prerequisites
for later levels, meaning a later level assumes that one or more earlier levels have been
satisfied automatically.

The order in which the maturity levels occur cannot change. However, the maturity
levels can overlap.

The transition from one maturity level to another is subject to certain conditions. For
example, an organization cannot ‘skip’ a level.

47
Figure 10. An example of a (software) project management maturity model. (Source:
[Kerzner, 2017a, Section 21.1].)

 Level 1—Common Language: In this level, the organization recognizes the

importance of project management and the need for a good understanding of the basic
knowledge on project management, along with the accompanying terminology.

 Level 2—Common Processes: In this level, the organization recognizes that

common processes need to be defined and developed such that successes on one
project can be repeated on other projects. There exist project management
principles that can be applied to and support other methodologies employed by the
organization.

 Level 3—Singular Methodology: In this level, the organization recognizes the

synergistic effect of combining multiple corporate methodologies into a single
methodology, the center of which is project management. The presence of a single
methodology makes process control easier.

 Level 4—Benchmarking: In this level, the organization recognizes that process

improvement is necessary to maintain a competitive advantage. To do that,
benchmarking is performed using appropriate metrics on a continuous basis.

48
 Level 5—Continuous Improvement: In this level, the organization evaluates the
information obtained through benchmarking (in Level 4), and then decides whether or
not this information will enhance the single methodology (in Level 3).

Board Time!
1. Give a means for Common Language.
2. Give a reason as to why every organization may not want to be at Level 5.

12.2. SOFTWARE PROJECT MANAGEMENT MATURITY AND STRATEGIC

COMPETENCY

In project management, maturity allows organizations to recognize that project

management is a strategic competency, as shown in Figure 11. In particular, for
organizations that promote their project management capabilities to external clients,
competency in project management is viewed as a sustained competitive advantage.

Figure 11. The potential implications related to competency of increasing maturity of

(software) project management. (Source: [Kerzner, 2017b, Section 1.11].)

12.3. INITIATIVES FOR SOFTWARE PROJECT MANAGEMENT MATURITY

There have been a number of proposals for (software) project management maturity
models, by organizations and by people around the world, over the years [Kerzner, 2001;
Crawford, 2002; Crawford, 2015; Kerzner, 2017a; Crawford, 2021; Kerzner, 2023].

49
12.3.1. CMMI

The Capability Maturity Model Integration (CMMI)18 of the CMMI Institute19 is a

“process improvement approach whose goal is to help organizations improve their
performance”. CMMI is a successor of SW-CMM.

CMMI currently addresses three areas of interest:

1. CMMI for Development (CMMI-DEV)

2. CMMI for Services (CMMI-SVC)
3. CMMI for Acquisition (CMMI-ACQ)

The structure of a maturity level in SW-CMM, which serves as an inspiration for

CMMI-DEV, is shown in Figure 12.

18
URL: [Link] .
19
URL: [Link] .

50
 Figure 12. The organization of SW-CMM. (Source: [Naik, Tripathy, 2008].)

A process area is a “cluster of related practices in an area that, when implemented

collectively, satisfy a set of goals considered important for making improvement in that
area”.

In CMMI for Development (CMMI-DEV) [CMMI Product Team, 2010; Chrissis,

Konrad, Shrum, 2011], there are several process areas pertaining to software project
management and cognate disciplines. CMMI core process areas are shown in Figure 13.

51
Figure 13. There are several CMMI Core Process Areas that are explicitly related to
software project management and cognate disciplines. (Source: Wikipedia.)

12.3.2. OPM3

The Organizational Project Management Maturity Model (OPM3)20 is a standard, by

the Project Management Institute (PMI), for assessing and developing capabilities in
Portfolio Management, Program Management, and Project Management21.

20
URL: [Link] .
21
The three types of management are related, but have different purposes. Old: The purpose of portfolio
management is to manage existing organizational assets, such as software systems. New: The purpose of
program management is to manage multiple, similar, initiatives, such as software projects aimed to
deliver a software product line (SPL).

52
A portfolio refers to a collection of programs, or a collection of projects, or both, and,
among other things, is managed as a group to achieve strategic objectives [PMI, 2013a;
PMI, 2013b].

A program refers to a collection of projects.

Figure 14 shows that all programs are part of a portfolio, but that projects can be either
directly part of a portfolio or part of a program.

Figure 14. The relationship between portfolios, programs, and projects in an

organization. (Source: [Whitaker, 2016a, Chapter 1].)

OPM3 has an accreditation scheme that provides organizations means to gain an

independently verified assessment of their maturity level.

OPM3 is commercial, and its use is restricted to PMI certified OPM3 Professionals.

12.3.3. P3M3

53
The Portfolio, Programme22 and Project Management Maturity Model (P3M3)23 is a
reference guide, by the Office of Government Commerce (OGC) of the United
Kingdom, for structured practice of portfolio, programme and project management for
achieving a successful outcome.

P3M3 decomposes the disciplines of portfolio, programme, and project management into
a hierarchy of Key Process Areas (KPAs), as shown in Figure 15.

Figure 15. A partial decomposition of P3M3. (Source: Portfolio, Programme and Project
Management Maturity Model (P3M3®) Introduction and Guide to P3M3®.)

In any project, the project management activities being carried out at the individual
project level are considered significant.

P3M3 acknowledges that the activities that are carried out at the organizational level
(by the organization responsible for the project) are also significant.

For example, such activities include assigning a manager to a project, or approving

the budget or resources for a project.

22
P3M3 uses UK English.
23
URL: [Link] .

54
These KPAs and activities can be used, as a basis for a checklist, by organizations to
assess their current capability and then charter a path for improvement prioritized by
those KPAs.

There are five maturity levels in P3M3:

 Level 1 – Awareness of Process

 Level 2 – Repeatable Process
 Level 3 – Defined Process
 Level 4 – Managed Process
 Level 5 – Optimized Process

12.4. SOFTWARE PROJECT MATURITY ASSESSMENT

There are organizations that provide different means, such as questionnaires, for
companies to assess their software project management maturity by self-examination.

For example:

(Source: IIL24.)

The result of the questionnaire would place a company into one of the maturity levels.

12.5. SOFTWARE PROJECT IMMATURITY

It is not only not right, it is not even wrong.

― Wolfgang Pauli

If ‘maturity’ is about what an organization is supposed to do (pattern), then ‘immaturity’

is about what an organization is not supposed to do (anti-pattern). This understanding has
led to immaturity levels (that is, negative maturity levels) [Finkelstein, 1992; Schorsch,
1996; Piney, 2009; Márquez-Gutiérrez, Carmona-Gonzalez, Castro-Zuluaga, 2020].

24
URL: [Link] .

55
The following is one interpretation:

 Level 0—Negligent: In this level, the organization is involved in “process-

washing”. It ignores any successful processes. It perceives all problems as technical
problems. It usually fails to produce any software.

 Level −1—Obstructive: In this level, the organization considers adherence to

process as essential and the production of any software as incidental. There is no
assessment of software quality because it is believed that following a process would
have led to high-quality software automatically.

 Level −2—Contemptuous: In this level, the organization downplays the software

process improvement efforts of other organizations. It disregards software
engineering. It produces artificial, self-advocating, measurement data.

 Level −3—Undermining: In this level, the organization discredits, even sabotages,

the software process improvement efforts of other organizations. It rewards poor
behavior and suboptimal performance.

Board Time!
Give an example of what might constitute as “process washing”.

13. ORGANIZATIONAL CULTURE AND SOFTWARE PROJECT

MANAGEMENT

There are many kinds of cultures at different levels: international, national,

organizational, and so on [Hofstede, Hofstede, Minkov, 2010].

The organizational culture “encompasses values and behaviors that contribute to the
unique social and psychological environment of a business [Rose, 2018, Chapter 9]. It
influences the way people interact, the context within which knowledge is created, the
acceptance or resistance they may have towards certain changes, and the way they
share or not share knowledge” [Wikipedia].

There are several factors that influence an organization’s culture, as shown in Figure 16.

56
Figure 16. A collection of factors that influence an organization’s culture. (Source:
[Kuster, Bachmann, Hubmann, Lippmann, Schneider, 2023, Section 3.4].

13.1. CULTURAL PRINCIPLES

In [Wiegers, 1996], the following cultural principles for cultivating an environment of

in an organization to serve as a guide to software projects have been given from the
perspective of quality:

1. Never Let Your Boss or Client Cause You To Do Poor Work

2. People Must Feel That Their Work is Appreciated

3. Continuing Education is the Responsibility of Each Team Member

4. Participation of the Client is the Most Critical Factor of Software Quality

5. Your Greatest Challenge is to Share the Vision of the Final Product with the Client

6. Continuous Improvement in Your Software Development Process is Possible and

Essential

57
7. Software Development Procedures can Help Establish a Common Culture of Best
Practices

8. Quality is the Number One Priority; Long-Term Productivity is a Natural

Consequence of Quality

9. Ensure that it is a Peer, Not a Client, Who Finds the Defect

10. A Key to Software Quality is to Repeatedly Go Through All Development Steps

Except Coding; Coding Should Only Be Done Once

11. Controlling Error Reports and Change Requests is Essential to Quality and
Maintenance

12. If You Measure What You Do, You Can Learn To Do It Better

13. Do What Seems Reasonable; Do Not Base Yourself On Dogma

14. You Cannot Change Everything At The Same Time. Identify Changes That Will
Reap The Most Benefits, and Start to Apply Them as of Next Monday

Indeed, Define Your Culture Before It Defines Itself and Culture Is What You Do
When the Unexpected Happens are the 97 Things Every Engineering Manager
Should Know [Fournier, 2020].

EXAMPLE

The influence of an organization’s culture on practices can be seen from the following
excerpt (which has been paraphrased for suitability) [Júnior, Farias, Silva, 2021]:

“The […] organizational culture represents a major [obstacle] to

enable the adoption of UML [because] practices adopted and the culture
[…] sometimes do not make the modeling feasible, [and] problems in
synchronization between artifacts hinder the adoption of models in
teams …”.

REMARKS

The cultural principle #6 is especially interesting in the light of continuous software

project management [Wysocki, 2019, Chapter 1; Layton, Ostermiller, Kynaston, 2020].

58
Board Time!
 Give a means for realizing the cultural principles #4, #9, and #14.
 (This is about the Software Engineering Code of Ethics and Professional Practice
(SECEPP)25 [Gotterbarn, Miller, Rogerson, 1997].) Give a cultural principle and a
corresponding principle and clause from SECEPP.

REMARKS

In [Collins, Porras, 2002], characteristics of a number of successful business

organizations are given. These characteristics include having a culture of “Win-Win”
[Valerdi, 2023]. This is accomplished by adopting the following attitude. Let for a given
management problem, P, there be competing solutions, S1, …, Sn. Then, instead of
choosing a single solution out of S1, …, Sn, an attempt is made to consider a solution, S,
that is composed of the best of all the solutions S1, …, Sn.

ACKNOWLEDGEMENT

The inclusion of images from external sources is only for non-commercial educational
purposes, and their use is hereby acknowledged.

25
URL: [Link] .

59
REFERENCES

[Adams, 1996] The Dilbert Principle. By S. Adams. HarperBusiness. 1996.

[Ahmed, 2012] Software Project Management: A Process-Driven Approach. By A.

Ahmed. CRC Press. 2012.

[Alami, Krancher, Paasivaara, 2022] The Journey to Technical Excellence in Agile

Software Development. By A. Alami, O. Krancher, M. Paasivaara. Information and
Software Technology. Volume 150. 2022. 14 Pages. DOI:
[Link]

[Appelo, 2011] Management 3.0: Leading Agile Developers, Developing Agile Leaders.
By J. Appelo. Addison-Wesley. 2011.

[Armour, 2001] Zeppelins and Jet Planes: A Metaphor for Modern Software Projects. By
P. G. Armour. Communications of the ACM. Volume 44. Number 10. 2001. Pages 13-
15.

[Augustine, Payne, Sencindiver, Woodcock, 2005] Agile Project Management: Steering

from the Edges. By S. Augustine, B. Payne, F. Sencindiver, S. Woodcock.
Communications of the ACM. Volume 48. Number 12. 2005. Pages 85-89.

[Basili, 2011] Learning through Application: The Maturing of the QIP in the SEL. By V.
R. Basili. In: Making Software: What Really Works, and Why We Believe It. A. Oram,
G. Wilson (Editors). O’Reilly Media. 2011. Pages 65-78.

[Bavota, De Lucia, Fasano, Oliveto, Zottoli, 2012] Teaching Software Engineering and
Software Project Management: An Integrated and Practical Approach. By G. Bavota, A.
De Lucia, F. Fasano, R. Oliveto, C. Zottoli. The Thirty Fourth International Conference
on Software Engineering (ICSE 2012). Zürich, Switzerland. June 2-9, 2012.

[Berkun, 2008] Making Things Happen: Mastering Project Management. By S. Berkun.

O’Reilly Media. 2008.

[Berry, 2002] The Inevitable Pain of Software Development, Including of Extreme

Programming, Caused by Requirements Volatility. By D. M. Berry. 2002.

[Blair, 2020] Agile Project Delivery: A Practical Approach for Corporate Environments
Beyond Software Development. By A. A. Blair. CSP Books. 2020.

60
[Bosch, 2014] Continuous Software Engineering. By J. Bosch (Editor). Springer
International Publishing. 2014.

[Brown, 2013] Enterprise Software Delivery: Bringing Agility and Efficiency to the
Global Software Supply Chain. By A. W. Brown. Addison-Wesley. 2013.

[Brown, Malveau, McCormick, Mowbray, 1998] AntiPatterns: Refactoring Software,

Architectures, and Projects in Crisis. By W. J. Brown, R. C. Malveau, H. W. McCormick,
T. J. Mowbray. John Wiley and Sons. 1998.

[Brown, McCormick, Thomas, 2000] AntiPatterns in Project Management. By W. J.

Brown, H. W. McCormick, S. W. Thomas. John Wiley and Sons. 2000.

[Brooks, 1987] No Silver Bullet: Essence and Accidents of Software Engineering. By F.

P. Brooks, Jr. Computer. Volume 20. Number 4. 1987. Pages 10-19.

[Capretz, Ahmed, Silva, 2017] Soft Sides of Software. By L. F. Capretz, F. Ahmed, F. Q.

B. da Silva. Information and Software Technology. Volume 92. 2017. Pages 92-94.

[Ceschi, Sillitti, Succi, Panfilis, 2005] Project Management in Plan-Based and Agile
Companies. By M. Ceschi, A. Sillitti, G. Succi, S. De Panfilis. IEEE Software. Volume
22. Number 3. 2005. Pages 21-27.

[Chin, 2004] Agile Project Management: How to Succeed in the Face of Changing
Project Requirements. By G. Chin. AMACOM. 2004.

[Chrissis, Konrad, Shrum, 2011] CMMI for Development: Guidelines for Process
Integration and Product Improvement. By M. B. Chrissis, M. D. Konrad, S. Shrum. Third
Edition. Addison-Wesley. 2011.

[Cline, 2015] Agile Development in the Real World. By A. Cline. Apress. 2015.

[Collins, Porras, 2002] Built to Last: Successful Habits of Visionary Companies. By J. C.

Collins, J. I. Porras. HarperCollins Publishers. 2002.

[CMMI Product Team, 2010] CMMI® for Development, Version 1.3. By CMMI Product
Team. Technical Report CMU/SEI-2010-TR-033 ESC-TR-2010-033. Software
Engineering Institute. Carnegie Mellon University. Pittsburgh, U.S.A. 2010.

61
[Cobb, 2011] Making Sense of Agile Project Management: Balancing Control and
Agility. By G. Cobb. John Wiley and Sons. 2011.

[Cobb, 2015] The Project Manager’s Guide to Mastering Agile: Principles and Practices
for an Adaptive Approach. By C. G. Cobb. John Wiley and Sons. 2015.

[Coplien, Harrison, 2005] Organizational Patterns of Agile Software Development. By J.

O. Coplien, N. B. Harrison. Prentice-Hall. 2005.

[Cortada, 2019] IBM: The Rise and Fall and Reinvention of a Global Icon. By J. W.
Cortada. The MIT Press. 2019.

[Crawford, 2002] Project Management Maturity Model: Providing a Proven Path to

Project Management Excellence. By J. K. Crawford. Marcel Dekker. 2002.

[Crawford, 2015] Project Management Maturity Model. By J. K. Crawford. Third

Edition. CRC Press. 2015.

[Crawford, 2021] Project Management Maturity Model. By J. K. Crawford. Fourth

Edition. CRC Press. 2021.

[Crowder, Friess, 2015] Agile Project Management: Managing for Success. By J. A.

Crowder, S. Friess. Springer International Publishing. 2015.

[Dingsøyr, 2021] Agile Iteration Reviews in a Project Course: A Key to Improved

Feedback and Assessment Practice. By T. Dingsøyr. The Third International Workshop
on Software Engineering Education for the Next Generation (SEENG@ICSE 2021).
Madrid, Spain. May 24, 2021.

[Dinsmore, Cabanis-Brewin, 2014] The AMA Handbook of Project Management. By P.

C. Dinsmore, J. Cabanis-Brewin. Fourth Edition. AMACOM. 2014.

[Dionisio, 2018] A Project Manager’s Book of Tools and Techniques. By C. S. Dionisio.

John Wiley and Sons. 2018.

[Dionisio, 2023] A Project Manager’s Book of Templates. By C. S. Dionisio. John Wiley

and Sons. 2023.

[Doglio, 2022] Skills of a Successful Software Engineer. By F. Doglio. Manning

Publications. 2022.

62
[Ebert, Vizcaíno, Manjavacas, 2020] IT Governance. By C. Ebert, A. Vizcaíno, A.
Manjavacas. IEEE Software. Volume 37. Issue 6. 2020. Pages 13-20.

[Endres, Rombach, 2003] A Handbook of Software and Systems Engineering: Empirical

Observations, Laws and Theories. By A. Endres, D. Rombach. Addison-Wesley. 2003.

[Ensmenger, 2010] The Computer Boys Take Over: Computers, Programmers, and the
Politics of Technical Expertise. By N. Ensmenger. The MIT Press. 2010.

[European Space Agency, 1995] Guide to Software Project Management. By ESA Board
for Software Standardisation and Control. ESA PSS-05-08 Issue 1 Revision 1. European
Space Agency. Paris, France. March 1995.

[Farooq, Omer, Tehseen, Nisah, 2021] Software Project Management Education: A

Systematic Review. By M. S. Farooq, U. Omer, R. Tehseen, I. U. Nisah. VFAST
Transactions on Software Engineering. Volume 9. Number 3. 2021. Pages 102-119.

[Finkelstein, 1992] A Software Process Immaturity Model. By A. Finkelstein. ACM

SIGSOFT Software Engineering Notes. Volume 17. Number 4. 1992. Pages 22-23.

[Finkelstein, 2015] What Amazing Bosses Do Differently. By S. Finkelstein. Harvard

Business Review. November 27, 2015.

[Fioravanti, Barbosa, 2019] Outlining Software Project Management Education by

Surveying Educators. By M. L. Fioravanti, E. F. Barbosa. The 2019 IEEE Frontiers in
Education Conference (FIE 2019). Cincinnati, U.S.A. October 16-19, 2019.

[Fioravanti, Maximiano, Barbosa, 2019] Practitioners’ Perspective on Software Project

Management Education. By M. L. Fioravanti, A. C. A. Maximiano, E. F. Barbosa.
Revista Novas Tecnologias na Educação. Volume 17. Number 3. 2019. Pages 273-284.

[Fitsilis, 2008] Comparing PMBOK and Agile Project Management Software

Development Processes. By P. Fitsilis. In: Advances in Computer and Information
Sciences and Engineering. T. Sobh (Editor). Springer Verlag. 2008. Pages 378-383.

[Fitzpatrick, Collins-Sussman, 2012] Team Geek: A Software Developer’s Guide to

Working Well with Others. By B. W. Fitzpatrick, B. Collins-Sussman. O’Reilly Media.
2012.

63
[Ford, Parsons, Kua, 2017] Building Evolutionary Architectures: Support Constant
Change. By N. Ford, R. Parsons, P. Kua. O’Reilly Media. 2017.

[Fournier, 2020] 97 Things Every Engineering Manager Should Know: Collective

Wisdom from the Experts. By C. Fournier. O’Reilly Media. 2020.

[Furnell, Scott, 2014] Is Social Networking the Future of Project Management? By R.

Furnell, P. Scott. International Journal of Digital Society. Volume 5. Issue 2. 2014. Pages
933-940.

[Garvin, Wagonfeld, Kind, 2013] Google’s Project Oxygen: Do Managers Matter? By D.

Garvin, A. B. Wagonfeld, L. Kind. Harvard Business School. Case number 9-313-110.
April 2013.

[Gilb, Finzi, 1988] Principles of Software Engineering Management. By T. Gilb, S. Finzi.

Addison-Wesley. 1988.

[Glass, 2002] Facts and Fallacies of Software Engineering. By R. L. Glass. Addison-

Wesley. 2002.

[Goleman, 2017] What Makes a Leader? By D. Goleman. Harvard Business School

Publishing Corporation. 2017.

[Gómez, Núñez, 2008] Agile Practices in Project Management. By J. Gómez, A. Núñez.

In: Software Process Improvement for Small and Medium Enterprises: Techniques and
Case Studies. H. Oktaba, M. Piattini (Editors). IGI Global. 2008. Pages 193-211.

[Gotterbarn, Miller, Rogerson, 1997] Software Engineering Code of Ethics. By D.

Gotterbarn, K. Miller, S. Rogerson. Communications of the ACM. Volume 40. Number
11. 1997. Pages 110-118.

[Greene, Stellman, 2005] Applied Software Project Management. By J. Greene, A.

Stellman. O’Reilly Media. 2005.

[Haes, Grembergen, Joshi, Huygh, 2020] Enterprise Governance of Information

Technology: Achieving Alignment and Value in Digital Organizations. By S. De Haes,
W. Van Grembergen, A. Joshi, T. Huygh. Third Edition. Springer Nature. 2020.

[Harris, 2018] The Business Value of Software. By M. D. S. Harris. CRC Press. 2018.

64
[Hayes, Lethbridge, Port, 2003] Evaluating Individual Contribution Toward Group
Software Engineering Projects. By J. H. Hayes, T. C. Lethbridge, D. Port. The Twenty
Fifth International Conference on Software Engineering (ICSE 2003). Portland, U.S.A.
May 3-10, 2003.

[Hazzan, Lapidot, Ragonis, 2011] Guide to Teaching Computer Science: An Activity-

Based Approach. By O. Hazzan, T. Lapidot, N. Ragonis. Springer-Verlag. 2011.

[Highsmith, 2009] Agile Project Management: Creating Innovative Products. By J.

Highsmith. Second Edition. Addison-Wesley. 2009.

[Hofstede, Hofstede, Minkov, 2010] Cultures and Organizations - Software of the Mind:
Intercultural Cooperation and Its Importance for Survival. By G. Hofstede, G. J.
Hofstede, M. Minkov. Third Edition. McGraw-Hill. 2010.

[Hughes, Cotterell, 2009] Software Project Management. By B. Hughes, M. Cotterell.

Fifth Edition. McGraw-Hill. 2009.

[Hull, Jackson, Dick, 2011] Requirements Engineering. By E. Hull, K. Jackson, J. Dick.

Third Edition. Springer-Verlag. 2011.

[Humphrey, 2002] Winning with Software: An Executive Strategy. By W. S. Humphrey.

Addison-Wesley. 2002.

[Humphrey, Over, 2011] Leadership, Teamwork, and Trust: Building a Competitive

Software Capability. By W. S. Humphrey, J. W. Over. Addison-Wesley. 2011.

[Hunt, 2021] Becoming a PMP® Certified Professional: A Study Guide to Mastering

Project Management for the PMP® exam. By J. A. Hunt. Packt Publishing. 2021.

[IEEE, 1990] IEEE Standard 610.12-1990. IEEE Standard Glossary of Software

Engineering Terminology. The Institute of Electrical and Electronics Engineers (IEEE)
Computer Society. 1990.

[IEEE, 1998] IEEE Standard 1058-1998. IEEE Standard for Software Project
Management Plans. The Institute of Electrical and Electronics Engineers (IEEE)
Computer Society. 1998.

[IEEE, 2011] IEEE Standard 1490-2011. IEEE Guide—Adoption of the Project

Management Institute (PMI®) Standard A Guide to the Project Management Body of

65
Knowledge (PMBOK® Guide)—Fourth Edition. The Institute of Electrical and
Electronics Engineers (IEEE) Computer Society. 2011.

[IEEE, 2014a] Guide to the Software Engineering Body of Knowledge (SWEBOK)

Version 3.0. The Institute of Electrical and Electronics Engineers (IEEE) Computer
Society. 2014.

[IEEE, 2014b] IEEE Standard 15026-1™-2014. IEEE Standard Adoption of ISO/IEC

15026-1—Systems and Software Engineering—Systems and Software Assurance—Part
1: Concepts and Vocabulary. The Institute of Electrical and Electronics Engineers (IEEE)
Computer Society. 2014.

[IIBA, 2009] A Guide to the Business Analysis Body of Knowledge, Version 2.0.
International Institute of Business Analysis (IIBA). 2009.

[IIBA, 2013] Agile Extension to the BABOK® Guide, Version 1.0. International Institute
of Business Analysis (IIBA). 2013.

[ISO/IEC, 2005] ISO/IEC TR 19759:2005. Guide to the Software Engineering Body of

Knowledge (SWEBOK). The International Organization for Standardization (ISO)/The
International Electrotechnical Commission (IEC). 2005.

[ISO/IEC, 2016] ISO/IEC TR 29110-1:2016. Systems and Software Engineering --

Lifecycle Profiles for Very Small Entities (VSEs) -- Part 1: Overview. The International
Organization for Standardization (ISO)/The International Electrotechnical Commission
(IEC). 2016.

[ISO/IEC/IEEE, 2009] ISO/IEC/IEEE 16326:2009. Systems and Software engineering --

Life Cycle Processes -- Project Management. The International Organization for
Standardization (ISO)/The International Electrotechnical Commission (IEC)/The Institute
of Electrical and Electronics Engineers (IEEE) Computer Society. 2009.

[ISO/IEC/IEEE, 2010] ISO/IEC/IEEE 24765:2010. Systems and Software Engineering --

Vocabulary. The International Organization for Standardization (ISO)/The International
Electrotechnical Commission (IEC)/The Institute of Electrical and Electronics Engineers
(IEEE) Computer Society. 2010.

[ISO/IEC/IEEE, 2019] ISO/IEC/IEEE 16326:2019. Systems and Software engineering --

Life Cycle Processes -- Project Management. The International Organization for

66
Standardization (ISO)/The International Electrotechnical Commission (IEC)/The Institute
of Electrical and Electronics Engineers (IEEE) Computer Society. 2019.

[Jayatilleke, Lai, 2018] A Systematic Review of Requirements Change Management. By

S. Jayatilleke, R. Lai. Information and Software Technology. Volume 93. 2018. Pages
163-185.

[Jia, Xin, 2018] Integration of Ethics Issues into Software Engineering Management
Education. By J. Jia, J. Xin. The 2018 ACM Turing Celebration Conference (TURC
2018). Shanghai, China. May 19-20, 2018.

[Johansen, Colomo-Palacios, Kristiansen, Samuelsen, 2019] Engaging Students in the

Context of Software Project Management Teaching. By S. H. Johansen, R. Colomo-
Palacios, M. Kristiansen, T. Samuelsen. The 2019 International Conference of
Technological Ecosystems for Enhancing Multiculturality (TEEM 2019). León, Spain.
October 16-18, 2019.

[Jones, 1998] Sizing Up Software. Scientific American. By C. Jones. Volume 279.

Number 6. 1998. Pages 104-111.

[Jones, 2017] A Retrospective View of the Laws of Software Engineering. By C. Jones.

CrossTalk. January/February 2017. Pages 17-23.

[Júnior, Farias, Silva, 2021] A Survey on the Use of UML in the Brazilian Industry. By
E. W. Júnior, K. Farias, B. da Silva. The Thirty Fifth Brazilian Symposium on Software
Engineering (SBES 2021). Joinville, Brazil. September 27, 2021-October 1, 2021.

[Kalliamvakou, Bird, Zimmermann, Begel, DeLine, German, 2019] What Makes a Great
Manager of Software Engineers? By E. Kalliamvakou, C. Bird, T. Zimmermann, A.
Begel, R. DeLine, D. M. German. IEEE Transactions on Software Engineering. Volume
45. Number 1. 2019. Pages 87-106.

[Kamthan, 2015] Wiki for Agility. By P. Kamthan. In: Human Factors in Software
Development and Design. S. Saeed, I. S. Bajwa, Z. Mahmood (Editors). IGI Global.
2015. Pages 174-193.

[Kamthan, 2022] A Framework for Analyzing and Comparing Software Projects in

Academia and Industry. By P. Kamthan. In: Industry Practices, Processes and Techniques
Adopted in Education. K. MacCallum, D. Parsons (Editors). Springer Nature. 2022.
Pages 355-379.

67
[Kasser, 2019] Systems Thinker’s Toolbox: Tools for Managing Complexity. By J. E.
Kasser. CRC Press. 2019.

[Kasser, 2020] Systemic and Systematic Project Management. By J. E. Kasser. CRC

Press. 2020.

[Katz, 2005] Motivating Technical Professionals Today. By R. Katz. Research-

Technology Management. Volume 48. Number 6. 2005. Pages 19-27. DOI:
[Link]

[Kendrick, 2011] 101 Project Management Problems and How to Solve Them: Practical
Advice for Handling Real-World Project Challenges. By T. Kendrick. AMACOM. 2011.

[Kerzner, 2001] Strategic Planning for Project Management using a Project Management
Maturity Model. By H. Kerzner. John Wiley and Sons. 2001.

[Kerzner, 2017a] Project Management: A Systems Approach to Planning, Scheduling,

and Controlling. By H. Kerzner. Twelfth Edition. John Wiley and Sons. 2017.

[Kerzner, 2017b] Project Management Metrics, KPIs, and Dashboards. By H. Kerzner.

Third Edition. John Wiley and Sons. 2017.

[Kerzner, 2023] Project Management Metrics, KPIs, and Dashboards: A Guide to

Measuring and Monitoring Project Performance. By H. Kerzner. Fourth Edition. John
Wiley and Sons. 2023.

[Keyes, 2013] Enterprise 2.0: Social Networking Tools to Transform Your Organization.
By J. Keyes. CRC Press. 2013.

[King, 1992] Project Management Made Simple: A Guide to Successful Management of

Computer Systems Projects. By D. King. Prentice-Hall. 1992.

[Kishimi, Koga, 2018] The Courage to be Disliked: How to Change Your Life and
Achieve Real Happiness. By I. Kishimi, F. Koga. Atria Books. 2018

[Kittlaus, Fricker, 2017] Software Product Management: The ISPMA-Compliant Study

Guide and Handbook. By H.-B. Kittlaus, S. A. Fricker. Springer-Verlag. 2017.

[Kliem, 2014] Creative, Efficient, and Effective Project Management. By R. L. Kliem.

CRC Press. 2014.

68
[Kruchten, 2011] Experience Teaching Software Project Management in both Industrial
and Academic Settings. By P. Kruchten. The Twenty Fourth IEEE-CS Conference on
Software Engineering Education and Training (CSEE&T 2011). Waikiki, U.S.A. May
22-24, 2011.

[Kua, 2009] You Are Not in Control. By P. Kua. In: 97 Things Every Project Manager
Should Know: Collective Wisdom from the Experts. B. Davis (Editor). O’Reilly Media.
2009. Pages 186-187.

[Kuster, Bachmann, Hubmann, Lippmann, Schneider, 2023] Project Management

Handbook: Agile – Traditional – Hybrid. By J. Kuster, C. Bachmann, M. Hubmann, R.
Lippmann, P. Schneider. Second Edition. Springer-Verlag. 2023.

[Langer, 2012] Guide to Software Development Designing and Managing the Life Cycle.
By A. M. Langer. Springer-Verlag. 2012.

[Laplante, Neill, 2006] Antipatterns: Identification, Refactoring, and Management. By P.

A. Laplante, C. J. Neill. Auerbach Publications. 2006.

[Layton, Ostermiller, 2017] Agile Project Management For Dummies. By M. C. Layton,

S. J. Ostermiller. Second Edition. John Wiley and Sons. 2017.

[Layton, Ostermiller, Kynaston, 2020] Agile Project Management For Dummies. By M.

C. Layton, S. J. Ostermiller, Kynaston. Third Edition. John Wiley and Sons. 2020.

[Li, Ko, Zhu, 2015] What Makes a Great Software Engineer? By P. L. Li, A. J. Ko, J.
Zhu. The Thirty Seventh International Conference on Software Engineering (ICSE 2015).
Florence, Italy. May 16-24, 2015.

[Lopp, 2021] Managing Humans: More Biting and Humorous Tales of a Software
Engineering Manager. By M. Lopp. Fourth Edition. Apress. 2021.

[Maley, 2012] Project Management: Concepts, Methods, and Techniques. By C. H.

Maley. CRC Press. 2012.

[Marques, Ochoa, 2013a] Transferring Software Development Knowledge and Skills in

the Academia: A Literature Review. By M. Marques, S. F. Ochoa. Technical Report
TR/DCC-2013-2. Computer Science Department. University of Chile. Santiago, Chile.
2013.

69
[Marques, Ochoa, 2013b] Using Thinklets to Support the Team Work in Novice Software
Teams. By M. Marques, S. F. Ochoa. Technical Report TR/DCC-2013-10. Computer
Science Department. University of Chile. Santiago, Chile. 2013.

[Márquez-Gutiérrez, Carmona-Gonzalez, Castro-Zuluaga, 2020] A Logistic Process

Immaturity Model Proposal. By M. Márquez-Gutiérrez, G. Carmona-Gonzalez, C.
Castro-Zuluaga. Foundations of Management. Volume 12. 2020. Pages 61-70.

[Martin, 2011] The Clean Coder: A Code of Conduct for Professional Programmers. By
R. C. Martin. Prentice-Hall. 2011.

[Mas, Mesquida, Colomo-Palacios, 2021] Enhancing the Student Perception on Software

Project Management in Computer Science. By A. Mas, A.-L. Mesquida, R. Colomo-
Palacios. IEEE Transactions on Education. Volume 64. Number 1. 2021. Pages 1-11.

[Maylor, Turner, Murray-Webster, 2013] How Hard Can It Be?: Actively Managing
Complexity in Technology Projects. By H. R. Maylor, N. W. Turner, R. Murray-Webster.
Research-Technology Management. Volume 56. Number 4. 2013. Pages 45-51. DOI:
[Link]

[McDonald, 2001] Why Is Software Project Management Difficult? And What That
Implies for Teaching Software Project Management. By J. McDonald. Computer Science
Education. Volume 11. Number 1. 2001. Pages 55-71.

[McGrath, 2011] Failing by Design. By R. G. McGrath. Harvard Business Review.

Volume 89. Issue 4. 2011. Pages 76-83.

[Mistrík, Grundy, Hoek, Whitehead, 2010] Collaborative Software Engineering. By I.

Mistrík, J. Grundy, A. van der Hoek, J. Whitehead (Editors). Springer-Verlag. 2010.

[Mohan, Merle, Jackson, Lannin, 2010] Professional Skills in the Engineering

Curriculum. By A. Mohan, D. Merle, C. Jackson, J. Lannin, S. S. Nair. IEEE
Transactions on Education. Volume 53. Number 4. 2010. Pages 562-571.

[Monson-Haefel, 2009] 97 Things Every Software Architect Should Know: Collective

Wisdom from the Experts. By R. Monson-Haefel (Editor). O’Reilly Media. 2009.

[Moreira, 2013] Being Agile: Your Roadmap to Successful Adoption of Agile. By M. E.

Moreira. Apress. 2013.

70
[Naik, Tripathy, 2008] Software Testing and Quality Assurance: Theory and Practice. By
K. Naik, P. Tripathy. John Wiley and Sons. 2008.

[Nerur, Mahapatra, Mangalaraj, 2005] Challenges of Migrating to Agile Methodologies.

By S. Nerur, R. Mahapatra, G. Mangalaraj. Communications of the ACM. Volume 48.
Number 5. 2005. Pages 73-78.

[Newton, 2018] A Systematic Literature Review of Project Management Tools and their
Impact on Project Management Effectiveness. By M. Newton. [Link]. Thesis. Purdue
University. 2018.

[Ninan, 2022] Social Media for Project Management. By J. Ninan. CRC Press. 2022.

[Ochodek, Kopczyńska, 2018] Perceived Importance of Agile Requirements Engineering

Practices – A Survey. By M. Ochodek, S. Kopczyńska. The Journal of Systems and
Software. Volume 143. 2018. Pages 29-43.

[O’Regan, 2022] Concise Guide to Software Engineering: From Fundamentals to

Application Methods. By G. O’Regan. Second Edition. Springer Nature. 2022.

[Peter, Hull, 2009] The Peter Principle: Why Things Always Go Wrong. By L. J. Peter,
R. Hull. HarperCollins Publishers. 2009.

[Peters, 2015] Training Software Project Managers. By L. Peters. CrossTalk.

January/February 2015. Pages 28-32.

[Peters, 2021] Software Project Management: Facts versus Beliefs and Practice. By L.
Peters. In: Research and Evidence in Software Engineering: From Empirical Studies to
Open Source Artifacts. V. Gupta, C. Gupta (Editors). CRC Press. 2021. Pages 89-100.

[Peters, Moreno, 2015] Educating Software Engineering Managers – Revisited: What

Software Project Managers Need to Know Today. By L. Peters, A. M. Moreno. The
Thirty Seventh International Conference on Software Engineering (ICSE 2015).
Florence, Italy. May 16-24, 2015.

[Pinheiro, 2002] Requirements Honesty. By F. A. C. Pinheiro. The 2002 International

Workshop on Time Constrained Requirements Engineering (TCRE 2002). Essen,
Germany. September 9, 2002.

71
[Pinheiro, 2003] Requirements Honesty. By F. A. C. Pinheiro. Requirements
Engineering. Volume 8. Number 3. 2003. Pages 183-192.

[Piney, 2009] A Project Management Immaturity Model. By K. Piney. PROject

BeneFITS. Volume 17. Number 4. 2009. Pages 1-5.

[PMI, 2008] A Guide to the Project Management Body of Knowledge (PMBOK®

Guide). By Project Management Institute. Fourth Edition. Project Management Institute
(PMI). 2008.

[PMI, 2013a] A Guide to the Project Management Body of Knowledge (PMBOK®

Guide). By Project Management Institute. Fifth Edition. Project Management Institute
(PMI). 2013.

[PMI, 2013b] Software Extension to the PMBOK® Guide Fifth Edition. By Project
Management Institute. Project Management Institute (PMI). 2013.

[PMI, 2017a] A Guide to the Project Management Body of Knowledge (PMBOK®

Guide). By Project Management Institute. Sixth Edition. Project Management Institute
(PMI). 2017.

[PMI, 2017b] Agile Practice Guide. By Project Management Institute. Project

Management Institute (PMI). 2017.

[PMI, 2021] A Guide to the Project Management Body of Knowledge (PMBOK®

Guide). By Project Management Institute. Seventh Edition. Project Management Institute
(PMI). 2021.

[Pranam, 2018] Product Management Essentials: Tools and Techniques for Becoming an
Effective Technical Product Manager. By A. Pranam. Apress. 2018.

[Ralph, 2018] Re-imagining a Course in Software Project Management. By P. Ralph. The

Fortieth International Conference on Software Engineering: Software Engineering
Education and Training (ICSE-SEET 2018). Gothenburg, Sweden. May 27-June 3, 2018.

[Reifer, 2014] Software War Stories: Case Studies in Software Management. By D. J.

Reifer. John Wiley and Sons. 2014.

[Rivera-Ibarra, Rodríguez-Jacobo, Fernández-Zepeda, Serrano-Vargas, 2010]

Competency Framework for Software Engineers. By J. G. Rivera-Ibarra, J. Rodríguez-

72
Jacobo, J. A. Fernández-Zepeda, M. A. Serrano-Vargas. The Twenty Third International
Conference on Software Engineering Education and Training (CSEE&T 2010).
Pittsburgh, U.S.A. March 9-12, 2010.

[Rojas, Mejía-Moncayo, 2019] Students’ Perception of a Postgraduate Course in Agile

Project Management Aimed at Developing Soft Skills. By A. E. Rojas, C. Mejía-
Moncayo. The Second International Conference on Applied Informatics (ICAI 2019).
Madrid, Spain. November 6-9, 2019.

[Rose, 2018] Enterprise Agility For Dummies. By D. Rose. John Wiley and Sons. 2018.

[Rost, Glass, 2011] The Dark Side of Software Engineering: Evil on Computing Projects.
By J. Rost, R. L. Glass. John Wiley and Sons. 2011.

[Rothman, 2007] Manage It! Your Guide to Modern, Pragmatic Project Management. By
J. Rothman. The Pragmatic Bookshelf. 2007.

[Rovida, Zafferri, 2022] The Importance of Soft Skills in Engineering and Engineering
Education. By E. Rovida, G. Zafferri. Springer Nature. 2022.

[Ruhe, Wohlin, 2014] Software Project Management in a Changing World. By G. Ruhe,

C. Wohlin (Editors). Springer-Verlag. 2014.

[Schaefer, 2009] Software Maturity: Design as Dark Art. By R. Schaefer. ACM

SIGSOFT Software Engineering Notes. Volume 34. Number 1. 2009. Pages 1-36.

[Schorsch, 1996] The Capability Im-Maturity Model (CIMM). By T. Schorsch.

CrossTalk. November 1996. Pages 1-4.

[Sedelmaier, Landes, 2018] Active Learning of Software Project and Quality

Management. By Y. Sedelmaier, D. Landes. The 2018 IEEE Global Engineering
Education Conference (EDUCON 2018). Santa Cruz de Tenerife, Spain. April 17-20,
2018.

[Simsa, 2009] Scope Change Happens; Get Used to It. By P. Simsa. In: 97 Things Every
Project Manager Should Know: Collective Wisdom from the Experts. B. Davis (Editor).
O’Reilly Media. 2009. Pages 148-149.

[Slaughter, 2014] A Profile of the Software Industry: Emergence, Ascendance, Risks, and
Rewards. By S. A. Slaughter. Business Expert Press. 2014.

73
[Sliger, Broderick, 2008] The Software Project Manager’s Bridge to Agility. By M.
Sliger, S. Broderick. Addison-Wesley. 2008.

[Smallwood, 2020] Information Governance: Concepts, Strategies, and Best Practices.

By R. F. Smallwood. Second Edition. John Wiley and Sons. 2020.

[Srikantaiah, Koenig, Hawamdeh, 2010] Convergence of Project Management and

Knowledge Management. By T. K. Srikantaiah, M. E. D. Koenig, S. Hawamdeh
(Editors). Scarecrow Press. 2010.

[Stamelos, 2010] Software Project Management Anti-Patterns. By I. Stamelos. The

Journal of Systems and Software. Volume 83. 2010. Pages 52-59.

[Stanier, 2020] Become an Effective Software Engineering Manager: How to Be the

Leader Your Development Team Needs. By J. Stanier. The Pragmatic Bookshelf. 2020.

[Stepanek, 2012] Software Project Secrets: Why Software Projects Fail. By G. Stepanek.
Apress. 2012.

[Stober, Hansmann, 2010] Agile Software Development: Best Practices for Large
Software Development Projects. By T. Stober, U. Hansmann. Springer-Verlag. 2010.

[Sudhakar, 2012] A Model of Critical Success Factors for Software Projects. By G. P.

Sudhakar. Journal of Enterprise Information Management. Volume 25. Issue 6. 2012.
Pages 537-558.

[Sukhoo, Barnard, Eloff, Poll, Motah, 2005] Accommodating Soft Skills in Software
Project Management. By A. Sukhoo, A. Barnard, M. M. Eloff, J. A. Van der Poll, M.
Motah. Issues in Informing Science and Information Technology. Volume 2. 2005. Pages
691-704.

[Sutton, 2010] Preliminary Research Context for Investigating the Use of Wikis as
Knowledge Management Tools to Project Management–Based Initiatives. By M. J. D.
Sutton. In: Convergence of Project Management and Knowledge Management. By T. K.
Srikantaiah, M. E. D. Koenig, S. Hawamdeh (Editors). Scarecrow Press. 2010. Page 122-
141.

[Tennant, 2022] Product Development: An Engineer’s Guide to Business Considerations,

Real-World Product Testing, and Launch. By D. V. Tennant. John Wiley and Sons. 2022.

74
[Trendowicz, Jeffery, 2014] Software Project Effort Estimation: Foundations and Best
Practice Guidelines for Success. By A. Trendowicz, R. Jeffery. Springer International
Publishing. 2014.

[Unger, 2009] Project Management Is Problem Management. By L. Unger. In: 97 Things

Every Project Manager Should Know: Collective Wisdom from the Experts. B. Davis
(Editor). O’Reilly Media. 2009. Pages 42-43.

[Valerdi, 2023] Lessons From the Father of Software Engineering. By R. Valerdi.

Computer. Volume 56. Issue 1. 2023. Pages 133-136.

[Välimäki, 2011] Pattern Language for Project Management in Global Software

Development. By A. Välimäki. Ph.D. Thesis. Tampere University of Technology.
Tampere, Finland. 2011.

[Villafiorita, 2014] Introduction to Software Project Management. By A. Villafiorita.

CRC Press. 2014.

[Waggoner, 2009] The Holy Trinity of Project Management. By P. Waggoner. In: 97

Things Every Project Manager Should Know: Collective Wisdom from the Experts. B.
Davis (Editor). O’Reilly Media. 2009. Pages 98-99.

[Wallace, 2016] Leadership Lessons from a UPS Driver: Delivering a Culture of We, Not
Me. By R. Wallace. Berrett-Koehler Publishers. 2016.

[Wastian, Rosenstiel, West, Braumandl, 2015] Applied Psychology for Project Managers:
A Practitioner’s Guide to Successful Project Management. By M. Wastian, L. von
Rosenstiel, M. A. West, I. Braumandl (Editors). Springer-Verlag. 2015.

[Wendorff, 2022] Politics in Software Development: Navigating Stakeholder Power and

Conflict in Organizations. By P. Wendorff. Apress. 2022.

[Whitaker, 2016a] Pass the PMP® Exam: Tools, Tips and Tricks to Succeed. By S.
Whitaker. Second Edition. Apress. 2016.

[Whitaker, 2016b] PMP® Examination Practice Questions: 400 Practice Questions and
Answers to help you Pass. By S. Whitaker. Third Edition. Apress. 2016.

75
[Wiefling, 2007] Scrappy Project Management: The 12 Predictable and Avoidable
Pitfalls that Every Project Faces. By K. Wiefling. Scrappy About. 2007.

[Wiegers, 1996] Creating a Software Engineering Culture. By K. Wiegers. Dorset House.

1996.

[Wnuka, Gorschek, Zahda, 2013] Obsolete Software Requirements. By K. Wnuka, T.

Gorschek, S. Zahda. Information and Software Technology. Volume 55. 2013. Pages
921-940.

[Wood, 2009] The Fallacy of the Big Round Ball. By D. Wood. In: 97 Things Every
Project Manager Should Know: Collective Wisdom from the Experts. B. Davis (Editor).
O’Reilly Media. 2009. Pages 124-125.

[Wysocki, 2009] Effective Project Management: Traditional, Agile, Extreme. By R. K.

Wysocki. Fifth Edition. John Wiley and Sons. 2009.

[Wysocki, 2014] Effective Project Management: Traditional, Agile, Extreme. By R. K.

Wysocki. Seventh Edition. John Wiley and Sons. 2014.

[Wysocki, 2019] Effective Project Management: Traditional, Agile, Extreme, Hybid. By

R. K. Wysocki. Eighth Edition. John Wiley and Sons. 2019.

[Yourdon, 2003] Death March: The Complete Software Developer’s Guide to Surviving.
By E. Yourdon. Second Edition. Prentice-Hall. 2003.

76
This resource is under a Creative Commons Attribution-NonCommercial-
NoDerivatives 4.0 International license.

77