Managing Projects

1, Identify the Problem

2, Defining a Software Development Process
3, Understanding the Customer’s Problem to Solve (HML, LIS, QFD , AHP)
4, Communicating in Harmony
5, Project Schedule Planning
6, Project Tracking: PTT Meeting
7, Development Testing
8, Vendor Relationships
9, Postproject Review: Understanding the Past to Improve the Future

Prepared by: Linsen

2000,3,9
 Identify the Problem

Project Problem:
• Slipping their schedules
• Overrunning their budget
• Compromising product quality
• Same mistakes happen again and again

? We need a Methodology to control the schedules,costs

and quality of a project.
 Defining a Project Process

Project Process Model:

• Code-and-fix
• Waterfall
• Incremental
• Iterative
Code-and-Fix Model:

Coding This model is most suited for very

small and simple projects

Testing

Delivery
Waterfall Model:
Requirement This model generally is suited for
medium projects with well-defined
requirement
Definition

Design

Coding

Testing

Delivery
Incremental Model:
Requirement This model generally is suited for
large projects with well-defined
Definition
requirement
Increment1
Increment2
Design Increment3

Spec Spec Spec

Coding&Test Coding&Test Coding&Test

Function Test Function Test Function Test

System Test

Delivery
 Iterative Model: This model generally is suited for
large projects that have not been
fully defined.
Iterative 1 Iterative 2 ... Iterative n
Requirement Requirement Requirement

Definition Definition Definition

Design Design Design

Coding&Test Coding&Test Coding&Test

Comp. Test Comp. Test Comp. Test

System Test

Delivery
Understanding the
• The customer’s Customer’s Problem to
problems and corresponding Solve
Theneeds
most are
common problems are:
not understand
• The customer’s problems and needs are not
fully documented
• Agreement has not been reached on the validity
of the contents of the requirements document
• Changes to an agreed-to requirements
document are not controlled
? We need a well thought out requirements document.
The rule
• The of Gathering
requirements Requirements
document focuses on the problems and needs--not
the solution---of the customer.
• Never assume you understand your customer’s problems and needs
if you have not worked closely with the customer for this purpose.
• More will be learned about your customer’s problems and needs
when you put them in print and verify their accuracy and
completeness with your customers
• The most successful product developers will be those who
consistently and tireless work at understanding their customer’s
problems and needs that must be satisfied
• Enlist requirements, record the designation of H,M and L, for high,
medium and low priority,designate whether the requirement needs
to be satisfied in the long,intermediate or short term: L,I and S
What Should
1, Describe theRequirements Address?
fundamental problem to be solved.
2, List specific needs that the solution must satisfy related to function
and tasks. (H,M,L and L,I,S)
3, Describe how the user currently operates.
4, Describe the environment that must be taken into account with the
solution
5, Identify any hardware and software needs that must be satisfied.
6, Describe the quality-related needs.
7, Describe the performance-related needs.
8, Describe the security-related needs.
9, Describe any compatibility and migration needs.
10, Describe the support-related needs.
Example: E-meeting Requirement Lists
Seq Requirement H.M.L L.I.S Req. By Priority
1 Book meeting room , control the confliction , H I CPD 1
reflect the resource usage
2 Integrate the applications of projectors , con-call M S CPD 1
devices
3 Integrate the meeting arrangement , include send M L C.J 2
out meeting agenda , send meeting minutes ,
record action items etc.
4 Integrate the action items or issues tracking L L C.J 3
 IT Challenges
• To deliver the projects that have the greatest
benefit to our internal and external clients
• To perform more and more day-to-day
production support activities
• No enough resources
• Unlike most projects that deliver a new
product upon completion.
Quality Function Deployment (QFD)

TQM Tools developed in 1960

• Manage Project Priorities
• Manage Project Management Resource
• Analytic Hierarchy Process (AHP) was
used to prioritize the benefit
Analytic Hierarchy Process
(AHP)
( 一 ) AHP 的評估尺度
在進行各因素間的兩兩比較時， AHP 所使用的基本評估尺度是由文字敘
述評比 ( Verbal judgments ranking ) 而來，包括「同等重要」、「稍重要
」、「頗重要」、「很重要」、「極為重要」；與其相對應產生數 尺度
( Numerical judgments ) 為 ( 1 、 3 、 5 、 7 、 9 ) ，和介於其中的折衷數
( 2 、 4 、 6 、 8 ) ，其內容詳述於表 2-2 階層程序分析法之階層概要圖
。
下表： AHP 評估尺度
尺度 定 義 說 明
Equal Importance
1 兩個因素具有同等的重要性相同重要
同等重要
Moderate Importance
3 根據經驗和判斷，認為其中一個因素較另一個稍重要
稍重要
Essential or strong
5 根據經驗和判斷，強烈傾向偏好某一因素
頗重要

