lect 14 project management k14 v01 - tuni · software project failure, j. defense sw eng., 2006]...

Department of Computer Systems

TIE-50200 LogiikkasynteesiLec 14 – Project management

Erno Salminen

Department of Computer SystemsTampere University of Technology

Spring 2014

#2/40 Department of Pervasive Computing

What variables define ”success” and ”failure”

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

with required features and functions 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

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


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

failure

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

Most of the following notes may seem obvious when written out. Nevertheless, such simple mistakes do occur in real life


SourcesR.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.Coley consulting, Why projects fail

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

W.S. Humphrey, Five reasions why software projects fail, Computer World, May 2002, http://www.computerworld.com/s/article/71209/Why_Projects_Fail


Failure reasons fall into 3 categories1. Project management –related2. Context–related3. Implementation-related 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 begeneralized to HW and HW/SW projectsas 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: Unrealistic or unarticulated project goals

Get the end users involved Get technical people involved when the goals and

requirements are captured Both from customer’s and developer’s side

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

Don’t be too greedy See also:

http://www.youtube.com/watch?v=1GSV2kVkO1w http://laughingsquid.com/the-expert-a-hilarious-sketch-about-the-

pain-of-being-the-only-engineer-in-a-business-meeting/


Management 1b: unclear goals Remember also the self-evident showstoppers

”evident to one’s self and to nobody else” - A. Bierce ”Oh, I forgot to mention that our Gizmo must cost less than

1€...” Hence, aim for quantifiable goals

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

calculated as...”Motivate your workers to aim for the common goal

Small details are solved ”automatically” when the common vision is clear

Reward them for success Don’t reward bonuses for regular or bad performance Motivation can also go terrible wrong: meaningless

”Company values” just worsen things


Mng 2: Badly defined requirementsCritical step in the projectPoor requirement

document creates Ambiguity for the design -

which way to choose? Contradictory goals – which

one is right?Most customers are

inexperienced in requirement capture

Get your most experienced engineers involved

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]


Mng 2b: Badly defined requirementsReview and validate requirements thoroughly Speak up if the requirements do not make sense Get acceptance on black-and-white Track their consequences – what other parts are

affected, how this can be verified in end product…

Remember: Even if product meets the specification, it may not meet customer’s wishes

Aim for MVP (minimum viable product) Minimum set of features to gather early feedback Release early, releasy often


Mng 2c: Badly defined requirements Prioritize requirements and changes

1. These features are absolutely necessary Bring the biggest revenue Create biggest losses if they fail

2. These might be incorporated if schedule allows

3. These are definitely rejected ”Asialliset hommat suoritetaan, muuten ollaan

kun Ellun kanat” – Vänrikki Koskela Dumbstriking real-life quote ”Even if things

are lower on the priority list, they are still as important…”

Small list of personal duties for a day/weekis a great help Relieves memory burden, improves

concentration, helps prioritizing


Mng 2d: req’ However, changes are inevitable Late changes to requirements

are also problematic 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 processor was a success, nonetheless!)

Apply a fast disciplined change procedure

Postpone/discard most, accept only the critical changes

Erno Salminen - April. 2011


Mng 3a: Poor project management Information hiding seldom pays off

Give reasons to decisions Tell what exactly was promised to

the customer Everyone should have access to the

requirements and code databaseDon’t forget where the money

comes fromEnsure that everyone knows in

which project they are involved inEnsure that project is properly

ended and not just fading withintime


Mng 3b: Poor project management Do not update your organizational structure every month 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 several but smaller mid-week panics

Short sprints

[C. Jones, Social and Technical reasons for software project failure, J. Defense SW Eng., 2006] FP=function point, sw complexity metric

It is psychologically rewardingto see progress

The larger the project, the greater the gap between the actual and the planned delivery date

In courses, the actual exercisetime is often 20-80% morethan students estimated

Actual

Planned


Mng 3c: Poor project management Avoid excess bureaucracy

“It is easier to be forgiven than granted“ – StubaNikula. Follow this guideline with care

”Three highly paid managers, in three continents, wasted many hours of work for deciding, if employeecan attend 150 EUR seminar” – true story

