Project Management Institute

The nine areas of project management outlined by Project Management Institute (PMI) are:

(1) Project Scope Management:

• Controlling the planning, execution, and content of the project.

 • We need to pay special attention to both project & product scope so that the software we end up with its what we intended to make in the first place

(2) Project Time Management:

• Managing everything that affects the projects schedule.

• Building the product at right time for maximum customer acceptance.

(3) Project Cost Management:

• Cost estimating, budgeting, and controlling the costs involved in building and maintaining the project.

(4) Project Quality Management:

• Ensuring that the product we are producing is a quality product and that it meets customer expectations.

(5) Project Human Resources Management:

• Hiring and managing the competent people to work for the project.

(6) Project Communications Management:

• Making sure that the people who information need get it, when they need it.

(7) Project Risk Management:

• Anticipating and handling risks as well as taking advantage of opportunities that can help a project.

(8) Project Procurement Management:

• Creating vendor contracts and purchasing goods and services.

(9) Project integration Management:

• Ensuring perfect coordination between all the knowledge areas.


To Download : http://www.megaupload.com/?d=TRJ8N7QE

Project Dimensions

Project dimensions include People, Product, Process, and Technology

(1) People: People management includes – Recruiting, Selection, Performance management, Training, Compensation, Career development, Work design, Team culture and Development

(2) Product: Before a project can be planned product objectives and scope should be established. Alternative solutions should be considered. Technical and management constraints should be identified. The software developer and customer must meet to define product objectives and scope. Scope identifies the primary data, functions and behaviors that characterize the product. Once the product objectives and scope are understood alternative solutions are considered.

(3) Process: A software process provides the framework from which a comprehensive plan for software development can be established. A number of different activities like 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 are carried out during the process follow up.

(4) Technology: Analysis of presently available technology to implement the project. Assessing the risks associated with the implementation of the technology especially while implementing new technology. Adopting technology that would reduce the cost of the finally built product. Imparting training about using the technology for team members who are new to the technology. Upgrading the implemented technology from time to time.

To Download : http://www.megaupload.com/?d=ZR8T8H2S

Procurement Management

Procurement management processes includes:

(a) Procurement Planning (b) Solicitation Planning (c) Solicitation (d) Source Selection (e) Contract Administration (f) Contract Close-out

(a) Procurement Planning: This involves taking decision on

                                                 • What to procure?

                                                 • What type of contract to use?

                                                 • Financial and organizations issues

(b) Solicitation Planning: Make or buy analysis is used for determining the cost effectiveness of procurement. PMs need to consult experts to assist them with the legal aspects of contracts. Decisions need to be made about appropriateness of the types of contracts e.g. fixed price contracts (more risk to seller), Cost reimbursable contracts (more risk to buyer), Unit price contracts (fixed price to seller and risks passed on to buyer). Solicitation planning includes:

• Writing the statement of work in sufficient details.

• Preparing procurement documents e.g. Request for proposal (RFP), Request for bid (RFB), Request for information (RFI).

• Developing source selection evaluation criteria.

(c) Solicitation: This involves:-

 • Finalizing procurement documents

• Advertising the work

• Providing clarifications

• Holding bidder’s conference

• Receiving proposal

(d) Source Selection: Source selection criteria cover:-

• Technical criteria

• Management criteria should also be given due importance

(e) Contract Administration: This involves:

• Finalizing and awarding the contract

• Monitoring performance

• Making contract modification (when required)

• Project members should be involved in writing and administering the contracts

(f) Contract Close-out: This include product verification and administrative close out e.g. formal acceptance, closure, contract file archiving.


To Download : http://www.megaupload.com/?d=VNDQJGO1

CE Charts

The main purpose of the CE diagram is to graphically represent the relationship between an effect and its various possible causes. The main steps in drawing a cause-effect diagram are as follows:-

(1) Clearly define the problem (the effect) to be studied. Here we can find the problems of particular types that are occurring in the system.

(2) We draw an arrow from left to right with a box containing the effect drawn at the head. This is the backbone of the diagram.

(3) We determine the major categories of causes. These could be the standard categories or some variation to suit the problem.

(4) We then write these major categories in boxes and connect them with diagonal arrows to the backbone.

(5) Then Brainstorm for the sub-causes of the major causes by asking repeatedly for each major cause “Why does this major cause produce the effect”?

(6) Then we add the sub-causes to the diagram clustered around the major cause. If necessary further we subdivided these causes & stop when no worthwhile answer to the question can be found.

To Download: http://www.megaupload.com/?d=EPT4KRIU

   

Statement of Work (SOW)

Sow describes all work products that will be produced and a list of people who will perform that work. It has a detailed description of all of the work products that will be created over the course of the project. A list of features that will be developed. A description of each intermediate deliverable or work product that will be built. 

COCOMO MODEL

The constructive Cost model (COCOMO) is an empirical estimation model i.e. the model uses a theoretically derived formula to predict cost related factors. This model was created by “Barry Boehm”. The COCOMO model consists of three models:-

(1) The Basic COCOMO Model: It computes the effort & related cost applied on the software development process as a function of program size expressed in terms of estimated lines of code (LOC or KLOC).

(2) The Intermediate COCOMO Model: It computes the software development effort as a function of – Program size and A set of cost drivers that include subjective assessments of product, hardware, personnel, and project attributes.

(3) The Advanced COCOMO Model: It incorporates all the characteristic of the intermediate version along with an assessment of cost driver’s impact on each step of software engineering process.

The COCOMO Model is defined for three classes of software projects stated as follows:-

(1) Organic Projects: These are relatively small and simple software projects which require small team structure having good application experiences.

(2) Semi-detached projects: These are medium size projects with a mix of rigid and less than rigid requirements level.

(3) Embedded Projects: These are large projects that have a very rigid requirement level. Here the 

hardware, software and operational constraints are of prime importance.

In below we will discuss only the Basic & intermediate COCOMO Models:

To Download: http://www.megaupload.com/?d=4GHKC51V

Waterfall Model

It is a simplest model, which states that the Phases are organized in a linear order. The model was originally proposed by “Royce”.

The various phases in this model are shown below:-

(1) Analysis Phase: It consists of planning and requirements definition activities. The end products of planning are – (a) System definition (b) project plan

(a) System definition – It is typically expressed in English. It incorporates charts, figure, graphs, tables and equation of various kinds.

(b) Project plan – It contains the life cycle model to be used, the preliminary development schedule, preliminary cost estimates and resources estimates, tools & technique to be used.

(2) Design Phase: This phase is concerned with – (a) identifying software components like functions, data streams and data stores, (b) Specifying software structures, (c) Maintaining a record of design decisions and providing blue prints for the implementation phase.

(3) Implementation Phase: It involves the translation of the design specifications into source code. It also involves activities like debugging, documentation and unit testing of the source code. In this stage various styles of programming can be followed like built-in and user defined data types, secure type checking, flexible scope rules, exception handling, concurrency constructs etc.

(4) System Testing Phase: It involves three kinds of activities: - (a) Unit testing (b) Integration testing (c) Acceptance testing

(a) Unit testing - Unit testing focuses on the smallest unit of software design i.e. the software component or module. Using the component-level design description as a guide, important control paths are tested to uncover errors within the boundary of the module. The unit test is white box oriented. Selective testing of execution paths is an essential task during the unit test. Boundary testing is the last and one of the most important tasks of the unit.

(b) Integration testing - Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure strictly as per design. The program is constructed and tested in small increments, where errors are easier to isolate and correct.

(c) Acceptance testing – Acceptance testing involves Planning & Execution of various types of tests in order to demonstrate that the implemented software system satisfies the requirements stated in the requirements document.

(5) Maintenance Phase: In this phase the activities include (a) Enhancement of Capabilities (b) Adaption of software to new processing environments and (c) Correction of software design. 

To Download: http://www.megaupload.com/?d=LXR3CR73

Pert

Pert is stand for “Project Evaluation Review Technique”. It is a technique of representing activities of project in its proper sequence & timing. Pert is methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program.

Terminologies used in PERT

(1) Pert Event: It is a point that marks the start or completion of one or more tasks. It consumes no time & uses no resources.

(2) Predecessor Event: An event that immediately precedes some other event without any intermediate events.

(3) Successor Event: An event that immediately follows some other event without any intermediate events.

(4) Pert Activity: It’s an actual performance of a task. It consumes time, it require resources (such as labors, materials, space, machinery etc).

(5) Optimistic time: The minimum possible time required to accomplish a task assuming nothing goes wrong.

(6) Pessimistic time: The maximum possible time required to accomplish a task assuming everything goes wrong.

(7) Most likely time: The best estimate of the time required to accomplish a task assuming everything goes normal.

Advantages of PERT:

(1) It helps us to estimate expected project completion time.

(2) It helps us to identify the critical path activities that directly impact the completion time.

