Unit 1: Software Project Basics

Software Project

A Software Project is the complete procedure of software development from requirement gathering to testing and maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product.

Need of software project management

Software is said to be an intangible product. Software development is a kind of all new stream in world business and there’s very little experience in building software products. Most software products are tailor made to fit client’s requirements. The most important is that the underlying technology changes and advances so frequently and rapidly that experience of one product may not be applied to the other one. All such business and environmental constraints bring risk in software development hence it is essential to manage software projects efficiently.

The image above shows triple constraints for software projects. It is an essential part of software organization to deliver quality product, keeping the cost within client’s budget constrain and deliver the project as per scheduled. There are several factors, both internal and external, which may impact this triple constrain triangle. Any of three factors can severely impact the other two.

Therefore, software project management is essential to incorporate user requirements along with budget and time constraints.

Software project vs. Other types of projects

Many techniques in general project management do apply to software projects also. However, following are some of the characteristics that makes software projects bit difficult.

Invisibility: When a physical artifact such as in construction of bridge progress is clearly visible.

But with software progress is not immediately visible.

Complexity: Per dollar, pound or Euro spent, software products contain more complexity.

Conformity: The traditional Engineers works with physical systems which are clearly governed by consistent physical laws. But software engineers have to conform to the human client’s or organizational requirements and if they are inconsistent in what they need then developing software can be a difficult job.

Flexibility: The software is very easy to adapt with the change in needs.

Activities Covered by SPM

Well, we all know that Software projects covers many activities to achieve a goal but the major three successive processes that brings a new system into being-includes:

1. The feasibility study: it is the study to find out whether a project is worth starting; to see if developmental and operational cost are feasible; and to see if there is value of the benefits from the system.
2. Planning: If feasibility study indicates that the project is viable, then project planning can start. We can make the detailed planning of the earlier stages of the project and start working on it. Planning may include forming a team, deciding a schedule and work allocation, resource requirement analysis, calculating cost, effort and time.
3. Project Execution: Now the execution of project can start. Generally, project execution involves Design and implementation phase.

“Design is making decision about the form of product to be created” 

“Implementation means coding, integration and testing of software” 

Categorizing Software Projects: 

• Information system Vs. Embedded System: Information systems (eg; Microsoft office Package) are those that help staffs to perform office processes and embedded systems are those that control machines (automatic washing machine).
• Outsourced Projects: Sometimes when a project is too large then some of its component is given to other companies to develop it for them. Such projects are called outsourced projects.
• Object-driven software projects: Projects that are developed to meet specific objectives only.
• Compulsory Vs. Voluntary users: Compulsory systems are those that has to be used by people to get their work done for example office software. Voluntary software are those that may be used or may not be used by users for example computer games.

Types of Software Development

• Frontend Development
• Backend Development
• Full-Stack Development
• Desktop Development
• Database Development
• Web Development
• Mobile Development
• Cloud Computing
• DevOps Engineering
• Security Engineering

Classification of Software Projects Based on software development Life Cycle

Full life cycle projects. A project that traverses the entire arc of the methodology being used: start to end. No standardization of software development life cycles (SDLC) introduces problems like

• A feasibility study determining whether the project is worthwhile
• Special testing that is beyond unit testing, integration testing, system testing, and acceptance testing
• Implementation, including installation of hardware, system software, application software, etc.
• Software commissioning, including creating master data files, user training, pilot runs, parallel runs, etc.

Therefore, all post-delivery activities and pre-user requirement activities are usually not considered part of the project.

Partial life cycle projects. projects that include only a portion of the SDLC. In partial life cycle projects, any number of permutations could occur, including:

 Testing projects in which the scope of the work involves conducting the specified or necessary software tests on the software product to certify the product (Unit testing and code walk-through are normally not included in this type of project.)

 Independent verification and validation (IV&V) projects in which projects go beyond mere testing, including code walk-through and other forms of validation to determine the efficiency of coding

 A project divided between two or more vendors based on the specialty to derive the advantages of best practices developed through specialization which can lead to defining the project by phase or by combination of phases, such as:

• Requirement analysis
• Design
• Software construction
• Testing

Approach driven