”All important decisions regarding EDA tools are made at least 2 organization steps above the level where the consequences are understood”

Be careful with bonus systems ”No. I won’t sell you this spare part, because then we

wouldn’t have any in stock, and what if someone wants to buy one? ” – true story

”We’ll give you a 50% bonus because that is what you got last year. – But this year was a great success, bonus should be 100% –Hmm, we’ll pay according to the net profit of Division E –But I work in Division B!” – true story

Soviet chandeliers tore the ceilings because the productivity of the lamp factory was measured as kilograms– urban legend or a true story?


Mng 4: Poor estimates of needed resources

Do not overestimate your (team’s) capabilities Hofstadter's Law: It always takes longer than you

expect, even when you take into account Hofstadter's Law. Especially verification (e.g. 40-80% of project’s time) Comments regarding the exercise work, anyone?

Remember mythical man-month [F.P. Brooks] Many tasks won’t finish sooner with more workers Often they are more late (managing overhead grows) Compare digging a well and trench

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

cookies etc. Ensure that project has enough resources right from

the start. Otherwise, you’ll be late from day one


Mng 4b: needed resources Account the other duties of the labor

administrative tasks, other projects, vacations... might account 30-50% of work hours

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

in the back in the brain distractingconcentration

Many tasks, e.g. debugging, requireuninterrupted concentration

Multitasking reduces productivity by 20-40%. Can you afford that? [Anderson, Study: Multitasking…,

CNN.com, Aug. 2001]


On ”multitasking”

Many tasks require coordinating with another team member, interrupting the current task of the assisting member. In this atmosphere, it is not unusual for developers to fail to recall the need to perform a specific task, known as prospective memory failure. In addition, productivity is negatively affected:

Czerwinski’s study [3] showed that tasks which resumed after interruption were more difficult to perform and took twice as long.

O’Conaill’s study [15] found 40% of interrupted tasks are not resumed at all [during the same day]

Further research [13] observed 57% of tasks were interrupted, and the time spent working uninterrupted was very small.

A recent study [12] of software engineers working at Microsoft indicated that 62% of developers surveyed believed recovering from interruptions was a serious problem.

Opportunities for breakdowns in communication are possible across numerous boundaries [11]. A large divide exists in communicating between managers and programmers. The reasons for this are several: technical inexperience, differing personality types, team structures,and personnel removal. Moreover, programmers are often buffered from upper management concerns, budget constraints, schedule concerns, and task priorities.



On ”multitasking” [refs] Citation on previous slide taken from Chris Parnin and Carsten Görg,

Design Guidelines for Ambient Software Visualization in the Workplace, VISSOFT 2007: 18-25. 2006

References: [3] M. Czerwinski, E. Horvitz, and S. Wilhite. A diary study of task switching

and interruptions. In CHI ’04: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 175–182, New York, NY, USA, 2004. ACM Press.

[15] B. O’Conaill and D. Frohlich. Timespace in the workplace: dealing with interruptions. In CHI ’95: Conference companion on Human factors in computing systems, pages 262–263, New York, NY, USA, 1995. ACM Press.

[13] G. Mark, V. M. Gonzalez, and J. Harris. No task left behind? Examining the nature of fragmented work. In CHI ’05: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 321–330, New York, NY, USA, 2005. ACM Press.

[12] T. D. Latoza, G. Venolia, and R. Deline. Maintaining mental models: a study of developer work habits. In ICSE ’06: Proceeding of the 28th international conference on Software engineering, pages 492–501, New York, NY, USA, 2006. ACM Press.

[11] H. Krasner, B. Curtis, and N. Iscoe. Communication breakdowns and boundary spanning activities on large programming projects.Empirical studies of programmers: second workshop, pages 47–64,1987.

Erno Salminen - Nov. 2008


Mng 5: Poor reporting of the project’s status

Bit boring, but essential No reason to make things look nice – be realistic and

honest Seek trade-off between being a yes man and a negative

creep Report concisely

1. What has been done?2. How do you know it works?3. What has not been done although planned? Why?4. What will happen next?

Opt for weekly/daily live reporting instead of writtenone every now and then

Excess reporting is usually a sign that management does not know what people actually do


Mng 5: Poor status reporting