(3) The start & end dates of the activities can be determined.

(4) The activities with slack time can be identified.

To Download: http://www.megaupload.com/?d=SIWNFU32

Project Charter

Project Charter will serve as an internal document that captures high level planning information (scope, deliverables, assumptions, etc.) about the Project. Its purpose is to recognize the existence of the project and to begin the planning process required to accomplish the Project goals.

Purpose of Project Charter

(1) Define project infrastructure (2) Summarize details of project plan

(3) Define roles and responsibilities (4) Show explicit commitment to project

(5) Set out project control mechanisms

Establish the project Charter:

(1) Vision: Write a concise vision statement that summarizes the purpose and intent of the project and describes what the world will be like when the project is completed. The vision statement should reflect a balanced view that will satisfy the needs of diverse customers as well as those of the developing organization.

(2) Objectives: Describe the important business objectives of the product in a way that is quantitative and measurable. These could include revenue increase, cost savings, return on investment, or target release dates. Determine how success will be defined and measured on this project.

(3) Scope: In Scope is what the project will include to meet the requirements of the Project goals. Out of Scope excludes responsibilities, activities, deliverables or other areas that are not part of the Project.

(4) Deliverables: Provide a high level list of “what” needs to be done in order to reach the goals of the project.  Each deliverable should be sufficiently detailed so that the Project Team will understand what needs to be accomplished.

 (5) Risks: Summarize the major risks associated with project, such as marketplace competition, timing issues, user acceptance, implementation issues, or possible negative impacts on the business.

Benefits of creating a charter include:

(1) Giving authority to project teams to commence work with official documented approval.

(2) Allowing senior management to set boundaries for the project scope.

(3) Formalizing partnerships.

(4) Helping project teams identify and plan for risks, increasing the chance of project success.

To Download: http://www.megaupload.com/?d=68GVZ8E1

Work breakdown structure (WBS)

A work breakdown structure (WBS) is a hierarchic decomposition or breakdown of a project or major activity into successive levels in which each level is a finer breakdown of the preceding one.

Major features of WBS: The major features of WBS is shown below:-

(1) Structure

   • WBS diagram is drawn like the organization chart.

   • Different desktop applications offer functionalities to easily create this kind of diagram.

(2) Classifications

There are two main classifications: (a) Product Hierarchy (b) Process Hierarchy

 (a) Product Hierarchy: It identifies the product components and indicates the manner in which the components are interconnected.

(b) Process Hierarchy: It identifies the work activities and the relationship between them.

(3) Description

• Each WBS element should be described with a title.

• The meaning of each title should be clear.

(4) Coding

• One of the main features of WBS is the ability to uniquely code the different elements of the work.

• The coding system can be alphabetic, numeric or alphanumeric.

(5) Depth

• The recommended depth of a WBS diagram is three to four levels.

                                                                                                              

Use of WBS: The potential uses of WBS include:-

• For dividing the project into phases.

• For dividing the project into responsibility areas within the organization.

• For dividing the schedule of the project into sub-schedule whose interrelation are known.

• For giving hierarchical outlining and coding for the work to be done.

To Download: http://www.megaupload.com/?d=4NZZTCYQ

Critical Path Method (CPM)

CPM uses activity oriented network which consist of a number of well recognized jobs, tasks or activities. Each task/activity is represented by arrow and the activities are joined together by events. CPM is generally used for simple, repetitive types of projects for which the activities time & costs are certainly and precisely known. Projects like construction of a building, road, bridge, physical verification of store can be handled by CPM. Thus it is Deterministic rather than Probabilistic model. 

Steps in CPM technique:

Step 1: Specify the individual activities                                                                                                          

A listing of all the activities in the project is made from the WBS (work breakdown structure).

Step 2: Determine the sequence of those activities

Some activities depend on others for their completion. They need to be identified.

Step 3: Draw a Network diagram

Once the activities & their sequencing have been defined the CPM diagram can be drawn.

Step 4: Estimate the completion time for each Activity

For each activity the completion time need to be estimated. This can be done on the basis of past experience.

Step 5: Identify the Critical path

The critical path is the longest duration path through the network where no activity is slack. The critical path can be identified by determining the following four parameters for each activity:

(a) Earliest start time (ES) – Earliest time at which the activity can start given that its previous activities must be completed first.

(b) Earliest finish time (EF) – It is equal to the earliest start time for the activity plus the time required to complete the activity.

(c) Latest finish time – The latest time at which the activity can be completed without delaying the project.

