Q1 - Hi Glen. I think I first met you either via a comment you put on my blog or on the newgrange project management email list. Anyway, it's been a long time but since we live worlds apart, we've never met. Here's what I think I know about you - you're a big hitting PM, with a strong history in aerospace; you live somewhere sunny; you like cycling; and, you're a fast typer. How close is that and what did I miss? Can you tell us a bit more about yourself?
I do work in the aerospace and defense business, but those domains have large IT projects associated with them as well. Our firm – Lewis & Fowler - provide delivery services to commercial as well as defense clients. Our approach to managing projects is called Deliverables Based Planning ® and is based on the principles of Integrated Master Plan / Integrated Master Schedule found in the US Department of Defense. This approach defines and measures progress through Accomplishments and their Criteria measures as 100% or 0%. Either you did what you said you had planned to done during these period or you didn’t. No partial completion. No almost done, or “I’ll catch up in system test.”
While I personally work in the defense side of software development, ERP, CAD, application software for ground systems, flight systems, and on orbit operations are common. Software development is still a large percentage of most defense and aerospace programs. But I also work in commercial domains. Mostly with ERP and Enterprise applications. These two domain have similar attributes – mission critical development, distributed teams, rapidly changing requirements, emerging technologies, and inconsistent funding sources. Agile as a principle provides a framework for “managing in the presence of change,” rather than the more conventional approach of “trying to manage change.”
One critical aspect of my work is the separation of “managing projects” from “developing code.” Many might say these are the same, and I actually held that view at one point. But it is not the case. The management of projects involves aspects that are not found in agile software development activities. The primary missing attribute is the discovery of the business value. Agile development assumes the “customer” can articulate this business value and use it to prioritize the work for the next iteration. This is usually not the case for larger projects. Therefore some form of Business Capabilities and the associated Requirements Management must take place. The next attribute is resource management. If there is truly a single team in the same room with the customer, then resource management is self managed. In the absence of this “ideal” world, someone needs to plan for the allocation of resources.
Comments