7. project cost management · •explain basic project cost management principles, concepts, and...

7. Project cost management

2 Information Technology Project

Management, Fourth Edition

Learning Objectives

• Understand the importance of project cost management.

• Explain basic project cost management principles, concepts, and terms.

• Discuss different types of cost estimates and methods for preparing them.



Learning Objectives

• Understand the processes involved in cost budgeting and preparing a cost estimate and budget for an information technology project.

• Understand the benefits of earned value management and project portfolio management to assist in cost control.

• Describe how project management software can assist in project cost management.



The Importance of Project Cost Management

• IT projects have a poor track record for meeting budget goals.

• The 2003 CHAOS studies showed the average cost overrun (the additional percentage or dollar amount by which actual costs exceed estimates) was 43 percent.

• U.S. lost $55 billion in IT projects in 2002 from cancelled projects and overruns compared to $140 billion in 1994.*

*The Standish Group, “Latest Standish Group CHAOS Report Shows Project Success Rates Have

Improved by 50%,” A Standish Group Research Note (3/25/03).



What Went Wrong?

According to the San Francisco Chronicle’s front-page story, “Computer Bumbling Costs the State $1 Billion,” the state of California had a series of expensive IT project failures in the late 1990s, costing taxpayers nearly $1 billion…It was ironic that the state that was leading in the creation of computers was also the state most behind in using computer technology to improve its services.* The Internal Revenue Service (IRS) managed a series of project failures that cost taxpayers over $50 billion a year—roughly as much money as the annual net profit of the entire computer industry.** Connecticut General Life Insurance Co. sued PeopleSoft over an aborted installation of a finance system.*** *Lucas, Greg, “Computer Bumbling Costs the State $1 Billion,” San Francisco Chronicle (2/21/99). **James, Geoffrey, “IT Fiascoes . . . and How to Avoid Them,” Datamation (November 1997). ***Songini, Marc L., “PeopleSoft project ends in court,” ComputerWorld (September 2001).



What is Cost and Project Cost Management?

• Cost is a resource sacrificed or foregone to achieve a specific objective, or something given up in exchange.

• Costs are usually measured in monetary units, such as dollars.

• Project cost management includes the processes required to ensure that the project is completed within an approved budget.



Project Cost Management Processes

• Cost estimating: Developing an approximation or estimate of the costs of the resources needed to complete a project.

• Cost budgeting: Allocating the overall cost estimate to individual work items to establish a baseline for measuring performance.

• Cost control: Controlling changes to the project budget.



Basic Principles of Cost Management

• Most members of an executive board have a better understanding and are more interested in financial terms than IT terms, so IT project managers must speak their language.

– Profits are revenues minus expenses.

– Life cycle costing considers the total cost of ownership, or development plus support costs, for a project.

– Cash flow analysis determines the estimated annual costs and benefits for a project and the resulting annual cash flow.



Table 7-1. Cost of Software Defects*

It is important to spend money up-front on IT projects to avoid spending a lot more later.

*Collard, Ross, Software Testing and Quality Assurance, working paper (1997).



Basic Principles of Cost Management • Tangible costs or benefits are those costs or benefits that an

organization can easily measure in dollars.

• Intangible costs or benefits are costs or benefits that are difficult to measure in monetary terms.

• Direct costs are costs that can be directly related to producing the products and services of the project.

• Indirect costs are costs that are not directly related to the products or services of the project, but are indirectly related to performing the project.

• Sunk cost is money that has been spent in the past; when deciding what projects to invest in or continue, you should not include sunk costs.



Basic Principles of Cost Management

• Learning curve theory states that when many items are produced repetitively, the unit cost of those items decreases in a regular pattern as more units are produced.

• Reserves are dollars included in a cost estimate to mitigate cost risk by allowing for future situations that are difficult to predict.

– Contingency reserves allow for future situations that may be partially planned for (sometimes called known unknowns) and are included in the project cost baseline.

– Management reserves allow for future situations that are unpredictable (sometimes called unknown unknowns).