http://space.mit.edu/cxc/local/dilbert_status_report.jpg

http://blogs.warwick.ac.uk/images/steverumsby/2007/02/15/dilbert2007916360215.gif

P.S. Dilbert would be most funny if it was fictional. Unfortuantely, it is a documentary comic…


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

optimistPrepare for the delays

You don’t exactly what it is, but it will happen harddisk failure, part delivery, manufacturing,

vacations, bugs, higher priority tasks, sick leave, vacations, damaged equipment...

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? Answer: One day at a time! React early!


Mng6: Unmanaged risks

Acknowledge that important people may leave

Hence, all codes musthave an easy-start Anyone can repeat

the basics Common repository Makefile, testbench,

examples, cocumentation

Estimate risk’sprobability and associated cost

What happens if André is fired or quits?


Reasons related to context



Context 7: Poor communication Poor communication among customers, developers,

and users Right hand does not know what the left one is doingMake sure that each meeting has agenda and

concise written conclusion ”Today, we’ll decide…” Preferably no phones, no laptops, no distractions – just the

current topic Don’t wait for late comers – it’s their loss, not yours Prepare well if you are to present something Write down who is responsible for task X and when

Do not use passive voice (bugs will be fixed…) Make sure that everyone has access to memos

Accept and welcome the debate Remember to ask ”stupid” questions Don’t shoot the messenger


Context 7: Poor communicationGets worse when number of stakeholders growsDo not underestimate the power informal

communication and face-to-face meetings, such as coffeebreaks

Locate the team members near to each others Some prefer ”war rooms” [Teasley, IEEE Tran SW

eng, 2002] I really like waiting for others in meetings,

especially looking at computer booting, projectorsetup, looking at file browsing and guessing the file version, waiting the slide show setup (it’sF5!)…NOT



Context7: poor comm + bad req



Just poor communication…


http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/6000/300/635


Context 8: Commercial pressure Rush to the market Feature explosion for marketing purposes (aka.

scope creep) Complicates development and maintenance, overhead

(area, mem. footprint, runtime, power)

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

In M

S W

röd

Overoptimizing the price Challenger

shuttle O-ring… Insufficient

resources Using cheap and

poor EDA tools


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

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

Conflict of interests arise in large consortium Maximizing personal/own group’ profit Not everyone is honest

Requires diplomacy and negotiation skills


Context 9: Stakeholder politics Opposing all changes vs. useless ”improvements” Legal and regulatory matters, auditing, certification ”Not invented here!” ”We have always done it that way” ”We can’t optimize that because that makes our

older product look stupid…” Elop effect: ”Hmm, this is surpising, our sales drop

catastrophically when we just said our product is crap and new ones are not coming soon”

”Are you absolutely sure that it does not infringeany existing patent?”

”Despite its novelties, we oppose your suggestionsfor optimization [because it may bring cutdowns in our budget in a long run]”