7 Ver/strong Importance 實際上非常傾向偏好某一因素

Extreme Importance
9 有證據確定，在兩相比較下，某一因素極為重要
極為重要

2,4,6,8 相鄰尺度間的折衷值 當折衷值需要時

FMEA 思維模型
 例子： 手 電筒 設計中的
過程步 FMEA
潛在失 潛在失效 潛在原
D
建議採取的
驟/輸 SEV OCC 當前管制 E RPN
效模式 影響 因 措施
入 T
開關彈 彈性降 選用彈性好
燈不亮 8 疲勞 5 目測 7 280
簧片 低 的簧片
選用彈性好
後蓋彈 彈性降
燈不亮 8 疲勞 4 目測 7 224 的簧絲 ; 改
簧 低
進工藝
燈座直
接觸不
燈座 時斷時通 7 徑公差 2 儀器測試 4 56 減少公差
良
大
公差大 8 儀器測試 4 160 減少公差
鬆動
前蓋 影響聚焦 5 磨損 9 儀器測試 7 315 改進公藝

擰不上 公差小 2 儀器測試 4 40 減少公差

 嚴重性 (S) : 對應于某潛在 發生 概率 (O ): 對應于原因 測試 性 (D): 在客戶方發生
失效效應的嚴重程度。 与失效模式比例的評估。 失效的可能性的等級。

1 對工序或客戶無影響 极少 < 1 in 1,500,000 可靠的測試控制

2 客戶可能忽略的失效 小概率 1 in 150,000 比較可靠的測試控制

對性能有微小影響
3 失效較少 1 in 15,000 良好的測試控制

4 對性能有較小影響 微量失效 1 in 2,000 測試控制

5 對性能有影響 偶然性失效 1 in 500 不完全的測試控制

工序 / 產品性能會降
6 一般 1 in 100 較低水平的控制
低但安全

7 工序 / 產品性能會降低 較多 1 in 50 低水平的控制

很嚴重以致不可修
8 大量 1 in 10 難于控制
复或無法使用

非常嚴重 ( 帶有
9 非常多 1 in 5 很難控制
警報提示的影響 )
安全性或可靠性故障
10 几乎全部 > 1 in 2 几乎無法控制
( 不帶有警報提示的影響 )
 風險優 先指數 (RPN)
Risk Priority Number

RPN 評价 理解或 行動

1 < RPN< 50 對產 品有 較小的 危害

對產 品有 中等的 危害 ，需
51 < RPN <100
進一 步改 善
對產 品有 嚴重危 害， 需深
101 < RPN <1,000
入調 查分 析
 因果矩陣

對顧客重要性的等級 7 7 9 5 合計

間隙過大

天線短路

熔接不良
天線壓傷
輸出（關鍵的內外部顧客需求）

i tem 過程的輸入
1 烙鐵的溫度 0 0 3 0 27
2 焊接的方法 5 1 10 1 139
3 天線線材的來料 5 1 7 1 110
4 PCB的來料 1 1 3 1 46
5 超音波機器的變異 10 9 6 7 222
6 超音波參數的設置 2 9 1 9 121
7 模具的變異 9 9 10 9 280
 柏拉圖
Pareto Chart of C1
1000 100

800 80

Percent
600 60
Count

400 40

200 20

0 0
C1 異 異 法 置 料 料 式 er
變 變 方 設 來 來 方 O th
的 的 的 的 的 B的 的
具 器 接 數 材 C 制
模 機 焊 參 線 P 壓
波 波 線
音 音 天
超 超
Count 280 222 139 121 110 46 33 46
Percent 28.1 22.3 13.9 12.1 11.0 4.6 3.3 4.6
Cum % 28.1 50.4 64.3 76.4 87.5 92.1 95.4 100.0
 Communicating in Harmony

We are All in This Together

Coming together is a beginning,

Keeping together is progress,
Working together is success.
The Rule of Communicating in Harmony:
1, Respect the individual
2, When you are wrong, admit it
3, Exercise tolerance
4, Be quick to assist
5, Ask others for assistance
6, Keep others informed--do not surprise
7, Bo a good listener
8,Greet people---remember their names
9,Be willing to break with tradition
10,Close problems
 Project Schedule Planning

The good plan must:

• Be well thought out

• Have the commitment of the participants
• Be aggressive yet achievable
 A Sample of Project Schedule Plan with Milestones
0 10 20 30 40 50 60 70 80
Requirements Berry, 4