Cost Estimating

• Project managers must take cost estimates seriously if they want to complete projects within budget constraints.

• It’s important to know the types of cost estimates, how to prepare cost estimates, and typical problems associated with IT cost estimates.



Table 7-2. Types of Cost Estimates



Cost Management Plan

• A cost management plan is a document that describes how the organization will manage cost variances on the project.

• A large percentage of total project costs are often labor costs, so project managers must develop and track estimates for labor.



Table 7-3. Maximum Departmental Headcounts by Year

A large percentage of the costs of many IT projects are human resource costs.



Cost Estimation Tools and Techniques • Basic tools and techniques for cost estimates:

– Analogous or top-down estimates: Use the actual cost of a previous, similar project as the basis for estimating the cost of the current project.

– Bottom-up estimates: Involve estimating individual work items or activities and summing them to get a project total.

– Parametric modeling: Uses project characteristics (parameters) in a mathematical model to estimate project costs.

– Computerized tools: Tools, such as spreadsheets and project management software, that can make working with different cost estimates and cost estimation tools easier.



Constructive Cost Model (COCOMO)

• Barry Boehm helped develop the COCOMO models for estimating software development costs.

• Parameters include:

– Function points: Technology-independent assessments of the functions involved in developing a system.

– Source Lines of Code (SLOC): A human-written line of code that is not a blank line or comment.

• Boehm suggests that only parametric models do not suffer from the limits of human decision-making.



Typical Problems with IT Cost Estimates

• Developing an estimate for a large software project is a complex task that requires a significant amount of effort.

• People who develop estimates often do not have much experience.

• Human beings are biased toward underestimation.

• Management might ask for an estimate, but really desire a bid to win a major contract or get internal funding.



Sample Cost Estimate

• See pages 262-266 for a detailed example that describes how to create a cost estimate for the Surveyor Pro project described in the opening case.

• Before creating an estimate, know what it will be used for, gather as much information about the project as possible, and clarify the ground rules and assumptions for the estimate.

• If possible, estimate costs by major WBS categories.

• Create a cost model to make it easy to change and document the estimate.



Figure 7-1. Surveyor Pro Project Cost Estimate



Figure 7-2. Surveyor Pro Software Development Estimate



Cost Budgeting

• Cost budgeting involves allocating the project cost estimate to individual work items over time.

• The WBS is a required input for the cost budgeting process because it defines the work items.

• Important goal is to produce a cost baseline:

– A time-phased budget that project managers use to measure and monitor cost performance.



Figure 7-3. Surveyor Pro Project Cost Baseline



Cost Control

• Project cost control includes:

– Monitoring cost performance.

– Ensuring that only appropriate project changes are included in a revised cost baseline.

– Informing project stakeholders of authorized changes to the project that will affect costs.

• Many organizations around the globe have problems with cost control.



Media Snapshot • Australia: Problems with the installation of an ERP system at Crane Group

Ltd. led to an estimated cost overrun of $11.5 million.*

• India: As many as 274 projects currently under implementation in the Central sector are suffering serious cost and time overruns.**

• Pakistan: Pakistan has sustained a cost overrun of Rs 1.798 billion (over $30 million U.S. dollars) in the execution of the 66.5 megawatt Jagran Hydropower Project in the Neelum Valley.***

• United States: Northern California lawmakers were outraged over Governor Arnold Schwarzenegger's announcement that commuters should have to pay construction costs on Bay Area bridges. Maybe it takes the Terminator to help control costs!****

*Songini, Marc L., “Australian Firm Wrestles With ERP Delays,” ComputerWorld (July 12, 2004).

**Srinivasan, G., “274 Central sector projects suffer cost, time overruns,” The Hindu Business Line (May 4, 2004).

***Mustafa, Khalid, “Rs 1.8 billion cost overrun in Jagran hydropower project,” Daily Times (November 19, 2002).

****Gannett Company, “Governor Refuses to Pay for Bay Bridge Cost Overruns,” News10 (August 17, 2004).



