Recommend a book for Project Management

[Chetan Parekh]

I am looking for a good book(s) that include following topics
(1)Complete SDLC Steps with in-depth discussion
(2)What reports will be generated at each stage of SDLC (with sample reports)
(3)How to do effort estimation
(4)How to add various kind of buffers

Please suggest me.

[Manish Hatwalne]

Two good books I can suggest on management (generic, not necessarily covering what you want) -

(1) Mythical Man Month, old classic
(2) Everyone needs a mentor

So Chetan, you're a manager now?? Wow!!

- Manish
[ September 14, 2006: Message edited by: Manish Hatwalne ]

[Masure Nilade]

Originally posted by Chetan Parekh:
(3)How to do effort estimation

Any project can be estimated accurately (once it's completed).

The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.

To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.

[Chetan Parekh]

Thnaks Manish. I will search them in book stores here.

[Chetan Parekh]

Originally posted by Masure Niladi:

Any project can be estimated accurately (once it's completed).

The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.

To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.

Can you tell me in which book you read this?

[Devesh H Rao]

Book called Personal Experience

[Chetan Parekh]

Originally posted by Manish Hatwalne:
Two good books I can suggest on management (generic, not necessarily covering what you want) -
(1) Mythical Man Month, old classic
(2) Everyone needs a mentor

Thanks Manish !!

Originally posted by Manish Hatwalne:

So Chetan, you're a manager now?? Wow!!

I have got new assignment. I jump one step ahead in this hierarchy.

[Peer Reynders]

Originally posted by Chetan Parekh:

Can you tell me in which book you read this?

I somehow suspect that the truth buried behind those somewhat exaggerated (for effect) statements is probably found in texts like:

Facts and Fallacies of Software Engineering by Robert L. Glass
amazonUS
Addison Wesley Professional

[Ilja Preuss]

Originally posted by Peer Reynders:

Facts and Fallacies of Software Engineering by Robert L. Glass
amazonUS
Addison Wesley Professional

Didn't like that book very much - contains a lot of critique, but near to zero constructive advice.

[Ilja Preuss]

Originally posted by Chetan Parekh:
(1)Complete SDLC Steps with in-depth discussion

This will heavily depend on the process you want to use. I like Agile approaches very much. "Sam's Teach Yourself Extreme Programming in 24 Hours" is a good introductory title for managers to one of the most prominent of them.

Another good title about the less tangible aspects of management is "Managing Agile Projects".

(2)What reports will be generated at each stage of SDLC (with sample reports)

The most important report, in my opinion, is a burn chart. See http://www.xprogramming.com/xpmag/jatRtsMetric.htm for a good introduction.

Another kind of "report" that is very valuable is the Daily Standup Meeting: http://www.mayford.ca/xp/standup_meeting.shtml

All other reports should be totally driven by the needs of your stakeholders.

(3)How to do effort estimation

I like the XP Planning Game for that. "Planning Extreme Programming" is a very good book on that topic.

I've also heard a lot of good things about "Agile Estimating and Planning", but haven't read it yet.

(4)How to add various kind of buffers

What do you think you need buffers for? Serious question.

[Chetan Parekh]

Thanks Ilja for valuable inputs.

Originally posted by Ilja Preuss:


What do you think you need buffers for? Serious question.

Will reply soon.

[Stan James]

Goldratt (The Goal, etc) talks about two forms of buffers that I liked.

In Theory of Constraints, Drum Buffer Rope has buffer holding the output of one step to be used as input to the next step. The buffer ensures that if the second station gets going a little faster than the first it won't go idle for lack of input. Overly large buffers (inventory) have huge expense and responsiveness problems so you want to keep them as small as possible, just barely big enough to avoid starving. For example our business analysts act as customer proxies. They try to stay ahead of the developer's need for "customer interaction" but not get so far ahead that their knowledge goes stale or that priority shifts make it worthless. It's not easy (understatement.)

In estimating, buffers are a bit of padding. When asked to give an estimate developers have two conflicting goals. One is to give the "best" estimate possible. An estimate is a statistical likelihood; given enough repetitions the average of your actuals ought to converge on your estimates. The other goal is to give an estimate you can safely make. Around here I hear "Give me a date you can commit to." Since there is always some uncertainty in a statistical likelihood, you add a buffer. This puts the poor developer in a classic Goldratt conflict - give my best estimate or my safe estimate?

Agile methods give you the freedom to give your best estimate at all times and adjust the plan based on actual performance. A largish project should have enough stories for the actuals to converge on the estimates - velocity levels out.

If you're not agile and you have to commit to a date then you can't afford your best estimate and you have to give yourself a buffer. A best estimate assumes each station or step in a process runs perfectly. If you have a sequence of steps with dependencies, any late step makes subsequent steps later, but any early step just piles up inventory in front of the next step. It's almost impossible for the whole project to finish early, but very likely it will finish late.

[Ilja Preuss]

Originally posted by Stan James:
In Theory of Constraints, Drum Buffer Rope has buffer holding the output of one step to be used as input to the next step. The buffer ensures that if the second station gets going a little faster than the first it won't go idle for lack of input. Overly large buffers (inventory) have huge expense and responsiveness problems so you want to keep them as small as possible, just barely big enough to avoid starving. For example our business analysts act as customer proxies. They try to stay ahead of the developer's need for "customer interaction" but not get so far ahead that their knowledge goes stale or that priority shifts make it worthless. It's not easy (understatement.)

The root problem I see here is that you are trying to optimize utilization. Lean Software Development (which adopted it from Lean Manufacturing) teaches us that that's not the best thing to do. What you should optimize instead is throughput - how long does it take for a single item to get from "a request from the customer" to "something that the customer can use".

And the way to optimize throughput is not by introducing buffers between stations - in fact buffers, as a form of inventory, reduce throughput. The way to optimize throughput is by having generalizing specialists - that way the team can shift man power around between activities (I hesitate to call it "stations") on an as-needed basis. No buffers needed.

Around here I hear "Give me a date you can commit to." Since there is always some uncertainty in a statistical likelihood, you add a buffer.

I'm not sure I'd call that a buffer. If I think I can commit to something that can be done with a likelihood of 90%, I'll give an estimate that has a likelihood of being met by 90%.

This puts the poor developer in a classic Goldratt conflict - give my best estimate or my safe estimate?

Where does the conflict come from? Isn't it totally *obvious* that I need to give the safe estimate in such a situation?

A largish project should have enough stories for the actuals to converge on the estimates - velocity levels out.

If you're not agile and you have to commit to a date then you can't afford your best estimate and you have to give yourself a buffer.

Why wouldn't the estimates level out on a non-Agile project in the same way they do on an Agile project?

A best estimate assumes each station or step in a process runs perfectly. If you have a sequence of steps with dependencies, any late step makes subsequent steps later, but any early step just piles up inventory in front of the next step. It's almost impossible for the whole project to finish early, but very likely it will finish late.

Ah, so the trick of an Agile project is to not have those dependencies allow to become bottlenecks?

[Stan James]

The root problem I see here is that you are trying to optimize utilization.

Yeah, I didn't make clear that it's not optimizing utilization of all stations but primarily the bottleneck. One aspect is a buffer to assure it never goes idle because that time directly affects throughput. If a non-bottleneck goes idle it really doesn't matter much. I've read that scheduling thought workers over about 80% utilization doesn't pay. Except for the poor SOB at the bottleneck.

The way to optimize throughput is by having generalizing specialists - that way the team can shift man power around between activities (I hesitate to call it "stations") on an as-needed basis.

Yes, something to that effect distinguishes software from machine based manufacturing if you can pull it off. Our culture is still specialists, period, and getting worse instead of better. Work is passed from one subteam to another, so the manufacturing metaphors fit pretty well. But in the best world it still takes non-zero time to pull someone from one task to another. Small tasks (stories)and small batches (iterations) really help.

Isn't it totally *obvious* that I need to give the safe estimate in such a situation?

No, because over time management will realize your safe estimates are padded and stop believing them. Of course it's management's fault for asking for solid commitments, but they won't remember that. I suppose you could finish early and surf the web the rest of your time but you want to be known as a good estimator AND a good deliverer.

Why wouldn't the estimates level out on a non-Agile project in the same way they do on an Agile project?

Part of the beauty of agile stuff is realizing that change happens, the original estimate is probably not going to be the actual, and everybody cooperates in planning the changes together. Accurate estimates and stable velocity are good. Non agile management tends to hand out a date, scope and budget and grade on making all three. Estimating long and always making the date are rewarded.

Ah, so the trick of an Agile project is to not have those dependencies allow to become bottlenecks?

Yes, I think that works out nicely. A pair of generalizing specialists can take a small task from beginning to end with minimal dependencies and hand-offs.

I'd guess we're very close on visions of the ideal. I'm just a lot further from it than you are these days. I was trying to suggest some places the OP might run into buffers, not a perfect state.

[ September 20, 2006: Message edited by: Stan James ]
[ September 20, 2006: Message edited by: Stan James ]

[Ilja Preuss]

Originally posted by Stan James:
Yes, something to that effect distinguishes software from machine based manufacturing if you can pull it off. Our culture is still specialists, period, and getting worse instead of better. Work is passed from one subteam to another, so the manufacturing metaphors fit pretty well.

Well, you know, even top manufacturing teams aren't doing that any longer.

Seriously, Lean Manufacturing teams, such as at Toyota, are crossfunctional teams that produce a whole car together, from beginning to end.

--------------------------------------------------------------------------------
Isn't it totally *obvious* that I need to give the safe estimate in such a situation?
--------------------------------------------------------------------------------

No, because over time management will realize your safe estimates are padded and stop believing them. Of course it's management's fault for asking for solid commitments, but they won't remember that. I suppose you could finish early and surf the web the rest of your time but you want to be known as a good estimator AND a good deliverer.

I'm certainly not suggesting the latter, but I also don't accept that it's totally managements fault. I'd also rather have the realize what a safe estimate means earlier than later. In fact, if I don't make sure that they understand it from the very beginning, and seriously commit to it, it's no surprise that they don't feel good about it.

Hell, why don't provide them with both estimates? "I can commit to do this in no more than three weeks. If all goes well, I expect to be already finished in two, though."

--------------------------------------------------------------------------------
Why wouldn't the estimates level out on a non-Agile project in the same way they do on an Agile project?
--------------------------------------------------------------------------------

Part of the beauty of agile stuff is realizing that change happens, the original estimate is probably not going to be the actual, and everybody cooperates in planning the changes together. Accurate estimates and stable velocity are good. Non agile management tends to hand out a date, scope and budget and grade on making all three.

Well, of course we all know what happens in those cases: either one of those three things later is discovered to be not fixed at all, or we deliver shit.

Estimating long and always making the date are rewarded.

I've never been at a place where that was true. But anyway, I don't understand how this is related to estimates not leveling out. Could you please elaborate?

I was trying to suggest some places the OP might run into buffers, not a perfect state.

Ah, I understood you to propose places where you'd *want* to have buffers. Thanks for the clarification!

[Stan James]

Well, you know, even top manufacturing teams aren't doing that any longer. Seriously, Lean Manufacturing teams, such as at Toyota, are crossfunctional teams that produce a whole car together, from beginning to end.

Yes, I remember reading as long as 20 years ago that 9 people built a Saab from start to finish. Fantastic concept. The Goal was more about machine shop kind of operations - though he never said exactly what was being made. You have a milling machine and a milling guy, a lathe and a lathe guy. It's absolutely a good thing for knowledge workers to get away from that and work something end to end, but some folks have the idea that the way to CMMI is specialist subteams, often under different management so you have to negotiate priorities with them as external partners, have sign-off and hand-off ceremonies. Painful.

David Anderson's "Agile Management for Software Engineering" promises to show how he used DBR and other Goldratt ideas, but the opening chapters put me to sleep. Maybe I should try again.

Hell, why don't provide them with both estimates? "I can commit to do this in no more than three weeks. If all goes well, I expect to be already finished in two, though."

There exist command-control hierarchies that aren't interested in what might happen, only what they can promise up the line. When promises are missed, yelling ensues. You wouldn't have an opening there would you?

But anyway, I don't understand how this is related to estimates not leveling out. Could you please elaborate?

I was guessing that velocity will be consistent and reliable only if everyone is giving "best" estimates, which I suggested is defined as actuals converging on the estimate or staying within acceptable variances over enough cases. I wouldn't expect the longer "safe" estimates to do that as well. They might be consistent, tho.

Sort of on topic ... I'm intrigued by folks who say their mix of small, medium, large stories is near enough the same over time that they can plan releases and iterations just by the number of stories and not even sum up the story point estimates.

[Michael Farinha]

I'm anxiously awaiting this book:
http://www.amazon.com/Head-First-Pmp/dp/0596102348/sr=8-1/qid=1159285597/ref=pd_bbs_1/102-9712155-5368966?ie=UTF8&s=books

[Stan James]

It's been a few days, but here is a WhitePaper that happens to cover the ToC buffering ideas nicely. It may well be that they don't apply to a small agile team with few handoffs.

[Ilja Preuss]

Originally posted by Stan James:
It may well be that they don't apply to a small agile team with few handoffs.

I just started reading the paper, but the phrase "the ability to execute to plan" catched my attention. That's exactly *not* what Agility is about!

[Ilja Preuss]

Originally posted by Stan James:
It's been a few days, but here is a WhitePaper that happens to cover the ToC buffering ideas nicely.

It seems I stopped reading before I got to the buffering point. Perhaps it's just me, or the late hour, but somehow the whole paper sounds way too much like "resource management" and "dealing with politics" to me, where it should instead talk about true collaboration and honest, respectful communication. :shrug:

[Paul Santa Maria]

I would strongly recommend taking a look at this book:
Effective Project Management, 3rd Edition
Robert K. Wysocki, Rudd McGary
[ September 30, 2006: Message edited by: Paul Santa Maria ]