Fresh or new software development projects. These types of projects are identical to full life cycle development projects.

COTS product customization/implementation projects. Numerous popular COTS products are available in the marketplace like, ERP by SAP and PeopleSoft, CRM, SCM, etc. Typical phases in these projects include:

• Current system study: a review of the present system
• Gap analysis: a comparison of the current system to the COTS product
• Customization report: a discussion of the desired levels of customization of the system
• Statement of work: definition of the required customization of the COTS product
• Design: how the software will accomplish the task Construction and integration
• Testing
• Custom code integration: integration of the code bases (in some cases it can include building a layer over the COTS product and integration of custom

developed code into the source code of the COTS product)

• COTS source code modification (rare)
• Implementation
• Training: instruction of users (all classes required) in usage of the system, troubleshooting, and operations and maintenance of the system
• Transition of the system

Many variations of these phases are also possible for COTS projects.

Porting. deals with moving software from one hardware platform to another hardware platform. Porting projects can include:

• Changes in programming language
• Differences between implementations

 Manual intervention to make the existing software work on new hard- ware without issues

A porting project involves:

• Documenting the differences between the two versions of the programming languages
• Developing a software tool to make corrections in the code
• Execution of the software porting tool to make all possible corrections
• Manual correction to make any specific corrections needed
• Conducting the specified software tests
• Modifications to the software engineering documents required to reflect the changes made in the software
• Conducting acceptance testing
• Delivery of the software

Migration. Oftentimes, new versions of programming languages and databases are released. When upgrades are released, upgrading software may become necessary to take advantage of new features and facilities provided in the newly released version.To take advantage of new facilities and features available in the newer version, manual changes are typically required and involve:

• Studying the new version
• Deciding which new features are desirable and need to be implemented
• Developing a functional expansion design document detailing the new features being implemented in the existing software
• Running and upgrading the software
• Implementing the functional expansion design in the software coding and incorporating necessary software changes
• Conducting all the tests necessary to ensure that the software delivers all the functionality it was supposed to before migration and all the functionality that is designed for the new software
• Conducting acceptance testing and delivering the software
• Data migration involving
  • Mapping the old database schema to the new database schema
  • Developing software/locating tools provided with the new database (if any) to migrate data from the old database to the new database
  • Running the tools to migrate data from the old database to the new database
  • Arranging for data entry in the new database for those fields that are absent in the old database, but present in the new database
  • Testing the database for known cases using the software, comparing the results with the desired results, and making necessary changes so that the new database is correct
  • Integrating the database with the software

Specific migration projects may have different activities from the activities described above.

Conversion. Typical activities in a conversion project include:

• Studying the existing software and specifications of the necessary conversion
• Preparing a conversion guidelines document detailing the procedure for incorporating the required modifications in the software
• Developing a tool (if feasible) to automatically incorporate the modifications in the software
• Running the tools or hand coding the changes
• Performing a manual walk-through of each program to locate the remaining required modifications and implementing them
• Conducting unit testing (and other tests as specified or as necessary)
• Conducting acceptance testing
• Delivering the software

Maintenance

Software maintenance projects are major money makers for software development organizations that are dependent on outsourcing. We need, however, to relax the specific beginning and ending requirements to call software maintenance a project. In a software maintenance project, generally there is a contract between the parties to take care of a specific application for a given period of time. An overall contract would specify:

• Billing rates
• Mode of requesting work
• Service level agreement (SLA) specifying the priorities and turn- around times Persons authorized to initiate/authorize work requests, accept deliveries, give clarifications

• Escalation mechanisms
• Billing cycles and payment schedules

This list could go on forever, depending on the specific needs and the “pain” of the organizations.

Normally, a maintenance work request (MWR) triggers software maintenance work. An MWR can be known by other terms, depending on the organization:

• Program modification request (PMR)
• Program change request (PCR)
• Defect report

• Software change request

Again, this list can also go on forever.

Work included in a software maintenance project is classified into five types: defect fixing, operational support, fixing odd behavior, software modification, and functional enhancement.

Defect repair. Defect fixing work involves fixing a reported defect. A defect may be classified as:

• Critical (a “show-stopper”)
• Major (hinders smooth functioning of work)
• Minor (mostly a nuisance; work is not affected)

Typically, defect fixing has an associated SLA in which the turnaround time for each class of defect, based on priority, is defined (i.e., the time between when a defect is reported until the time it is fixed, the regression test is completed, and the software is handed over to production). Sometimes, the turnaround time can be as little as hours or minutes, depending on the application and the needs of the organization. Normally, the maximum turnaround time for fixing a defect would be about 2 days. In a defect-fixing scenario, follow-up and progress reporting are frequent and close together. Generally, the steps in fixing a defect include:

• Studying the defect report
• Replicating the defect scenario in a development environment
• Studying the code
• Locating the defect
• Fixing the defect, conforming to code change guidelines
• Arranging for peer review and implementing feedback (if any)
• Arranging for independent regression testing and implementing feedback (if any).
• Delivering the fixed code to production for implementation in the production system
• Closing the request

Functional expansion. When additional functionality is required in existing software, functional enhancement is the tool to achieve it. Functional enhancement work is generally of longer duration and may range from a calendar week upward. Work included in functional enhancement includes:

• Adding a new screen or report
• Adding additional processing functionality (e.g., quarterly/half yearly/yearly processing)
• Adding a new module in the software
• Integrating with another software

• Building interfaces with other software
• Adding new hardware and building an interface to the new hardware in the existing software

Functional expansion generally fits the full SDLC model in which the project leverages the full software engineering process and the project management process and can be treated as an independent project if the duration is sufficiently long enough. The level of process rigor required is typically driven by risk. Each organization has a different definition of a project that should be treated as a functional enhancement project. For example, in one organization, a functional enhancement project is defined as “work with the duration of one person-month of effort or more,” while in another, the definition of a functional enhancement project is “40 hours of effort.”

Operational support. Operational support is similar to defect fixing. Many times, operational support requires immediate attention. Activities under operational support include:

• Running periodic jobs (end of day/week/month)
• Taking backups
• Restoring from backups

• User management functionality (including creation, deletion, and
  • suspending of user accounts and changing access privileges, etc.)
  • Providing “hand-holding” assistance at a specific workstation
  • Extracting data and producing an ad hoc report on an urgent basis
  • Providing a temporary patch so that operations may continueInvestigating operational complaints

Again, the list of activities is long and varied.

Fixing odd behavior. In large, complex software systems, and in systems that have been in existence for many years and have undergone software maintenance (e.g., defect fixes, software modifications, and functional expansions), random defects may often crop up under some circumstances, but not in others. These random defects are generally difficult to replicate in a development environment. One reason is because the defect occurs in the field and the person witnessing the defect does not note the chain of events that caused the defect. So until the defect becomes chronic, it might have been handled as an operational support activity and not have been recognized as defect. Such puzzling defects can be placed in the odd behavior category of software maintenance. Odd behavior can be caused by the application software or the system software, a client workstation or a virus, network security, or a combination of all of these. Diagnosing and correcting odd behavior issues may take longer than a week because correcting odd behavior is similar to conducting research. General steps in fixing odd behavior include:

• Studying the odd behavior report
• Trying to replicate the behavior scenario in a development environment
• Studying the code
• Listing all possible alternative reasons for the reported behavior
• Reviewing the code for each alternative for possible opportunities for improvement
• Iterating/eliminating all causes, one by one
• Fixing all possible opportunities for code improvement
• Arranging for peer review
• Arranging for independent regression testing
• Delivering the software to production for implementation of improved code in the production system
• Waiting for another report of the identical odd behavior and repeating all the above steps.
• Keeping the request open through a period of observation

Software modification. Software modification work is the bulk of software maintenance in most organizations. Modification of working software is necessitated due to:

• Changes in requirements mainly due to changed conditions occurring over a period of time
  • Changes in business processing logic
  • Convenience for users
  • Changes in statutory requirements

Often, modifications include changes to reports, changes to screens by moving around data fields, adding or deleting a data field or two, or some other small enhancement. Steps in the process of software modification include:

• Studying the software modification request
• Analyzing the existing software to identify components that require modification Preparing a design modification document and obtaining approval from appropriate executives
• Implementing the approved design modification in the code
• Arranging for peer review of the modified code
• Arranging for independent functional testing of the modified functionality to ensure that it conforms to the approved design document and implementing feedback (if any)
• Arranging for independent regression testing and implementing feedback (if any) Delivering the modified artifact to production for implementation in the production system
• Closing the request

Web Application

Web projects refer to Web-based application development projects.

A Web application consists of:

• HTML pages that include graphics to enhance the “look and feel” of the Web pages
• Backend programs for data manipulation
• Middleware programs for application server or rules engines
• Middleware programs for security management
• Other application-specific programs

Another notable feature of Web applications is that backend programming and middleware programming may be in different programming languages and may require persons with different skill sets, even for the same project. Another request is for independence from databases and Web browsers, which necessitates coding routines that are not oriented toward functionality. Additionally, a Web application needs to be developed so that it facilitates an easy change of code. Environmental changes that have nothing to do with the organization, e.g., a new security threat, the release of a new browser, or the upgrade of an existing browser, etc., can also trigger software maintenance in a Web application even though the functionality remains unaltered. Web-based and client server projects have a very similar profile.

Agile development

Agile software development refers to a group of software development methodologies based on iterative development, in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Approaches to Software Project Management

Software project execution has two components, namely, software engineering and management. Software engineering consists of all of the technical activities that are performed to build the project deliverable. Management facilitates software engineering so that the project deliverable is completed on time, efficiently and effectively, and without defects.

Alignment of Software Engineering Methodology with Project

Management Methodology

There are two general schools of thought about the linkage of the software engineering and management methodologies: tightly coupled and loosely coupled.

Tightly coupled. One school of thought maintains that both of the methodologies are tightly coupled and that management is completely dependent on the software engineering methodology adopted for building the project deliverable. Therefore, project management needs to be tightly interlaced with software engineering.

Note: In some software engineering methodologies, such as agile methods, the distinction between software engineering and project management is somewhat blurred. In this situation, the argument is that the SPM or software project manager acts as a coach because the primary responsibility of an SPM is to be the voice of the people and a leader rather than a director.

Loosely coupled. In the other school of thought, the two aspects of software engineering and management are loosely coupled, but they do influence each other. Therefore, each aspect needs some amount of tailoring to suit the other. Additionally, in this school of thought, project management is considered to have multiple objectives, with the primary objective being to build the deliverable. Other objectives include management of the schedule, productivity, quality, resources, morale, customers, and profit. In the loosely coupled school of thought, an SPM is to be a manager first and to be aware of the software engineering methodology second.

Briefly, software engineering methodologies include waterfall, incremental, spiral, object oriented, use case-based (unified modeling language), and agile methods of various types. These methodologies are also commonly referred to as SDLCs (software development life cycles). Agile methods include extreme programming (XP), scrum, clear case, feature-driven development, test-driven development, dynamic systems development, rational unified process (RUP, the agile version), adaptive software development, and pragmatic programming. Agile methods, with the exception of RUP, encourage only the development of the minimal required documentation associated with the software’s development. RUP, however, is an exception because RUP is a detailed software engineering process that includes levels of documentation that are similar to other types of methods.

The alignment of the project management methodology to the software development methodology is driven by a number of factors, such as organizational size and the form of software engineering used on a particular project. For example, in a small organization in which the owner is a technical person who is actively involved in project activities, the management methodology can completely align with the software engineering methodology. In other cases, e.g., when types of projects and project management styles are more varied, using disparate software engineering methodologies, then aligning the project management methodology completely with the software engineering methodology, is problematic.

A completely aligned project management methodology is suitable for smaller, more homogenous organizations, while less homogenous organizations should have a project management methodology that is decoupled from the soft- ware engineering methodology of the project. Because the methodology of soft- ware engineering used on a project has an impact on project management, each project will need to have the management methodology tailored to some extent to align with the software engineering methodology.

The Ad Hoc Methods Based Approach