Earned Value Management (EVM)

• EVM is a project performance measurement technique that integrates scope, time, and cost data.

• Given a baseline (original plan plus approved changes), you can determine how well the project is meeting its goals.

• You must enter actual information periodically to use EVM.

• More and more organizations around the world are using EVM to help control project costs.



Earned Value Management Terms • The planned value (PV), formerly called the budgeted cost of work

scheduled (BCWS), also called the budget, is that portion of the approved total cost estimate planned to be spent on an activity during a given period.

• Actual cost (AC), formerly called actual cost of work performed (ACWP), is the total of direct and indirect costs incurred in accomplishing work on an activity during a given period.

• The earned value (EV), formerly called the budgeted cost of work performed (BCWP), is an estimate of the value of the physical work actually completed.

• EV is based on the original planned costs for the project or activity and the rate at which the team is completing work on the project or activity to date.



Rate of Performance • Rate of performance (RP) is the ratio of actual work

completed to the percentage of work planned to have been completed at any given time during the life of the project or activity.

• Brenda Taylor, Senior Project Manager in South Africa, suggests using this approach for estimating earned value.

• For example, suppose the server installation was halfway completed by the end of week 1. The rate of performance would be 50 percent (50/100) because by the end of week 1, the planned schedule reflects that the task should be 100 percent complete and only 50 percent of that work has been completed.



Table 7-4. Earned Value Calculations for One Activity After Week One



Table 7-5. Earned Value Formulas



Rules of Thumb for Earned Value Numbers

• Negative numbers for cost and schedule variance indicate problems in those areas.

• A CPI or SPI that is less than 100 percent indicates problems.

• Problems mean the project is costing more than planned (over budget) or taking longer than planned (behind schedule).



Figure 7-4. Earned Value Calculations for a One-Year Project After Five Months



Figure 7-5. Earned Value Chart for Project after Five Months

If the EV line is below the AC or PV line, there are problems in those areas.



Project Portfolio Management • Many organizations collect and control an entire

suite of projects or investments as one set of interrelated activities in a portfolio.

• Project portfolio management has five levels: 1. Put all your projects in one database. 2. Prioritize the projects in your database. 3. Divide your projects into two or three budgets based

on type of investment. 4. Automate the repository. 5. Apply modern portfolio theory, including risk-return

tools that map project risk on a curve.



Benefits of Portfolio Management • Schlumberger saved $3 million in one year by organizing 120

information technology projects into a portfolio.

• META Group research shows that: – Organizations that evaluate information technology projects by

what their business impacts are and what their potential business values will be implement projects that result in 25 percent more improvement to the bottom line.

– By 2005-2006, more than 50 percent of the CIOs for Global 2000 companies will adopt project portfolio management tools and techniques for IT projects, asset management, and budget planning and monitoring.

– Business executives state that using project portfolio management allows managers to make decisions faster and with more confidence.*

*META Group, “IT Investment Management: Portfolio Management Lessons Learned,” A META Group White Paper (www.metagroup.com) (2002).



Using Software to Assist in Cost Management

• Spreadsheets are a common tool for resource planning, cost estimating, cost budgeting, and cost control.

• Many companies use more sophisticated and centralized financial applications software for cost information.

• Project management software has many cost-related features, especially enterprise PM software.



Figure 7-6. Sample Project Portfolio Management Screen Showing Project Health



Chapter Summary

• Project cost management is traditionally a weak area in IT projects, and project managers must work to improve their ability to deliver projects within approved budgets.

• Main processes include:

– Cost estimating

– Cost budgeting

– Cost control

8. PROJECT QUALITY MANAGEMENT

63,000 known bugs in Windows 2000?

• In February 2000, a Microsoft Corp memo caused quite a stir when it was leaked to the public. An excerpt from that memo reads

“Our customers do not want us to sell them products with over 63,000 potential defects. They want those defects corrected. How many of you would spend $500 on a piece of software with over 63,000 potential known defects?”