(d) Latest start time – It is equal to the latest finish time minus the time required to complete the activity.

Advantages of CPM:

(1) The activities & their outcomes can be shown as a network.

(2) It displays dependencies to help scheduling.

(3) It determines slack time.

(4) It evaluates which activities can run parallel to each other.

(5) It determines the project duration which optimizes both direct & indirect costs.

(6) If properly developed & applied CPM can encourage a team feeling.

(7) They are useful in new project managers.

(8) It is widely used in industry.

Disadvantage of CPM:

(1) The critical path is not always clear & needs to be calculated carefully.

(2) Estimating the completion of an activity can be difficult.


To Download: http://www.megaupload.com/?d=O57CQ2FV

Gantt Charts

The brief description of Gantt charts are shown below:-

(1) A Gantt chart is a graph of activities against time. It is the most effective way to present a project’s plan and its progress.

(2) A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt chart illustrates the start and finish dates of the tasks (activity) in a project.

(3)The task list comes from the Work breakdown structure of the project.

(4) Some Gantt charts also show the dependency relationships between activities.

(5) Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical “Today” line.

(6) A Gantt chart can indicate:

• Milestones • Slack time • Activities on the critical path

(7) Once the project has started, the Gantt chart can also show:

• Activities that have started and their actual start dates.

• Activities that have finished and their actual completion dates.

• Revised milestone and activity dates.

• Revised slack time and critical path.

• Actual performance compared to the original plan.

(8) Dependency relationship between activities is represented as follows:

(9) Simple Gantt chart is shown in below figure:

                                                                                           

Reasons to use GANTT CHARTS

Gantt charts are convenient means of representing graphically schedules, appointments and events such charts help members of an organization to plan activities better.

Information about “WHAT” is happening, “WHERE” is happening and “WHO” will be present is valuable to concerned people in the organization.

It is good because:

• It plots activities as bars on time scale.

• It indicates different: Activities, Responsibilities, Estimated or Planned activities start and target dates.

• Actual start and target dates.

• It aids in: Scheduling activities, Coordinating activities, Evaluating progress, Reallocating resources in case of problems.

Advantages of GANTT CHARTS

(1) Gantt charts are relatively easy to create and maintain.

(2) Able to reflect the status of each project task at any point in time.

(3) Able to represent overlapping or parallel tasks.

Disadvantages of GANTT CHARTS

(1) Does not show a task interrelationship.

(2) These are not ideal project control.

To Download: http://www.megaupload.com/?d=JUMMJWSE

Types of Risk

(1) Project Risk – Project risk threaten the project plan. Project risk identifies potential budgetary, schedule, personnel (Staffing & organization), resources, customer, and requirement problem and their impact on a software project.

(2) Technical Risk – Technical risks threaten the quality and timeliness of the software to be produced. They include: Implementation problem, Design problem, Maintenance problems, Interfacing problems and technical obsolescence.

(3) Business Risk – Business risk threaten the viability of the software to be built. Candidates for the top five business risks are: (a) Market risk – Where the product is not required in the market (b) Strategic Risk – Where the product does not fill the business strategy of the customer (c) Management Risk – Where the management is no more interested in the project due to change in focus or people of management (d) Budget Risk – Where the management or control on budgetary is lost and at-last (e) Sales Risk – Where the sales force does not find the appropriate & effective method to sell the product.

(4) Known Risk – Known risk are those that can be un-covered after careful evaluation of the project plan.

(5) Predictable Risk – Predictable risks are extrapolated from past experiences (e.g. staff turnover, poor communication with the customer etc).

(6) Un-Predictable Risk – Un-Predictable risks are the joker in the deck. They are extremely difficult to identify in advance. For this kind of risk, reactive risk management strategy needs to be taken.   

To Download: http://www.megaupload.com/?d=DSR858I3                                                         

Software Configuration Management

Software configuration Management (SCM) is an umbrella activity that is applied throughout the software process, because change can occur at any time.

Software Configuration Management (SCM) Process

The Five basic SCM tasks are:                                                             

(1) Identification of Object (2) Version Control (3) Change control (4) Configuration auditing and (5) Reporting

(1) Identification of Object – To control and mange SCIs each of them must be separately named and then organized using object-oriented approach. The SCIs can be classified in to two kinds of objects—(A) Basic objects & (B) Aggregate objects

(A) Basic objects: It is a “unit of text” created by software engineer during analysis, design, coding or testing phases.

(B) Aggregate objects: It’s a collection of basis objects and other aggregate objects.