By definition, adhoc methods are not documented and are dependent on the involved parties. In an adhoc method approach, a software project manager (SPM) is given almost absolute control within a general policy framework that tends to be rather flexible. In organizations that allow adhoc methods, management typically dictates policy and then modifies the policy as necessary or when convenient. In this situation, often the management style also reflects the personality of the leader of the organization. Management driven by the personality of the leader is classically referred to as “hero-driven” management. In organizations with hero driven management, success is more luck than process supported.Advantages of the ad hoc methods approach are that it:

• Fits a dynamic environment
• Allows the leader to have absolute control
• Is perceived to allow very fast response to environmental changes
• Can be the least costly, and the most profitable, methodology (if nothing surprising happens)
• Is perfect for pinning the blame for failure on one person
• Reduces process overhead activities to nearly zero (e.g., process definition, maintenance groups, measurement, and analysis)
• Permits the principle of “unity of command” to be implemented
• Leads to a sense of “heroism” in management styles

Disadvantages of the ad hoc methods approach are that it:

• Creates uncertainty in the workplace
• Fosters a leader-centric environment rather than an environment driven by organizational and project goals
• Centralizes authority: lose the leader, lose the project
• Results in outcomes being unpredictable (because they are person-driven)
• Focuses on people monitoring rather than on overall project monitoring
• Causes growth in an organization to be limited by the capacity of an SPM
• Leads to deterioration of morale in the workplace due to the encouragement of an undesirable, ego-driven environment (e.g., encourages an increase of self-serving sycophants)
• Hinders (or makes impossible) the development of leaders from within the organization

(employees work in their own “cocoons”)

All in all, the ad-hoc method approach might produce some grand successes, but these successes are not sustainable. Because of the inevitability of failure in human endeavors, the impact on the organization can be severe: failure cripples an organization — from which it may not recover. Despite the risks, however, ad hoc approaches to software project management continue to be adopted by a significant number of organizations.

The Process-driven Approach

Organizations using a process-driven approach are characterized by having documented processes for all activities. Individuals must also be knowledgeable in the processes that concern them to be effective and efficient.

An organization that adopts a process-driven approach to software project management recognizes that the onus is on the organization as well as the individual SPM for ensuring continued project successes. The organization facilitates the execution of projects by providing the processes, the tools, a knowledge repository, the training, and expert assistance as needed to help the SPM(s). In other words, the organization’s infrastructure enables successful execution of projects by the SPM. In addition to facilitation, the organization also has the responsibility of project oversight, monitoring, measurement, and benchmarking and effecting improvements in processes, tools, and the knowledge repository to continuously keep the organization well honed.

Each SPM is responsible for executing projects while diligently conforming to defined processes provided by the organization. SPMs also are responsible for providing feedback, suggestions, and support for the organizational initiatives in continuous improvement of processes, tools, and the knowledge repository.

In a process-driven organization, the organization and the SPM work in a close-knit manner, complimenting each other’s efforts. The goal of the process- driven approach is to achieve uniformity across the organization in project execution regardless of the SPM involved. An often-mentioned benefit of the process-driven approach is that it enables the free movement of people from project to project with no discernable impact on project execution.

Advantages of a process-driven approach to software project management include:

• Minimizes the person-dependency of project management
  • Enables a beginner in project management to perform like an expertand an expert to excel
• Facilitates the “plowing back” of experience gained from project execution into the process (As a result, every project execution enriches the process.)
• Equips everyone with the best practices in the process culled fromproject execution.
• Monitors projects rather than people

Involves the organization in project execution and organizational expertise, not only from the process, but also from senior executives whose considerable experience influences project execution and sup- ports its continued success

• Provides uniformity of project execution across the organization, irrespective of the people involved in the project, which leads to orga- nizational maturity
• Facilitates measurement, resulting in fair performance appraisals, which makes possible real morale improvement in an organization (Having measurements also facilitates benchmarking the organiza- tional performance with similar organizations and enables improve- ment thereof.)
• Builds the basis for predictability in project execution
  • Enables all-round participation; iteratively drives an organization toward excellence
• Promotes the recruitment and induction of new people into projects because processdriven processes facilitate raising newcomers’ performances to acceptable levels quickly

All in all, a process-driven approach facilitates person-independence in project execution, while facilitating process improvement and moving toward unifor-mity in project execution across the organization — characteristics that tend to foster organizational excellence.