Uniform Computer Information Transactions Act (UCITA)

• A software vendor could legally disclaim any obligation to sell products that work.

• In the event of a dispute, a software vendor could disable a customer’s software remotely – even if it totally disrupted the customer’s business.

• Security experts would be prohibited from reverse engineering software in order to examine it for defects and viruses.

• A software vendor could legally stop a user from making public comments on the quality or performance of a product.

Project Quality Management (PQM) - PMBOK®

• 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 responsibility and implements them by means of quality planning, quality assurance, quality control, and quality improvement within the quality system.

PMBOK® – Project Quality Management Process

• Quality Planning – Determining which quality standards are

important and how they will be met.

• Quality Assurance – Evaluating overall project performance to ensure

quality standards are being met.

• Quality Control – Monitoring the activities and results of the project

to ensure that the project complies with the quality standards.

PQM Focuses on

• The project’s products – Business Case

– Project Plan

– The IT Solution

– Etc.

• And the project’s processes – Scope management

– Risk management

– Requirements Analysis

– Design

– Implementation

– Etc.

The Quality Chain

Project and IT development processes support the project’s products Customers may be internal or external

More efficient & effective use of resources Minimize errors Meet or exceed stakeholder expectations

More rework, waste, & errors Negative impact on project goal & objectives Poor quality can be an embarrassment!

Project Quality Management

Figure 10.1

The Quality Movement

• Early humankind – Quality = Survival

• Craftsmanship – In the middle ages guilds regulated:

• Who could sell what in a particular town

• Ensured standardized pricing and quality

• Supported members & their families when members could no longer work

• Regulated forms of labor – Masters – owned the shop

– Apprentices – were bound to a master & learned the trade

– Journeymen – completed training & waited for a job opening!


• The Industrial Revolution

– Eli Whitney (1765 – 1825) • Invented the cotton gin

• But also invented mass production

– In 1798 received $134,000 from the US Government to deliver 10,000 rifles within 2 years

– Shortage of gunsmiths

– Developed the manufactory where machines could build interchangeable parts and men could learn to operate the machines

– Took 10 years to deliver the last rifle, but proved that the concept worked!


• Scientific Management - Fredrick W. Taylor (1856 – 1915) – Management would set arbitrary rules of thumb

• Workers produced so much each day – no more, no less

– Believed the production process could be more efficient and employed “Scientific Management”

• Break a task down into smaller tasks & study it to find the best and most efficient way of doing it

• Time – motion studies using stopwatch

– Did not sit well with labor unions because many ignored the human factors & believed profits could be increased by speeding up the workers


• Walter A. Shewhart (1891 – 1967)

– Worked for Western Electric Company (Bell Telephones

– Quality improvements needed for underground equipment

– Applied statistical theory to control production processes

Control Chart for a Process within Statistical Control

Control Chart for a Process Not in Statistical Control

Figure 10.2


• The Rise of Japan – W. Edwards Deming (1900 – 1993)

• Worked with Shewhart at Western Electric Hawthorne Plant in Chicago, IL in the 1920s

• Management treated the worker as a cog in the machinery

• Final inspection used to control quality – Worker not directly responsible

– Scrap & rework reduced per piece rate

• Invited to give series of day-long lectures in Japan in the 1950s

• The rest is history…

Deming’s 14 Points

1. Have a purpose (improve products and services, be competitive, stay in business, and provide jobs).

2. Adopt the new philosophy of management.. 3. Don’t depend on inspection at the end. 4. Don’t award business based on price alone of price. 5. Keep improving constantly. 6. Institute training on the job. 7. Institute leadership 8. Drive out fear. 9. Break down barriers between departments. 10. Eliminate slogans. 11. a) Eliminate quotas b) Eliminate management by objective and by numbers. 12. Take pride in your work. 13. Focus education and self-improvement. 14. It takes everyone to accomplish the transformation. From Out of the Crisis by W. Edwards Deming (1986)


• The Rise of Japan continued

