Skip to main content


The Deadline: A Novel About Project ManagementI read Tom DeMarco's 'The Deadline'. during x-mas holidays in 2006.  I am sharing a small excerpt from the book.

"We'll be doing GANNT Charts," Kalbfuss was saying, "and PERT charts, status reporting, a section on interfaces to the human resources department, conduct of weekly meetings, use of e-mail, filling out time cards, progress tracking, project milestone reporting, and - this is a new section that we're very excited about - setting up a quality program. Yes is that a question in the back ?" 

Mr Tompkins stood. "Yes. My name is Tompkins. My question is, Is that it ? Is that the whole agenda? "
"Yup, that's it," Kalbfuss answered confidently."
"That's your whole course on project management.?"
"Uh huh. Um. Do you feel something is missing?"
"Nothing important. Just the matter of people."
"Yes. We use people here to get projects done."
"Of course."
"I might have thought that you would have something about people in your course."
"Such as?"
"Well, hiring, for example. Hiring is only the most important thing a manager does."
"Probably is," Kalbfuss allowed. "We are not saying you shouldn't be doing that. We are not saying that it is not important to do it well either. And we are not saying..."
"Seems like you're not saying much of anything about it at all."
Kalbfuss looked down at this notes. 'Um. No, I guess not. Well, you see, hiring is one of those soft matters that's not too easy to teach."
"Not easy, only essential. I notice you also don't seem to have anything in your course about matching people to their work."
"No. That too is important. However,..."
"However, you won't be saying anything about it."
"Nothing either about keeping people motivated."
"No, Again, that's a soft subject."
"Nothing either about team building."
'Well , I will be saying how 'important' it is. How everybody should be thinking of himself, and here I might also say 'herself'... should think of himself or herself as a member of the team. We're all a team here, you know. Oh, yes. And i am going to stress how essential that is and how everybody should..."
"Yes, yes. But you won't say anything about how to build teams, how to keep them healthy, how to get them started, how to give them a chance of jelling, or any of that?"
"No. We'll be concentrating more on the hard science of management."
''You're going to teach us the hard science of management without even touching on people selection, task matching, motivation, or team formation - the four most essential ingredients of management?"
"Well, we're not going to talk about any of those. Does that bother you, Mr..."
"Tompkins. Yes, something bothers me."
"What bothers you?"
"That you've got a course that leaves those four things out and you want to call the course 'Project Management."
"Oh. So, it's just the title that bothers you. Well, what should we call it then?"
"How about 'Administrivia?"
There was a soft gasp in the room. Tompkins turned on his heel and walked out.
If you wonder why i recalled the above after more than three and half years, below is the reason.

Dated 27 Oct 1996 and i came across this today.


Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …