Comments on: Lean Projects Are Lean Projects http://www.reformingprojectmanagement.com/2005/04/24/484/ The magazine for the project age Sun, 12 Oct 2008 19:47:17 +0000 http://wordpress.org/?v=2.0.5 by: Jeff http://www.reformingprojectmanagement.com/2005/04/24/484/#comment-975 Sat, 21 May 2005 17:32:08 +0000 http://www.reformingprojectmanagement.com/2005/04/24/484/#comment-975 I enjoyed checking out your blog, nice work. If you have some time, please check mine out. It’s focus is project management, resource management, document management, help desk and we can be found at http://www.pbcinc.ca/blog I enjoyed checking out your blog, nice work. If you have some time, please check mine out. It’s focus is project management, resource management, document management, help desk and we can be found at http://www.pbcinc.ca/blog

]]> by: Glen B Alleman http://www.reformingprojectmanagement.com/2005/04/24/484/#comment-972 Wed, 11 May 2005 20:34:07 +0000 http://www.reformingprojectmanagement.com/2005/04/24/484/#comment-972 The second article can be generalized across many project domains. The first article seems to be specific to software development using agile processes. Building spacecraft is different than coding .net web apps. I only get one chance to weld the proplusion system piping right. If its not right the system has to be ripped out and redone, delaying the launch. So requirements, design, build, test are sequential, with high cermony transisition processes. The software that controls the propulsion system has the same attributes. The trouble I have with "general purpose" agile is it really is context free. The proponents many times fail to establish a specific context for their suggestions - assumping that all software is like their software. This is not only true it is misleading to the uninitiated. The core concepts of agile - feedback, small increments, test as you go, customer engagment, plan for change - are applicable across a broad spectrum. Putting them into practice is not the same has understanding the principles. As Yogi says "In theory there is no difference between theory and practice. In practice there is." Until we start putting our agile PM processes in a specific context, much of the discussion will remain around the theory not the practice. The second article can be generalized across many project domains. The first article seems to be specific to software development using agile processes.
Building spacecraft is different than coding .net web apps. I only get one chance to weld the proplusion system piping right. If its not right the system has to be ripped out and redone, delaying the launch. So requirements, design, build, test are sequential, with high cermony transisition processes. The software that controls the propulsion system has the same attributes.
The trouble I have with “general purpose” agile is it really is context free. The proponents many times fail to establish a specific context for their suggestions - assumping that all software is like their software. This is not only true it is misleading to the uninitiated.
The core concepts of agile - feedback, small increments, test as you go, customer engagment, plan for change - are applicable across a broad spectrum. Putting them into practice is not the same has understanding the principles.

As Yogi says “In theory there is no difference between theory and practice. In practice there is.”

Until we start putting our agile PM processes in a specific context, much of the discussion will remain around the theory not the practice.

]]> by: Diana Hutchinson http://www.reformingprojectmanagement.com/2005/04/24/484/#comment-970 Wed, 27 Apr 2005 15:39:55 +0000 http://www.reformingprojectmanagement.com/2005/04/24/484/#comment-970 These articles really ring true based on my experience with new product development. It reinforces my commitment to continue to fight for serial rather than parallel development of multiple products, and to avoid 100% + utilization of people. These articles really ring true based on my experience with new product development. It reinforces my commitment to continue to fight for serial rather than parallel development of multiple products, and to avoid 100% + utilization of people.

]]>