– Joseph Juran (1904 - )

• Viewed quality as “fitness for use”

• Also invited to Japan to conduct seminars in the 1950s

• Message is that quality does not happen by accident – it must be planned.


• Juran’s Quality Planning Road Map (Quality Trilogy) – Quality Planning

1. Identify who the customers are.

2. Determine the needs of those customers.

3. Translate those needs into our language.

4. Develop a product that can respond to those needs.

5. Optimize the product features so as to meet our needs as well as customer needs.

– Quality Improvement 6. Develop a process that is able to produce the product.

7. Optimize the process.

– Quality Control 8. Prove that the process can produce the product under operating conditions.

9. Transfer the process to Operations.


• The Rise of Japan continued

– Kaoru Ishikawa (1915 - 1989)

• Studied under Deming

• Believes quality is a continuous process that relies on all levels of the organization

• Advocated the use of easy-to-use statistical tools – Ishikawa, or Fishbone Diagram

– Pareto Diagram

– Flow Charts

Ishikawa, or Fishbone Diagram

Figure 10.4

Pareto Chart

Figure 10.5

Flow Chart for Project Scope Verification

Figure 10.6


• Philip Crosby (1926 – 2001)

– Advocated

• “Do it right the first time”

• “Zero defects”

• “Quality is free”

• “Non-conformance costs organizations money”

Quality Systems

• International Organization for Standardization (ISO) – Derived from Greek word “isos,” meaning equal

– Formed in 1947

– Today has over 130 members “to facilitate the international coordination and unification of industrial standards.”

– Standards make up the ISO 9000 (organizations) and ISO 14000 (environmental) families

Quality Systems ISO 9000 Principles

• Customer Focus

• Leadership

• Involvement of People

• Process Approach

• System Approach to Management

• Continual Improvement

• Factual Approach to Decision Making

• Mutually Beneficial Supplier Relationships

Quality Systems 6 Sigma

• Six Sigma framework (D-M-A-I-C cycle)

– Define

– Measure

– Analyze

– Improve

– Control

Quality Systems 6 Sigma

• Originated by Motorola in Schaumburg, IL

• Based on competitive pressures in 1980s – “Our quality stinks”

Sigm

a

Defects Per

Million

1 δ 690,000

2 δ 308,537

3 δ 66,807

4 δ 6,210

5 δ 233

6 δ 3.4

3 δ 6 δ

Five short or long landings at any

major airport

One short or long landing in 10

years at all airports in the US

Approximately 1,350 poorly

performed surgical operations in

one week

One incorrect surgical operation in

20 years

Over 40,500 newborn babies

dropped by doctors or nurses each

year

Three newborn babies dropped by

doctors or nurses in 100 years

Drinking water unsafe to drink for

about 2 hours each month

Water unsafe to drink for one

second every six years

Six Sigma Programs

• Master Black Belts – Have the highest level of technical and organizational experience and

expertise who train Six Sigma Black Belts

• Black Belts – Come from various disciplines, have a high degree of experience and

expertise and are held in high esteem

• Green Belts – Six Sigma leaders or project managers

• Champions – An added role in many organizations. They are leaders who are

committed to the success of the Six Sigma project, provide funding, and can ensure organizational barriers and obstacles are removed

Quality Systems TickIT

• Quality initiative initiated by the British Computer Society (BCS) in 1991

• Software organizations were reluctant to adopt ISO 9000 standards – Too general & too difficult

• TickIT guides a company through ISO certification by an independent certification body

• TickIT gives software developers an accredited quality certification specialized for software organizations to increase the confidence of customers and suppliers

Quality Systems The Capability Maturity Model Integration

(CMMI)

• Software Engineering Institute (SEI) at Carnegie-Mellon University

• Includes a set of recommended practices for a set of key process areas specific to software development.

• Provide guidance as to how an organization can best control its processes for developing and maintaining software.

• Provide a path for helping organizations evolve their current software processes toward software engineering and management excellence

CMMI