SA/SD Berry,Jane

Specification Jane,2

Testing Plan Jane, 1

Coding/Testing Everybody

Component Testing Cory, 10

System Testing Jane, 10

User Training
Berry, 4
Pilot Run John , 10
Delivery

Maintenance
 A Sample of Critical Path A-B-D-F

ra cy
0 10 20 30 40 50 60
Du en

n
tio
De t y
nd
i
tiv

pe
Ac

A - 10 A
B A 10 B
C A 8 C
D B 10 D
E A 18 E
F D,E 30 F
 The Steps to Developing a Project Schedule Plan(PSP)

Step1, Assign project manager

Step2, Requirement analysis
Step3, Prepare for project schedule planning meeting
Scheduling the meeting and distributing the meeting notice
Describing what is to be built(Requirement)
Listing activity responsibility matrix(O,A,R)
Collecting other useful information
Step4, Kick off project schedule planning meeting
Step5, Complete assignments
Step6, Approve PSP
Step7, Distribute approved PSP to project members
 Project Tracking: PTT Meeting

The Goal of Project Tracking Team Meeting :

• Review progress and stay in control

• Identify potential problems before they happen
• Put solution in place when issues occur

? How to improve the efficiency of the PTT meeting?

Sample customized project checklist
Respon Planned Actual
Id# Activty Depend.
. Person Start End Start End
210 CTP preparation 51s Berry 4/4 5/13 4/4 5/16
211 CTP review 210 Berry 5/16 5/27 5/17 5/27
212 CTP update 53,211 Berry 5/30 6/10 5/30 6/14
213 CTP approval 212 Berry 6/13 6/17 6/15 6/22
214 CTP refresh 213 Berry 6/20 6/24 6/23 6/27
220 STP preparation 51s Berry 5/23 7/1 5/23 7/1
221 STP review 220 Berry 7/4 7/15 7/4
222 STP update 53,221 Berry 7/18 7/29
223 STP approval 222 Berry 8/1 8/5
(08/05)
230c Component test 213,321s Berry 6/20 08/10 6/23
224 STP refresh 223 Berry 8/8 8/12
(08/08)
240c System test 223,323s Berry 08/11 9/30
250c Regression test 240 Berry 10/3 10/14
Minutes of Hub Operation Meeting ( 一）

Pending Issues
Issue Team Due
Action Status
Date MIC YCH date
10.Compaq將于9/23至MIC audit,請YCH克服倉庫的相 Henry David 9/16 9/10需全部ok﹒H
關concern: 行政部門 庫﹐V庫之空調需
特別注意﹒
a.倉庫的溫濕度﹐冷氣机等環境問題﹒
8/26 b.貴重料(V庫,H庫)之防靜電處理﹒
c.二層架之工安處理﹒
d.儲位混料之說明(目前1個棧板最多放4种料).
e.若需MIC協助之處﹐請YCH提出﹐以便盡快處理﹒
11.Microsoft S/W進出料均需scan每一套盒子﹐以能稽 Randy
Henry MIS將install新程式
8/26 核 country key record,而使進出帳得以 balance:請 YCH 10/1
Chiping 予YCH.
study process,提處理區域﹐方式﹐時程﹒
1.Free charge 程式﹕10月前ok,以區分該PO#与正常PO
9/2 Justin 10/1
之編碼方式﹒
仍有124項未退﹐
9.Slow Moving: PMC已提出list,請采購協助通知厂商處
9/2 Buyer 9/15 請采購每周報告
理退貨﹒
處理情形
Minutes of Hub Operation Meeting ( 二）

The Meeting Minutes (Sep.9)

Issue Team Due
Action Solution
Date MIC YCH Date
9/9 1. Inbound Report 分析問題件 增加“短溢裝"類別 Randy 9/15
9/9 改成 Audit Report Y.T. Randy 持續
3. 1, ECO/ECR 煩請CYH填寫“品質异常通知書"﹐并知會 Buyer
9/9 IQC﹐經IQC判定后﹐才由采購會同IQC 修改 Y.T.
4. 2, 收料時發現料號异常 P/N. Randy 持續
YCH 增加DIR程式﹐使工單run時不會抓該 9/30
5. DIR 處理
9/9 料﹐并可追蹤DIR記錄﹒ Chiping Karun
9/9 6. 更發儲位原因分析 需增加各類原因之統計比例﹒ Randy 9/15
9/9 7. 儲位轉移統計 每周報告儲位轉移統計數量﹒ Randy 持續
8. Hot Shot 目標 25%以下﹒ PMC 9/30
9/9
BOM:60%,1小時備料之散單﹕15%,2小時備料 PMC 9/30
9/9 9. 領料單比例目標
之散單﹕25%. 領料單位 Randy
9/9 10. Outbound 准時完成目標 100%. Randy 9/30
Cycle Count 發現既有誤﹐需知會MIC﹐填 Henry
11.盤點調整后發現錯誤
9/9 “庫存調整單"﹐即時調拔PW5﹒ 財會 Randy 持續
需同時check Oracle 及YCH系統﹐与EDI856等
12. Cycle Count
9/9 資料﹐以便釐清真實盈虧狀況﹒ Henry Rands 持續
Sample project agenda format
PTT M e e ting age nda:04/15/9x

Time Item Presenter

08:00 Project high-risk areas Turner
08:15 Overview of project progress Turner
Progress of project activities
08:20 Change control Yamato
08:30 Low-level design and code Grow
08:40 Unit and function test Miller
08:45 Component test Berry
08:50 System test Berry
09:05 Publications Vandegrift
09:10 Performance Vila
09:15 Usability Smith

09:15 Progress of action items

41 Casey
37 Kaptsan
5,12,19 Madison
38 Miller
39 Short
27,44 Yamato
09:30 New action items All
09:45 30-day outlook Rosenman
09:50 Plan work/escalation meetings Turner,all
10:00 Adjourn
Tracking Meeting Ground Rules
• Come on time.
- Not five or 10 minutes late.
• Come prepared.
• If behind on an activity , them address:
-Why the activity is late.
- What other areas are/might become impacted.
- What recovery plan will be/is in place.
- Whether you need help.
• Time-consuming problems are to be resolved outside of
the meeting.
• “Raise hand” if the meeting is perceived to be off
course.
• Encouraged:Open and candid status reports and
discussion.
One Day at a Time

Ensure a PTT leader is assigned who understands the job

and is empowered to make it happen. Ensure that the
project’s leadership is in full support of the project tracking
principles discussed--and that they are committed to enforce
them. Teach the discipline--one day at a time --required to
stay in control. Nobody said it would be easy or simple. On
the contrary ,there is a tremendous amount of skill and
discipline required .But it can be done!
 Development Testing
Flowpaths for module ABC
1 5






2 6
EXIT
ABC
3



7


4
 Unit Test
Plan
1. For each module , identify the set of flowpaths that will be
tested to satisfy the two required conditions presented in the
preceding section:
--All code (therefore,all flowpaths) is executed.
--All primary logic path combinations are executed.
2. State the method to be used to create the test environment that
will allow all these flowpaths to be executed.
3. List the entry and exit criteria for starting and ending the unit
test period. Include dependencies on people and equipment.
4. State the schedule to be followed for starting and ending the
unit test for each module.
 System Test Plan
1. Identify a “function text matrix” of functions versus test
scripts.
2. State the method to be used in creating an environment that
will allow all functions to be executed.
3. List the entry and exit criteria for starting and ending the
function test period. Include dependencies on people and
equipment.
4. State the schedule to be followed for starting and ending each
test identified in the function test matrix.
5. Define the problem-tracking process.
 Defect Type - Anomaly Classification by Type
IEEE Standard
1 Logic problem 4 Data handling problem
1.1 Forgotten cases or steps 4.1 Initialize data incorrectly
1.2 Duplicate logic 4.2 Accessed or stored data incorrectly
1.3 Extreme condition neglected 4.2.1 Flag or index set incorrectly
1.4 Unnecessary functions 4.2.2 Packed/Unpacked incorrectly
1.5 Misinterpretation 4.2.3 Referenced wrong data variable
1.6 Missing condition test 4.2.4 Data referenced out of bounds
1.7 Checking wrong variable 4.3 Scaling or units of data incorrect
1.8 Iterate loop incorrectly 4.4 Dimensioned data incorrectly
2 Computational problem 4.4.1 Variable type incorrect
2.1 Equation insufficient or incorrect 4.4.2 Subscripted variable incorrectly
2.1.1 Missing computation 4.5 Scope of data incorrect
2.1.2 Operand in equation incorrect 4.6 Sensor data incorrect or missing
2.1.3 Parentheses used incorrectly or not used 4.7 Operator data incorrect or missing
2.2 Precision loss 4.8 External data incorrect or missing
2.2.1 Rounding or truncation fault 4.9 Embedded data in tables incorrect or missing
2.2.2 Mixed mode 4.10 Output data incorrect or missing
2.3 Sign convention fault 4.11 Input data incorrect or missing
3 Interface problem 5 Format problem
3.1 Interrupt handled incorrectly 6 Enhancement
3.2 I/O timing incorrect 6.1 Output style enhancement
3.2.1 Timing fault cases data loss 6.2 User interface enhancement
3.3 Subroutine module mismatch
3.3.1 Wrong subroutine called
3.3.2 Incorrectly located subroutine call
3.3.3 Nonexistent subroutine
3.3.4 Inconsistent subroutine arguments
3.4 User Interface Problem
 Vendor Relationships
The benefits of using vendors include:
• You can obtain skills or technology that are not readily
available in your organization.
• Regular employees can be offered increased job security during
financially tougher times by letting go of vendors before
downsizing an organization.
• You can start activities sooner than your resources would
otherwise allow.
• The project’s overall schedules can potentially be shortened.
• You can associate your project with a well-know and well-
respected vendor.
• You can perform activities for a potentially lower cost.
The Vendor Contract Process

1 An RFP is created and distributed.

2 Vendors create and distribute proposals.

3 A vendors is selected .

4 A contract is negotiated,signed, and executed.

Vendor contract process.

Defining the Vendor’s Work

1. There is a direct relationship between the

completeness of your RFP and the completeness of
the bid proposals received.

2. When it comes to quality work from a vendor ,, you

usually get what you ask for . Ask in the RFP !

3. Don’t blindside your own organization--get your

organization’s agreement before releasing the RFP
to Vendors .
 Performance Incentives

Contract: Vendor-tested code available:12 months

Defects discovered in system test :<2.0/KLOC
Defects discovered after delivery to customers:.2/KLOC

Bonus: 5% - Vendor-tested code available one month early

10% - Defects discovered in system test:1.0-1.5/KLOC
20% - Defects discovered in system test
10% - Defects discovered after delivery to customer:<.1/KLOC

Penalty 5% - For each month vendor-tested code is late

5% - For each additional .5 defects/KLOC discovered
in system test over 2.0 defects/KLOC
5% - For each addition .2 defects/KLOC discovered
after delivery to customers over .2 defects/KLOC
Selecting a Vendor
Project management Vendor Vendor Vendor
Evaluation categories ABC DEF GHI
Project scheduling, tracking, and 1.75 2.25 2.00
reporting methodology
˙Clearly defined process, roles responsibilities, 2 3 2
tools
˙Frequent and regular tracking meetings' 2 2 2
˙Dependency management 1 2 2
˙Planned communication with company buying 2 2 2
services
Project organization structure 2.00 2.50 2.00
˙Supports software development process; 2 2 2
built-in checks and balances
˙Clear definition of roles and authority 2 3 2
Problem management approach 2.00 2.00 2.00
˙Defined and responsive process 2 2 2
Staffing and skills 1.00 2.00 2.00
˙Availability of headcount, skills, leaders, across 1 2 2
required disciplines
Related experience 1.00 2.50 2.00
˙Seasoned development; experience on similar 1 3 2
products
˙Indicators of learning from past experience --- 2 2
Software development process 1.67 2.67 2.00
˙Clearly defined activities, roles, and 2 3 2
responsibilities
˙Comprehensive 2 3 2
˙Effective checks and balances, entry/exit 1 2 2
conditions
Facilities/equipment/tools 2.00 2.00 1.50
˙Productive environment 2 2 2
˙Security 2 2 1
Overall score for project management 1.63 2.27 1.93
Scoring criteria

Score Meaning Definition

3 Exceptional
Exceeds performance or capability; high probability
of success; no significant weakness

2 Acceptable Satisfies evaluation criteria; good probability of

success; any weaknesses can be easily corrected

1 Marginal Currently fails to satisfy the evaluation criteria;low

probability of success;significant deficiencies,but
correctable
Unacceptable
0 Significant deficiencies;needs a major revision to
bid proposal to correct
 Vendor Relationships

Optimism is eternal. We are forever

hopeful that the next software project will

proceed infinitely smoother than the last.

General topics for a post project review.
• Staffing
• Mission objectives
• Product definition and change control
• Customer involvement
• Schedules and tracking
• Education and training
• Productivity
• Tools
• Quality
• Vendors and subcontractors
• People communications
• Support from outside groups
• Software development process improvements
• Other processes that worked well; did not work well
• Financial budget
• Other problems and/or suggestions
Postproject review topics for the component test organization.

• Availability of needed product information

• Test plan
• Functional coverage of test scripts
• Developing the test scripts
• Test script inspections
• Running the test scripts
• Automation of test scripts
• Problems discovered in product code
• Self-documentation of test scripts
• Tools required and/or used
• Hardware availability
Summary

Neglect always carries a high cost.

An organization can realize big savings.

Applying this knowledge to future projects can

mean taking greater profits to the bank.