What is the Right Approach?

Due to the diversity of software nature, attempting to prescribe one “right” approach is neither feasible nor appropriate. We will discuss different approaches accordingly:

The Ad Hoc Approach

An ad hoc approach will serve well organizations in which:

• The organization is small.
• Organizations that do not need to have a set of documented project references.
• The senior manager can ensure uniformity through personal intervention and act as the resolution mechanism when there are differences of opinion.
• The number of concurrent projects is less than five.

The Process-driven Approach

In this approach the organization build reliable and mature processes. Strict internal controls and external verification through audits are also mandatory. In addition to auditors, other statutory groups act as “watchdogs” over these organizations. In short, a process-driven approach contains defined methods for carrying out the work as well as the checks and balances necessary to ensure that the processes deliver results and that everyone adheres to the processes.

A process-driven approach consists of:

• Processes for carrying out the activities
• Agencies responsible for carrying out the activities
• Processes for ensuring that quality is built into the deliverables
• Agencies responsible for assuring quality in the deliverables
• Processes for defining and maintaining organizational processes
• Agencies responsible for defining and maintaining organizational processes
• Processes for measuring and analyzing the process performance
• Agencies responsible for measurement and analysis of process performance

Two main frameworks commonly used in process-driven approach are: ISO 9000 (of the International Organization for Standardization) and CMMI (Capability Maturity Model Integration of the SEI, the Software Engineering Institute of Carnegie Melon University). ISO covers the entire organization, while CMMI covers activities that are specifically relevant to software and hardware products.

From the beginning, however, software engineers have resisted any move toward adopting a process-driven approach. For example, the waterfall model was the first processdriven approach to software development, but in today’s envi- ronment, more people continue to hate the waterfall model rather than to love it. As a result, many other approaches, namely, rapid application development (RAD), joint application development (JAD), incremental, and agile methods (e.g., XP, scrum), were developed to replace the waterfall methodology. Although methodologies come and go, and some are forgotten, interestingly the waterfall model is still in the mix.

The first activity in software project management is the acquisition of a project. Deciding on the project to be undertaken is a very important strategic activity as it can put a huge influence on the organization’s financial health and profitability. Project acquisition should therefore be a collaborative activity between the business acquisition team, technical team, finance team, and senior management. The focus of senior management is from a strategic perspective.

Software Project Acquisition

• The first step in the project management is acquisition of a project.
• This is carried out by a business acquisition team with the assistance of a technical team.
• There are two types of project acquisition:
  • Acquisition from an external client
  • Acquisition from an internal source

 Acquisition from an external client

• In this project is acquired from a prospective client or the external organization.
• The project is to be a revenue-generating source.
• Characteristics of a project from a prospective client include:
  • The project will result in revenue for the acquiring organization from the external client.
  • The software product resulting from execution of the project will be used or resold by the external organization.
  • The external organization will impose stipulations on quality, schedule and cost.
  • End users will typically not be directly accessible to the software development

Steps in project acquisition from a external client

1. The request for proposal
2. The proposal
   1. Software estimation
   2. Delivery commitments
   3. Pricing the proposal
   4. Preparing the proposal
3. Negotiation
4. Contract acceptance

Writing proposal

A project proposal is a document that outlines everything stakeholders need to know to initiate a project. It’s a necessary first step towards getting a project off the ground. A project proposal is usually selected during the project intake process.

A well-written project proposal informs and persuades, and combines project management skills with a few other essential skills: research, data analysis, and some copywriting.

It follows conventional proposal formats that include the following elements:

• Executive summary. Short and to the point, the executive summary is essentially the project’s elevator pitch. It states the problem clearly, addresses how your proposed project intends to solve the problem, and discusses what a successful project looks like.
• Background or history. This section outlines both successful and unsuccessful previous projects, including how the latter could have been handled better, with the goal of showing how the proposed project will be more successful based on the lessons of the past.
• Requirements. This section briefly summarizes what’s needed throughout the project life cycle in terms of resources, tools, project schedule, etc.
• Solution. The solution section explains how you intend to approach the project and bring it to completion. It covers the project management steps, techniques, and skills needed to get things done more efficiently, as well as how to manage problems.
• Authorization. This section states explicitly who the project’s decision-makers are and the stakeholders authorized by the client to make approval/sign-off decisions.
• Appendix. Any information not included in the actual proposal should be in the appendix, such as materials and resources that team members and stakeholders can use to learn more about the project.