• Software Process – The logical organization of people, materials, energy, equipment, and

procedures into work activities to produce a specified end result

• Software Process Capability – The expected results that can be achieved by following a particular

software process that can be used to predict the outcome if a software process is followed

• Software Process Performance – The actual results achieved when a particular software process is

followed so that actual performance can be compared to expected results

• Software Process Maturity – The extent to which a particular software process is explicitly and

consistently defined, managed, measured, controlled, and effectively used

Quality Systems CMMI

• Immature Software Organization – Reactive in nature - Managers continually “fight fires”

– Schedules & budgets are usually exceeded

– Functionality & quality often compromised to meet schedules

– Project success determined by who is or is not part of the project team

– No basis for judging quality

– Never seems to be enough time to address problem issues or improve the current processes

Quality Systems CMMI

• Mature Software Organization – Proactive and able to follow a set of disciplined processes throughout

the software project.

– Software processes and the roles of individuals are defined explicitly and communicated throughout the organization.

– Software processes are consistent throughout the organization and continually improved based on experimentation or experiences.

– Quality of each software process is monitored so that the products and processes are predictable across different projects.

– Budgets and schedules are based on past projects so they are more realistic and the project goals and objectives are more likely to be achieved.

Maturity Levels

• Maturity levels lay successive foundations for continuous improvement

• Can measure the maturity of an organization’s software process

• Can evaluate its software process capability

• Help prioritize improvement efforts

Levels of Software Process Maturity

Figure 10.7

Quality Systems

CMMI • Level 1: Initial

– Characterized by an immature software organization in which the software process is ad hoc and often reactive to crises. Does not have a stable environment for software projects, and success of a project rests largely with the people on the project and not the processes that they follow.

– Key Process Area • no key process areas are in place

Quality Systems

CMMI

• Level 2:

– Repeatable - Basic policies, processes, and controls for managing a software project are in place. Previous project successes can be repeated by other project teams on other projects.

– Key Process Area • Software Configuration Management

• Software Quality Assurance

• Software Subcontract Management

• Software Project Tracking and Oversight

• Software Project Planning

• Requirements Management

Quality Systems

CMMI

• Level 3: – Defined - Software engineering and management processes are

documented and standardized throughout the organization and become the organizations standard process.

– Key Process Area • Peer Reviews

• Intergroup Coordination

• Software Product Engineering

• Integrated Software Management

• Training Programs

• Organization Process Definition

• Organization Process Focus

Quality Systems

CMMI

• Level 4:

– Managed - Quantitative metrics for measuring and assessing productivity and quality are established for both software products and processes which are characterized as being quantifiable and predictable.

– Key Process Areas

• Software Quality Management

• Quantitative Process Management

Quality Systems

CMMI

• Level 5:

– Optimizing at the highest level of software process maturity- the whole organization is focused on continuous process improvement.

– Key Process Areas

• Process Change Management

• Technology Change Management

• Defect Prevention

The IT Project Quality Plan

Figure 10.8

• Focus on customer satisfaction

• Prevention not inspection

• Improve the process to improve the product

• Quality is everyone’s responsibility

• Fact-based management


Quality Philosophies and Principles


Quality Standards and Metrics

Figure 10.9

Project Quality Metrics

• Process

– Control the defects introduced by the processes required to create the project deliverables

– Can be used to improve software development or maintenance

– Should focus on the effectiveness of identifying and removing defects or bugs


• Product

– Focuses on the intrinsic quality of the deliverables and satisfaction of the customer, client, or sponsor with these deliverables

– Attempt to describe the characteristics of the project’s deliverables and final product


• Project

– Focus on the control of the project management processes to ensure that the project meets its overall goal as well as its scope, schedule, and budget objectives

Examples of Process, Product, & Project Metrics Type Metric Description

Process Defect Arrival Rate The number of defects found over a specific period of time.

Defects by Phase The number of defects found during each phase of the project.

Defect Backlog The number of defects waiting to be fixed.

