TKTTKT--1212 1212 Digitaalijärjestelmien toteutus · [N. Holmes, The Data Doughnut and the...

TKTTKT--1212 1212 Digitaalijärjestelmien Digitaalijärjestelmien toteutustoteutustoteutustoteutusLec 14 Lec 14 –– Project managementProject management

Erno SalminenErno Salminen

Department of Computer SystemsDepartment of Computer SystemsTampere University of TechnologyTampere University of TechnologyTampere University of TechnologyTampere University of Technology

Spring 2011Spring 2011

Department of Computer Systems

What variables define ”success” and What variables define ”success” and ”failure””failure”failurefailure

1. Scope and quality – user gets the job done2. Scedule – it is ready on time2. Scedule it is ready on time3. Budget – it is cheap enough IT project statistics [Chaos 2009] IT project statistics [Chaos 2009] 32% Succeeded - delivered on time, on budget,

with required features and functionsq 44% Challenged - late, over budget, and/or with

less than the required features and functions 24% Failed - cancelled prior to completion or

delivered and never used

#2/35 Department of Computer Systems

[http://community.ca.com/blogs/theitgovernanceevangelist/archive/2009/05/04/understanding-project-failure-rates.aspx]

Why talk about failure?Why talk about failure?There is not exact formula for successHowever, there are quite exact predictors forHowever, there are quite exact predictors for

failure

Interactive part: list 5 reasons for project Interactive part: list 5 reasons for project failure with your partner


SourcesSourcesR.N. Charette, Why software fails [software

failure],Spectrum, IEEE, Vol. 42, Iss. 9, ] pSept. 2005, pp. 42 - 49.N. Holmes, The Data Doughnut and the g

Software Hole, Computer, Vol. 39, Iss. 6, June 2006, pp. 100 - 99.Coley consulting, Why projects fail,

http://www.coleyconsulting.co.uk/failure.htm

W S H h Fi i h ftW.S. Humphrey, Five reasions why software projects fail, Computer World, May 2002, http://www computerworld com/s/article/71209/Why Projects Fail


http://www.computerworld.com/s/article/71209/Why_Projects_Fail

Failure reasons fall into 3 categoriesFailure reasons fall into 3 categories1. Project management –related2. Context–related2. Context related3. Implementation-related Note that only category 3 is technical matter Note that only category 3 is technical matter Most could be avoided with common sense and

more or less human-science Although, the cited surveys discuss SW

projects, the discussion may be generalized to HW d HW/SW j t llHW and HW/SW projects as well


[R.N. Charette, Why software fails [software failure],Spectrum, IEEE, Vol. 42, Iss. 9, Sept. 2005, pp. 42 - 49. ]

[N. Holmes, The Data Doughnut and the Software Hole, Computer, Vol. 39, Iss. 6, June 2006, pp. 100 - 99.]

Mng 1: Mng 1: Unrealistic or unarticulated Unrealistic or unarticulated project goalsproject goals

Get the end users involved You must infiltrate technical people to the meeting

h th l d i t t dwhere the goals and requirements are captured Both from customer’s and developer’s side

There is no free lunch: ”If you choose A, you y , ycannot have B” – R. Colwell Do you want a good car or a cheap car? Do we optimize performance or power? Do we optimize performance or power? Most simple thing, often forgotten

Don’t be too greedy “Is it feasible?”


http://www.youtube.com/watch?v=1GSV2kVkO1w

Management 1b: unclear goalsManagement 1b: unclear goalsUnrealistic or unarticulated project goalsDocument also the self-evident things

” id t t ’ lf d t b d l ” A Bi ”evident to one’s self and to nobody else” - A. Bierce ”Oh, I forgot to mention that our Gizmo must cost less

than 1€...”M ti t k t i f thMotivate your workers to aim for the common goal Reward them for success Counterexample: meaningless ”Company values” just

worsen thingsHence, use only quantifiable goals, y q g

Goals that are unambiguosly met or not E.g. ”This projects cuts expenses by 8%. Expenses

are calculated as...”


Mng 2: Badly defined requirementsMng 2: Badly defined requirementsCritical step in the projectEven if product meets the

Fig: [J.P. Bowen, M.G. Hinchey, Ten Commandments of Formal Methods ...Ten Years Later, Computer, Vol. 39, Iss. 1, Jan. 2006, pp. 40 – 48]

specification, it may not meet customer’s wishes

Most customers areMost customers are inexperienced in requirement capture

Poor requirement document creates Ambiguity for the design Ambiguity for the design -

which way to choose? Contradictory goals – which

one is right?


one is right?

Mng 2b: Badly defined requirementsMng 2b: Badly defined requirementsOr late changes to requirements The sooner the better; the less the better; e.g. Pentium bug: optimize area just before tape-

out E.g. legendary ”Eight is beautiful” – Ken Kutaragi

(Cell did not fail, though)R i d lid t i t th hlReview and validate requirements thoroughly Speak up if the requirements do not make any

sensesense Get acceptance on black-and-white Track their consequences


Track their consequences

Mng 2c: Badly defined requirementsMng 2c: Badly defined requirementsHowever, changes are inevitable Apply disciplined change procedurepp y p g p Postpone/discard most, accept the

critical changesPrioritize requirements and changes These features are absolutely

necessary They bring the biggest income They create biggest losses if they fail They create biggest losses if they fail

These might be incorporated if schedule allows


These are definitely rejected

Mng 3: Poor project managementMng 3: Poor project management ”All important decisions [regarding

tools] are made at least 2 organization steps above the levelorganization steps above the level where the consequences are understood”L j l l Long projects are also more late Split to small projects instead of

”sqeezing” Settle few milestones that have to be

met Convert the huge last week’s panic into Convert the huge last week s panic into

several but smaller mid-week panics

Excess bureaucracy


Mng 3b: poor mng + schedule estimMng 3b: poor mng + schedule estim The larger the project, the greater the gap between the actual

delivery date and the planned delivery date of the application


[C. Jones, Social and Technical reasons for software project failure, J. Defense SW Eng., 2006]

Mng 3c: Poor project managementMng 3c: Poor project management Information hiding seldom

pays offp y Give reasons to decisions Tell what exactly was

promised to the customer Everyone should have

access to the requirementsaccess to the requirements and code database

Do not update yourDo not update your organizational structure every month


y

Mng 4: Mng 4: Poor estimates of needed Poor estimates of needed resourcesresources

Do not overestimate your (team’s) capabilities Everything takes longer than you think

f ( % f ) Especially verification (e.g. 40-80% of project’s time) Comments regarding the exercise work, anyone?

Remember mythical man-monthy Many tasks won’t finish sooner with more workers Often they are more late (managing overhead grows) Compare digging a well and trench Compare digging a well and trench

However, one ”super-designer” may account 5-10 regular engineers They are rare! Make them feel comfortable, bake them

cookies etc.


Mng 4b: Mng 4b: needed resourcesneeded resourcesAccount the other duties of the labor administrative tasks, other projects, vacations..., p j ,

Most people are productive when they can concentrate on one thing at a timeg Task switching takes time Even if the pending task is

small, it is in the back in the brain and distracts concentrationconcentration

Multitasking reduces productivity by 20-40%


[Anderson, Study: Multitasking…, CNN.com, Aug. 2001]

Mng 5: Mng 5: Poor reporting of the project’s Poor reporting of the project’s statusstatusstatusstatusStatus reports are boring, I know, but

essentialNo reason to make things look nice – be

realistic and honestReport concisely What has been done? How do you know it works? What has not been done although planned?

Why? What will happen next?


Mng6: Unmanaged risksMng6: Unmanaged risksMother nature is a bitch and Murphy was an

optimist.Prepare for the delays

part delivery, manufacturing, vacations, bugs, higher priority tasks, damaged equipment...p y , g q p

What if COTS does not work as expected?What if our subcontractor goes out of business

within 5 years?Question: How does a large project get to be one

year late?year late? Answer: One day at a time! React early!


Mng6: Mng6: Unmanaged risksUnmanaged risks

Acknowledge that gimportant people may leave

Hence, all codes ,must have an easy-startMakefile Testbench Documentation Examples Examples

Estimate risk’s probability and associated cost


associated cost

Context 7: Poor communicationContext 7: Poor communicationPoor communication among customers,

developers, and usersRight hand does not what the left one is doingRight hand does not what the left one is doingMake sure that each meeting has agenda and

written conclusion which everone agrees Prepare well if you are to present something Make sure that everyone has access to those memos

Accept and welcome the debateAccept and welcome the debateRemember to ask ”stupid” questionsDo not underestimate the power informal

i ti d f t f ti hcommunication and face-to-face meetings such as coffeebreaks

Don’t shoot the messenger


g

Context7: poor comm + bad reqContext7: poor comm + bad req

#20/35 Department of Computer SystemsErno Salminen - April. 2011

Context 8: Commercial pressureContext 8: Commercial pressure Rush to the market Feature explosion for marketing p g

purposes (aka. scope creep) Complicates development and

maintenance overhead (area memmaintenance, overhead (area, mem. footprint, runtime, power)

S W

röd

Overoptimizing

In M

S Overoptimizing the price Challenger Challenger

shuttle O-ring…


Fig. 1 [R. Boecker et al., Reducing the Gap Between What User Know and Whta They need to know, in. Universal Usability, 2002]

g

Context 9: Stakeholder politicsContext 9: Stakeholder politics Stakeholder (corporate), a person, group,

organization, or system who affects or can be affected by an organization's actionsy g

”We can’t optimize that because makes our older products look stupid…”

”Are you absolutely sure that it does not y yinfringe any existing patent?”

”Despite its novelties, we oppose your suggestions [because it may bring cutdowns in

b d t i l ]”gg [ y g

our budget in a long run]” ”Not invented here!” ”We have always done it that way”e a e a ays do e t t at ay ”We won’t sell your application at our store.

And that is just because. And we will sue your sorry ass if you complain”


y y p

Impl 10: Use of immature technologyImpl 10: Use of immature technology

Or technology unfamiliar to the developers or vendors ”Make sure that simple things work ” Make sure that simple things work...

Project’s success should not hinge on the adequate performance of new technology

A project can be based on an emerging technology thoughtful assessment that such a technology has

extraordinary potential y p differential value achieved by being an early adopter

Even in these cases, first carry out pilot projects that provide experience with the technologythat provide experience with the technology limit the scope of its implementation to minimize potential

damage


Impl 11: Sloppy development practicesImpl 11: Sloppy development practices

Poor documentation Inconsistent naming No version control No review process Ignoring the compiler warnings Not checking return values Not using assertions 25% of admin time spent going down blind alleys

due to bad msgs [Candea]due to bad msgs [Candea] ”I hope someone else will check it” ”I’ll code this first and test after that”


I ll code this first and test after that[Candea, http://resist.isti.cnr.it/free_slides/dependable/candea/Lecture-08_(Manageability).pdf]

Impl 11b: must use version controlImpl 11b: must use version controlUse version control (Git, SVN, ...)Teaches one to take logically consistent steps eac es o e to ta e og ca y co s ste t steps

in a projectHelps backup processp p pEasy throw-away code prototypingKeeps track of your work (how many changesKeeps track of your work (how many changes

in a week?)Keeps track who did whatpOne can go back to see any previous versionA must for all work


A must for all work

Impl 12: Inability to manage complexityImpl 12: Inability to manage complexity

Divide-and-conquer, separation (orthogonalization) of concers Separate computation and communication Separate computation and communication Separate function and architecture

Reuse everything you can Model-based design, model-driven engineering

Obtain early estimates and bounds Establish the critical choices early Establish the critical choices early Automate the implementation via synthesis

Techniques for this challenge are addressed in TKT 2431 S C D iTKT-2431 SoC Design


Impl 12b: Inability to manage complexityImpl 12b: Inability to manage complexity

“The most important aspect of any design is how it is partitioned. The second most important aspect of any design is its interfaces ” M Keatingany design is its interfaces. – M. Keating Minimize coupling between modules Dst and source parameters always in the same order

Si il i ti Similar naming convention Use consistent units

If some function users meters as units, no function should illi tuse millimeters

Try to make functionality obvious Names should not be too long but they should also be to-

th i tthe-point Try to make misuse hard (e.g. add checks and asserts to

the code)


Another viewsAnother views

Department of Computer Systems

Why projects fail [Coley Consulting]Why projects fail [Coley Consulting]1. Lack of User Involvement2. Long or Unrealistic Time Scales2. Long or Unrealistic Time Scales3. Poor or No Requirements4 Scope Creep4. Scope Creep5. No Change Control System6 Poor Testing6.Poor Testing


Five reasons why software projects Five reasons why software projects fail [W.S. Humhrey, ComputerWorld]fail [W.S. Humhrey, ComputerWorld]fail [W.S. Humhrey, ComputerWorld]fail [W.S. Humhrey, ComputerWorld]

1. Unrealistic schedules2. Inapproriate staffing2. Inapproriate staffing “The only way to complete an engineering project

rapidly and efficiently is to assign an adequate number of people and then protect them from interruptions and distractions.”

3 Ch i i t d i d l t3. Changing requirements during development4. Poor-quality work5. Believing in magic


[http://www.computerworld.com/s/article/71209/Why_Projects_Fail]

Another view of the cost factorsAnother view of the cost factorsEach bar denotes a factor used in cost estimation.

For example, very capable personnel may bring up to 4.18x reduction

In cost.

[B.W. Boehm, Improving Software Productivity,

Computer, Vol. 20, Iss. 9, Sept. 1987, pp. 43 - 57.]

#31/35 Department of Computer SystemsErno Salminen - Nov. 2008

Further reading on project managementFurther reading on project management

Robert P. Colwell, The Pentium Chronicles: The People, Passion, and Politics Behind pIntel's Landmark Chips, Wiley-IEEE Computer Society, 2005Author is former chief IA32 architect for

Pentium II, III, and 4 microprocessorsBrilliant stuff


R. Colwell, Pentium ChroniclesR. Colwell, Pentium Chronicles ”The very essence of engineering is the art of

of compromise, of trading-off one thing to p g ganother” ”The act of codifying one’s thinking unfailingly y g g g y

reveals conceptual holes, mental vagueness, and outrigth errors” ”Nothing will ever be attempted if all possible

objections must be first overcome” One must take some risks

”You cannot run a project from ten thousand


feet”

Further reading on project management (2)Further reading on project management (2)

David Shippy and Mickie Phipps, The Race for a New Game Machine, Kensinkgton P bli hi C ti 2008Publishing Corporation, 2008Designing Cell processor at

Sony/Toshiba/IBM Design Center (STI)Sony/Toshiba/IBM Design Center (STI)Chip used in Playstation3 and

Xbox 360Xbox 360Authors lead the development of

the new PowerPC processorthe new PowerPC processorBrilliant stuff


Further readingFurther reading History's Worst Software Bugs (Wired)

http://www.wired.com/news/technology/bugs/0,2924,69355,00.html Software Horror Stories (Nachum Deshowitz, Tel Aviv

Uni ersit )University) http://www.cs.tau.ac.il/~nachumd/horror.html

Failure Rate (collection of failure rate statistics from IT surveys) http://www it-cortex com/Stat Failure Rate htm http://www.it-cortex.com/Stat_Failure_Rate.htm

The DailyWTF http://thedailywtf.com/

More on management's role in IT project failures: the failureMore on management s role in IT project failures: the failure rate of IT projects is quite high (John Glaser) http://www.allbusiness.com/technology/306312-1.html


TKTTKT--1212 1212 Digitaalijärjestelmien toteutus · [N. Holmes, The Data Doughnut and the...

Documents

Transcript of TKTTKT--1212 1212 Digitaalijärjestelmien toteutus · [N. Holmes, The Data Doughnut and the...