Steps to writing your own project proposal

• Step 1: Define the problem
• Step 2: Present your solution
• Step 3:Define your deliverables and success criteria
• Step 4: State your plan or approach
• Step 5: Outline your project schedule and budget
• Step 6: Tie it all together
• Step 7: Edit/proofread your proposal

• A proposal is a multipage document that has two separate parts:
• The technical proposal and
• The financial proposal

Technical proposal

The technical proposal contains the following sections:

• Title page
• Contents
• Introduction
• Scope of work
• Approach and methodology
• Deliverables
• Approval required from the client
• Schedule for project execution
• Software estimation
• Inclusion
• Exclusion
• Responsibilities

Financial proposal

The financial proposal contains the following sections:

• Fee
• Fee exclusion
• Validity period
• Payment terms
• Intellectual property right
• Force majeure clause
• Software tools or components to be supplied by the client
• Facilities
• Price escalation clause
• Arbitration and jurisdiction
• Consequential liability

Negotiation

Negotiation is a process consisting of the activities necessary to resolve different types of disputes through consultations between the parties involved in order to reach a consensus.

• In negotiation, the client’s finance team, assisted by the client’s technical team, conducts price negotiations with the vendor’s business acquisition team.
• Most negotiation situation, give-and-take occurs.
• During negotiation process, decisions are made “across the table” to clinch the deal

Negotiations can take place at any time in the project lifecycle and may be formal or non-formal.

Formal negotiation implies an agreement through contracts and formal documents, while informal negotiations include debates to resolve a conflict between team members, for instance.

In project management, the negotiation process is divided into phases and include:

• Planning: the preparation of all relevant information necessary for the discussion.
• Debate: here the key issues are examined and discussed.
• Proposal: the creation of the proposal as a way of solving the problem presented.
• Revision: this can include negotiating compromises before an agreement is formalized and before the information is shared throughout the organization.

Negotiating skills

Practice

The very first thing to do, as happens in all things, is to practice a lot.

Probably everyone negotiates more than they think – both in their professional life and in their private life.

It is therefore important to be aware of these negotiating situations, to analyze how you approach and deal with the moment, how you feel and what could be improved for the next time.

Preparation

It is important to spend some effort on preparation for negotiation.

If a project manager knows they are meeting a supplier, for example, they should think in advance about what they want to achieve from this agreement and explore potential alternatives.

This way you will engage in the discussion more confidently and know in advance what you want to achieve.

However, it is important to remember to remain receptive to other people’ points of view as well.

It is not a negotiation if you refuse to change your standpoint and force the other person to accept your ideas.

Manage your emotions

Conflict situations and negotiations often expose the worst in people.

It is therefore important for the project manager to be prepared for how they will react in a potentially difficult and perhaps embarrassing conversation.

Take your time

Negotiations can take a long time and be running on a continuous basis; it is unlikely that in a single meeting, everything will be discussed and resolved.

For large projects, multiple meetings could be held to ensure that everything is documented effectively and to the satisfaction of both parties.

And even when the agreement is concluded, the project manager may find himself negotiating more precise details or new terms to move the project in the right direction.

 Listen

When preparing for a negotiation, you need to try your best to think about what you want to say, how to say it, how to reply to what you think the other person will say.

Simply put, a project manager must also be ready to listen.

Listening will help you identify the other party’s weaknesses and help you really understand what others want.

Contract acceptance

Once the order to execute a project has been received from the client the business acquisition team reviews the order to ensure:

• Price, delivery date and payment terms are in agreement with those specified in the order.
• All terms and conditions agreed upon and those specified in the order are in agreement.
• Any new conditions are inserted in the order.
• The scope of work is as agreed.
• If new concerns are raised, the business acquisition team may need to renegotiate with the client to resolve all contentious issues.

Project acquisition from an internal client

