MECHIR BANDA TEAM (MBT): Software Project Management CS615

Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf 
 
Handouts | Lectures | Contents | Books 
<div>
 </div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxLDnETWXpnH3RPlQMicShcLQM-fG64z36K-bo1SxDnb2dxLXtaQAdAkzQsvbtk5uh8yhK8GoeSbHsJDgEzMT6sF6uzsAgZUSc_4dzEMedIDfJ61yNt3EIiy_O209nU_xa5w5Pu8VAqGw/s1600/CS615-Software+Project+Management%252C+A+Practitioner%2527s+Approach+by+E.+M.+Bennatan.jpg" imageanchor="1"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxLDnETWXpnH3RPlQMicShcLQM-fG64z36K-bo1SxDnb2dxLXtaQAdAkzQsvbtk5uh8yhK8GoeSbHsJDgEzMT6sF6uzsAgZUSc_4dzEMedIDfJ61yNt3EIiy_O209nU_xa5w5Pu8VAqGw/s640/CS615-Software+Project+Management%252C+A+Practitioner%2527s+Approach+by+E.+M.+Bennatan.jpg" width="426" /></a></div>
<div>
 </div>
<div>
 </div>
<div>
Software Project Management (CS615) 
1 
© Copyright Virtual University of Pakistan 
LECTURE # 1 
1. Introduction & Fundamentals 
1.1 What is Management? 
Basically, the management involves the following activities: 
􀂐 Planning- deciding what is to be done 
􀂐 Organizing- making arrangements 
􀂐 Staffing- selecting the right people for the job 
􀂐 Directing- giving instructions 
􀂐 Monitoring- checking on progress 
􀂐 Controlling- taking action to remedy hold-ups 
􀂐 Innovating- coming up with new solutions 
􀂐 Representing- liaising with users, etc. 
1.2 What is Project Management? 
Project Management is the art of maximizing the probability that a project 
delivers its goals on Time, to Budget and at the required Quality. 
The art of planning for the future has always been a human trait. In essence a 
project can be captured on paper with a few simple elements: a start date, an end 
date, the tasks that have to be carried out and when they should be finished, and 
some idea of the resources (people, machines etc) that will be needed during the 
course of the project. 
Project management is the application of knowledge, skills, tools, and 
techniques to project activities to meet project requirements. Project management 
is accomplished through the use of the processes such as: initiating, planning, 
executing, controlling, and closing. It is important to note that many of the 
processes within project management are iterative in nature. This is in part due to 
the existence of and the necessity for progressive elaboration in a project 
throughout the project life cycle; i.e., the more you know about your project, the 
better you are able to manage it. 
Project management is also defined as a strategic competency that has successfully been 
applied in such high profile projects as the construction of silk root, organizing and managing the 
Olympics Games, and the construction of Islamabad-Lahore motorway, just to name a few. If 
project management can play a major role in these success stories, just imagine what it might be 
able to do for your own organization. 
The term project management is sometimes used to describe an organizational 
approach to the management of ongoing operations. This approach, more properly 
called management by projects, treats many aspects of ongoing operations as 
projects to apply project management techniques to them. 
Software Project Management (CS615) 
2 
© Copyright Virtual University of Pakistan 
Almost any human activity that involves carrying out a non- repetitive task 
can be a project. So we are all project managers! We all practice project 
management (PM). But there is a big difference between carrying out a very 
simple project involving one or two people and one involving a complex mix of 
people, organizations and tasks. 
1.3 What is Software Project Management? 
When the plan starts to involve different things happening at different times, some 
of which are dependent on each other, plus resources required at different times 
and in different quantities and perhaps working at different rates, the paper plan 
could start to cover a vast area and be unreadable. 
Nevertheless, the idea that complex plans could be analyzed by a computer to 
allow someone to control a project is the basis of much of the development in 
technology that now allows projects of any size and complexity, not only to be 
planned, but also modeled to answer 'what if?' questions. 
The original programs and computers tended to produce answers long after an 
event had taken place. Now, there are many project planning and scheduling 
programs that can provide real time information, as well as linking to risk 
analysis, time recording, and costing, estimating and other aspects of project 
control. 
But computer programs are not project management: they are tools for 
project managers to use. Project management is all that mix of components of 
control, leadership, teamwork, resource management etc that goes into a 
successful project. 
Project managers can be found in all industries. Their numbers have grown 
rapidly as industry and commerce has realized that much of what it does is project 
work. And as project-based organizations have started to emerge, project 
management is becoming established as both a professional career path and a way 
of controlling business. 
So opportunities in project management now exist not only in being a project 
manager, but also as part of the support team in a project or program office or as a 
team leader for part of a project. There are also qualifications that can be attained 
through the professional associations. 
Software Project Management (CS615) 
3 
© Copyright Virtual University of Pakistan 
1.4 What is a Project? 
A project is an activity with specific goals which takes place over a finite 
period of time. 
“A temporary organization that is needed to produce a unique and pre-defined 
outcome or result at a pre-specified time using pre-determined resources” 
Projects are often implemented as a means of achieving an organization’s 
strategic plan. Operations and projects differ primarily in that operations are 
ongoing and repetitive while projects are temporary and unique. A project can 
thus be defined in terms of its distinctive characteristics—a project is a temporary 
endeavor undertaken to create a unique product or service. Temporary means 
that every project has a definite beginning and a definite end. Unique means that 
the product or service is different in some distinguishing way from all other 
products or services. For many organizations, projects are a means to respond to 
those requests that cannot be addressed within the organization’s normal 
operational limits. 
Projects are undertaken at all levels of the organization. They may involve a 
single person or many thousands. Their duration ranges from a few weeks to more 
than five years. Projects may involve a single unit of one organization or may 
cross organizational boundaries, as in joint ventures and partnering. 
Examples of projects include: 
• Developing a new product or service. 
• Effecting a change in structure, staffing, or style of an organization. 
• Designing a new transportation vehicle. 
• Developing or acquiring a new or modified information system. 
• Constructing a building or facility. 
• Building a water system for a community in a developing country. 
• Running a campaign for political office. 
• Implementing a new business procedure or process. 
1. Temporary 
Temporary means that every project has a definite beginning and a definite end. 
The end is reached when the project’s objectives have been achieved, or it 
becomes clear that the project objectives will not or cannot be met, or the need for 
the project no longer exists and the project is terminated. Temporary does not 
necessarily mean short in duration; many projects last for several years. In every 
case, however, the duration of a project is finite; projects are not ongoing efforts. 
2. Unique, Product Service or Result 
Projects involve creating something that has not been done in exactly the same 
way before and which is, therefore, unique and distinct. Projects create: 
Software Project Management (CS615) 
4 
© Copyright Virtual University of Pakistan 
• A product or artifact that is produced, is quantifiable and can be either an 
end item in itself or a component item 
• A capability to perform a service, such as business functions supporting 
production or distribution 
• A result, such as new knowledge. For example, a research and 
development project develops knowledge that can be used to determine 
whether or not a trend is present or a new process will benefit society. 
The presence of repetitive elements does not change the fundamental uniqueness 
of the project work. For example: 
• A project to develop a new commercial airliner may require multiple 
proto-types. 
• A project to bring a new drug to market may require thousands of doses of 
the drug to support clinical trials. 
• A real estate development project may include hundreds of individual 
units. 
• A development project (e.g., water and sanitation) may be implemented in 
five geographic areas. 
3. Aims/Tasks/Purpose 
The projects are designed to achieve specific targets defined in terms of aims, 
tasks or a purpose. The nature and size of the project depends upon 
complexity of the task, realization of the aims and scope of the purpose any 
organization wants to achieve. In short project has to be aimed for achieving 
certain tasks in a given time frame. 
4. Limited Time Scale 
The projects are always designed considering time constraints. Extension to 
the project completion dead lines are always discouraged as time overrun, 
costs extra and in some cases opportunity cost for not completing a project is 
too high. 
􀀔 Progressive, Elaboration 
Progressive elaboration is a characteristic of projects that accompanies the 
concepts of temporary and unique. “Progressively” means developing thoroughly 
in steps, and continuing steadily by increments while elaborated means “worked 
out with care and detail; developed thoroughly” 
For example, the project scope will be broadly described early in the project, and 
made more explicit and detailed as the project team develops a better and more 
complete understanding of the objectives and deliverables. 
Progressive elaboration of project specifications must be carefully coordinated 
with proper project scope definition, particularly if the project is performed under 
contract. When properly defined, the scope of the project—the work to be done— 
Software Project Management (CS615) 
5 
© Copyright Virtual University of Pakistan 
should be controlled as the project and product specifications are progressively 
elaborated. 
The following examples illustrate progressive elaboration in two different 
application areas. 
􀀹 Example 1. Development of a chemical processing plant begins with process 
engineering to define the characteristics of the process. These characteristics are 
used to design the major processing units. This information becomes the basis for 
engineering design, which defines both the detail plant layout and the mechanical 
characteristics of the process units and ancillary facilities. All of this results in 
design drawings that are elaborated to produce fabrication and construction 
drawings. During construction, interpretations and adaptations are made as 
needed and subject to proper approval. This further elaboration of the deliverables 
is captured in as-built drawings, and final operating adjustments are made during 
testing and turnover. 
􀀹 Example 2. The product of an economic development project may initially be 
defined as: “Improve the quality of life of the lowest income residents of 
community X.” As the project proceeds, the products may be described more 
specifically as, for example: “Provide access to food and water to 500 low income 
residents in community X.” The next round of progressive elaboration might 
focus exclusively on increasing agriculture production and marketing, with 
provision of water deemed to be a secondary priority to be initiated once the 
agricultural component is well under way. 
Software Project Management (CS615) 
6 
© Copyright Virtual University of Pakistan 
LECTURE # 2 
1. Introduction & Fundamentals 
1.5 Goals of Project management 
Project management is the discipline of defining and achieving a set of goals 
while optimizing the use of allocated resources (time, money, people, space, 
etc). This includes planning, scheduling and maintaining progress of the 
activities that comprise the project. Project management is normally reserved for 
focused, non-repetitive, time-limited activities with some degree of risk and that 
are beyond the usual scope of program (operational) activities for which the 
organization is responsible. 
Project management software describes the tools to efficiently coordinate and 
automate the various project management component processes. Project 
management software generally offers extensive reporting features, such as dayto- 
day status updates of project progress, scheduling and dependency trees, and 
system-generated alerts when schedules slip beyond pre-set tolerances. Most 
project management tools include web-accessible interfaces so that employees 
can access features of the software relevant to their needs, and functionality to 
allow managers to share resource pools without overbooking. 
1.6 Project Characteristics 
1. Temporary 
Temporary means that every project has a definite beginning and a definite end. 
The end is reached when the project’s objectives have been achieved, or it 
becomes clear that the project objectives will not or cannot be met, or the need for 
the project no longer exists and the project is terminated. Temporary does not 
necessarily mean short in duration; many projects last for several years. In every 
case, however, the duration of a project is finite; projects are not ongoing efforts. 
2. Unique, Product Service or Result 
Projects involve creating something that has not been done in exactly the same 
way before and which is, therefore, unique and distinct. Projects create: 
• A product or artifact that is produced, is quantifiable and can be either an 
end item in itself or a component item 
• A capability to perform a service, such as business functions supporting 
production or distribution 
Software Project Management (CS615) 
7 
© Copyright Virtual University of Pakistan 
• A result, such as new knowledge. For example, a research and 
development project develops knowledge that can be used to determine 
whether or not a trend is present or a new process will benefit society. 
The presence of repetitive elements does not change the fundamental uniqueness 
of the project work. For example: 
• A project to develop a new commercial airliner may require multiple 
proto-types. 
• A project to bring a new drug to market may require thousands of doses of 
the drug to support clinical trials. 
• A real estate development project may include hundreds of individual 
units. 
• A development project (e.g., water and sanitation) may be implemented in 
five geographic areas. 
5. Aims/Tasks/Purpose 
The projects are designed to achieve specific targets defined in terms of aims, 
tasks or a purpose. The nature and size of the project depends upon 
complexity of the task, realization of the aims and scope of the purpose any 
organization wants to achieve. In short project has to be aimed for achieving 
certain tasks in a given time frame. 
6. Limited Time Scale 
The projects are always designed considering time constraints. Extension to 
the project completion dead lines are always discouraged as time overrun, 
costs extra and in some cases opportunity cost for not completing a project is 
too high. 
1.7 Four Project Dimensions 
Software project management is an umbrella activity within software engineering. 
It begins before any technical activity is initiated and continues throughout the 
definition, development, and support of computer software. 
Four P's have a substantial influence on software project management- people, 
product, process, and project. 
• People must be organized into effective teams, motivated to do high-quality 
software work, and coordinated to achieve effective communication. 
• The product requirements must be communicated from customer to 
developer, partitioned (decomposed) into their constituent parts, and 
positioned for work by the software team. 
• The process must be adapted to the people and the problem. A common 
process framework is selected, an appropriate software engineering paradigm 
is applied, and a set of work tasks is chosen to get the job done. 
Software Project Management (CS615) 
8 
© Copyright Virtual University of Pakistan 
• The project must be organized in a manner that enables the software team to 
succeed. 
Effective software project management focuses on the four P’s: people, product, 
process, and project. The order is not arbitrary. The manager who forgets that 
software engineering work is an intensely human endeavor will never have 
Success in project management. A manager who fails to encourage 
comprehensive customer communication early in the evolution of a project risks 
building an elegant solution for the wrong problem. The manager who pays little 
attention to the process runs the risk of inserting competent technical methods and 
tools into a vacuum. The manager who embarks without a solid project plan 
jeopardizes the success of the product. 
⇒ People 
In a study published by the IEEE, the engineering vice presidents of three 
major technology companies were asked the most important contributor to a 
successful software project. They answered in the following way: 
VP 1: I guess if you had to pick one thing out that is most important in our 
environment. I’d say it’s not the tools that we use, it’s the people. 
VP 2: The most important ingredient that was successful on this project was 
having smart people…very little else matters in my opinion....The most 
important thing you do for a project is selecting the staff...The success of the 
software development organization is very, very much associated with the 
ability to recruit good people. 
VP 3: The only rule I have in management is to ensure I have good people – 
real good people-and that I grow good people – and that I provide an 
environment in which good people can produce. 
Indeed, this is a compelling testimonial on the importance of people in the 
software engineering process. And yet, all of us, from senior engineering vice 
presidents to the lowliest practitioner, often take people for granted. Managers 
argue (as the preceding group had) that people are primary, but their actions 
sometimes belie their words. In this section we examine the players who 
participate in the software process and the manner in which they are organized 
to perform effective software engineering. 
1. The Players 
The software process (and every software project) is populated by players 
who can be categorized into one of five constituencies: 
1. Senior managers who define the business issues that often have 
significant influence on the project. 
Software Project Management (CS615) 
9 
© Copyright Virtual University of Pakistan 
2. Project (technical) managers who must plan, motivate, organize, 
and control the practitioners who do software work. 
3. Practitioners who deliver the technical skills that are necessary to 
engineer a product or application. 
4. Customers who specify the requirements for the software to be 
engineered and other stakeholders who have a peripheral interest in 
the outcome. 
2. End-users 
Who interact with the software once it is released for production use. 
Every software project is populated by people who fall within this 
taxonomy. To be effective, the project team must be organized in a way 
that maximizes each person’s skills and abilities. And that’s the job of the 
team leader. 
3. Team Leaders 
Project management is a people-intensive activity, and for this reason, 
competent practitioners often make poor team leaders. They simply don’t 
have the right mix of people skills. And yet, as Edgemon states: 
“unfortunately and all too frequently it seems, individuals just fall into a 
project manager role and become accidental project managers.” [EDG95]. 
The cultivation of motivated, highly skilled software people has been 
discussed since the 1960s (e.g., [COUBO] [WIT94} [DEM9B]). In fact, 
the “people factor’ is so important that the Software Engineering Institute 
has developed a people management capability maturity model (PMCMM), 
“to enhance the readiness of software organizations to undertake 
increasingly complex applications by helping to attract, grow, motivate, 
deploy, and retain the talent needed to improve their software 
development capability” [CUR94]. 
The people management maturity model defines the following key 
practice areas for software people: recruiting, selection, performance 
management, training, compensation, career development, organization 
and work design, and team/culture development. Organizations that 
achieve high levels of maturity in the people management area have a 
higher likelihood of implementing effective software engineering 
practices. 
The PM-CMM is a companion to the software capability maturity model 
that guides organizations in the creation of a mature software process. 
⇒ The Process 
Software Project Management (CS615) 
10 
© Copyright Virtual University of Pakistan 
In a fascinating book that provides an economist’s view of software and 
software engineering, Howard Baetjer. Jr, comments on the software process: 
Software development is a social learning process. The process is a dialogue 
in which the knowledge that must become the software is brought together and 
embodied in the software. The process provides interaction between users and 
designers: between users and evolving tools, and between designers and 
evolving tools [technology] It is an iterative process in which the evolving tool 
itself serves as the medium for communication, with each new round of the 
dialogue eliciting more useful knowledge from the people involved. 
When you build a product or system, it’s important to go through a series of 
predictable steps – a road map that helps you create a timely, high-quality 
result, The road map that you follow is called a ‘software process’ . 
Software engineers and their managers adapt the process to their needs and 
then follow it. In addition, the people who have ties defined by the process 
requested the software play a role in the software process. 
At a detailed level, the process that you adopt depends on the software you’re 
building. One process might be appropriate for creating software for an 
aircraft avionics system, while an entirely different process would be 
indicated for the creation of a web site. 
From the point of view of a software engineer, the work products are the 
programs, documents and data produces as a consequence of the software 
engineering activities defined by the process. 
A software process provides the framework from which a comprehensive plan 
for software development can be established. 
A small number of framework activities are applicable to all software projects, 
regardless of their size or complexity. 
A number of different task sets-tasks, milestones, work products and; quality 
assurance points-enable the framework activities to be adapted to the 
characteristics of the software project and the requirements of the project 
team. 
Finally, umbrella activities – such as software quality assurance, software 
configuration management, and measurement – overlay the process model. 
Umbrella activities are independent of anyone framework activity and occur 
throughout the process. 
Software Project Management (CS615) 
11 
© Copyright Virtual University of Pakistan 
LECTURE # 3 
1. Introduction & Fundamentals 
1.8 Project Dimensions 
⇒ Product and Technology 
– The 80:20, rule was originated by Vilfredo Pareto, an Italian economist who 
studies the distribution of wealth in a variety of countries around 1900. He 
discovered a common phenomenon: about 80% of the wealth in most countries 
was controlled by a consistent minority -- about 20% of the people. Pareto called 
this a "predictable imbalance." His observation eventually became known as 
either the "80:20 rule" or "Pareto's Principle." 
The credit for adapting Pareto's economic observations to business goes to the 
"Father of Total Quality Management," service quality consultant Joseph M. 
Juran. In 1950, he published "The Quality Control Handbook," which first 
recognized the applicability of the Pareto principle in the context of inventory 
management, e.g.: 
• 20% of the repair parts normally account for 80 percent of the total 
inventory 
• 80% of production volume usually comes from 20% of the producers 
He subsequently recognized that this rule of thumb was universally applicable 
across fields of endeavor. As a credit to Pareto's work, Juran named his finding 
the Pareto Principle. This universal management theory became generalized as 
"the 80-20 Rule": 
The "80:20 rule" has become one of the best known "leadership shorthand terms" 
reflecting the notion that most of the results (of a life, of a program, of a financial 
campaign) come from a minority of effort (or people, or input). 
The Rule, states that a small number of causes (20%) is responsible for a large 
percentage (80%) of the effect. It means that in anything a few (20 percent) are 
vital and many (80 percent) are trivial. 
There is an inherent imbalance between cause and effect, effort and reward, inputs 
and outputs, etc; and that imbalance tends to the ratio of 80:20. So, if we know 
which 20% of our work produces 80% of our income, we can do more of it and 
our income will increase proportionately! 
Software Project Management (CS615) 
12 
© Copyright Virtual University of Pakistan 
You know 20 percent of you stock takes up 80 percent of your warehouse space 
and that 80 percent of your stock comes from 20 percent of your suppliers. Also 
80 percent of your sales will come from 20 percent of your sales staff. 20 percent 
of your staff will cause 80 percent of your problems, but another 20 percent of 
your staff will provide 80 percent of your production. It works both ways. 
Some Sample 80/20 Rule Applications 
80% of process defects arise from 20% of the process issues. 
20% of your sales force produces 80% of your company revenues. 
80% of delays in schedule arise from 20% of the possible causes of the delays. 
80% of customer complaints arise from 20% of your products or services. 
How It Can Help You 
– The value of the Pareto Principle for a manager is that it reminds you to focus on 
the 20 percent that matters. Of the things you do during your day, only 20 percent 
really matter. Those 20 percent produce 80 percent of your results. Identify and 
Characteristic 
focus on those things. When the fire drills of the day begin to sap your time, 
remind yourself of the 20 percent you need to focus on. If something in the 
schedule has to slip, if something isn't going to get done, make sure it's not part of 
that 20 percent. 
Pareto's Principle, the 80/20 Rule, should serve as a daily reminder to focus 80 
percent of your time and energy on the 20 percent of you work that is really 
important. Don't just "work smart", work smart on the right things. 
– Size 
The larger product, there will be more requirements and features to deliver, 
eventually it will take more time in its production. So if you cut the size of the 
produce to half it will save you 60% of the effort. 
– Characteristic 
– Development Tools 
Software Project Management (CS615) 
13 
© Copyright Virtual University of Pakistan 
Customer delivered value 
1.9 Project Phases 
Organizations performing projects will usually divide each project into several 
Project phases to improve management control and provide for links to the 
ongoing operations of the performing organization. 
Collectively, the project phases are known as the project life cycle. Software 
development, just like most other activities, has a beginning, middle and an end. 
The end of one development activity is sometimes perceived as being linked to 
the beginning of a new development activity thus producing a cycle of beginningmiddle- 
end, link, beginning-middle-end, link, and so forth. 
This view of software development is referred to as the software development 
life cycle. 
A project has five phases. Here's a brief summary of each: 
⇒ Initiation 
Articulate your vision for the project, establish goals, assemble your team, 
and define expectations and the scope of your project. 
⇒ Planning 
Refine the scope, identify specific tasks and activities to be completed, 
and develop a schedule and budget. 
⇒ Executing 
Accomplish your goals by leading your team, solving problems, and 
building your project. 
Value of products 
Value of services 
Financial cost 
Personal value 
Psychical cost 
Image value 
Time cost 
Real value to 
the customer 
Total value 
Total costs 
Energy cost 
+ 
- 
Software Project Management (CS615) 
14 
© Copyright Virtual University of Pakistan 
⇒ Controlling 
Monitor changes to the project make corrections, adjust your schedule to 
respond to problems, or adjust your expectations and goals. 
⇒ Closing 
Deliver your project to your audience, acknowledge results, and assess its 
success. Take the time to compose a written evaluation of the project and 
the development effort. 
The middle three phases are not sequential. You will find that you are constantly 
planning, executing, and controlling your project as necessary. 
Aren't these phases really just common sense? In many ways, yes, but keep in 
mind that software development, whether a few Web pages or a complex CDROM, 
is a complex, unpredictable process. 
Most software projects (something like 80 percent) are delivered late, 
substantially over budget, and incomplete. The more effort you put into managing 
your project, the more you increase your chances of success. 
– Characteristics of Project Phases 
Each project phase is marked by completion of one or more deliverables. A 
deliverable is a tangible, verifiable work product such as a feasibility study, a 
detail design, or a working prototype. The deliverables, and hence the phases, are 
part of a generally sequential logic designed to ensure proper definition of the 
product of the project. 
The conclusion of a project phase is generally marked by a review of both key 
deliverables and project performance to date, to a) determine if the project should 
continue into its next phase and b) detect and correct errors cost effectively. These 
phase-end reviews are often called phase exits, stage gates, or kill points. 
Each project phase normally includes a set of defined deliverables designed to 
establish the desired level of management control. The majority of these items are 
related to the primary phase deliverable, and the phases typically take their names 
from these items: requirements, design, build, test, startup, turnover, and others, 
as appropriate. 
– Characteristics of the Project Life Cycle 
The project life cycle serves to define the beginning and the end of a project. For 
example, when an organization identifies an opportunity to which it would like to 
respond, it will often authorize a needs assessment and/or a feasibility study to 
decide if it should undertake a project. The project life-cycle definition will 
determine whether the feasibility study is treated as the first project phase or as a 
separate, standalone project. 
Software Project Management (CS615) 
15 
© Copyright Virtual University of Pakistan 
The project life-cycle definition will also determine which transitional actions at 
the beginning and the end of the project are included and which are not. In this 
manner, the project life-cycle definition can be used to link the project to the 
ongoing operations of the performing organization. 
The phase sequence defined by most project life cycles generally involves some 
form of technology transfer or handoff such as requirements to design, 
construction to operations, or design to manufacturing. Deliverables from the 
preceding phase are usually approved before work starts on the next phase. 
However, a subsequent phase is sometimes begun prior to approval of the 
previous phase deliverables when the risks involved are deemed acceptable. This 
practice of overlapping phases is often called fast tracking. 
Project life cycles generally define: 
􀂃 What technical work should be done in each phase (e.g., is the work of the 
architect part of the definition phase or part of the execution phase?). 
􀂃 Who should be involved in each phase (e.g., implementers who need to be 
involved with requirements and design). 
􀂃 Project life-cycle descriptions may be very general or very detailed. Highly 
detailed descriptions may have numerous forms, charts, and checklists to 
provide structure and consistency. Such detailed approaches are often called 
project management methodologies. 
􀂃 Most project life-cycle descriptions share a number of common 
characteristics: 
􀂃 Cost and staffing levels are low at the start, higher toward the end, and drop 
rapidly as the project draws to a conclusion. 
􀂃 The probability of successfully completing the project is lowest, and hence 
risk and uncertainty are highest, at the start of the project. The probability of 
successful completion generally gets progressively higher as the project 
continues. 
􀂃 The ability of the stakeholders to influence the final characteristics of the 
project’s product and the final cost of the project is highest at the start and 
gets progressively lower as the project continues. A major contributor to this 
phenomenon is that the cost of changes and error correction generally 
increases as the project continues. 
Care should be taken to distinguish the project life cycle from the product life 
cycle. For example, a project undertaken to bring a new desktop computer to 
market is but one phase or stage of the product life cycle. 
Although many project life cycles have similar phase names with similar 
deliverables required, few are identical. Most have four or five phases, but some 
Software Project Management (CS615) 
16 
© Copyright Virtual University of Pakistan 
have nine or more. Even within a single application area, there can be significant 
variations. 
One organization’s software development life cycle may have a single design 
phase while another’s has separate phases for functional and detail design. 
Subprojects within projects may also have distinct project life cycles. For 
example, an architectural firm hired to design a new office building is first 
involved in the owner’s definition phase when doing the design, and in the 
owner’s implementation phase when supporting the construction effort. The 
architect’s design project, however, will have its own series of phases from 
conceptual development through definition and implementation to closure. The 
architect may even treat designing the facility and supporting the construction as 
separate projects with their own distinct phases. 
– Project Life Cycle includes the following Phases and activities: 
A. Concept Phase 
1. User Need 
2. Initial Investigation 
3. User Review 
4. System Performance Design 
5. Candidate Review 
6. Study Phase Report 
B. Requirements Phase 
1. The software requirements specification document 
2. The project development plan 
3. The software test plan 
C. Design Phase 
1. General System Review 
2. Processing Requirements Identification 
3. Data Base Design 
4. Control Requirements 
5. Output Design 
6. Input Design 
7. Software Selection 
8. Equipment Selection/Acquisition 
9. People 
10. Reference Manual Identification 
11. Plans 
12. Design Specifications Preparation 
13. Design Phase Report Preparation 
D. Development Phase 
Software Project Management (CS615) 
17 
© Copyright Virtual University of Pakistan 
1. Implementation Planning 
2. Computer Program Design 
3. User Review 
4. Equipment Acquisition and Installation 
5. Coding and Debugging 
6. Computer Program Testing 
7. System Testing 
8. Reference Manual Preparation 
9. Personnel Training 
10. Changeover Plan Preparation 
11. Development Phase Report Preparation 
12. User Acceptance Review 
E. Operation Phase 
1. System Changeover 
2. Routine Operation 
3. System Performance Evaluation 
4. System Changes/Enhancements 
1.10 Software Development Lifecycle 
⇒ Water Fall Theme 
Software development, just like most other activities, has a beginning, middle and 
an end. The end of one development activity is sometimes perceived as being 
linked to the beginning of a new development activity thus producing a cycle of 
beginning-middle-end, link, beginning-middle-end, link, and so forth. This view 
of software development is referred to as the software development life cycle. 
There are many variations of the software development life cycle. Figure 1 
presents a simple life cycle that was common during the first few decades of 
software development. In those early days of software development, the 
programmer would create programs by iterating from code to fix then back to 
code, and then to fix again, until something acceptable was (hopefully) produced. 
At the start of the cycle, there was usually no clear concept of what was required, 
and the basic development procedure was a form of 'let's see what we can do' 
approach. 
The software development method represented by the development cycle in Fig.1 
is often referred to as the code and fix method (for obvious reasons). Software 
development methodologies have come a long way since the days of code and fix, 
though it is surprising how much software is still being developed this way. 
Successful management of any project, especially software projects, requires 
planning, and planning is impossible with code and fix, which is totally 
unpredictable. Management of software development within an engineering 
Software Project Management (CS615) 
18 
© Copyright Virtual University of Pakistan 
discipline is based on a much more orderly set of development phases. These 
phases are not implemented solely by programmers; they require software 
engineers. In fact, programming has become a relatively small part of the modern 
software development cycle, as is evident from Table 1. 
The numbers in Table 1 are derived from the general shift in emphasis to software 
planning (requirements and design) and testing. Commercial data processing 
systems, with some exceptions, still spend a significant amount of development 
time in the programming and unit testing phase. Real-time systems are often more 
complex, and may include extensive hardware software integration. This usually 
requires more planning and more integration and testing. 
Figure 1: the code and fix method 
Table 1 Estimated percentage of time spent in each major software development phase 
Planning Code and unit test Integration and test 
Commercial data processing 25% 40% 35% 
Real-time systems 35% 25% 40% 
Military systems 40% 20% 40% 
Military systems require high reliability and are usually closely supervised by the 
customer, leading to a significant increase in the time spent in planning. 
The data in Table 1, of course, represents a generalization; commercial data 
processing systems can be just as complex as a real-time system. 
Figure 2 presents the basic phased model of a software development cycle. This 
model, called the Waterfall model, gets its name from the way in which each 
phase cascades into the next (due to overlapping), as demonstrated in Fig. 3. 
Some interpretations of the Waterfall model, like the one that follows, combine 
the top level design and the detailed design phases into a single design phase, and 
the integration and test phases into a single phase. In fact, there are many 
variations of the classic Waterfall model, but they are all based upon a systematic 
transition from one development phase to the next, until the project is complete. 
Concept Code Fix Test 
Maintain 
Software Project Management (CS615) 
19 
© Copyright Virtual University of Pakistan 
Conception 
Maintenance Software 
Requirements 
Test 
Top level 
Design 
Integration Detailed 
Design 
Implementation 
Figure 2: The phased model of the software development life cycle 
Conception 
Software requirements 
Top level" design 
Detailed design 
Implementation 
Integration 
Test 
Maintenance 
T 
Figure 3: The Waterfall model of the software development life cycle 
⇒ Rapid prototyping There are other development methodologies that do not move 
from one phase to the next like the Waterfall model. Rapid prototyping, for 
Software Project Management (CS615) 
20 
© Copyright Virtual University of Pakistan 
instance, iterates in a mini-development phase until a system prototype is 
developed (see Fig. 4). After the prototype is complete, the Waterfall approach 
can then be implemented to complete the full system. Rapid prototyping is 
particularly helpful in projects where the requirements are difficult to specify. The 
prototype can be used as a tool for analyzing and determining what the 
requirements should be. 
⇒ The Spiral model, described by Boehm (1988), is another development method 
that iterates between the requirements, design and implementation phases. 
However, the Spiral model continues iterating until the final system is complete. 
Within each, iteration, the Spiral model follows a phased approach similar to the 
Waterfall model. 
Different models maybe suitable for different software projects or for different 
software development organizations However, a good model must include certain 
fundamental features. Some of these basic requirements are discussed in IEEE 
Standard (IEEE 1993) Standard for Software Life Cycle Processes. This standard 
describes the processes that are mandatory for the development of software and 
specifies the activities that must be included in the life cycle model. 
Most modern software development models, and certainly those following IEEE 
Standard 1074, include some form of the basic phased model. It is therefore 
important to understand the different phases and how they relate to one another. 
Concept Prototype Requirements Design Implementation Test 
The rapid prototyping cycle 
Figure 4: Rapid prototyping followed by the phase method. 
Software Project Management (CS615) 
21 
© Copyright Virtual University of Pakistan 
LECTURE # 4 
1. Introduction & Fundamentals 
1.11 Costs and Cost Management 
Project Cost Management includes the processes required to ensure that the 
project is completed within the approved budget. 
⇒ Resource Planning—determining what resources (people, equipment, 
materials and what quantities of each should be used to perform project 
activities. 
⇒ Cost Estimating—developing an approximation (estimate) of the costs of 
the resources needed to complete project activities. 
⇒ Cost Budgeting—allocating the overall cost estimate to individual work 
activities. 
⇒ Cost Control—controlling changes to the project budget. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. 
Each process may involve effort from one or more individuals or groups of 
individuals, based on the needs of the project. 
Each process generally occurs at least once in every project phase. 
Although the processes are presented here as discrete elements with well-defined 
interfaces, in practice they may overlap and interact in ways not detailed here. 
Project cost management is primarily concerned with the cost of the resources 
needed to complete project activities. 
However, project cost management should also consider the effect of project 
decisions on the cost of using the project’s product. 
For example, limiting the number of design reviews may reduce the cost of the 
project at the expense of an increase in the customer’s operating costs. This 
broader view of project cost management is often called life-cycle costing. Lifecycle 
costing together with Value Engineering techniques are used to reduce cost 
and time, improve quality and performance, and optimize the decision-making. 
In many application areas, predicting and analyzing the prospective financial 
performance of the project’s product is done outside the project. 
Software Project Management (CS615) 
22 
© Copyright Virtual University of Pakistan 
In others (e.g., capital facilities projects), project cost management also includes 
this work. When such predictions and analyses are included, project cost 
management will include additional processes and numerous general management 
techniques such as return on investment, discounted cash flow, payback analysis, 
and others. 
Project cost management should consider the information needs of the project 
stakeholders—different stakeholders may measure project costs in different ways 
and at different times. For example, the cost of a procurement item may be 
measured when committed, ordered, delivered, incurred, or recorded for 
accounting purposes. 
1.12 Project vs. Program Management 
⇒ What is a Program? 
“A coordinated portfolio of projects that change organizations to achieve benefits 
of strategic importance” 
Program management is the process of managing multiple on 
going projects. An example would be that of designing, manufacturing and 
providing support infrastructure for an automobile make. 
It can be argued that Program Management has evolved from the complexities of 
the more intricate aspects of Project Management. 
As projects became larger; more interrelated; complex and multidimensional, the 
need arose to have an approach that controlled Project Management whilst 
remaining focused on the strategic objectives of the business. Whilst Project 
Management focused on technical delivery, Program Management engaged on 
relating design concepts to the business strategic vision of the future. 
It is very important that you understand the concept of Program Management as a 
method. Approaches may vary but definitions are relatively common. It is 
appropriate to understand the ‘mission, goals and objectives’ of Program 
Management and then relate these to the Program you propose to develop. 
Definitions will fall within each of these headings and it is possible to develop 
your own template which fits your organizational program. For example: 
– Mission: 
To co-ordinate a portfolio of projects to harmonize communications in 
order to achieve a set of stated business objectives: Provision of strategy 
alignment, with design objectives, in order to maintain control over a 
Software Project Management (CS615) 
23 
© Copyright Virtual University of Pakistan 
multiple project environment; ensuring quality end deliverables which 
meet business operational needs. 
The above is a fairly complex mission statement but provides a framework 
to develop an intricate set of goals in order to utilize Program 
Management. It is possible to develop an extensive list of goals, 
depending upon the level of detail you wish to acquire. The following are 
offered as suggestions: 
– Goals: 
1. Clearly defined roles and responsibilities 
2. Established baselines and Terms of Reference statement 
3. Type of program defined 
4. Future business blueprint 
5. Recognition of business transformation procedures 
6. Defined structure of the Program 
7. Route Map 
8. Visible end deliverables — vision of the future 
9. Identification of future benefits 
10. Risk 
11. Contingency planning 
Software Project Management (CS615) 
24 
© Copyright Virtual University of Pakistan 
Each of the goals would then be analyzed for providing objectives. For example: 
• Managing a program embraces functions, risks and strategies outside of what a 
project manager does. 
• A program has goals beyond those of a project or group of projects. Program 
outcomes are usually service delivery focused whereas a project is more likely 
to be focused on the delivery of a 'product'. 
• A program is more than a grouping of projects (that's just a program of works). 
• The coordinated management of a portfolio of projects to achieve a set of 
business objectives 
• There are many more meanings of the term program management. Here are the 
more common meanings: 
– The Multi-Project Organization: 
Program Management is the directing of a portfolio of projects that benefit 
from a consolidated approach. 
Jobbing engineering companies; software houses contracting for work; and 
many other types of organization; run many simultaneous projects each of 
which may or not contribute towards the corporate goals. 
Typically the result of such a project is a deliverable which is eventually 
delivered to a client for payment. After many delays the payment arrives and 
Software Project Management (CS615) 
25 
© Copyright Virtual University of Pakistan 
gets paid into the company’s bank account thereby increasing cash flow which 
is achieving one of the company’s objectives. 
Sometimes the projects are much more directly aimed at corporate goals - 
opening a new factory or launching a new product - spring to mind. 
The common elements of the projects are that they run simultaneously or at 
least overlap with each other, they share resources and are supposed to 
generate some income. One project being cancelled does not necessarily 
change the organization’s general direction. These types of programs run for 
ever and need have no end date. The projects are separate in that there need 
not be logical links between projects. Whilst they share the same resources, 
delays in one project need not cause delays in others. 
– The Mega Project 
The management of a portfolio of projects towards one specific objective; 
Program management can also mean one very large project. 
The USA’s Man on the Moon Project was such a program. In this sense the 
term program indicates one very large project which is made up from a 
number of components. Within the Apollo program there were many projects: 
the Lunar Lander, the Orbiter, the Launcher and the Control Systems were all 
projects which were large, complex and interesting. Polaris and the 
Manhattan project (which resulted in the nuclear bomb) are other famous 
projects large enough to be called programs. Therefore, particularly in USA, 
the word program refers to a series of projects which make up one large 
project. 
The program is usually reflected in the management structure as there will be 
a program manager to whom the project managers will report. Said program 
manager or sometimes program director will concern himself with recruiting 
and maintaining his project management teams and on integrating the 
deliverables of each project into one overall program. In this meaning of 
program management there is likely to be one physical deliverable. 
These sorts of programs end. There will be a time when the overall objective 
has been achieved and the program and all of its constituent projects are over. 
The projects within this type of program are often linked. Delays with one 
project often cause knock on effects with others due to logical links between 
tasks in both projects. 
For example if the moon rocket launch pad project was delayed, it would 
delay the testing of the moon rocket itself. The Beirut Shopping Mall will be 
of little use without the water treatment plant and the new sewer scheme. Such 
Software Project Management (CS615) 
26 
© Copyright Virtual University of Pakistan 
projects may not share the same resources but there are almost certain to be 
linked through their logic. 
1.13 Project Success 
Project success is correlated with thorough analyses of the need for project 
deliverables. Our research has shown that when a project results in deliverables 
that are designed to meet a thoroughly documented need, then there is a greater 
likelihood of project success. So managers should insist that there is a 
documented business need for the project before they agree to consume 
organizational resources in completing it. 
We conduct planned and controlled software projects for one primary reason - it 
is the only known way to manage complexity. And yet, we still struggle. In 1998, 
industry data indicated that 26 percent of software projects failed outright and 46 
percent experienced cost and schedule overruns [REE99]. 
Although the success rate for software projects has improved somewhat, our 
project failure rate remains higher than it should be. 
In order to avoid project failure, a software project manager and the software 
engineers who build the product must avoid a set of common warning signs, 
understand the critical success factors that lead to good project management, and 
develop a common sense approach for planning, monitoring and controlling the 
project. 
In order to manage a successful software project, we must understand what can go 
wrong (so that problems can be avoided) and how to do it right. In an excellent 
paper on software projects, John Reel [REE99] defines ten signs that indicate that 
an information systems project is in jeopardy: 
1. Software people don't understand their customer's needs. 
2. The product scope is poorly defined. 
3. Changes are managed poorly. 
4. The chosen technology changes. 
5. Business needs change (or are ill-defined) 
6. Deadlines are unrealistic. 
7. Users are resistant. 
8. Sponsorship is lost [or was never properly obtained). 
9. The project team lacks people with appropriate skills. 
10. Managers [and practitioners) avoid best practices and lessons learned. 
Jaded industry professionals often refer to the 90-90 rule when discussing 
particularly difficult software projects: The first 90 percent of a system absorbs 90 
percent of the allotted effort and time. The last 10 percent takes the other 90 
Software Project Management (CS615) 
27 
© Copyright Virtual University of Pakistan 
percent of the allotted effort and time [ZAH94]. The seeds that lead to the 90-90 
rule are contained in the signs noted in the preceding list. 
But enough negativity! How does a manager act to avoid the problems just noted? 
Reel [REE99] suggests a five-part commonsense approach to software projects: 
1. Start on the right foot. This is accomplished by working hard (very hard) 
to understand the problem that is to be solved and then setting realistic 
objects and expectations for everyone who will be involved in the project. 
It is reinforced by building the right team (Section 3.2.3) and giving the 
team the autonomy, authority, and technology needed to do the job. 
2. Maintain momentum. Many projects get off to a good start and then 
slowly disintegrate. To maintain momentum, the project manager must 
provide incentives to keep turnover of personnel to an absolute minimum, 
the team should emphasize quality in every task it performs, and senior 
management should do everything possible to stay out of (the team's way. 
3. Track progress. For a software project, progress is tracked as work 
products (e.g., specifications, source code, sets of test cases) are produced 
and approved (using formal technical reviews) as part of a quality 
assurance activation, software process and project measures can be 
collected and used to assess progress against averages developed for the 
software development organization. 
4. Make smart decisions. In essence, the decisions of the project manager 
and the software team should be to "keep it simple.” Whenever possible, 
decide to use commercial off-the-shelf software or existing software 
components, decide to avoid custom interfaces when standard approaches 
are available, decide to identify and then avoid obvious risks, and decide 
to allocate more time than you think is needed to complex or risky tasks 
(you'll need every minute). 
5. Conduct a postmortem analysis. Establish a consistent mechanism for 
extracting lessons learned for each project. Evaluate the planned and 
actual schedules, collect and analyze software project metrics, get 
feedback from team members and customers, and record findings in 
written form. 
– Projects and Strategy 
Projects are a means of organizing activities that cannot be addressed 
within the organization’s normal operational limits. 
Projects are therefore often utilized as a means of achieving an 
organization’s strategic plan, whether the project team is employed by the 
organization or is a contracted service provider. 
Projects are typically authorized as a result of one or more of the 
following strategic considerations: 
Software Project Management (CS615) 
28 
© Copyright Virtual University of Pakistan 
􀂃 A market demand (e.g., an oil company authorizes a project to build a 
new refinery in response to chronic gasoline shortages) 
􀂃 A business need (e.g., a training company authorizes a project to create a 
new course in order to increase its revenues) 
􀂃 A customer request (e.g., an electric utility authorizes a project to build a 
new substation to serve a new industrial park) 
􀂃 A technological advance (e.g., an electronics firm authorizes a new 
project to develop a new generation of video game player after the 
introduction of the corresponding new game format) 
􀂃 A legal requirement (e.g., a paint manufacturer authorizes a project to 
establish guidelines for the handling of a new toxic material). 
No project ever goes 100% as planned, so project managers must learn to adapt to 
change. There are many things that can go wrong with project management. 
These are commonly called barriers. Here are some possible barriers: 
1. Poor Communication 
– Many times a project may fail because the project team does not 
know exactly what to get done or what's already been done. 
2. Disagreement 
– Project must meet all elements in a contract. 
– Customer and project manager must agree on numerous 
elements. 
– Failure to comply with standards and regulations. 
– Inclement weather. 
– Union strikes. 
– Personality conflicts. 
– Poor management 
3. Poorly defined project goals 
1.14 Trade-Off Triangle 
Good project management deals with three factors: time, cost and 
performance. 
Projects are successful if they are completed on time, within budget, and to 
performance requirements. In order to bring the many components of a large 
project into control there is a large toolkit of techniques, methodologies, and 
tools. 
Software Project Management (CS615) 
29 
© Copyright Virtual University of Pakistan 
These techniques provide the tools for managing different components 
involved in a project: planning and scheduling, developing a product; 
managing financial and capital resources, and monitoring progress. However 
the success of a project will always rest on the abilities of a project manager 
and the team members. 
In managing competing project requirements Project managers often talk of a 
triple constraint: 
– Project scope 
– Time and 
– Cost 
Project quality is affected by balancing these three factors. 
High quality projects deliver the required product or service within scope, on 
time and within budget. 
The relationship among these factors is such that if any one of the three 
factors changes, at least one other factor must change. 
Simply put: project success means completing all project deliverables on time, 
within budget, and to a level of quality that is acceptable to sponsors and 
stakeholders. 
The project manager must keep the team's attention focused on achieving 
these broad goals. Most people still want their projects to be on time, meet 
quality objectives, and not cost more than the budget. These form the classic 
time, quality, cost triangle. 
In fact if you have an unlimited budget and unlimited time, project 
management becomes rather easy. For most people, however, time and money 
are critical and that is what makes project management so important today. 
Project management is often summarized in a triangle. The three most 
important factors are time, cost and scope. These form the vertices with 
quality as a central theme. 
Software Project Management (CS615) 
30 
© Copyright Virtual University of Pakistan 
1. Projects must be delivered on time. 
2. Projects must be within cost 
3. Projects must be within scope 
4. Projects must meet customer quality requirements 
More recently, this has given way to a project management diamond, with 
time, cost, scope and quality the four vertices and customer expectations as a 
central theme. No two customers' expectations are the same so you must ask 
what their expectations are. 
A project goes through four phases during its life: 
1. Project Definition: Defining the goals, objectives and critical success 
factors for the project 
2. Project Initiation: Everything that is needed to set-up the project before 
work can start 
3. Project Control: Ensuring that a project stays on track and taking 
appropriate action to ensure it does 
4. Project Closure: Disbanding of all the elements that were required to run 
the project 
Software Project Management (CS615) 
31 
© Copyright Virtual University of Pakistan 
1.15 Project Management Skills 
The role of the Leader in project management is one of great responsibility. 
It's the project manager's job to direct and supervise the project from 
beginning to end. Here are some other roles: 
(a) Leadership 
(b) Communications 
(c) Problem Solving 
(d) Negotiating 
(e) Influencing the Organization 
(f) Mentoring 
(g) Process and technical expertise 
(a) Leadership 
Leadership is a complex phenomenon involving the leader, the followers, 
and the situation. Perhaps the best way for you to begin to understand the 
complexities of leadership is to see some of the ways leadership has been 
defined. Leadership researchers have defined leadership in the following 
different ways: 
􀂃 The creative and directive force of morale. (Munson, 1921) 
􀂃 The process by which an agent induces a subordinate to behave in a 
desired manner. (Bennis, 1959) 
􀂃 The presence of a particular influence relationship between two or 
more persons. (Hollander & Julian, 1969) 
􀂃 Directing and coordinating the work of group members. (Fiedler, 
1967) An interpersonal relation in which others comply because they 
want to, not because they have to. (Merton, 1969; Hogan, Curphy, & 
Hogan, 1994) 
􀂃 Transforming followers, creating visions of the goals that may be 
attained, and articulating for the followers the ways to attain those 
goals. (Bass, 1985; Fichy & Devanna, 1986) 
􀂃 The process of influencing an organized group toward accomplishing 
its goals. (Roach & Behling, 1984) 
􀂃 Actions that focus resources to create desirable opportunities. 
(Campbell, 1991) 
Software Project Management (CS615) 
32 
© Copyright Virtual University of Pakistan 
􀂃 The leader's job is to create conditions for the team to be effective. 
(Ginnett, 1996) 
Leading and managing are both essential management skills: one 
without the other is likely to produce poor results. Managing is primarily 
concerned with “consistently producing key results expected by 
stakeholders,” while leading involves: 
􀂃 Establishing direction—developing both a vision of the future and 
strategies for producing the changes needed to achieve that vision. 
􀂃 Aligning people—communicating the vision by words and deeds to 
all those, whose cooperation may be needed to achieve the vision. 
􀂃 Motivating and inspiring—helping people energize themselves to 
overcome political, bureaucratic, and resource barriers to change. 
On a project, particularly a larger project, the project manager is generally 
expected to be the project’s leader as well. 
Leadership is not, however, limited to the project manager: it may be 
demonstrated by many different individuals at many different times during 
the project. 
Leadership must be demonstrated at all levels of the project (project 
leadership, technical leadership, and team leadership). 
(b) Communicating 
Communicating involves the exchange of information and the ability to 
transmit and receive information with a high probability that the intended 
message is passed from sender to receiver. 
The sender is responsible for making the information clear, unambiguous, 
and complete so that the receiver can receive it correctly. The receiver is 
responsible for making sure that the information is received in its entirety 
and understood correctly. 
Few skills are more vital to leadership. Studies show that good leaders 
communicate feelings and ideas, actively solicit new ideas from others, 
and effectively articulate arguments, advocate positions, and persuade 
others. 
The quality of a Leader’s communication is positively correlated with 
subordinate satisfaction as well as with productivity and quality of 
services rendered. 
Software Project Management (CS615) 
33 
© Copyright Virtual University of Pakistan 
Effective communication skills are also important because they provide 
leaders and followers with greater access to information relevant to 
important organizational decisions. 
Communicating has many dimensions: 
– Written and oral, listening and speaking 
– Internal (within the project) and external (to the customer, the 
media, the public, etc.). 
– Formal (reports, briefings, etc.) and informal (memos, ad hoc 
conversations, etc.) 
– Vertical (up and down the organization) and horizontal (with peers 
and partner organization) 
The general management skill of communicating is related to, but not the 
same as, Project Communications Management. 
Communicating is the broader subject and involves a substantial body of 
knowledge that is not unique to the project context, for example: 
– Sender-receiver models—feedback loops, barriers to 
communications, etc. 
– Choice of media—when to communicate in writing, when to 
communicate orally, when to write an informal memo, when to 
write a formal report, etc. 
– Writing style—active versus passive voice, sentence structure, 
word choice, etc. 
– Presentation techniques—body language, design of visual aids, 
etc. 
– Meeting management techniques—preparing an agenda, dealing 
with conflict, etc. 
Project Communications Management is the application of these broad 
concepts to the specific needs of a project—for example, deciding how; 
when; in what form; and to whom to report project performance. 
(c) Negotiating 
Negotiating involves conferring with others to come to terms with them or 
reach an agreement. 
Agreements may be negotiated directly or with assistance; mediation and 
arbitration are two types of assisted negotiation. 
Negotiation is an approach that may help resolve some conflicts. Some 
important tips on negotiation include; preparing for a negotiation session; 
Software Project Management (CS615) 
34 
© Copyright Virtual University of Pakistan 
keeping people and problems separate; focusing on issues, not positions 
and seeking win-win outcomes. 
Negotiations occur around many issues, at many times, and at many levels 
of the project. 
During the course of a typical project, project staff is likely to negotiate 
for any or all of the following: 
• Scope, cost, and schedule objectives. 
• Changes to scope, cost, or schedule. 
• Contract terms and conditions. 
• Assignments. 
• Resources. 
(d) Problem Solving 
There are three steps involved in this important leadership role; identifying 
problem; analyzing its cause; and solving the problem. 
Problem solving involves a combination of problem definition and 
decision-making. 
Problem definition requires distinguishing between causes and symptoms. 
Problems may be: 
– Internal (a key employee is reassigned to another project) 
– External (a permit required to begin work is delayed). 
– Technical (differences of opinion about the best way to design a 
product) 
– Managerial (a functional group is not producing according to 
plan) or 
– Interpersonal (personality or style clashes). 
(e) Decision-making 
Decision-making includes analyzing the problem to identify viable 
solutions, and then making a choice from among them. 
Decisions can be made or obtained (from the customer, from the team, or 
from a functional manager). 
Once made, decisions must be implemented. 
Decisions also have a time element to them—the “right” decision may not 
be the “best” decision if it is made too early or too late. 
Software Project Management (CS615) 
35 
© Copyright Virtual University of Pakistan 
(f) Influencing the Organization 
Influencing the organization involves the ability to “get things done.” 
It requires an understanding of both the formal and informal structures of 
all the organizations involved—the performing organization, customer, 
partners, contractors, and numerous others, as appropriate. 
Influencing the organization also requires an understanding of the 
mechanics of power and politics. 
Both power and politics are used here in their positive senses. 
Power is “the potential ability to influence behavior, to change the course 
of events, to overcome resistance, and to get people to do things that they 
would not otherwise do.” 
In similar fashion, “politics is about getting collective action from a group 
of people who may have quite different interests. It is about being willing 
to use conflict and disorder creatively. 
The negative sense, of course, derives from the fact that attempts to 
reconcile these interests result in power struggles and organizational 
games that can sometimes take on a thoroughly unproductive life of their 
own.” 
Influence can be exercised in a: variety of ways. It may be the 'bridge to 
engine room' approach, where the leader commands and controls. Or the 
influence can be exercised by guiding and facilitating the group's behavior 
so that the goal is accomplished. 
Finally, leadership implies that a leader motivates the group to spend 
energy in attaining the goals of the group. 
Influence without change or movement isn’t influence. Leaders make 
change happen, a difficult but vitally important task. 
(g) Mentoring 
Mentoring or being a Transformational leadership is more concerned with 
engagement between leaders and followers. 
Leaders attempt to engage the full person of the subordinate and enthuse 
them. They arouse in their subordinates a heightened awareness of the key 
issues for the group or the organization. They seek to concern subordinates 
with achievement, growth and development. 
Software Project Management (CS615) 
36 
© Copyright Virtual University of Pakistan 
Creating a new vision is something that almost all writers on 
transformational leadership emphasize. 
The vision points the way to a new state of affairs. It is an appealing 
picture of a more desirable future. It inspires people to believe that the 
future is worth the upheaval of undoing the present. 
A vision needs to be a source of self-esteem and a common purpose for 
members of the organization. 
(h) Technical Skills: 
A project manager must have technical skills. This relates to financial 
planning, contract management, and managing creative thinking and 
problem solving techniques are promoted. 
Software Project Management (CS615) 
37 
© Copyright Virtual University of Pakistan 
LECTURE # 5 
1. Introduction & Fundamentals 
1.16 PM’s nine Knowledge Areas 
1. Project Integration Management 
Project Integration Management includes the processes required to ensure that the 
various elements of the project are properly coordinated. It involves making 
tradeoffs among competing objectives and alternatives to meet or exceed stakeholder 
needs. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. Each 
process generally occurs at least once in every project phase. 
Project integration management comes into play when a cost estimate is needed 
for a contingency plan, or when risks associated with various staffing alternatives 
must be identified. However, for a project to be completed successfully, 
integration must also occur in a number of other areas as well. For example: 
􀂃 The work of the project must be integrated with the ongoing operations of the 
performing organization. 
􀂃 Product scope and project scope must be integrated. 
One of the techniques used to both integrate the various processes and to measure 
the performance of the project as it moves from initiation through to completion is 
Earned Value Management (EVM). 
• Earned value is the amount of work completed, measured according to the 
budgeted effort that the work was supposed to consume. 
• It is also called the budgeted cost of work performed. 
• As each task is completed, the number of person-months originally planned 
for that task is added to the earned value of the project. 
– Earned value charts: An earned value chart has three curves: 
• The budgeted cost of the work scheduled. 
• The earned value. 
• The actual cost of the work performed so far. 
2. Project Scope Management 
Software Project Management (CS615) 
38 
© Copyright Virtual University of Pakistan 
Project Scope Management includes the processes required to ensure that the 
project includes all the work required, and only the work required, to complete the 
project successfully. It is primarily concerned with defining and controlling what 
is or is not included in the project. 
The processes, tools, and techniques used to manage product scope vary by 
application area and are usually defined as part of the project life cycle 
A project generally results in a single product, but that product may include 
subsidiary components, each with its own separate but interdependent product 
scopes. For example, a new telephone system would generally include four 
subsidiary components—hardware, software, training, and implementation. 
Completion of the project scope is measured against the project plan, but 
completion of the product scope is measured against the product requirements. 
Both types of scope management must be well integrated to ensure that the work 
of the project will result in delivery of the specified product. 
3. Project Time Management 
Project Time Management includes the processes required to ensure timely 
completion of the project. The followings are major processes in developing the 
project time schedule: 
(a) Activity Definition—identifying the specific activities that must be 
performed to produce the various project deliverables. 
(b) Activity Sequencing—identifying and documenting interactivity 
dependencies. 
(c) Activity Duration Estimating—estimating the number of work periods that 
will be needed to complete individual activities. 
(d) Schedule Development—analyzing activity sequences, activity durations, 
and resource requirements to create the project schedule. 
(e) Schedule Control—controlling changes to the project schedule. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. Each 
process generally occurs at least once in every project phase. 
4. Project Cost Management 
Software Project Management (CS615) 
39 
© Copyright Virtual University of Pakistan 
Project Cost Management includes the processes required to ensure that the 
project is completed within the approved budget. 
Resource Planning—determining what resources (people, equipment, materials) 
and what quantities of each should be used to perform project activities. 
Cost Estimating—developing an approximation (estimate) of the costs of the 
resources needed to complete project activities. 
Cost Budgeting—allocating the overall cost estimate to individual work 
activities. 
Cost Control—controlling changes to the project budget. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. Each 
process generally occurs at least once in every project phase. 
5. Project Quality Management 
Project Quality Management includes the processes required to ensure that the 
project will satisfy the needs for which it was undertaken. It includes “all 
activities of the overall management function that determine the quality policy, 
objectives, and responsibilities and implements them by means such as quality 
planning, quality assurance, quality control, and quality improvement, within the 
quality system. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. Each 
process generally occurs at least once in every project phase. 
Project quality management must address both the management of the project and 
the product of the project. The generic term product is occasionally used, in 
literature regarding quality, to refer to both goods and services. 
6. Project Human Resource Management 
Project Human Resource Management includes the processes required to make 
the most effective use of the people involved with the project. It includes all the 
project stakeholders—sponsors, customers, partners, and individual contributors 
Following are some major processes: 
Software Project Management (CS615) 
40 
© Copyright Virtual University of Pakistan 
􀂃 Organizational Planning—identifying, documenting, and assigning project 
roles, responsibilities, and reporting relationships. 
􀂃 Staff Acquisition—getting the human resources needed assigned to and 
working on the project. 
􀂃 Team Development—developing individual and group competencies to 
enhance project performance. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. 
There is a substantial body of literature about dealing with people in an 
operational, ongoing context. Some of the many topics include: 
􀂃 Leading, communicating, negotiating, etc. 
Key General Management Skills: 
􀂃 Delegating, motivating, coaching, mentoring, and other subjects related to 
dealing with individuals. 
􀂃 Team building, dealing with conflict, and other subjects related to dealing 
with groups. 
􀂃 Performance appraisal, recruitment, retention, labor relations, health and 
safety regulations, and other subjects related to administering the human 
resource function. 
Most of this material is directly applicable to leading and managing people on 
projects, and the project manager and project management team should be 
familiar with it. However, they must also be sensitive as to how this knowledge is 
applied on the project. For example: 
Project Human Resource Management includes the processes required to make 
the most effective use of the people involved with the project. It includes all the 
project stakeholders—sponsors, customers, partners, and individual contributors. 
Major processes include: 
􀂃 Organizational Planning—identifying, documenting, and assigning project 
roles, responsibilities, and reporting relationships. 
􀂃 Staff Acquisition—getting the human resources needed assigned to and 
working on the project. 
􀂃 Team Development—developing individual and group competencies to 
enhance project performance. 
Software Project Management (CS615) 
41 
© Copyright Virtual University of Pakistan 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. 
7. Project Communications Management 
Project Communications Management includes the processes required to ensure 
timely and appropriate generation, collection, dissemination, storage, and ultimate 
disposition of project information. It provides the critical links among people, 
ideas, and information that are necessary for success. Everyone involved in the 
project must be prepared to send and receive communications, and must 
understand how the communications in which they are involved as individuals 
affect the project as a whole. 
Major processes include: 
􀂃 Communications Planning—determining the information and 
communications needs of the stakeholders: who needs what information, 
when they will need it, and how it will be given to them. 
􀂃 Information Distribution—making needed information available to project 
stakeholders in a timely manner. 
􀂃 Performance Reporting—collecting and disseminating performance 
information. This includes status reporting, progress measurement, and 
forecasting. 
􀂃 Administrative Closure—generating, gathering, and disseminating 
information to formalize a phase or project completion. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project. Each 
process generally occurs at least once in every project phase. 
Communicating is a broader subject and involves a substantial body of knowledge 
that is not unique to the project context. For example: 
􀂃 Sender-receiver models—feedback loops, barriers to communications, etc. 
􀂃 Choice of media—when to communicate in writing versus when to 
communicate orally, when to write an informal memo versus when to write a 
formal report, etc. 
􀂃 Writing style—active versus passive voice, sentence structure, word choice, 
etc. 
􀂃 Presentation techniques—body language, design of visual aids, etc. 
􀂃 Meeting management techniques—preparing an agenda, dealing with 
conflict, etc. 
Software Project Management (CS615) 
42 
© Copyright Virtual University of Pakistan 
8. Project Risk management 
Project Risk management is the systematic process of identifying, analyzing, and 
responding to project risk. It includes maximizing the probability and 
consequences of positive events and minimizing the probability and consequences 
of adverse events to project objectives. 
􀂃 Risk Management Planning—deciding how to approach and plan the risk 
management activities for a project. 
􀂃 Risk Identification—determining which risks might affect the project and 
documenting their characteristics. 
􀂃 Qualitative Risk Analysis—performing a qualitative analysis of risks and 
conditions to prioritize their effects on project objectives. 
􀂃 Quantitative Risk Analysis—measuring the probability and consequences of 
risks and estimating their implications for project objectives. 
􀂃 Risk Response Planning—developing procedures and techniques to enhance 
opportunities and reduce threats to the project’s objectives. 
􀂃 Risk Monitoring and Control—monitoring residual risks, identifying new 
risks, executing risk reduction plans, and evaluating their effectiveness 
throughout the project life cycle. 
These processes interact with each other and with the processes in the other 
knowledge areas. Each process generally occurs at least once in every project. 
9. Project Procurement Management 
Project Procurement Management includes the processes required to acquire 
goods and services, to attain project scope, from outside the performing 
organization. For simplicity, goods and services, whether one or many, will 
generally be referred to as a product. 
An overview of the major processes includes: 
􀂃 Procurement Planning—determining what to procure and when. 
􀂃 Solicitation Planning—documenting product requirements and identifying 
potential sources. 
􀂃 Solicitation—obtaining quotations, bids, offers, or proposals, as appropriate. 
􀂃 Source Selection—choosing from among potential sellers. 
􀂃 Contract Administration—managing the relationship with the seller. 
􀂃 Contract Closeout—completion and settlement of the contract, including 
resolution of any open items. 
These processes interact with each other and with the processes in the other 
knowledge areas as well. Each process may involve effort from one or more 
individuals or groups of individuals, based on the needs of the project 
Software Project Management (CS615) 
43 
© Copyright Virtual University of Pakistan 
Project Procurement Management is discussed from the perspective of the buyer 
in the buyer-seller relationship. The buyer-seller relationship can exist at many 
levels on one project. Depending on the application area, the seller may be called 
a subcontractor, a vendor, or a supplier. 
The seller will typically manage its work as a project. In such cases: 
􀂃 The buyer becomes the customer, and is thus a key stakeholder for the seller. 
􀂃 The seller’s project management team must be concerned with all the 
processes of project management, not just with those of this knowledge area. 
􀂃 The terms and conditions of the contract become a key input to many of the 
seller’s processes. The contract may actually contain the input (e.g., major 
deliverables, key milestones, cost objectives), or it may limit the project 
team’s options (e.g., buyer approval of staffing decisions is often required on 
design projects). 
Software Project Management (CS615) 
44 
© Copyright Virtual University of Pakistan 
LECTURE # 6 
1. Introduction & Fundamentals 
1.17 Team leader 
Most definitions of leadership involve three components: influence group and 
goal. First, leaders are individuals who influence the behavior of others. These 
others are usually referred to as sub ordinates or followers. Second, leadership is 
usually examined in the context of a group, especially work groups such as 
managers and their teams or foremen and their subordinates. Third, research on 
leadership stresses a group goal that has to be accomplished. So a definition is: 
Leadership is the process in which an individual influences the group 
members towards the attainment of group or organization goals. 
Note that the influence can be exercised in a: variety of ways. It may be the 
'bridge to engine room' approach, where the leader commands and controls. Or 
the influence can be exercised by guiding and facilitating the group's behavior so 
that the goal is accomplished. The notion of reciprocity is also part of man 
definitions. Influencing is often two ways. Leaders may influence followers, but 
followers influence leaders to lead in one way rather than another. An influencing 
style appropriate for checkout assistant in a supermarket may be different from 
that appropriate for rock scientists. The choice is open to the leader of how to 
influence is one of the key aspects investigated by leadership researchers. 
Another aspect of leadership is that the right to lead is often voluntarily conferred 
on the leader by some or all members of the group. A group of friends may 
recognize one, of their group as the leader, in the sense that she influences the 
group more than any of the other members. There also may be informal leader. 
While the nominal head of a department may have the formal leadership position, 
the real leadership may be exercised by someone lower down the hierarchy who 
influences the group towards goals that may not be those that the organization 
whishes to be pursue. 
Finally, leadership implies that a leader motivates the group to spend energy 
in attaining the goals of the group. Influence without change or movement isn’t 
influence. Leaders make change happen, a difficult but vitally important task. 
1.18 Leaders and Managers 
Although it is common to use the terms 'leader' and 'manager' interchangeably, 
nowadays many writers point to a difference between the two. 
Software Project Management (CS615) 
45 
© Copyright Virtual University of Pakistan 
The difference is that to function as a leader, a person must exercise influence 
over another person in the attainment of organizational goals, as described in the 
definition above. Managerial ' functions of organizing, planning, scheduling, 
processing information, communicating, and so on, do not necessarily involve 
leadership. Some managers perform both types of function and can be described 
as leaders, but others do not. There is no automatic link between the two concepts. 
Note, too, that leaders are not necessarily just at the top of organizations. 
Influence can be exerted in most job functions and at levels of seniority or 
hierarchy. The distinction between managers and leaders was, developed by 
Bennis and Nanus (1985) in their influential book Leaders. In it they put forward 
the view that: 
Leadership is path finding 
Management is path following 
Management is about doing things right 
Leadership is about doing the right things 
What they meant by this is that leadership is about having a vision. It involves 
having a strategy or thinking strategically; it means having a view of where the 
organization should go or be or do; it means deciding what is important for the 
success of the organization; it involves envisaging the future, A leader's 
responsibility is to think what are the key criteria for success of his or her part of 
the business and not just now but for the future. 
Managers, on the other hand, are more concerned with implementing others 
strategies and plans, They are concerned with running their part of the 
organization, making sure that the accounts get prepared, that invoices are sent 
out, that the service is sold, that the traffic is directed, that the research paper is 
written, or whatever the task that needs to be done. 
A very similar view is put forward by Kotter (1990). He argues that management 
is concerned with activities which are designed to produce 'consistency and order', 
whereas leadership is concerned with, 'constructive or adaptive change'. Kotter 
says there are four major ways that management and leadership differ: 
1. Planning and budgeting versus establishing direction. Management 
involves making detailed steps and timetables for achieving results, then 
marshalling resources to make it happen. Leadership means developing a 
vision of the future and strategies for achieving that vision. 
2. Organizing and staffing versus aligning people. Management comprises the 
allocation of tasks in line with plans, staffing them appropriately, delegating 
responsibility and monitoring implementation. Leadership involves 
communicating the vision so that others understand and agree with it. 
3. Controlling and problem-solving versus motivating and inspiring. 
Management involves monitoring results of a plan, identifying problems with 
the plan and then solving them. Leadership involves 'energizing people' 
Software Project Management (CS615) 
46 
© Copyright Virtual University of Pakistan 
towards the vision. It means appealing to their needs and values so that they 
overcome barriers to change. 
4. Outcomes: predictability and order, or change. Management produces 
predictability and order so that others, such as customers or shareholders can 
rely on consistent results. Leadership produces change that is often a quantum 
leap, such as new products or new approaches to managing people, that makes 
the organization more competitive. 
Kirkpatrick and Locke (1991) suggest that the following traits distinguish 
leaders from non-leaders: 
• Drive (achievement. ambition, energy, tenacity, initiative); 
• Leadership motivation (personalized or socialized); .honesty and 
integrity; 
• Self-confidence (including emotional stability); 
• Cognitive ability (the ability to marshal and interpret a wide variety 
of information); 
• Knowledge of the business 
They point out, though, that there is much more to being an effective leader than 
merely possessing a list of traits. While the traits may provide people with the 
potential for leadership, it is the capacity to create a vision and implement it that 
turns the potential into reality. 
Strong leadership motivation may sound an obvious trait for a leader. After all, 
only those who want the weighty responsibilities and grueling pressures of 
leadership are likely to strive for it. McClelland (1985) distinguishes between two 
types of power motivation. On the one hand, leaders may be interested in 
personalized power, which describes the motivation of leaders who "seek power 
for its own sake, who wish to dominate others and are often concerned with the 
status and trappings of power. The late Robert Maxwell, former owner of the 
Mirror Group allegedly displayed such traits. On the other hand, leaders who 
show socialized power motivation are more interested in cooperating with others 
to achieve desired goals. They work with others rather than attempting to 
dominate or control them. From the point of view of subordinates and the 
organization as a whole, the leader motivated by socialized power is obviously 
preferable. On the question of cognitive ability; leaders must be able to gather, 
integrate and interpret large amounts of information. Many 
Many researchers have pointed out that it is not necessary to be brilliant, though; 
leadership effectiveness is helped by above average intelligence, not genius. Of 
Kirkpatrick and Locke’s six characteristics, some would argue that drive and 
persistence are much more important than intelligence. 
In conclusion, the trait approach has undergone a revival. Recent research 
suggests that traits do matter. Yet the research shows that there are only a handful 
Software Project Management (CS615) 
47 
© Copyright Virtual University of Pakistan 
of traits which distinguish leaders from others, and a clear distinction between 
effective and ineffective leaders has not yet emerged. 
In an excellent book of technical leadership, Jerry Weinberg suggests a MOI 
model of leadership: 
Motivation: The ability to encourage (by "push or pull") technical people to 
produce to their best ability. 
Organization: The ability to mold existing processes (or invent new ones) that 
will enable the initial concept to be translated into a final product. 
Ideas or innovation: The ability to encourage people to create and feel creative 
even when they must work within bounds established for a particular soft- ware 
product or application. 
Weinberg suggests that successful project leaders apply a problem solving 
management style. That is, a software project manager should concentrate on 
understanding the problem to be solved, managing the flow of ideas, and at the 
same time, letting everyone on the team know (by words and, far more important, 
by actions) that quality counts and that it will not be compromised. 
Another view [EDG95] of the characteristics that define an effective project 
manager emphasizes four key traits: 
Problem solving An effective software project manager can diagnose the 
technical and organizational issues that are most relevant, systematically structure 
a solution or properly motivate other practitioners to develop the solution, apply 
lessons learned from past projects to new situations, and remain flexible enough 
to change direction if initial attempts at problem solution are fruitless. 
Managerial identity 
A good project manager must take charge of the project. She must have the 
confidence to assume control when necessary and the assurance to allow good 
technical people to follow their instincts. 
Achievement 
To optimize the productivity of a project team, a manager must reward initiative 
and accomplishment and demonstrate through his own actions that controlled risk 
taking will not be punished. 
Influence and team building 
An effective project manager must be able to "read" people; she must be able to 
understand verbal and nonverbal signals and react to the needs of the people 
sending these signals. The manager must remain under control in high-stress 
situations. 
Software Project Management (CS615) 
48 
© Copyright Virtual University of Pakistan 
1.19 Project Organization 
People are managed through an organizational structure. This hierarchical 
structure is based on the four cornerstones of management: delegation, 
authority, responsibility and supervision (see Fig.1). Delegation bestows 
authority, and authority produces (and requires) responsibility. Both 
authority and responsibility require supervision, and effective supervision 
requires a suitable organizational structure: 
Most projects are organized as teams, with each team assigned specific 
functions within the project, Different types of project require different 
types of team structure, as for example a team of junior programmers 
requires a technical team leader while a team of experts may require only 
an administrative team leader. It is the project manager's responsibility to 
select the structure best suited for the project. 
Basically an organization is a group of people intentionally organized to 
accomplish an overall, common goal or set of goals. Business 
organizations can range in size from two people to tens of thousands. 
Figure 1: The four cornerstones of management 
There are many ways to organize a software project. The larger the project 
the more critical the organizational structure becomes. Badly organized 
projects breed confusion, and confusion leads to project failure. Figure 2 
describes the basic structure of a project in which below the project 
manager are just two general functions: development and support. This 
very basic software project structure was not uncommon in the 1950s and 
1960s. It is still a valid project structure for very small projects (up to five 
developers), though occasionally it can still be found today in larger 
projects. 
Delegation 
1 
Supervision 
2 
Authority 
3 
Responsibility 
4 
Software Project Management (CS615) 
49 
© Copyright Virtual University of Pakistan 
Figure 2: Basic structure of a development project 
Figure 3: Software project organizational chart 
Project 
Project 
development 
Project 
support 
Project 
manager 
Deputy 
project 
manager 
System 
engineer 
Independent 
test group 
Secretary 
Quality 
assurance 
Configuration 
control 
Development 
team 1 
Development 
team 2 
Development 
team 3 
Software Project Management (CS615) 
50 
© Copyright Virtual University of Pakistan 
Project 
manager 
Deputy project 
manager 
Integration 
Group 
Independent 
Group 
Secretary 
Quality 
assurance 
Configuration 
control 
SW sub-project 
Manager 1 
SW sub-project 
Manager 2 
SW sub-project 
Manager 3 
Team 1 
Team 2 
Team 3 
Team 1 
Team 2 
Team 1 
Team 2 
Team 3 
Figure 4: Large hardware/software project organizational chart 
Project managers are just two general functions: development and support. This very 
basic software project structure was not uncommon in the 1950s and 1960s. It is a project 
structure for very small projects (up to five developers). Though occasionally, it can still 
be found today in larger projects. 
Figure 3 describes a detailed organizational chart including all major support functions. 
This organizational structure is suitable for large projects (with a staff exceeding 20). 
Smaller projects may not require a deputy project manager or separate configuration 
control and quality assurance groups. 
Very large projects (exceeding a staff of 40) can often be managed more easily by 
dividing the project into sub-projects. Figure 4 presents the organizational chart for a 
large project. This chart includes both software and hardware development teams, and an 
integration group that is responsible for hardware/software integration as well as 
integration within each group. 
As an example, consider the organization of a large satellite project. The project manager 
is in fact responsible for a number of projects: the ground control station, the rocket and 
the satellite itself. The software for all of these sub-projects is managed within a single 
project office. Each sub-project is then managed by a sub-project manager. An 
organizational chart similar to the one described in Fig. 4 can be applied to the satellite 
project; the resulting chart is described in Fig. 5. 
Software Project Management (CS615) 
51 
© Copyright Virtual University of Pakistan 
Satellite 
PM 
Sub-project 
Coordinator 
Scientific 
Engineer 
Integration 
Team 
Secretary 
Quality assurance Ground control 
Station sub-project 
Rocket 
Development 
Sub-project 
Satellite 
Sub-project 
Team 1 
Team 2 
Team 3 
Team 
1 
Team 
2 
Team 
1 
Team 
2 
Team 
3 
Quality 
Assurance 
Independent 
Group 
Configuration 
Control 
Figure 5: Satellite project organizational chart 
Clearly the project's organizational structure is dependent on the type of project being 
developed. Some of the issues that must be considered are: 
– Project size: the larger the project, the more important the organization. Large 
projects have significant human communications and coordination overhead, and 
therefore require more support functions. 
– Hardware/software development projects. The simultaneous development of 
hardware and software is not easy. Planning, integration and testing are much 
more complicated, and require dedicated support groups. 
– High reliability systems. Any system that is sensitive to issues of reliability (such 
as military or life-saving systems) requires a major effort in quality assurance. 
Quality is also an important consideration in many marketable software products 
(e.g. communications packages). These types of project require a separate quality 
assurance organization. 
Software Project Management (CS615) 
52 
© Copyright Virtual University of Pakistan 
􀀔 The Organizational structure 
The organization's structure, or design, is the overall arrangement of the 
organization's various roles, processes and their relationships in the organization. 
The design of an organization is a means to accomplishing the organization's 
overall goal -- the structure is not an end in itself. In systems theory terms, the 
design ensures that the appropriate inputs go through the necessary processes to 
produce the required outputs to produce the intended outcomes. 
The structure of the performing organization often constrains the availability of or 
terms under which resources become available to the project. Organizational 
structures can be characterized as spanning a spectrum from functional to 
projectized, with a variety of matrix structures in between. 
⇒ Corporate structure: The project's organization is largely dependent on the overall 
structure of the company within which the project is being developed. Many of the 
project support functions can be provided by centralized groups within the company. 
In fact, basic services, such as financial, secretarial and legal services, are commonly 
provided by the parent or corporate organization. 
Corporate structure usually dictates one of two basic types of project organization: 
matrix or pyramid. Figure 5 describes the structure of a matrix organization (compare 
this to the pyramid structure in Fig. 4). Within a corporate matrix organization, the 
project manager manages the technical activities of the project staff, while his or her 
involvement in non-technical personnel issues (e.g. salary reviews, promotion, and 
training) is minimal. 
⇒ Matrix Structure 
Think of the functional structure. Imagine if you took someone from each of the 
major functions in the functional structure (the boxes along the bottom of the 
organization chart), e.g., people from sales, engineering, etc., and organized them into 
a separate group intended to produce and sell one certain kind of product or service. 
Members of this group stay together until that product is produced or they continue to 
sell and service it. This overall structure (made up of a functional structure that also 
has groups assigned to products) is a matrix structure. This structure is useful because 
it focuses highly skilled people from across the organization to work on a complex 
product or service. It can be difficult though, because each person essentially reports 
to two supervisors: the supervisor of the functional area (e.g., engineering) and the 
product manager, as well. When the organization needs constant coordination of its 
functional activities, then lateral relations do not provide sufficient integration. 
Consider the matrix structure. To adopt the matrix structure effectively, the 
organization should modify many traditional management practices. 
Matrix organizations are a blend of functional and projectized characteristics. Weak 
matrices maintain many of the characteristics of a functional organization, and the 
Software Project Management (CS615) 
53 
© Copyright Virtual University of Pakistan 
project manager role is more that of a coordinator or expediter than that of a manager. 
In similar fashion, strong matrices have many of the characteristics of the projectized 
organization—full-time project managers with considerable authority and full-time 
project administrative staff. 
Most modern organizations involve all these structures at various levels. For example, 
even a fundamentally functional organization may create a special project team to 
handle a critical project. Such a team may have many of the characteristics of a 
project in a projectized organization. The team may include full-time staff from 
different functional departments, it may develop its own set of operating procedures, 
and it may operate outside the standard, formalized reporting structure. 
Matrix Organizations are a blend of functional and projectized characteristics. Weak 
matrices maintain many of the characteristics of a functional organization, and the 
project manager role is more that of a coordinator or expediter than that of a manager. 
In similar fashion, strong matrices have many of the characteristics of the projectized 
organization—full-time project managers with considerable authority and full-time 
project administrative staff. 
Most modern organizations involve all these structures at various levels. For example, 
even a fundamentally functional organization may create a special project team to 
handle a critical project. Such a team may have many of the characteristics of a 
project in a projectized organization. The team may include full-time staff from 
different functional departments, it may develop its own set of operating procedures, 
and it may operate outside the standard, formalized reporting structure. 
• The advantages of a matrix organization are: 
– More expertise: a matrix organization can maintain experts in specific fields 
(communications, data bases, graphics etc.) who are then assigned to different 
projects. A single project cannot always afford the luxury of maintaining 
experts in all fields. 
– Flexibility: it is easier to move people around from one project to another. 
This results in better utilization of the available expertise. 
– Emphasis on managing the project: the project manager is freed of many of 
the staff management tasks, leaving more time to concentrate on the technical 
aspects of the project. 
However, matrix organizations also have significant disadvantages: 
– Fewer management measures. One of the primary tools for generating 
motivation, promotion, is taken out of the hands of the project manager. The 
manager has little influence on the developer's salary and professional role in 
the organization. 
Software Project Management (CS615) 
54 
© Copyright Virtual University of Pakistan 
– Lower staff loyalty. All employees like to know exactly who their superior is. 
In a matrix organization, an employee has more than one superior. This causes 
a division of loyalty, and a weaker bond between employee and manager. 
These disadvantages often outweigh the advantages of the corporate matrix 
organization. 
Motivation is a major factor in the success of a project, and anything that 
undermines motivation is usually contrary to the best interests of the project. 
Unfortunately, the best interests of the project do not always completely coincide 
with the best interests of the company. 
Pyramid organizations provide a clear, well-defined hierarchy in which all 
individuals know their own position and the positions of those above and below 
them. When promotion and status play a major role in generating motivation (and 
they often do), then the pyramid organization is most effective. Many other 
factors generate motivation; Sense of achievement, praise and peer esteem, are 
just a few. 
Though promotion and status are not always the most effective motivators, a 
project manager should rarely relinquish any effective management tool. 
Therefore, from the perspective of a single project, the pyramid organization is 
often the best. 
⇒ Functional Structure 
Most business organizations start out with a functional structure, or a small 
variation of this structure. This is the basic "building block" for other structures. 
In this structure, there is a central office which oversees various departments or 
major functions, e.g., human resources, finances, sales, marketing, engineering, 
etc. Think of a picture that has a box at the top labeled "Central Office". Think of 
a row of boxes underneath the top box. Each box is labeled, e.g., sales, 
engineering, human resources, etc. Connect the boxes with lines coming down 
from the top box to each of the boxes below. Use functional structures when the 
organization is small, geographically centralized, and provides few goods and 
services. When the organization experiences bottlenecks in decision making and 
difficulties in coordination, it has outgrown its functional structure. 
The classic functional organization is a hierarchy where each employee has one 
clear superior. Staff members are grouped by specialty, such as production, 
marketing, engineering, and accounting at the top level, with engineering further 
subdivided into functional organizations that support the business of the larger 
organization (e.g., mechanical and electrical). Functional organizations still have 
projects, but the perceived scope of the project is limited to the boundaries of the 
function: the engineering department in a functional organization will do its work 
Software Project Management (CS615) 
55 
© Copyright Virtual University of Pakistan 
independent of the manufacturing or marketing departments. For example, when a 
new product development is undertaken in a purely functional organization, the 
design phase is often called a design project and includes only engineering 
department staff. If questions about manufacturing arise, they are passed up the 
hierarchy to the department head, who consults with the head of the 
manufacturing department. The engineering department head then passes the 
answer back down the hierarchy to the engineering project manager. 
⇒ Project Structure 
In this structure, there is a centralized corporate office and under it, are various 
divisions each of which is dedicated to producing and / or selling a certain type of 
business or product, e.g., product 1, product 2, etc. Each division that is dedicated 
to a certain business or product is, in turn, is organized as its own functional 
structure. So, for example, the division dedicated to making product 1 has its own 
sales department, human resources, etc. Basically, project structure is a bunch of 
functional structures each of which reports to one central office. Use a divisional 
structure when the organization is relatively large, geographically dispersed, 
and/or produces wide range of goods/services. 
In a projectized organization, team members are often collocated. Most of the 
organization’s resources are involved in project work, and project managers have 
a great deal of independence and authority. Projectized organizations often have 
organizational units called departments, but these groups either report directly to 
the project manager or provide support services to the various projects. 
􀀔 Structural dimensions: 
􀂃 Centralization -the extent to which functions are dispersed in the 
organization, either in terms of integration with other functions or 
geographically 
􀂃 Formalization - regarding the extent of policies and procedures in the 
organization 
􀂃 Hierarchy - regarding the extent and configuration of levels in the 
structure 
􀂃 Routinization - regarding the extent that organizational processes are 
standardized 
􀂃 Specialization - regarding the extent to which activities are refined 
􀂃 Training - regarding the extent of activities to equip organization 
members with knowledge and skills to carry out their roles 
􀀔 Contextual Dimensions: 
􀂃 Culture - the values and beliefs shared by all (note that culture is often 
discerned by examining norms or observable behaviors in the workplace) 
Software Project Management (CS615) 
56 
© Copyright Virtual University of Pakistan 
􀂃 Environment - the nature of external influences and activities in the 
political, technical, social and economic arenas 
􀂃 Goals - unique overall priorities and desired end-states of the organization 
􀂃 Size - number of people and resources and their span in the organization 
􀂃 Technology - the often unique activities needed to reach organizational 
goals, including nature of activities, specialization, type of 
equipment/facilities needed, etc. 
􀀔 Role and responsibility assignments 
Project roles (who do what) and responsibilities (who decide what) must be 
assigned to the appropriate project stakeholders. Roles and responsibilities may 
vary over time. Most roles and responsibilities will be assigned to stakeholders who 
are actively involved in the work of the project, such as the project manager, other 
members of the project management team, and the individual contributors. The 
roles and responsibilities of the project manager are generally critical on most 
projects, but vary significantly by application area. Project roles and responsibilities 
should be closely linked to the project scope definition. A Responsibility 
Assignment Matrix (RAM) is often used for this purpose. On larger projects, RAMs 
may be developed at various levels. For example, a high-level RAM may define 
which group or unit is responsible for each component of the work breakdown 
structure, while lower-level RAMs are used within the group to assign roles and 
responsibilities for specific activities to particular individuals. 
􀀔 Organization chart 
An organization chart is any graphic display of project reporting relationships. It 
may be formal or informal, highly detailed or broadly framed, based on the needs of 
the project. For example, the organization chart for a three- to four-person internal 
service project is unlikely to have the rigor and detail of the organization chart for a 
3,000-person disaster response team. An Organizational Breakdown Structure 
(OBS) is a specific type of organization chart that shows; which organizational 
units are responsible for which work packages. 
􀀔 Project Personnel 
The staffing management plan describes when and how human resources will be 
brought onto and taken off of the project team. The staffing plan may be formal or 
informal, highly detailed or broadly framed, based on the needs of the project. It is a 
subsidiary element of the overall project plan. 
The staffing management plan often includes resource histograms. Particular 
attention should be paid to how project team members (individuals or groups) will 
be released when they are no longer needed on the project. 
Appropriate reassignment procedures may: 
Software Project Management (CS615) 
57 
© Copyright Virtual University of Pakistan 
– Reduce costs by reducing or eliminating the tendency to “make work” to fill 
the time between this assignment and the next. 
– Improve morale by reducing or eliminating uncertainty about future 
employment opportunities. 
􀂃 Supporting detail 
Supporting detail for organizational planning varies by application area and 
project size. Information frequently supplied as supporting detail includes, but is 
not limited to: 
– Job descriptions (position descriptions) —written outlines by job title of the 
competencies; responsibilities, authority; physical environment, and other 
characteristics involved in performing a given job. 
– Training needs—if the staff to be assigned is not expected to have the 
competencies 
Needed by the project, those competencies will need to be developed as part of 
the project. 
􀀔 Key Concepts in Design of Good Organization 
Effective Organizational System provides assessment and training in 
communication effectiveness through focus groups, retreats, workshops, and 
experiential activities. Coaching addresses such skills as active listening, 
constructive differing, conflict resolution, negotiation, mediation, persuasiveness, 
and clarity in delivering a message. At the core of the training is the fundamental 
premise that the role of communication is to create understanding. When 
communication is effective, it promotes understanding and plays a fundamental role 
in building interpersonal skills, leadership and strong teams. 
An efficient organization is characterized by timely and productive systems and 
procedures. At its extreme it has no spare capacity to plan ahead or to respond 
easily to market changes. 
An effective organization is characterized by the ability to pre-empt competitors, 
respond swiftly and efficiently to changing situations, and display agility in its 
structure and conduct of operations. It has efficient systems and procedures but has 
the capacity to anticipate and plan ahead. 
Organizational System provides assessment and training in communication 
effectiveness through focus groups, retreats, workshops, and experiential activities. 
Coaching addresses such skills as active listening, constructive differing, conflict 
resolution, negotiation, mediation, persuasiveness, and clarity in delivering a 
Software Project Management (CS615) 
58 
© Copyright Virtual University of Pakistan 
message. At the core of the training is the fundamental premise that the role of 
communication is to create understanding. When communication is effective, it 
promotes understanding and plays a fundamental role in building interpersonal 
skills, leadership and strong teams. Organizations that achieve high levels of 
maturity in the people management area have a higher likelihood of implementing 
effective software engineering practices. 
– Span of control - the range of employees who to report to a managerial 
position 
– Authority - the formally-granted influence of a position to make decisions, 
pursue goals and get resources to pursue the goals; authority in a managerial 
role may exist only to the extent that subordinates agree to grant this authority 
or follow the orders from that position 
– Responsibility - the duty to carry out an assignment or conduct a certain 
activity 
– Delegation - process of assigning a task to a subordinate along with the 
commensurate responsibility and authority to carry out the task 
– Chain of command - the lines of authority in an organization, who reports to 
whom 
– Accountability - responsibility for the outcome of the process 
– Line authority - the type of authority where managers have formal authority 
over their subordinates' activities (the subordinates are depicted under the 
manager on a solid line in the organization chart); departments directly 
involved in producing services or products are sometimes called line 
departments 
– Staff departments - the type of authority where managers influence line 
managers through staff's specialized advice; departments that support or 
advise line departments are called staff departments and include, e.g., human 
resources, legal, finance, etc. 
Software Project Management (CS615) 
59 
© Copyright Virtual University of Pakistan 
LECTURE # 7 
2. Software Development Fundamentals 
Management Fundamentals 
2.1 Evolution of Software 
The understanding about software and software development has come a long 
way from the days of punch cards and Ada. In the first stage of computing, 
hardware mattered the most. Computers themselves were the domains of the 
government, and most software was developed in defense-funded labs, dedicated 
to the advancement of science and technology in the national interest. 
By the 1950s, large corporations realized the benefits of using computers. They 
increasingly started using computers to process and analyze financial and 
production data. These computers were huge in size. There was inadequate 
software available for them. Even the software that existed was designed 
essentially to function on a specific hardware product. The software was 
developed and maintained by the company that manufactured the hardware. 
Software design and documentation existed only in the developer's head. If the 
developer left the company, you would find maintenance to be a nightmare. 
In the second phase of software evolution, the corporate and academic sectors 
increasingly started using computers, and the perspective about both software and 
software development began to change. By the late 1960s and early 1970s, 
concepts such as multi-sessions, multi-user systems, multiprogramming gained a 
foothold. Soon computers were developed to collect, process, transform, and 
analyze data in seconds. The focus of software development shifted from custom 
software to product software. Now, multiple users on multiple computers could 
use the same software. This phase of software evolution also saw the emergence 
of software maintenance activities. These activities comprised fixing bugs, and 
modifying the software based on changes in user requirements. 
The third phase in software evolution was driven by the widespread use of 
silicon-based microprocessors, which further led to the development of highspeed 
computers, networked computers, and digital communication. Although, all 
the advancement in software and hardware was still largely restricted to enterprise 
applications manufacturers had begun to see the application of the microprocessor 
in something as mundane as ovens to the robots used in car plants. 
The fourth, and current, phase of software evolution began in the early 1990s. 
This phase saw the growth of client-server environment, parallel computing, 
distributed computing, network computing, and object-oriented programming. 
Software Project Management (CS615) 
60 
© Copyright Virtual University of Pakistan 
This phase also witnessed the growing popularity of personal computer (PC). 
During this phase, the Internet facilitated easy accessibility of information. In 
addition to complex software to support the advanced hardware, the scope of 
software development widened to include software products for the common man. 
Figure 1.1 sketches the path of software from the 1950s onwards. 
• The Software Crisis 
The rapid evolution of software design concepts and software development 
methodology resulted in an ad hoc approach to software development. In the early 
days of computing, stress was laid more on computer hardware than on software. 
This happened mainly because hardware consumed the largest portion of the 
project budget. Project managers closely followed the process of hardware 
funding, budgeting, analysis and design, production, and implementation. 
Software development, on the other hand, was left to the developers. There was 
no training conducted, documentation maintained, or methodology followed for 
software development. You will find that this attitude persisted until the 1970s, 
when finally processes and methodologies for software design and development 
began to be created. However, the ad hoc approach to software development that 
Software Project Management (CS615) 
61 
© Copyright Virtual University of Pakistan 
was prevalent in the early stages of software evolution hampered the application 
of systematic processes. This conflict referred to as the software crisis. Some of 
the reasons to which you can attribute the software crisis include: 
– Software developers used-multiple programming languages. 
– Software developers used multiple variations of standard programming 
languages. 
– Most of the requirements were complex with regard to the existing 
capabilities, 
– Users, who had little or no experience of developing or even using 
software, formulated requirements. 
– Software developers poorly mapped requirements to the actual product. 
– Software developed had low interoperability. 
– Software maintenance was costly. 
– Hardware developed at a faster rate than software (better hardware 
requires better software to operate it). 
During the period of software crisis, you will find that software that was produced 
was generally over budgeted, under scheduled, and of poor quality. The 
immediate knee-jerk response to these problems was software maintenance, 
which began to consume huge resources. During this period, maintaining software 
was adopted as a short-term solution due to the costs involved in fixing software 
regularly. This often resulted in the original software design approach getting lost 
due to the lack of documentation. 
In contrast, the situation in the present times has changed to a large extent. 
Software costs have risen, although hardware is purchased easily off the shelf. 
Now, the primary concerns regarding software projects are project delays, high 
costs, and a large number of errors in the finished product. 
2.2 Project Execution Fundamentals 
Tracking 
For the project manager, it is essential to be constantly informed of the true status 
of the project. This is achieved by assuring the regular flow of accurate 
information from the development teams. Many of the methods of acquiring 
information are not objective and rely on the accuracy of the reports provided by 
the project developers themselves. They include: 
– Periodic written status reports 
– Verbal reports 
– Status meetings 
– Product demonstrations (demos) 
Product demonstrations are particularly subjective, because they demonstrate only 
what the developer wishes to be seen. The project manager needs objective 
Software Project Management (CS615) 
62 
© Copyright Virtual University of Pakistan 
information. Such information can often be acquired from reports produced by 
support groups, such as: 
– Quality assurance reports 
– Independent test reports 
Although reports and meetings are indeed useful sources of information, nothing 
can replace direct contact between the project manager and the development staff. 
Frequent informal talks with the developers are excellent sources of information, 
especially when held in an informal atmosphere (and not in the project manager's 
office). 
The project manager must keep on constant guard against an error commonly 
referred to as the '90/50 syndrome’, which states that, 'it takes 50 percent of the 
time to complete 90 percent of the work, and an additional 50 percent of the time 
to complete the remaining 10 percent of the work'. This means that project 
developers will begin to boast quite early that they have 'almost finished' their 
tasks. Unfortunately, there is a great difference between 'almost finished' and 
‘finished'. 
Finishing a task -writing documentation, and polishing off the last few problems, 
often takes longer than developers anticipate. This is because these activities 
produce very few visible results, and developers tend (wrongly) to associate work 
with results. Therefore, managers can obtain more information from developers 
by asking them how long they estimate it will take to finish, and not how much of 
their work has been completed. 
• Status reports 
Status reports should be required from every member of the development team, 
without exception. The reports should be submitted periodically, usually weekly 
or bi-weekly, and should contain at least the following three sections (see Fig. 
5.8): 
1. Activities during the report period 
Each subsection within this section describes a major activity during the report 
period. The description of each activity should span two to three lines. Activities 
should be linked to the project task list or work breakdown structure (WBS) (see 
Chapter 10 for a description of the WBS). 
2. Planned activities for the next report period 
Each subsection within this section describes a major activity planned for the next 
report period. The description of each activity should span one to two lines. 
3. Problems 
Software Project Management (CS615) 
63 
© Copyright Virtual University of Pakistan 
Each subsection within this section describes a major problem that either occurred 
during the report period, or that was reported previously and has not yet been 
resolved. This means that problems will be repeatedly reported until they are 
resolved. In particular, this section must explain why this report's Section 1 does 
not correspond to the previous report's Section 2. 
All reports should also contain: 
1. Date of report 
2. Report period (e.g. 3 July to 10 July 1992) 
3. Name of report (e.g. Communications team status report) 
4. Name of person submitting the report 
The preparation of a periodic status report should take about 20 minutes, but not 
longer than 30 minutes. Developers should submit their status reports to their 
team leader. The team leader then combines the reports of the team into a single 
status report, while maintaining the same report structure. This activity should 
take the team leader about 30 minutes, but not longer than 45 minutes (this is 
easily done when the reports are prepared and submitted by electronic mail). 
Each team leader submits the team status report to the project manager. The 
individual status reports need not be submitted; these should be filed and 
submitted to the project manager only on request. 
Software Project Management (CS615) 
64 
© Copyright Virtual University of Pakistan 
From: John Doe, Team leader 
To: Frank Smith, Project Manager 
Date: 15 June 1993 
User interface team: Weekly status report 
for the period 5-12 June 1993 
1. Activities during the report period: 
1.1 The design of the user help screens (activity 3.12.6) was completed on schedule. 
The design specs were submitted to configuration control. 
1.2 Coding of the command pass through modules (activity group 5.12) continues, and is 
currently behind schedule by about 1 week. 
2. Activities planned for next week: 
2.1 Coding of the command pass through modules (activity group 5.12) will be 
completed, and unit tests will be started. 
2.2 Two members of the team (Ed and Joan) will attend a two day course on the 
Programmer’s interface to the new user interface package. This is an unscheduled 
activity that was approved at the last project meeting. This will not delay the 
schedule, due to the early completion of the command pass through modules (see 
Section 1.2 above). 
3. Problems: 
3.1 The user interface package we originally planned to use was found to be inadequate 
for the project. Two team members will study the new proposed package (sec Section 2.2 
above). If the new package is also found to be unsuitable, then this will severely impact 
our development schedule. 
3.2 One of our team members (Jack Brown) has been using an old VTI00 terminal 
instead of a workstation for the past two weeks, due to the acute shortage of 
workstations. This is the reason why Jack's task 5.12 was not completed this week, as 
scheduled. 
Figure 5.8: Example of a weekly status report 
The project manager also receives status reports from other project support 
personnel such as the project systems engineer or the deputy project manager. The 
project manager then prepares the project status report by combining the 
individual reports received into a single three-part report. The project status report 
is then submitted to top management. 
Software Project Management (CS615) 
65 
© Copyright Virtual University of Pakistan 
Project status reports are not necessarily submitted at the same frequency as 
internal project status reports. Project reports may be submitted bi-weekly or 
monthly. 
• Project status meetings 
Project status meetings should be held periodically, usually once a week. A good 
time for status meetings is either at the end of the last day of the week, or at the 
beginning of the first day of the week. Status meetings also contribute to the 
atmosphere of order and control within the project, and should be held regularly, 
at a fixed time. Participants who cannot participate in the project status meeting 
may, with the project manager's approval, delegate participation to another 
member of their team. 
The project manager prepares for the status meeting by reviewing the status 
reports submitted by the key project members (particularly scrutinizing the 
problem section). Therefore the status reports should be submitted at least two to 
three hours before the status meeting. Project status meetings are attended by the 
key project members. The meeting begins with a report of project activities and 
general issues by the project manager. Then each participant should be given 
about five to ten minutes to report on the activity of his or her team or area of 
responsibility. The discussion of problems should not be restricted to the person 
reporting the problem and the project manager. All problems may be addressed by 
all participants, with possible assistance offered between team leaders, thus 
making their experience available throughout the project. It is not the project 
manager's role to provide solutions to the problems, but rather to guide the team 
members toward solutions. 
Solutions should be worked out whenever possible during the status meeting. Any 
problem not resolved within five minutes should be postponed for discussion by 
the relevant parties after the status meeting. The proceedings of all project status 
meetings must be recorded. Verbatim minutes are not required, though the 
following items should appear in the record: 
1. Date of meeting 
2. Name of meeting 
3. Present (list of participants) 
4. Absent (list of absent invited participants) 
5. Action items (name, action, and date for completion) 
6. Major decisions and items discussed 
The record of the project status meeting should be typed and distributed as soon 
as possible, but no later than by the end of the day. This is particularly important 
when there are action items to be completed on the same day. When the project is 
sufficiently large to justify a secretary, then the record will be taken and typed by 
Software Project Management (CS615) 
66 
© Copyright Virtual University of Pakistan 
the secretary. In smaller projects, the project manager can rotate this task each 
week between the participants. 
2.3 Software Project Management Framework 
You all know that a project is much more than a collection of methodologies, 
tasks, resources, and reviews. A project is a synchronized event where there is 
perfect harmony and understanding between the participants. The participants are 
equipped with the essential skills of planning, cooperating, helping, and 
communicating. However, the most important activity here is to orchestrate the 
movement of the participants. The onus lies with the project manager to 
synchronize the activities of the project to result in a perfect presentation. 
Although each project manager has a unique style of functioning, there are some 
fundamental approaches that guide a project manager. These approaches are 
traditional project management concepts and software engineering concepts. To 
understand software projects and their dynamics, you must be aware of the 
environment in which a software project is executed. This further requires an 
understanding of the larger framework of software project management. 
In this chapter, you will learn to, build a connection between traditional project 
management concepts and software engineering concepts. Both traditional and 
software projects share the same methodologies, techniques, and processes. 
However, managing software projects requires a distinct approach. In this, 
chapter, you will learn to apply traditional project management principles to 
software projects. Further, you will learn about the responsibilities of a software 
project manager. You will also learn about the phases in a software project and 
the activities within each phase. Finally, the chapter will provide you an overview 
of the problems that affect a software project and the myths prevalent about 
software project management. 
2.4 Software Development Life Cycle (SDLC) 
The development of a software project consists of many activities spread across 
multiple phases. Dividing a software project into phases helps you in managing 
the complexities and uncertainties involved in the software project. 
2.5 Phases of a Software project 
Each phase represents the development of either a part of the software product or 
something associated with the software project, such as user manual or testing. 
Each phase is composed of various activities. You can consider a phase complete 
when all activities are complete. 
Software Project Management (CS615) 
67 
© Copyright Virtual University of Pakistan 
A phase is named according to the primary deliverable set that is achieved at the 
end of that phase. For example, if the requirements document is required as the 
output, the phase is called the requirements phase. Similarly, most software 
projects have phases for analysis, design, construction, implementation, and 
testing. 
A typical software project includes the following phases: 
– Software requirement analysis phase 
– Software Design Phase 
– Software Planning Phase 
– Software construction phase 
– Software testing phase 
– Software acceptance and maintenance phase 
2.6 SDLC Models 
Different organizations have different ways of assessing and arranging the phases 
in a project. These are called process models. Process models define how a 
software life cycle actually works. They provide you with a framework to plan 
and execute the various phases in the project. Typically, project life cycles display 
the following characteristics: 
• The level of cost and effort required in a software project life cycle is small to 
begin with but grows larger towards the end of the project. This happens 
because the phases such as software construction and implementation, which 
come at later stages in a software project, require more resources than the 
initial phases of the project. 
• At the start of the SDLC, external entities, such as the customer and the 
organization, play an important role with regard to their effect on the 
requirements. However, towards the end of the software project as the cost 
and effort required to implement changes rise, the requests for change in 
requirements decreases. 
• The uncertainty faced by the software project is highest at the beginning of the 
SDLC. Their level decreases as the project progresses. 
There are a few standard software process models that you can use, with some 
customization. Some standard process models are given below: 
• The Waterfall model: This is the traditional life cycle model. It assumes that 
all phases in a software project are carried out sequentially and that each 
phase is completed before the next is taken up. 
• The Prototyping Model: A model that works on an iterative cycle of gathering 
customer requirements, producing a prototype based on the requirement 
specifications, and getting the prototype validated by the customer. Each 
Software Project Management (CS615) 
68 
© Copyright Virtual University of Pakistan 
iteration of the life cycle builds on the prototype produced in the previous 
iteration. 
• The Incremental Model: The Incremental model is an example of an 
evolutionary life cycle model. It combines the linear nature of the Waterfall 
model and the iterative nature of the Prototyping model. The Incremental 
model divided the development life cycle into multiple linear sequences, each 
of which produces an increment of the final software product. In this model, 
the software product is developed in builds. A build is defined as a selfcontained 
unit of the development activity. The entire development cycle is 
planned for a specific number of logical builds, each having a specific set of 
features. 
• The Spiral model: Another evolutionary life cycle model that combines the 
linear nature of the Waterfall model and the iterative nature of the Prototyping 
model. The project life cycle is divided into phases, and each phase is 
executed in all of the iteration of the Spiral Model. 
Software Project Management (CS615) 
69 
© Copyright Virtual University of Pakistan 
LECTURE # 8 
2. Software Development Fundamentals 
Management Fundamentals 
2.7 Organizational Issues and Project Management 
Organizational issues have a deep influence on a software project, its progress, 
and the role of the project manager. The policies of an organization can affect the 
way the organization handles the customer, different types of technologies, and 
different software projects. The organizational issues that can influence a software 
project include: 
• Reaction to external influences 
• Interest in adherence to standards 
• Definition of core competency area 
• Existence of knowledge management system 
• Interest in human resources 
One organizational issue that can influence a software project is the reaction of 
the organization to external influences.- As a project manager, it is important for 
you to assess how the organization reacts to changes in the external environment, 
For example, in the current technology environment that changes rapidly, an 
organization should be proactive in strengthening its capability baseline by 
adopting new technology and retraining its employees as per market 
requirements. 
Interest in adherence to standards is another organizational issue that can 
influence a software project. The current technology environment is highly 
dynamic. Various nonprofit and independent organizations have developed 
protocols and standards for the standardization of software development and 
measurement: For example; the Software Engineering Institute at the Carnegie 
Mellon University has developed the Capability Maturity Model (SEI-CMM). 
The CMM rates the processes of a software development organization and 
classifies it into five maturity levels. Software development organizations can also 
get the quality-related certifications issued by the International Standards 
Organization smoothen your project management tasks by standardizing the 
internal processes and optimizing performance. 
Definition of core competency area also influences a software project. An 
organization that creates software must understand how they are created and 
establish processes accordingly For example, if the core competency of the 
organization lies in manufacturing chemicals, it should preferably not attempt 
Software Project Management (CS615) 
70 
© Copyright Virtual University of Pakistan 
software development for such an organization, it is better to purchase an off-theshelf 
software product. 
An organizational issue that positively influences the tasks of software project 
managers is the presence of a good knowledge management system within the 
organization. Knowledge management is the collection of processes that control 
the creation and utilization of knowledge within the organization. A good 
knowledge management system allows you to access relevant information and 
make informed decisions. 
Another organizational issue that can influence a software project is the interest of 
management in human resources. The human resources of an organization are its 
primary resource. You need to ensure that the people in the development team 
enjoy a comfortable work environment, which is conducive for smooth and 
trouble-free work. This includes providing suitable compensations, a friendly 
work environment, and smooth processes. The absence of these factors negatively 
affects employee morale, and therefore, productivity. 
2.8 Managing Processes 
As a software project manager, you become the key player in a software project. 
You not only manager the day-to-day activities of the project but also ensure that 
the software product is delivered on time. What makes your role challenging is 
the performance of project-related activities within a specified budget and time 
constraint. At the same time, you need to keep the requirements and specifications 
of the customer in mind. 
To deliver expected results, you carry out three successive processes: studying the 
feasibility of the project, planning to meet the requirement, and executing the 
plan. These processes can be further broken down into activities, such as 
planning, staffing, and monitoring. 
You plan and organize the software development team to complete development 
within the stipulated time and budget. To do this, you form a team of people who 
have the required technical skills. Then, you ensure that all activities are carried 
out as planned by the relevant people. 
Your responsibilities include analyzing customer requirements, determining the 
scope of the software project, allocating resources top the project, scheduling the 
project, and executing the project. These responsibilities can be considered in 
terms of the areas where management skills are required. The primary software 
project management areas that you need to concentrate on include: 
• Managing Resources 
• Managing Cost 
Software Project Management (CS615) 
71 
© Copyright Virtual University of Pakistan 
• Managing Risk 
• Managing Schedule 
• Managing the project plan 
• Managing quality 
⇒ Managing Resources 
The primary input required to create software are resources. Resources for a 
software project may be of three kinds: human, hardware, "and software. Human 
resource management is about effectively identifying the people with the 
appropriate skills, assigning roles and responsibilities to these people, and 
establishing reporting relationships. On the other hand, hardware and software 
resource management relates to identifying and ensuring resources such as 
workstations, disk space on servers, software tools, and software licenses. You 
need to ensure that human resource identification and allocation is carried out; 
simultaneously with hardware and software resource management. 
To manage resources effectively, there are two areas that you require your 
attention. These include: 
• Management of human resource 
• Identification of the critical hardware and software resources 
Management of human resources calls for a number of actions. First, you define 
reporting relationship for the software project. Reporting relationship can exist 
within and across organizational units, technical areas, and hierarchical levels. 
Next, determine the skills required for the software project, and identify the 
appropriate people who possess the required skills. You can review the resource 
pool and identify resources on the basis of their experience and availability. In 
case the resources are unavailable, you request for their release from another 
project or outsource the required resources. Depending upon the organizational 
practices arid experiences from past projects, you can assign roles and 
responsibilities to the development team. Finally, create a staff management plan 
and an organizational chart to show the hierarchical structure of the development 
team. 
Management of human resources also requires efficient team development. This 
is a complex activity because it combines managing people and organizing the 
reporting structure within the team. You can build cohesion and commitment 
within the team through team building activities. These activities include 
conducting team meetings to involve people from areas other than management 
into decision-making. 
To manage human resources, you also need to implement a reward and 
recognition system. This helps in promoting and reinforcing positive 
performance. It is important that you make the link between the performance and 
Software Project Management (CS615) 
72 
© Copyright Virtual University of Pakistan 
reward explicit and achievable. You should also ensure that the training needs of 
the development team are met. 
A second resource management area that requires attention is identification of the 
hardware and software resources that are critical for the project. As a software 
project manager, you must identify all the critical hardware and software 
resources and document them in the project plan. After the required resources are 
identified, you define control limits for each resource. Control limits for a 
resource are the upper and lower limit beyond which the resource is above or 
below the required level. For example, if a software project requires disk space on 
the central server, the control limits for the disk space are the required maximum 
and minimum disk space. Note that not all hardware and software resources are 
critical to the success of a software project. In some software projects, you may 
not find any critical resource at the beginning. However, as the project progresses, 
some resources might become critical. For efficient resource management, you 
should periodically assess hardware and software resource requirements for the 
software project. Just as a resource may become critical as a project progresses, a 
resource might also become less critical over a period of time. Therefore; plan, 
assess, and take corrective action for all the resources through the duration of the 
software project. 
⇒ Managing Cost 
The cost factor has a considerable influence on the execution of a software 
project. The budget of a software project is affected by factors, such as the current 
orientation of the organization toward software development, number of skilled 
personnel available, infrastructure, and computer hardware and software. The 
budget can also be influenced by timely availability of resources. If a particular 
resource is allocated to the project later than required, the costs involved could go 
up drastically. 
Quite often, when a software project starts to become too expensive, many project 
managers also tend to start cutting costs. This can have a direct impact on 
employee morale. When employee morale drops, so does the quality of work, and 
the productivity. Therefore, as a project manager you must prepare for all 
circumstances through proper estimation and allocation. To manage costs for 
software projects, you need an accurate estimation of costs. To do that, there is a 
sequence of steps that you need to perform. 
• Identify the resources required for the project 
• Estimate the cost of each activity 
• Set cost baselines for each activity 
• Implement a control system for cost changes 
To estimate costs, you first identify and describe all the resources required in the 
software project. You also estimate the duration for which the resources are used. 
Software Project Management (CS615) 
73 
© Copyright Virtual University of Pakistan 
Next, estimate the cost of each resource. To estimate the cost, you can use 
mathematical tools. However, in the case where limited information is available 
about resources, you can also use expert judgment to estimate costs. 
After the costs of the required resources are estimated, you set cost baselines for 
each activity. Cost baselines measure the performance of an activity with regard 
to the cost and duration defined for the completion of the activity. 
Finally, as the project manager you implement a control system for cost changes. 
The cost control system defines cost baselines, identifies cost changes, and 
modifies cost baselines to adjust cost changes. 
⇒ Management Risk 
Risk management is an integral part of project management. In software projects, 
where uncertainties are very high, risk management and mitigation is even more 
critical. Taking risks for high payoffs might bring in high profits but not without 
the danger of losses. Risk on a small scale is acceptable to most project managers 
as the element of loss is minimal. However, large risks pose a danger to the 
progress of a software project and you need to manage them. Risk management 
activities involve identifying potential risks, assessing them, and planning for 
contingent actions if a risk materializes. 
As a project manager, you perform two primary activities to manage risks for 
software project: 
• Risk Analysis 
o Risk identification 
o Risk quantification 
• Risk management 
The first activity in risk analysis is risk identification. Risk identification helps 
you point out the, potential risks for a software project across all phases of the 
project. Risks might evolve through the duration of a software project, and 
therefore, risk identification is an ongoing activity. To identify potential risks for 
a software project, you can analyze the activities in the software project, the 
software product description, and risks faced by the development team in similar 
past projects. This exercise allows you to identify the potential sources of risks to 
the current software project, Assessing the factor influencing the different inputs 
also allows you to identify the phases in the SDLC when risk might materialize. 
After potential risks have been identified, you can quantify them. This is done to 
ascertain their priority. If multiple risks materialize at the same time, then you 
must assign a priority to each risk based on the degree of impact on the project 
and handle the highest-risk events first. For example, the risk of change in client 
Software Project Management (CS615) 
74 
© Copyright Virtual University of Pakistan 
requirements during the software construction phase is a higher risk than a 
deadline for a deliverable being missed. Therefore, you first manage the risk that 
has a higher priority. To quantify project risks, you can use various mathematical 
and statistical tools. You can also use expert judgment to assess and quantify 
risks. 
After you have identified and quantified the potential risks for a software project, 
you create a risk mitigation plan. The purpose of the risk mitigation plan is to help 
you identify procedures to choose the path of least damage and highest returns in 
a case a risk materializes. To mitigate risks for a software project, you first need 
to be aware of the opportunities and threats that can be pursued or ignored. This 
enables you to focus on the risks that might have a negative impact on the 
software project and develop contingent plans to deal with these risks. You can 
also mitigate risks by evolving alternative strategies to altogether prevent 
potential risks from materializing. 
In case an unplanned risk materializes, you must be aware of the dependencies of 
the project activities so that ad hoc solutions can be evolved. However, as the 
project manager you can avoid unplanned risks from materializing by engaging in 
an intensive risk identification and mitigation exercise before the software project 
commences. 
⇒ Managing Schedule 
Time is a major constraint for a software project. With most software projects, the 
delivery dates for the software product are already committed to the customer at 
the time the project commences. As a software project manager you must perform 
various tasks to balance time and deadlines. These are: 
– Identify the different deliverables that constitutes the software product 
– Define the activities that are required to produce the deliverables 
– Identify the interdependencies between activities 
– Define the duration of each activity 
– Assess the project network diagram 
– Create a schedule management and control plan 
The first task is to identify the different deliverables that constitute the software 
product. These deliverables also mark the completion of the different phases 
within a software project. 
Next, define the activities that are required to produce the deliverables. To do this, 
you can break down the SDLC into phases, identify the deliverables at the end of 
each phase, and the activities required for creating the deliverables. 
Software Project Management (CS615) 
75 
© Copyright Virtual University of Pakistan 
After the activities are defined, you identify the interdependencies between them. 
The purpose of this exercise is to organize the activities and sequence them in the 
form of a project schedule. 
Next, you define the duration of each activity. The inputs that you need for 
scheduling are the resources required to complete each activity. Then, assesses the 
availability of these resources and the duration of each similar activity in similar 
past projects. 
After estimating the time required for each activity to complete, you assess the 
project network diagram. This includes an assessment of the duration estimates, 
resource requirements, resource pool description, and assumptions and constraints 
for the software. You can use Mathematical tools to determine a schedule for the 
project. The project schedule defines the activities within each phase, the team 
members assigned to complete each activity, the duration of each activity, and the 
start and end dates for all of the activities. 
Finally, create a schedule management and control plan. The purpose of this plan 
is to identify when changes occur, Implement the changes to the project schedule, 
and ensure that the changes are beneficial to the software project. After the 
changes are implemented, you might need to modify the sections of the project 
plan to ensure that the project is completed on time. 
Software Project Management (CS615) 
76 
© Copyright Virtual University of Pakistan 
LECTURE # 9 
2. Software Development Fundamentals 
Management Fundamentals 
2.8 Managing Processes 
⇒ Managing the Project Plan 
Preparing it project plan for a software project helps you ensure that the specified 
requirements and objectives are met successfully. It is a collation of all planning 
activities that have happened for a software project. This includes activities such 
as design and analysis, activity definition, risk planning, and cost estimation. To 
create the plan, you assess all planning activities, organizational policies 
regarding the creation of the project plan and assumption and constraints for the 
project. To implement the software project plan, you require management skills, 
such as leadership, communication, and problem solving, along with the basic 
knowledge about the software. You also need to ensure that the senior 
management bf the company has authorized work on the software project. 
Knowledge management techniques help you to make informed decision 
regarding the project plan. 
After the project plan is executed, you manage the changes to it in such a way that 
the performance measurement baselines are not impacted, To manage the project 
plan effectively you monitor the project plan, periodic performance status reports, 
and requests for change. The primary tool that you can use to control the changes 
in the project plan is the change control mechanism: This is a set of formal 
procedures for changing the project plan. 
⇒ Managing Quality 
The quality of software development depends largely on the understanding of 
‘quality’ and quality management within the software development team. In 
software projects where each member has a different understanding of quality and 
his or her role in implementing it, the software product is usually not of the 
required quality. 
Implementing software quality is often associated with the software developer. 
However, the role of the project manager is crucial in implementing quality 
awareness and a quality-producing work environment. When a software project 
starts missing deadlines and is in danger of exceeding the budget, project 
managers often lose the focus on quality and lay stress on meeting deadlines. 
However, the focus should be the other way round. A focus on delivering a 
Software Project Management (CS615) 
77 
© Copyright Virtual University of Pakistan 
quality product, even at the cost of missing a deadline or two ensures that your 
customer comes back for repeat orders. On the other hand, the price of nonconformance 
(PONC) on quality standards simply translates into the loss of 
goodwill and loss of business. 
Modern quality management techniques compliment project management and the 
role of the project manager. Quality management techniques ensure that a 
software product conforms to the customer requirements. Quality management 
further ensures that errors are prevented in the first round itself. Checks for errors 
and effort for removing the errors consume much more time, effort, and cost than 
it takes to prevent the errors in the first place. Therefore, maintaining quality in a 
software project is the domain of all team members. 
However, as the project manager you have a critical role in maintaining quality. 
You provide the resources required to complete the activities of the software 
project and ensure that quality levels are constantly monitored. 
You first identify the areas that must be monitored for ensuring quality and the 
quality measures to implement. Then, consider the quality policy of the 
organization, the scope of the project, the applicable standards, and the software 
product description. Next, use tools, such as a cost-benefit analysis and a 
flowchart, to identify the areas where you need to monitor quality and the 
subsequent actions for control. The output of this exercise is the quality plan for 
the software project. In addition, this exercise allows you to create checklists to 
help monitor quality. 
As a software project manager, you also need to use a quality control mechanism 
so that the quality of the software product does not suffer. The aim of the quality 
control mechanism is to ensure compliance with quality standards. 
2.9 Project Execution 
You already learned in the beginning of the chapter that a software project is 
divided into different phases. This division is done on the basis of the activities 
performed in each phase. Similarly, project management activities are also 
arranged in phases. As a project manager, you perform the activities that map to 
each of these phases. The project management phases can be broadly categorized 
as follows; 
– Project initiation 
– Project closedown 
– Project planning, control, and tracking 
– Product implementation 
• Project Initiation 
Software Project Management (CS615) 
78 
© Copyright Virtual University of Pakistan 
The tasks performed for project initiation are mentioned below: 
Requirement gathering: The first task is to gather the customer requirements. 
Customer requirements may be spoken or unspoken. Therefore, the challenge for 
the project manager is to elicit the requirements in such a way that both the 
spoken and unspoken customer needs and wants are gathered. After collecting the 
required information, you need to translate the customer requirements into 
technical specifications for the software project. 
Scope determination: The scope of a software project can be defined as the 
combination of the software product arid services to be delivered to the customer. 
You carry out the scope determination exercise to define the scope of the software 
project. The scope determination exercise enables you to refine and understand 
the customer requirements. You can refine the scope definition further by 
breaking down each deliverable into smaller and more manageable activities. The 
scope determination exercise also helps you identify the technology for creating 
the software product. 
Resource allocation: During project initiation, you identify the resources required 
and allocate them to the software project. The resources identified may be people, 
reusable software components, and hardware or software tools. You allocate the 
resource to the software project on the basis of the activities defined in the scope 
determination exercise. While allocating appropriate resources for a software 
project, you also need to calculate the cost of each resource. The cost of a 
resource is calculated according to the duration of the resource in the software 
project. Estimating the cost of resources also helps you prepare a budget for the 
software project. 
Note: 
Scope determination and resource allocation are discussed in more detail in later 
chapters. 
Initial project plan: Another exercise that you carry out during project initiation 
is the creation of a rough project plan. This plan is a draft version and carries only 
the primitive project plan features. This project plan carries the initial risk 
analysis of the software project, the initial start and end dates, the duration of the 
activities in the project, and the sequencing of these activities. 
• Project Planning, Controlling, and Tracking 
This activity of the project manager involves detailed tasks. These tasks are 
mentioned below: 
Detailed project plan: After the scope for the software project is determined and 
the product design is ready, you prepare a detailed project plan. To create a 
detailed project plan, you define a detailed list of all the elements that make up the 
Software Project Management (CS615) 
79 
© Copyright Virtual University of Pakistan 
project deliverables. Next, the deliverables are further broken up to help In the 
calculation of durations, start dates and end dates for each activity mentioned in 
the plan. Roles and responsibilities are assigned to people with the appropriate 
skills to complete each activity within specified time. 
Control mechanism: These are set up to control the impact of changes on the 
software project. The control mechanism includes a detailed risk management and 
mitigation plan, a detailed quality plan, and quality assurance activities. You also 
implement a review and audit system for periodic assessment and measurement of 
the software project activities. The review and audit system enables you to 
evaluate the progress of the software project. It ensures that all necessary data is 
collected, deviation from the planned baselines is checked, and corrective action 
is taken at all checkpoints. In this way, the review and audit system ensures 
compliance with the organizational processes for software development. 
Software Project Management (CS615) 
80 
© Copyright Virtual University of Pakistan 
LECTURE # 10 
2. Software Development Fundamentals 
Management Fundamentals 
2.9 Project Execution 
⇒ Product Implementation 
Product implementation activities involve defining processes related to the 
implementation of the software product at the customer site. Some of the tasks 
that you perform for product implementation are mentioned below: 
• Implementation plan creation: An implementation plan defines the duration of 
implementation and the hard and software perquisites for implementing the 
software product. 
• Support plan creation: the project manager also needs to create a support plan for 
the customer. The support plan includes consideration such as the postimplementation 
support activities provided to the customer. Post-implementation 
considerations include the number of support staff available to the customer, their 
names, contact numbers, and the duration of their availability. 
• Training plan creation: During product implementation, you create a training 
plan to train the customer on the software product. The training plan includes 
considerations such as the duration of training, the prerequisites for training 
people, and the number of people that can be trained simultaneously. 
• User acceptance plan: You also need to prepare a user acceptance plan. The user 
acceptance plan provides a detailed outline on how and when the user acceptance 
tests are performed. The primary focus of user acceptance test is to ensure that the 
final software product offers all the functionality and performance that the 
customer wanted. Therefore, the customer tests the software product for issues 
such as aesthetics, user friendless, and scalability. 
⇒ Project Closedown 
The final activity for a project manager is project closedown. For most software 
projects, the project closedown activities take place in the post-implementation 
phase. However, in some software projects, the customer requests support 
activities for a longer duration. In such cases, the software project is considered 
Software Project Management (CS615) 
81 
© Copyright Virtual University of Pakistan 
closed immediately after implementation. The tasks that you perform in project 
closedown are mentioned below: 
• Prepare closedown report: The project closedown report contains the results of 
the causal analysis that you do for the project. This contains an analysis of what 
went wrong, what went right, and what you could have done better in the software 
project. 
• Identify learning: You also need to assess the entire software project and the 
results of the causal analysis to identify the key learning points from the software 
project. This helps you identify areas of improvement for future projects. The 
learning points can also be used by the organization as considerations while 
planning and executing the next software project. 
• Identify reusable software components: Reusing software components enables 
you to lower the cost, time, and effort required to complete the software project 
successfully. After project closedown, you identify the software components that 
can be reused in future projects of similar nature. The software components 
prepared for a software project may be complete, partially complete, or in the 
design stage. These components or their designs can be assessed for usability in 
future projects. 
• Create reference material: After the project is complete, you can create white 
papers and reference documents. This can be a significant contribution to the 
organization and the application area of the software by creating an authoritative 
knowledge base. 
2.10 Project Management Myths 
In most cases, you learn the skills required to manage a software project while on 
the job. As a result, most software project managers practice a lot of management 
techniques that are of doubtful authenticity. Many software project managers 
learn about the so-called management skills and concepts that are actually myths. 
⇒ Clarifying the Project Management Myths 
The following list aims to clarify some of the more prevalent myths in software 
project management. 
1. Combining the best resources with the worst resources available for a 
software project helps to complete the project successfully. 
2. A general statement of objectives is sufficient to begin work on the software 
project. 
Software Project Management (CS615) 
82 
© Copyright Virtual University of Pakistan 
3. Allocating extra resources to a late project allows it to catch up with the 
project schedule. 
4. As software by itself is flexible, you can change the requirements at any point 
in the software project life cycle. 
5. The management and the customer always impose an unrealistic deadline for 
the software project. 
6. A software project that meets all the stated objectives is a success. 
7. Software maintenance is an easy task and requires less effort than actual 
software development. 
8. Identifying and reporting errors during the reviews makes the software 
developer unhappy and spoils the work environment. 
9. Web-enabling an application or adopting client/server; architecture helps to 
run software projects smoothly. 
Myth: Combining the best resources with the worst resources available for a project 
helps to complete the project successfully. 
In software projects, combining the best resources with the worst resources drags 
down the efficiency and productivity of good resources. This invariably decreases 
the speed of the software project, and the project ends much after the specified 
deadline. 
Myth: A general statement of objective is sufficient to begin work on the software 
project. 
Many software project managers and customers believe that a general statement 
of objectives gives a reasonable idea of the requirements. However, a formal and 
detailed description of the customer requirements is needed before the project 
commences. The software project manager must ensure that all information 
regarding the software project, such as the functions, performance, interfaces, 
constraints, assumptions and validation criteria is gathered. 
Myth: Allocating extra resources to a late project allows it to catch up with the 
project schedule. 
A software project is not a mechanical process such as, say; digging an artificial 
lake. In case of creating an artificial lake, adding more people to the job can help 
dig a larger area in the same time. However, in a software project, adding, more 
people actually increases the time required to finish the project. This happens 
because a new person joining the project requires time to understand the 
Software Project Management (CS615) 
83 
© Copyright Virtual University of Pakistan 
requirements of the client, software design, and standards. Moreover, the existing 
people in the project need to devote time and effort to train the new people on the 
software project. Therefore, allocating additional resources to a risky situation 
increases the risk to the software project. 
Myth: As software by itself is flexible, changes in the requirements can be made at 
any point in the software project life cycle. 
Requests for changes are common with all projects. However, the timing of the 
change for requests is critical. This is because an untimely change adversely, 
impacts the cost of the software project. For example, a change request during the 
requirements gathering stage has a relatively low impact on costs. On the other 
hand, a change request during, the software construction stage can be extremely 
expensive to incorporate. The software project manager must decide with the 
customer upon a set of objectives that must be achieved at the end of the project. 
In addition, the project manager and the customer must decide on a specific 
phase, beyond which only critical change requests are accepted. 
Myth: The management and customer always impose an unrealistic deadline for the 
software project. 
The management and customer usually believe that project managers prepare cost 
effort, and time estimates inclusive of buffers. The management and customers 
rationalize that if they can cut the buffers by imposing a tight deadline or a low 
budget on a project, the project manager would still complete the project on time. 
Myth: A software project that meets all the stated objectives is a success. 
Customer requirements for a software project are always in two forms, spoken 
and unspoken. Usually, the objectives formed from the customer requirements are 
based on the spoken requirements. The software project manager must to be 
aware of the unspoken requirements and ensure that these are met. 
Myth: Software maintenance is an easy task and requires less effort than actual 
software development. 
If change requests are made toward the end of the project, then maintenance 
activities can contribute to large costs and effort overruns. Moreover, contrary to 
the popular view, implementing changes in the software product in the 
maintenance stage is a painstaking task. 
Myth: Identifying and reporting errors during the reviews makes the software 
developer unhappy and spoil the work environment. 
Software Project Management (CS615) 
84 
© Copyright Virtual University of Pakistan 
If a developer makes an error, it is important to point it out so that the error is 
fixed in time. A project manager must communicate assertively so that the team 
does not lose focus on quality. In addition, letting an error pass may have ripple 
effects on the quality of the software product, frustrating the entire team. 
Myth: Web-enabling an application or adopting client / server architecture helps to 
run software projects smoothly. 
No single technology platform, language, or architecture is a one-point solution 
for all software projects. All approaches to software development have unique 
merits and demerits. For example, if a marketing firm needs to make information 
accessible to people at remote locations, then a, Web-based application is a good 
option. However, mainframes are still preferred for applications created for the 
banking industry. 
Software Project Management (CS615) 
85 
© Copyright Virtual University of Pakistan 
LECTURE # 11 
2. Software Development Fundamentals 
Management Fundamentals 
2.11 Problems in Software Projects 
Software projects are similar to traditional projects in the sense that the same 
types of problems affect them both. However, the difference in managing these 
problems lies in the approach that you take to the specific issue. For example, a 
technology-related problem for a software project might be the low degree of 
reuse of the software components created. However, for a car-manufacturing firm, 
there is no chance of reusing a component such as a front axle. 
You can classify the problems that affect software projects into the following four 
categories: 
• People-related problems 
• Process-related problems 
• Product-related problems 
• Technology-related problems 
⇒ People-related problems 
People-related problems in a software project are: 
• Low motivation: As the project manager it is your responsibility to ensure an 
optimal level of motivation within the team. Lengthy projects, complex 
activities1 and scarce resources often decrease the motivation level in a 
software development team. However, you need to lead in such a way that the 
team is constantly motivated to do a good job. 
• Problem employees: Some members of any team always create a problem. For 
example, an employee may carry a 'holier-than thou' attitude. Problem 
employees raise the chances of conflicts and differences of opinions within 
the development team. They lower the efficiency and productivity of other 
team members and make it difficult to meet the objectives of the software 
project within the specified time. You need to ensure that employees are not 
allowed to create a pr9blem for the rest of the team. Even if the employee is 
very competent, you need to assess the indispensability of such emp1oyees for 
the project. Moreover, you refrain from playing favorite with certain 
employees and treat everyone with the same measure. 
Software Project Management (CS615) 
86 
© Copyright Virtual University of Pakistan 
• Unproductive work environment: The work environment is a major factor 
that affects the productivity of the development team. For example, a noisy or 
cramped workspace decreases the motivation levels of the employees. 
Similarly, unfriendly organizational policies also lower the motivation of the 
team members. As the project manager, you need to ensure that the team is 
protected from harmful external make the workspace friendly to work in. 
• Inefficient project management style: the project manager needs to lead by 
example. The team members absorb the work culture, work ethic, and attitude 
of the project manager and implement it in their work style. If you display a 
lack of leadership qualities and weak ideals, the motivation levels decrease 
across software team. 
• Lack of stakeholder interest: For a software project to be a success, each 
stakeholder needs to take an active interest in the progress of the project. Al1 
stakeholders, including the customer, the management, and the software 
development team, need to commit to the success of the project. For example, 
if the software development team is not committed to the project, then their 
contribution may not be to the optimum level. 
• Ineffective project sponsorship by management: Lack of commitment of the 
senior management to a software project lowers the motivation level of the 
team members. If the management commits to the progress of a software 
project, and takes a keen interest in the progress, the confidence of the 
software development team will increase. 
⇒ Process- related Problems 
The process-related problems in a software project are: 
• Unrealistic schedule: Assigning unrealistic deadlines for a software project is 
a primary reason why software projects are delayed. Often, the marketing or 
the management team commit a delivery date to the customer in the hope of 
getting the project contract. However, these dates are not decided in 
consultation with the development team. The rationale for assigning the 
deadlines is unfounded. You need to ensure that the deadlines match the 
ability of the software team to deliver the software product. As it is not always 
possible to shift deadlines committed to the customer, you also need to plan 
the resource allocation and project execution such that the deadlines are met. 
• Insufficient identification: Unidentified, partially identified, and unplanned 
risks pose a threat to the success of a software project. You need to intensively 
identify risks and evolve a risk management plan such that the project is 
completed successfully, on time. 
Software Project Management (CS615) 
87 
© Copyright Virtual University of Pakistan 
• Unsuitable life cycle model selection: Different software projects require 
different SDLC models. For example, a project to create banking .software is 
different from software for a satellite where the concept needs to be 
researched. For the former example, the Waterfall model is more applicable. 
For the latter example, the Spiral model is more suitable. Selecting the correct 
life cycle model is critical to the success of a software project. 
• Abandoning quality under pressure of deadlines: Where a software project 
faces a shortage of resources, time, and funds, project managers often push 
away quality concerns and focus on meeting deadlines and staying within the 
budget. Abandoning quality has a ripple effect that actually adds even more 
time, effort, and costs to the software projects. The cost of doing things right 
the first time is lower than the cost of inspection during product delivery. 
Also, the cost of inspection is lower than the cost of debugging software after 
the customer spots errors. 
• Unstructured and hurried software development: When software project 
progresses with more focus on meeting deadlines and staying within a budget, 
the approach to the software development is unstructured and hurried. You 
should plan the software project such that all the activities are identified, 
sequenced properly, and roles and responsibilities assigned to the various 
people on the project. You should also maintain the focus of the development 
team toward a structured approach to software development. 
⇒ Product-related Problems 
There are many product-related problems that you can face in a software project. 
These are: 
• Product scope changed toward the end of the project life cycle: The project 
time, effort, and cost estimates for a software project can go up dramatically 
when the customer changes the scope 9f the product toward the end of the 
project. In such situations, you should verify the criticality of the scope 
change. However, if the change request is not critical, you should retain the 
original scope with a proper explanation to the customer. If the change request 
is critical, you should explain the situation to the customer. Usually, a 
customer gives more time and funds to a software project if proper 
justification is provided. In some cases, the scope change may also be because 
of a change in government policy. It may become mandatory for you to 
include such change requests. 
• Research-oriented software development: Many software projects digress 
from the original scope because of the nature of the software product or 
technology used. When a totally new kind of software is developed or a new 
Software Project Management (CS615) 
88 
© Copyright Virtual University of Pakistan 
technology is used, the software development team can lose focus of the 
objectives by getting into a research-oriented approach. It becomes your 
responsibility as the project manager to maintain the focus on the objective. 
Software Project Management (CS615) 
89 
© Copyright Virtual University of Pakistan 
LECTURE # 12 
2. Software Development Fundamentals 
Management Fundamentals 
2.10 Problems in Software Projects 
⇒ Product-related Problems 
• III-defined scope: You need to define the scope of the software product in the 
initial stages of a software project. The scope of a software product is defined 
in terms of the functionality requirements, the performance requirements, the 
assumptions, and the constraints on the product. If the product scope is ill 
defined, the software project does not have a proper focus on the features 
required in the product. 
• Fuzzy users: You also need to clarify the background characteristics of the 
users of the final software product at the beginning of the software project. If 
the description of the users is fuzzy, then the software analysis, design, and 
development stages may reflect the ambiguity with regard to the functions and 
performance of the final software product. 
⇒ Technology-related problems 
You may also encounter technology-related problems in a software project. These 
include: 
• Overestimated savings from reusable components and new tools and 
methods: You can reuse software components in a software project to save 
time, effort, and cost of creating the component again. It is important that you 
assess the savings that the use of such a software component provides to a 
software project. This expectation of both the customer and the management 
might not be met, if you overestimate the savings from reusing software 
components. 
• Switching tools in mid way: The current technology environment offers new 
tools and technologies for software development at a fast rate. All these tools 
and technologies offer the benefits of a shorter development cycle, lower 
costs, and under better functionality than earlier tools. You should identify 
and commit to the tool and technology for the software project before the 
project commences. Switching the tool or technology used during the software 
development stage causes the developers to relearn a new tool. In addition, 
Software Project Management (CS615) 
90 
© Copyright Virtual University of Pakistan 
there is a chance that it might not be possible to integrate the software already 
developed with the new tool. 
• Integrating different software products in cross-platform implementation: 
The modem software environment requires that all software should integrate 
with each other. However, many software projects do not plan for integration 
with existing software in the same or different domain. This limits the 
applicationofsu9h software and reduces the shelf life drastically. They key to 
the success of a software product is interoperability. The software project 
manager needs to determine the scope for the software product such that is 
can be integrated easily with existing software. 
⇒ Summary 
The phases in a software project can be organized into a project life cycle. Some 
standard life cycle models are the Waterfall model, the Prototyping model, the 
Incremental model, and the Spiral model. 
Organizational policies and attitudes influence the progress of a software project 
and the tasks of a software project manager. For smooth progress of software, 
project, the organization should be proactive in adopting changes in technology 
and market environments, focused on developing software, and accept software 
projects that match the organizational capability baseline. In addition, the 
organization should implement employee-friendly human resource policies and 
good knowledge management system. 
The role of a software project manager includes managing resources, cost, risk, 
schedules, project plan, and quality. Software project management activities can 
be divided into phases. The main phases and the associated activities are initiating 
the project, planning, controlling, and tracking, implementing the product, and 
project closedown. 
Initiating the project includes gathering requirements, determining the scope, 
allocating resources, and creating an initial project plan. Planning, controlling, 
and tracking involve creating a detailed project plan, constructing software, and 
implementing a control mechanism. Implementing the product comprises 
implementation plan, support plan, training plan, and user acceptance plan. 
Project closedown includes preparing closedown report, identifying learning for 
future projects, and identifying reusable software components for future software 
projects. 
Problems- affecting software projects can be classified into people-related, 
project-related, product-related, and technology-related. 
Various myths regarding software project management are adding more people to 
a late project can help to finish the project on time, combining the best resources 
Software Project Management (CS615) 
91 
© Copyright Virtual University of Pakistan 
with the worst resources results in optimal resource allocation, and changes to the 
scope of the software project and the software product can be made at any-time in 
the SDLC. 
Software Project Management (CS615) 
92 
© Copyright Virtual University of Pakistan 
LECTURE # 13 
2. Software Development Fundamentals 
Technical Fundamentals 
2.11 Requirements Management 
⇒ Preview 
Software requirements engineering is a process of discovery, refinement, 
modeling and specification. The system requirements and role allocated to 
software-initially established by the system engineer-are refined in detail. 
Models of the required data information and control flow and operational 
behavior are created. Alternative solutions are analyzed and a complete 
analysis model is created. 
Requirements engineering is the systematic use of proven principles, 
techniques, languages, and tools for the cost effective analysis, 
documentation, and on-going evolution of user needs and the specification 
of the external behavior of a system to satisfy those user needs. Notice that 
like all engineering disciplines, requirements engineering is not conducted 
in a sporadic random or otherwise haphazard fashion, but instead is the 
systematic use of proven approaches. 
Both the software engineer and customer take an active role in software 
requirements engineering-a set of activities that is often referred to as 
analysis. The customer attempts to reformulate a sometimes nebulous 
system-level description of data, function and behavior into concrete 
detail. The developer acts as interrogator, consultant, problem solver and 
negotiator. 
The overall role of Software in a larger system is identified during system 
engineering. However, it's necessary to take a harder look at software's 
role-to understand the specific requirements that must be achieved to build 
high-quality software. That's the job of software requirements analysis. To 
perform the job properly, you should follow a set of underlying concepts 
and principles. Generally, a software engineer performs requirements 
analysis However, for complex business applications a 'system analyst’ 
trained in the business aspects of the application domain may perform the 
task. If you don't analyze, it's highly likely that you'll build a very elegant 
software solution that solves the wrong problem. The result is wasted time 
and money, personal frustration and unhappy customers. 
Software Project Management (CS615) 
93 
© Copyright Virtual University of Pakistan 
Data, functional, and behavioral requirements are identified by eliciting 
information from the customer. Requirements are refined and analyzed to 
assess their clarity, completeness, and consistency. 
⇒ Requirements analysis 
Requirements analysis is a software engineering task that bridges the gap 
between system level requirements engineering and software design 
(Figure 1). Requirements engineering activities result in the specification 
of software's operational characteristics (function, data; and behavior), 
indicate software's interface with other system elements, and establish 
constraints that software must meet. Requirements analysis allows the 
software engineer (sometimes called analyst in this. role) to refine the 
software allocation and build models of the data, functional, and 
behavioral domains that will be treated by software. Requirements 
analysis provides the software designer with a representation of 
information, function, and behavior that can be translated to data, 
architectural, interface, and component-level designs. Finally, the 
requirements specification provides the developer and the customer with 
the means to assess quality once software is built. 
Figure 1: a bridge between system engineering and software design 
Software requirements analysis may be divided into five areas of effort: 
(1) Problem recognition, 
(2) Evaluation and synthesis, 
(3) Modeling 
(4) Specification, and 
(5) Review 
System 
Engineerin 
g 
Software 
Design 
Software 
Requirement 
s 
Analysis 
Software Project Management (CS615) 
94 
© Copyright Virtual University of Pakistan 
Initially, the analyst studies the System Specification (if one exists) and 
the Software Project Plan. It is important to understand software in a 
system context and to review the software scope that was used to generate 
planning estimates. Next, communication for analysis must be established 
so that problem recognition is ensured. The goal is recognition of the basic 
problem elements as perceived by the customer/users. 
􀂃 Problem evaluation 
Problem evaluation and solution synthesis is the next major area of 
effort for analysis. The analyst must define all externally observable 
data objects, evaluate the flow and content of information, define and 
elaborate all software functions, understand software behavior in the 
context of events that affect the system, establish system interface 
characteristics, and uncover additional design constraints. Each of 
these tasks serves to describe the problem so that an overall approach 
or solution may be synthesized. For example, an inventory control 
system is required for a major supplier of auto parts. The analyst finds 
that problems with the current manual system include: 
(1) Inability to obtain the status of a component rapidly 
(2) Two or three-day turnaround to update a card file 
(3) Multiple reorders to the same vendor because there is no way to 
associate vendors with components, and so forth. 
Once problems have been identified, the analyst determines what 
information is to be produced by the new system and what data will be 
provided to the system. For instance, is the customer desires a daily 
report that indicates what parts have been taken from inventory and 
how many similar parts remain. The customer indicates that inventory 
clerks will log the identification number of each part as it leaves the 
inventory area. 
􀂃 Solution synthesis 
Upon evaluating current problems and desired information (input and 
output), the analyst begins to synthesize one or more solutions. To 
begin, the data objects processing functions and behavior of the system 
are defined in detail. Once this information has been established, basic 
architectures for implementation are considered. 
A client/server approach would seem to be appropriate, but does the 
software to support this architecture fall within the scope outlined in 
the Software Plan? A database management system would seem to be 
required, but is user/customer's need for associativity justified? The 
process of evaluation and synthesis continues until both analyst and 
Software Project Management (CS615) 
95 
© Copyright Virtual University of Pakistan 
customer feel confident that software can be adequately specified for 
subsequent development steps. 
Throughout evaluation and solution synthesis, the analyst's primary 
focus is on "what, not "how." What data does the system produce and 
consume what functions the system must perform. What behaviors do 
the system exhibit, what interfaces, are defined and what constraints 
apply? 
During the evaluation and solution synthesis activity, the analyst 
creates models of the system in an effort to better understand data and 
control flow, functional processing, operational behavior, and 
information content. The model serves as a foundation for software 
design and as the basis for the creation of specifications for the 
Software. The customer may be unsure of precisely what is required. 
The developer may be unsure that a specific approach will properly 
accomplish function and performance. For these, and many other 
reasons, an alternative approach to requirements analysis, called 
Prototyping, may be conducted. 
Software Project Management (CS615) 
96 
© Copyright Virtual University of Pakistan 
LECTURE # 14 
2. Software Development Fundamentals 
Technical Fundamentals 
2.11 Requirements Management 
⇒ Requirements Analysis 
• Evaluation and Synthesis 
Upon evaluating current problems and desired information (input 
and output), the analyst begins to synthesize one or more solutions. 
To begin, the data objects processing functions and behavior of the 
system are defined in detail. Once this information has been 
established, basic architectures for implementation are considered. 
A client/server approach would seem to be appropriate, but does 
the software to support this architecture fall within the scope 
outlined in the Software Plan? A database management system 
would seem to be required, but is user/customer's need for 
associativity justified? The process of evaluation and synthesis 
continues until both analyst and customer feel confident that 
software can be adequately specified for subsequent development 
steps. 
Throughout evaluation and solution synthesis, the analyst's 
primary focus is on "what, not "how." What data does the system 
produce and consume what functions the system must perform. 
What behaviors do the system exhibit, what interfaces, are defined 
and what constraints apply? 
• Models 
During the evaluation and solution synthesis activity, the analyst 
creates models of the system in an effort to better understand data 
and control flow, functional processing, operational behavior, and 
information content. The model serves as a foundation for software 
design and as the basis for the creation of specifications for the 
Software. 
• Specification 
Software Project Management (CS615) 
97 
© Copyright Virtual University of Pakistan 
During the evaluation and solution synthesis activity, the analyst 
creates models of the system in an effort to better understand data 
and control flow, functional processing, operational behavior, and 
information content. The model serves as a foundation for software 
design and as the basis for the creation of specifications for the 
Software. The customer may be unsure of precisely what is 
required. The developer may be unsure that a specific approach 
will properly accomplish function and performance. For these, and 
many other reasons, an alternative approach to requirements 
analysis, called Prototyping, may be conducted. 
• Concerns for Review 
The customer may be unsure of precisely what is required. The 
developer may be unsure that a specific approach will properly 
accomplish function and performance. For these, and many other 
reasons, an alternative approach to requirements analysis, called 
Prototyping, may be conducted. 
For example, an inventory control system is required for a major 
supplier of auto parts. The analyst finds that problems with the 
current manual system include: 
(1) Inability to obtain the status of a component rapidly, 
(2) Two- or three-day turn- around to update a card file, 
(3) Multiple reorders to the same vendor because there is no way to 
associate vendors with components, and so forth. 
Once problems have been identified, the analyst determines what 
information is to be produced by the new system and what data 
will be provided to the system. For instance, customer desires a 
daily report that indicates what parts have been taken from 
inventory and how many similar parts remain. The customer 
indicates that inventory clerks will log the identification number of 
each part as it leaves the inventory area. 
Upon evaluating current problems and desired information (input 
and output), the analyst begins to synthesize one or more solutions. 
To begin, the data objects, processing functions, and behavior of 
the system are defined in detail. Once this information has been 
established, basic architectures for implementation are considered. 
A client/server approach would seem to be appropriate, but does 
the software to support this architecture fall within the scope 
outlined in the Software Plan? A database management system 
would seem to be required, but is the user/customer's need for 
Software Project Management (CS615) 
98 
© Copyright Virtual University of Pakistan 
associativity justified? The process of evaluation and synthesis 
continues until both analyst and customer feel confident that 
software can be adequately specified for subsequent development 
steps. 
⇒ Requirements Elicitation for Software 
Before requirements can be analyzed, modeled, or specified they must be 
gathered through an elicitation process. A customer has a problem that 
may be amenable to a computer-based solution. A developer responds to 
the customer's request for help. 
Communication has begun. But, as we have already noted, the road from 
communication to understanding is often full of potholes. 
1. Initiating the Process 
The most commonly used requirements elicitation technique is to 
conduct a meeting or interview. The first meeting between a 
software engineer (the analyst) and the customer can be likened to 
the awkwardness of a first date between two adolescents. Neither 
person knows what to say or ask; both are worried that what they 
do say will be misinterpreted; both are thinking about where it 
might lead (both likely have radically different expectations here); 
both want to get the thing over with, but at the same time, both 
want it to be a success. Yet, communication must be initiated. 
Gause and Weinberg [GAU89] suggest that the analyst start by 
asking context-free questions. That is, a set of questions that will 
lead to a basic understanding of the problem, the people who want 
a solution, the nature of the solution that is desired, and the 
effectiveness of the first encounter itself. The first set of contextfree, 
questions focuses on the customer, the overall goals, and the 
benefits. For example; the analyst might ask: 
– Who is behind the request for this work? 
– Who will use the solution? 
– What will be the economic benefit of a successful solution? 
– Is there another source for the solution that you need? 
These questions help to identify all stakeholders who will have 
interest in the software to be built. In addition, the questions 
identify the measurable benefit of a successful implementation and 
possible alternatives to custom software development. 
Software Project Management (CS615) 
99 
© Copyright Virtual University of Pakistan 
The next set of questions enables the analyst to gain a better 
understanding of the problem and the customer to voice his or her 
perceptions about a solution: 
– How would you characterize "good" output that would be 
generated by a successful solution? 
– What problem(s) will this solution address? 
– Can you show me (or describe) the environment in which the 
solution will be used? 
– Will special performance issues or constraints affect the way 
the solution is approached? 
The final set of questions focuses on the effectiveness of the 
meeting. Gause and Weinberg call these meta-questions and 
propose the following (abbreviated) list: 
– Are you the right person to answer these questions? Are your 
answers "official"? 
– Are my questions relevant to the problem that you have? 
– Am I asking too many questions? 
– Can anyone else provide additional information? 
– Should I be asking you anything else? 
These questions (and others) will help to "break the ice" and 
initiate the communication that is essential to successful analysis. 
But a question and answer meeting format is not an approach that 
has been overwhelmingly successful. In fact, the Q&A session 
should be used for the first encounter only and then replaced by a 
meeting format that combines elements of problem solving, 
negotiation, and specification. 
2. Facilitated Application Specification Techniques 
Too often, customers and software engineers have an unconscious 
"us and them" mind-set. Rather than working as a team to identify 
and refine requirements, each constituency defines its own 
"territory" and communicates through a series of memos, formal 
position papers, documents, and question and answer sessions. 
History has shown that this approach doesn't work very well. 
Misunderstandings abound, important information is omitted, and 
a successful working relationship is never established. 
It is with these problems in mind that a number of independent 
investigators have developed a team-oriented approach to 
requirements gathering that is applied during early stages of 
Software Project Management (CS615) 
100 
© Copyright Virtual University of Pakistan 
analysis and specification. Called facilitated application 
specification techniques "(FAST). 
This approach encourages the creation of a joint team of customers 
and developers who work together to: 
Identify the problem 
Propose elements of the solution 
Negotiate different approaches and specify a preliminary set of 
solution requirements. 
FAST has been used predominantly by the information systems 
community, but the technique offers potential for improved 
communication in applications of all kinds. 
Many different approaches to FAST have been proposed. Each 
makes use of a slightly different scenario, but all apply some 
variation on the following basic guidelines: 
– A meeting is conducted at a neutral site and attended by both 
software engineers and customers. 
– Rules for preparation and participation are established. 
– An agenda is suggested that is formal enough to cover all 
important points but informal enough to encourage the free 
flow of ideas. 
– A ‘facilitator’ (can be a; customer, a developer, or an outsider) 
controls the meeting. 
– A "definition mechanism" (can be work sheets, flip charts, or 
wall stickers or an electronic bulletin board, chat room or 
virtual forum) is used. 
The goal is to identify the problem, propose elements of the 
solution, negotiate different approaches, and specify a preliminary 
set of solution requirements in an atmosphere that is conducive to 
the accomplishment of the goal. 
To better understand the flow of events as they occur in a typical 
FAST meeting, we present a brief scenario that outlines the 
sequence of events that lead up to the meeting, occur during the 
meeting, and follow the meeting. 
Initial meetings between the developer and customer occur and 
basic questions and answers help to establish the scope of the 
problem and the overall perception of a solution. Out of these 
initial meetings, the developer and customer write a one- or twopage 
"product request." A meeting place, time, and date for FAST 
are selected and a facilitator is chosen. Attendees from both the 
Software Project Management (CS615) 
101 
© Copyright Virtual University of Pakistan 
development and customer/user organizations are invited to attend. 
The product request is distributed to all attendees before the 
meeting date. 
3. Quality Function Deployment 
A quality management technique that translates needs of customers 
into technical requirements of software. 
i. Normal Requirement: meeting objectives & goals stated for a 
product or system during meeting 
i. Expected Requirement: Implicit to products / system and may 
be so fundamental that customer does not explicitly state them 
i. Exciting Requirement: Features beyond customer’s expectation 
and prove to be very satisfying when present 
4. Use Cases 
As requirements are gathered as part of: 
• Informal meeting 
• FAST or QFD 
SW Engineer can create a set of scenario that identify a thread of 
usage for system to be constructed; providing a description of how 
system will be used. 
5. Analysis Principles 
A variety of modeling notations are developed by investigators. 
Each analysis method has a unique point of view. However all 
analysis methods are related by a set of operational principles like: 
– The information domain of a problem must be represented and 
understood. 
– The functions that the software is to perform must be defined. 
– The behavior of the software (as a sequence of external events) 
must be represented. 
– The models that depict information function and behavior must 
be partitioned in a manner that uncovers details in a layered (or 
hierarchical) fashion. 
Software Project Management (CS615) 
102 
© Copyright Virtual University of Pakistan 
– The analysis process should move from essential information 
toward implementation detail. 
6. Software Prototyping 
Analysis should be conducted regardless of the SW engineering 
paradigm. (Various approaches apply) 
In some cases it is possible to apply operational analysis principles 
and derive a model of SW from which a design can be developed. 
In other situation Requirement Elicitation (FAST, QFD etc) is 
conducted and a model is built, called Prototype. 
Software Project Management (CS615) 
103 
© Copyright Virtual University of Pakistan 
LECTURE # 15 
2. Software Development Fundamentals 
Technical Fundamentals 
2.11 Requirements Management 
⇒ The Software Requirements Specification 
The Software Requirements Specification is produced at the culmination of the 
analysis task, The function and performance allocated to software as part of 
system engineering are refined by establishing a complete information 
description, a detailed functional description, a representation of system behavior, 
an indication of performance requirements and design constraints, appropriate 
validation criteria, and other: information pertinent to requirements. The National 
Bureau of Standards; IEEE (Standard No. 830-1984), and the U.S. Department of 
Defense have all proposed candidate formats for software requirements 
specifications (as well as other software engineering documentation). 
Mode of specification has a great impact on quality of solution. Forcing SWE to 
work with incomplete, inconsistence, or misleading specifications result in 
frustration and confusion affecting: 
– Quality 
– Timeliness and 
– Completeness of SW product 
• Principles 
i. Separate functionality from implementation. 
ii. Develop a model of desired behavior of a system that encompasses data and 
the functional response of a system to various stimuli from the environment. 
iii. Establish the context in which SW operates by specifying the manner in which 
other system components interact with software. 
iv. Define the environment in which system operates and indicate how a highly 
inter-wined collection of agents react to stimuli in the environment (changes 
to objects) produced by those agents. 
v. Create a cognitive model rather than a design or implementation model. 
Cognitive model describes a system as perceived by its user community. 
Software Project Management (CS615) 
104 
© Copyright Virtual University of Pakistan 
vi. Recognize that; “the specifications must be tolerant of incompleteness and 
augmentable.” 
vii. A specification is always a model –an abstraction-of some real (or envisioned) 
situation that is normally quite complex. Hence it will be incomplete and will exit 
at many levels of detail. 
i. Establish the content and structure of a specification in a way that will enable it to 
be amenable to change. 
• Representation 
i. Representation format and content should be relevant to the problem. (A 
general outline of SRS can be developed). 
ii. Information contained within the specification should be nested. 
iii. It should reveal layers of information so that reader can move to the level 
of detail required. Paragraph & diagram number scheme to indicate level. 
iv. Diagrams and other notational forms should be restricted in number and 
consistent in use. (Confusing or inconsistent notations, whether graphical 
or symbolic degrades understating and foster errors.) 
v. Representation should be revisable. 
vi. The content of specification will change. Ideally, CASE tools should be 
available to update all representations that are affected by each change. 
The function and performance allocated to software as part of system engineering 
are refined by establishing: 
1. A complete information description, 
2. A detailed functional description, 
3. A representation of system behavior, 
4. An indication of performance requirements and design constraints, 
5. Appropriate validation criteria, and other: information pertinent to 
requirements. 
The Introduction of the software requirements specification states the goals and 
objectives of the software, describing it in the context of the computer-based 
system; actually, the Introduction may be nothing more than the software scope of 
the planning document. 
Software Project Management (CS615) 
105 
© Copyright Virtual University of Pakistan 
The Software Requirements Specification is produced at the culmination of the 
analysis task. The function and performance allocated to software as part of 
system engineering are refined by establishing: 
– A complete information description 
– A detailed functional description 
– A representation of system behavior 
– An indication of performance requirements and design constraints 
– Appropriate validation criteria and other information pertinent to 
requirements. 
The Information Description provides a detailed description of the problem that 
the software must solve. Information content, flow, and structure are documented. 
Hardware, software, and human interfaces are described (or external system 
elements: and internal software functions. 
A description of each function required to solve the problem is presented in the 
Functional Description. 
A processing narrative is provided for each function: 
– Design constraints are stated and justified 
– Performance characteristics are stated, and 
– One or more diagrams are included to graphically represent the overall 
structure of the software and interplay among software functions and other 
system elements 
The Behavioral Description section of the specification examines the operation of 
the software as a consequence of external events and internally generated control 
characteristics. 
Validation Criteria is probably the most important and, ironically, the most often, 
neglected section of the Software Requirements specification. 
– How do we recognize a successful implementation? 
– What classes of tests must be conducted to validate function, performance, 
and constraints? 
We neglect this section because completing it demands a thorough understanding 
of software requirements-something that we often do not have at this stage. 
Yet, specification of validation criteria acts as an implicit review of all other 
requirements. It is essential that time and attention be given to this section. 
Finally, the specification includes a Bibliography and Appendix. 
Software Project Management (CS615) 
106 
© Copyright Virtual University of Pakistan 
 
<a href="http://www.genrica.com/vustuff/BIT715/BIT715_handouts_1_45.pdf" target="_blank">Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf</a></div>

Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf

Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf Handouts | Lectures | Contents | Books ...