Fix Response Time The average time it takes to fix a defect.

Defective Fixes The number of fixes that created new defects.

Product Mean Time to Failure Average or mean time elapsed until a product fails.

Defect Density The number of defects per lines of code (LOC) or function points.

Customer Found Defects The number of defects found by the customer.

Customer Satisfaction An index to measure customer satisfaction – e.g., scale from 1

(very unsatisfied) to 5 (very satisfied)

Project Scope Change Requests The number of scope changes requested by the client or sponsor.

Scope Change Approvals The number of scope changes that were approved.

Overdue tasks The number of tasks that were started but not finished by the

expected date or time.

Tasks that should have started The number of task that should have started but have been

delayed.

Over budgeted tasks The number of tasks (and dollar amount) of tasks that have cost

more to complete than expected

Earned Value Budgeted Cost of Work Performed (BCWP) – see Chapter 8.

Over allocated Resources The number of resources assigned to more than one task.

Turnover The number of project team members who quit or terminated.

Training Hours The number of training hours per project team member.


Verification and Validation • Verification

– Focuses on process-related activities to ensure that the products & deliverables meet specified requirements before final testing

– Are we building the product the right way?

Verification • Technical Reviews

– Ensure that the IT solution will conform to the specified requirements – Walk-through’s are review process where a programmer or developer “walks”

or leads a group of other programmers or developers through a program or technical design

• Business Reviews – Are designed to ensure that the IT solution provides the required

functionality defined in the project scope and detailed requirements definition to ensure that a particular project deliverable

• Is complete • Provides information necessary for the next phase or process • Meets predefined standards • Conforms to the project (and software development) methodology

• Management Reviews – Compares the project’s actual progress against the baseline project

plan – Useful for resolving issues or making critical decisions – Usually focuses on the project’s scope, schedule, budget, and quality

objectives


Verification and Validation

• Validation focuses on

– Product-oriented activities that attempt to determine if the system or project deliverables meet the customer or client’s expectations

– Testing • Does the system function as intended and have all the capabilities &

features defined in the project’s scope and requirements definition?

Software Testing Approaches Unit Testing Focuses on the module, program, or object level to determine whether

specific functions work properly.

•Black Box Testing – Tests the program against specified requirements or

functionality.

•White Box Testing – Examines paths of logic or the structure inside a

program.

•Gray Box Testing – Focuses on the internal structure of the program.

Integration

Testing

Tests whether a set of logically related units (e.g., functions, modules,

programs, etc.) work together properly after unit testing is complete.

Systems

Testing

Tests the system as a whole in an operating environment to verify

functionality and fitness for use. May include tests to verify usability,

performance, stress, compatibility, and documentation.

Acceptance

Testing

Certifies that the system satisfies the end user or customer’s scope and

detailed requirements after systems testing is complete. It is the user’s or

client’s responsibility to assure that all features and functionality are

included so that the project’s MOV will be achieved.


Change Control and Configuration Management

• Change is inevitable throughout the project life cycle

• At some point, changes must be managed

– What changes were made?

– Who made the changes?

– When were the changes made?

– Why were the changes made?


Change Control and Configuration Management

• Component Identification

– Naming conventions

• Version Control

– Evolutionary changes

• Configuration Building

– Builds & Releases

• Change Control

– Proposed changes are evaluated, approved or rejected, scheduled, and tracked

– Reporting & auditing

Monitor and Control

Quality Control Activities

Figure 10.10

Quality Control Activities should focus on the inputs and outputs of each process. This can be viewed in terms of the systems concept.

Quality Control

Tools

Figure 10.11

Many of the tools introduced in this chapter are useful for monitoring and controlling the quality control activities of the project.

Learn, Mature, and Improve

• Lessons learned

– Provide the basis for continual improvement

– Can be the basis for identifying and implementing best practices

A quality plan should do more that attempt to build a better IT solution, it should also support the organization in searching for ways to manage projects better.

7. project cost management · •explain basic project cost management principles, concepts, and...

Documents