For example – Design specification is an aggregate object.Each object has a set of unique features for distinct identification. Every object should have :- (a) An unique name (b) A description of the object including its SCI type e.g. Document, program, or data, a project identifier and version information (c) A list resources, which are entities that are processed, provided or required by the project.

(2) Version Control – It combines various tools and procedures to manage and control different versions of SCI objects that are created during the software engineering process.

(3) Change control – Change control includes human procedures and automated tools to control the reasons for change. The following processes take place when a situation of change occurs:

(A) Change Request: A change request is first submitted and then it is evaluated to asses its--- Technical merits, Potential side effects, Subsystem and the cost for implementing the change.

(B) Change Report: After the evaluation is done, a change report is created that is submitted to the change control Authority/Board (CCA/CCB). CCA or CCB is a group who are responsible for evaluating the change report and makes the final decisions on the status and priority of the change. This group generates an Engineering Change Order (ECO) for each approved change.Engineering Change Order (ECO) – It consist of the following:

* The description of the change to be made

* Constraints that has to be taken care of and

* Criteria for review and audit

(C) Check Out & Check In: The object to be changed is “checked out” of the project database, the decided changes are made and appropriate SQA (Software Quality Assurance) activities are performed. The object is then “checked in” the project database and appropriate version control mechanisms are used to create the next version of the software.

(4) Formal technical reviews (FTR) & Configuration auditing – These two activities are required to ensure that the change made to the software is properly implemented.Formal technical review is apart of software Quality Assurance (SQA) procedures. The objectives of FTR are:

* To uncover errors in functions, logic or implementation

* To verify that the software under review should meet its requirement

* To make the project more manageable

* It consists of walkthroughs, inspection and round-robin procedures

Software configuration audit consists of the following auditing procedures:

* To check whether the changes specified in the ECO (Engineering Change Order) has been properly made and to check if any additional modules are added.

* To check whether formal technical reviews are conducted for the assessment of technical correctness.

* To check whether SE standards are properly followed.

* To check whether the change is highlighted in the SCI (Software Configuration Items).

* To check whether all the related SCIs are properly updated.

(5) Configuration Status Reporting (CSR) – It’s an SCM task which summarizes the activities done so far which includes the following:

(a) The report of all the activities done.

(b) The report on the persons involved in the above reported activities.

(c) The report on the time and date when the reported activities were accomplished.

(d) The report on various other factors or objects that will be affected due to the reported activity.


To Download: http://www.megaupload.com/?d=7OBXU6TG

Risk Management

Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. A risk is a potential---it might happen, it might not. In ideal risk management, a prioritization process is followed whereby the risk with the greatest loss and the greatest probability of occurring are handled first and risks with lower loss and lower probability of occurring are handled in descending order.

Principle of Risk Management

(1) Risk management should create value.

(2) Risk management should be an integrate part of organizational processes.

(3) Risk management should be part of decision making.

(4) Risk management should be systematic and structured.

(5) Risk management should be based on the best available information.

(6) Risk management should be transparent and inclusive.

(7) Risk management should be tailored.

(8) Risk management should be dynamic, iterative and responsive to change.

Risk Management Strategy – There are to types of Risk management strategies:

(a) Reactive risk Strategy: Reactive risk Strategies follows that the risks have to be tackled at the time of their occurrence. No precautions are to be taken as per this strategy. They are meant for risks with relatively smaller impact.

(b) Proactive risk strategy: Proactive risk strategies follows that the risks have to be identified before start of the project. They have to be analyzed by assessing their probability of occurrence, their impact after occurrence and steps to be followed for its precaution. They are meant for risks with relatively higher impact.    

To Download: http://www.megaupload.com/?d=7269JQUB                                                        

Risk Identification

Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading etc).

Methods used for Risk identification under Risk management One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic categories:

Product Size – Risks associated with the overall size of the software to be built or modified.

Business Impact – Risks associated with constraints imposed by management or the marketplace.

Customer Characteristics – Risks associated with the sophistication of the customer and the developer’s ability to communicate with the customer in a timely manner.

Process Definition – Risks associated with the degree to which the software process has been defined and is followed by the development organization.

Development Environment - Risks associated with the availability and quality of the tools to be used to build the product.

Technology to be built - Risks associated with the complexity of the system to be built and the “newness” of the technology that is packaged by the system.

Staff size and Experience - Risks associated with the overall technical and project experiences of the software engineers who will do the work.


To Download: http://www.megaupload.com/?d=YPSOCIZY