• The resultant software product is not for delivery to an outside organization
• No direct revenue for the organization will result from this project
• Project expenditures are treated as a cost to the organization
• Expected benefits are reduced cost of operation, improved quality, reduced turnaround times etc.
• End-users of the developed software are within the same organization and therefore are accessible to the software development team.
• The project commences with a feasibility study and ends when the software is installed for use by end users or the project is cancelled.

Phases of the Project Management Life Cycle

1. Initiation
2. Planning
3. Execution
4. Closure

Note: Some methodologies also include a fifth phase—controlling or monitoring—, this phase is covered under the execution and closure phases.

Initiation

• First, you need to identify a business need, problem, or opportunity and brainstorm ways that your team can meet this need, solve this problem, or seize this opportunity.
• During this step, you figure out an objective for your project, determine whether the project is feasible, and identify the major deliverables for the project.
• Project management steps for the initiation phase

Steps for the project initiation phase:

• Undertaking a feasibility study: Identify the primary problem your project will solve and whether your project will deliver a solution to that problem
• Identifying scope: Define the depth and breadth of the project
• Identifying deliverables: Define the product or service to provide
• Identifying project stakeholders: Figure out whom the project affects and what their needs may be
• Developing a business case: Use the above criteria to compare the potential costs and benefits for the project to determine if it moves forward
• Developing a statement of work: Document the project’s objectives, scope, and deliverables that you have identified previously as a working agreement between the project owner and those working on the project

Planning

• Once the project is approved to move forward based on your business case, statement of work, or project initiation document, you move into the planning phase.
• During this phase of the project management life cycle, you break down the larger project into smaller tasks, build your team, and prepare a schedule for the completion of assignments.
• Create smaller goals within the larger project, making sure each is achievable within the time frame.
• Smaller goals should have a high potential for success.

Steps for the project planning phase

• Creating a project plan: Identify the project timeline, including the phases of the project, the tasks to be performed, and possible constraints
• Creating workflow diagrams: Visualize your processes using swimlanes to make sure team members clearly understand their role in a project
• Estimating budget and creating a financial plan: Use cost estimates to determine how much to spend on the project to get the maximum return on investment
• Gathering resources: Build your functional team from internal and external talent pools while making sure everyone has the necessary tools (software, hardware, etc.) to complete their tasks
• Anticipating risks and potential quality roadblocks: Identify issues that may cause your project to stall while planning to mitigate those risks and maintain the project’s quality and timeline
• Holding a project kickoff meeting: Bring your team on board and outline the project so they can quickly get to work

Execution

• You’ve received business approval, developed a plan, and built your team.
• It’s time to get to work.
• The execution phase turns your plan into action.
• The project manager’s job in this phase of the project management life cycle is to keep work on track, organize team members, manage timelines, and make sure the work is done according to the original plan.

Steps for the project execution phase

• Creating tasks and organizing workflows: Assign granular aspects of the projects to the appropriate team members, making sure team members are not overworked
• Briefing team members on tasks: Explain tasks to team members, providing necessary guidance on how they should be completed, and organizing process-related training if necessary
• Communicating with team members, clients, and upper management: Provide updates to project stakeholders at all levels
• Monitoring quality of work: Ensure that team members are meeting their time and quality goals for tasks
• Managing budget: Monitor spending and keeping the project on track in terms of assets and resources

Closure

• Once your team has completed work on a project, you enter the closure phase.
• In the closure phase, you provide final deliverables, release project resources, and determine the success of the project.
• Just because the major project work is over, that doesn’t mean the project manager’s job is done—there are still important things to do, including evaluating what did and did not work with the project.

Steps for the project closure phase

• Analyzing project performance: Determine whether the project’s goals were met (tasks completed, on time and on budget) and the initial problem solved using a prepared checklist.
• Analyzing team performance: Evaluate how team members performed, including whether they met their goals along with timeliness and quality of work
• Documenting project closure: Make sure that all aspects of the project are completed with no loose ends remaining and providing reports to key stakeholders
• Conducting post-implementation reviews: Conduct a final analysis of the project, taking into account lessons learned for similar projects in the future
• Accounting for used and unused budget: Allocate remaining resources for future projects