Elop effect: [http://communities-dominate.blogs.com/brands/2011/08/coining-term-elop-effect-when-you-combine-osborne-effect-and-ratner-effect.html]


Context 9: Stakeholder politics (2) ”We will offshore these jobs and the new people will master

them instantly. No problem.” ”At the moment, we can’t hire anyone to send the bills” ”No, I cannot serve the paying customer because I’m making

reports about our sales” ”We won’t sell your application at our store. And that is just

because. And we will sue your sorry ass if you complain” ”We have invested much money in this death march and

therefore we’ll continue on and on”


http://3.bp.blogspot.com/_Xq0nPfnJPHQ/S-1M-ZkeavI/AAAAAAAAAFs/uAbBPBbCxSY/s1600/dilbert.gif

#32/40 Department of Pervasive ComputingErno Salminen - April. 2011 http://i.snag.gy/kdu77.jpg


Reasons related to implementation



Impl 10: Use of immature technology

Or technology unfamiliar to the developers orvendors ”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 differential value achieved by being an early adopter

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

damage


Impl 11: Sloppy developmentpractices

No version control (see later slide) Some steps not repeatable by others than the orig. designer

Licenses, EDA tool setup/projetc files, local files, OS, undocumented tricks…

Creates a single point of failure, e.g. due to long sick leave Many manual, error-prone steps

Automate as mush possbile, e.g. with scripts make, run test, analyze_perf…

Unrecognized vendor-lock Proprietary file format prevents moving to better environment/chip Design works only with certain (old) tool/OS version

Non-existing/outdated/poor documentation Poor link between docs and code No review process No headers in files (designer, purpose, project…)


Impl 11: Sloppy developmentpractices (2)

Inadeqaute verfication/test suite Plain stupidity: ”What do you mean that price list must

be correct? It’s an estimate, get it?” – true story Ignoring the compiler warnings Dead code Inconsistent naming Not checking return values Not using assertions 25% of admin time spent going down blind alleys due to

bad msgs [Candea] Forgetting that code lives forever

Prepare that it will be read and modified many years afterdevelopment

”I hope someone else will check it” ”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 control Use version control (Git, SVN, ...)

Works well with text: .txt, .c, .h, .vhd, .tex, .java, .html., xml, .csv, .py… Teaches one to take logically consistent steps in a project

Add files, update, commit, check log… Not just for ”ready” files

Very few things are ready ever. Most things are somewhat ready and always under development

Depends on company policy regarding continuous integration Helps backup process

Easy throw-away code prototyping Keeps track of your work (how many

changes in a week?) Keeps track who did what One can go back to see any previous

version Write reasonable commit log messages Version control is must for all work


Impl 12: Inability to managecomplexity

Limit the scope Divide-and-conquer, separation (orthogonalization)

of concers 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 Automate the implementation via synthesis

Carry out a small pilot project first Remember it’s a proof-of-concept, not final implemtation!

Techniques for this challenge are addressed in TIE-50506 SystemDesign


Impl 12b: Inability to manage complexity

Many projects have hundreds to thousands of files “The most important aspect of any design is how it

is partitioned. The second most important aspect of any design is its interfaces.” – M. Keating Minimize coupling between modules Try to make functionality obvious Try to make misuse hard (e.g. add checks and asserts to

the code) Dst and source parameters always in the same order Similar naming convention Use consistent measurement units

If some function users meters as units, no function should use millimeters

Names should not be too long but they should also be to-the-point


SummaryMany things can go wrongSome things will go wrongOften most things go ok Ensure that they are the important ones Be careful and precise Understand the real problem Don’t be greedy – Prioritize – Min. viable product Prefer real work over bureaucracy Remember where the money comes from

Hopefully these generic lessons help you to recognize common pitfalls in real life and avoid them



Another views


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

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


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

1. Unrealistic schedules2. 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.” Agreed!

3. Changing requirements during development4. Poor-quality work5. Believing in magic

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


Another view of the schedule factors


[B.W. Boehm, Improving Software Productivity,

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

Each bar denotes a factor used in schedule estimation.

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

in schedule (cost). Such factors have been refined in COCOMO II and other similar estimation methodologies.


Productivity factors Table shows the best and

worst differences to nominal development

Decrease factor is usuallylarger than increase It is much easier to

mess up than beingextra productive

E.g. trying reuse crappySW is doomed, highrequirement creep dropsproductivity by 77%, skipping inspections by48%...

From: P. Goldberg, Producing Production QualitySoftware - Lecture 14, New York Univ., 2005, online

http://www.cs.nyu.edu/artg/Producing_Production_Quality_Software/Fall2005/


Further reading on project management

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

Pentium II, III, and 4 microprocessorsBrilliant stuff


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

of compromise, of trading-off one thing to another” ”The act of codifying one’s thinking unfailingly

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)

David Shippy and Mickie Phipps, The Race for a New Game Machine, KensinkgtonPublishing Corporation, 2008Designing Cell processor at

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

Xbox 360Authors lead the development of

the new PowerPC processorBrilliant stuff E.g. ”Eight is beautiful”


Further 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

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

The DailyWTF http://thedailywtf.com/

More 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

D. Galorath, Software Project Failure Costs Billions.. Better Estimation & Planning Can Help, Galorath Inc., June 2012, [online]. http://www.galorath.com/wp/software-project-failure-costs-

billions-better-estimation-planning-can-help.php

lect 14 project management k14 v01 - tuni · software project failure, j. defense sw eng., 2006]...

Documents