Comments on: Advising and Project Management http://magic.aladdin.cs.cmu.edu/2006/02/13/advising-and-project-management/ Algorithms are everywhere. Sun, 30 Aug 2009 23:42:14 -0400 http://wordpress.org/?v=2.9-rare hourly 1 By: Project Management Hut http://magic.aladdin.cs.cmu.edu/2006/02/13/advising-and-project-management/comment-page-1/#comment-31431 Project Management Hut Tue, 02 Jun 2009 20:45:02 +0000 http://magic.aladdin.cs.cmu.edu/?p=260#comment-31431 I think there's only one meaning if you're not getting an honest answer to your questions, you're either feared or not a respected Project Manager. Either case, you're not doing your job properly as communication constitutes 90% of all Project Management activities. I think there’s only one meaning if you’re not getting an honest answer to your questions, you’re either feared or not a respected Project Manager. Either case, you’re not doing your job properly as communication constitutes 90% of all Project Management activities.

]]> By: mukesh agrawal http://magic.aladdin.cs.cmu.edu/2006/02/13/advising-and-project-management/comment-page-1/#comment-216 mukesh agrawal Thu, 23 Mar 2006 23:07:24 +0000 http://magic.aladdin.cs.cmu.edu/?p=260#comment-216 i think you're too quick to conclude that trying several ideas and moving on won't work for systems research. the difference might just be that you have to make the decision to drop a project more quickly. (because you'll need a lot of time to finish the project that does look viable.) i think you’re too quick to conclude that trying several ideas and moving on won’t work for systems research. the difference might just be that you have to make the decision to drop a project more quickly. (because you’ll need a lot of time to finish the project that does look viable.)

]]> By: Maverick Woo http://magic.aladdin.cs.cmu.edu/2006/02/13/advising-and-project-management/comment-page-1/#comment-186 Maverick Woo Mon, 13 Feb 2006 23:00:43 +0000 http://magic.aladdin.cs.cmu.edu/?p=260#comment-186 I note that the advices inside this book can be of different effectiveness to different areas of Computer Science. In particular, it's more for Systems and less for Theory. In Theory, as you know, it's common to try quite a few problems without making significant progress and move on. It's part of research. But you cannot hope to do that in Systems. In this regard, that suggests failure management methods in this book cannot be blindly applied to Theory projects. The size of a team is also an important factor. Rarely do we have teams of over 5 people in Theory research. So perhaps we have an easier time to deal with the people dynamics than in software development. I note that the advices inside this book can be of different effectiveness to different areas of Computer Science. In particular, it’s more for Systems and less for Theory.

In Theory, as you know, it’s common to try quite a few problems without making significant progress and move on. It’s part of research. But you cannot hope to do that in Systems. In this regard, that suggests failure management methods in this book cannot be blindly applied to Theory projects.

The size of a team is also an important factor. Rarely do we have teams of over 5 people in Theory research. So perhaps we have an easier time to deal with the people dynamics than in software development.

]]> By: David Molnar http://magic.aladdin.cs.cmu.edu/2006/02/13/advising-and-project-management/comment-page-1/#comment-185 David Molnar Mon, 13 Feb 2006 09:40:47 +0000 http://magic.aladdin.cs.cmu.edu/?p=260#comment-185 Thanks for posting these links. I'll have to take a look at the book. I'm curious, though, to know if you have found any major points of divergence between advice for grad school and advice for software projects. For example, in my limited experience with software engineering, a lot of the projects and concerns are driven by external factors (e.g. what does the client need). Doing research and picking a research direction seems to have less of that pressure, although it's certainly present. Thanks for posting these links. I’ll have to take a look at the book. I’m curious, though, to know if you have found any major points of divergence between advice for grad school and advice for software projects. For example, in my limited experience with software engineering, a lot of the projects and concerns are driven by external factors (e.g. what does the client need). Doing research and picking a research direction seems to have less of that pressure, although it’s certainly present.

]]>