Friday, March 04, 2005
New BLOG
Brian Kennemer pointed me to a new BLOG host that can be syndicated
http://herdingcats.typepad.com/
Is the new location. This BLOG will stick around for awhile, then fad away. See ya at the new location
http://herdingcats.typepad.com/
Is the new location. This BLOG will stick around for awhile, then fad away. See ya at the new location
Sunday, February 27, 2005
The Iron Triangle and Independent Variables
Stuart asked the question about the difference between a Spider Diagram and the Iron Triangle.
- The Iron Triangle tries to portray there are three variables in a project: Time, Cost and Scope. They are connected in an "iron triangle." If one moves - gets larger - then the other two are effected in some way. Usually this way is they have to get larger as well. Imagine stretching one side the triangle, then to other tow side grow in proportion. The problem of course is the mechanics of the triangle have strange behaviors in practice. I can stretch the time and not impact the scope but just the cost, but pulling on the top of the triangle. I could pull on the lower right corner and stretch the Cost and Schedule leaving the time the same.
But this of course is an oversimplification of real projects.
- The Spider diagram provides more dimensions and also provides a description of the interaction between these dimensions that MAY not impact other dimension. It is assumed and in fact mandatory in the Iron Triangle for at least one other dimension to change in response to ANY change.
- The Spider diagram shown in the example allows a two stage change between the variables. The Spider diagram (actually a Spider Chart) was developed in the product marketing domain, to show relationships between products.
So to answer Stuart's question:
- More dimensions
- More independence between variables
- An arbitrary number of variables
Is Agile Project Management Just Good Systems Engineering?
The Agile Development Conference is coming to Denver. I've given some thought to writing a paper for the conference. My past papers for ADC and XP Universe were focused on code development in CMMI environments. In the past 4 years I've become deeply embedded in large integrated projects with many partners and subcontractors. The primary process used to manage both the business and technical aspects of these projects is Systems Engineering.
The Systems Engineering discipline provides the Framework for not only agile project management but also the Declaration of Interdependence (DoI). Contrary to some statements, DoI as well as most of the agile project management processes are already embedded in Systems Engineering. In the context of Systems Engineering, APM and DoI are not new paradigms. Maybe a newly discovered existing paradigm. But not new. Using the EAI/IS632 definition:
The Systems Engineering discipline provides the Framework for not only agile project management but also the Declaration of Interdependence (DoI). Contrary to some statements, DoI as well as most of the agile project management processes are already embedded in Systems Engineering. In the context of Systems Engineering, APM and DoI are not new paradigms. Maybe a newly discovered existing paradigm. But not new. Using the EAI/IS632 definition:
Another briefer description is:Systems engineering is "an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system people, products, and process solutions that satisfy customer needs.
Systems engineering ensures the whole product worksThe challange here is to include the people aspects of "engineering" and "project management" into this definition. A primary goal in systems engineering is to:
together with its external systems to meet the needs of the customer.
Harmonize Goals, WorkThe final definition is:
Products, and Organizations.
Systems Engineering produces both the product and the processes for producing the product.With these definitions in mind, Agile Project Management can now have a foundation beyond the core work processes found in PMBOK and CMMI IPPD PM. It can address the "whole" of a project, technology, business and people.
Saturday, February 26, 2005
Cross Talk Articles
The March 2005 Issue of CrossTalk has several articles that are appropriate to agile project management.
- A description of Micorsoft's IT organization and its work processes
- Personal earned value and consistently meeting schedule commitments
- Watts Humphrey's 12 reasons software development projects fail
For those not familiar with CrossTalk it is the Journal of Defense Software Engineering
Thursday, February 24, 2005
Value flow is Earned Value Management
The latest "discovery" in the agile project management world is "value flow." This is one of the core outcomes of Earned Value Management. The "value" earned as task complete and the program matures are defined by the Budgeted Cost for Work Performed (BCWP). This value can be represented in several ways:
- Physical value of the completed work. Automobile transmission housings ready for assembly in the Toyota Camery's flowing down the assembly line.
- Propulsion systems piping welded in place for the Mars lander
- Software modules checked into the repository after having passed 100% of the unit test
When the Agile Project Management forums speak of "value flow" this is directly represented in the EIA-748A Earned Value Management System specification. This is the "value" in Earned Value.
Melt Down Your Iron Triangle?
I get the sense at times that those who come late to the party try to catch up by making a scene about problems that have already been addressed. The "melting of the Iron Triangle" is the current example
The concept of the Iron Triangle of project management: Cost, Schedule, and Scope is not only outdated but inappropriate in most situations. The "triple constraints" - the Iron Triangle - was a familiar approach to illustrating the tradeoffs of the dependent variables of a project. Turns out those ranting against the Iron Triangle have missed the boat on the replacement of the simple three independent variables. Max Wideman has a article on adding quality to the first three variables.
A further view of the dependent variable constraints is a Spider diagram that shows 10 or so independent variables of the project and how they impact the total project as a collection. This approach provides not only more dimensions, but physically represents the relationship - independent and dependent - between the variables. The spider diagram started in product marketing and has spread to other domains.
So like many "generalizations" melt your Iron Triangle starts out as an over simplification, but stimulates further discussion.
The concept of the Iron Triangle of project management: Cost, Schedule, and Scope is not only outdated but inappropriate in most situations. The "triple constraints" - the Iron Triangle - was a familiar approach to illustrating the tradeoffs of the dependent variables of a project. Turns out those ranting against the Iron Triangle have missed the boat on the replacement of the simple three independent variables. Max Wideman has a article on adding quality to the first three variables.
A further view of the dependent variable constraints is a Spider diagram that shows 10 or so independent variables of the project and how they impact the total project as a collection. This approach provides not only more dimensions, but physically represents the relationship - independent and dependent - between the variables. The spider diagram started in product marketing and has spread to other domains.
So like many "generalizations" melt your Iron Triangle starts out as an over simplification, but stimulates further discussion.
Wednesday, February 23, 2005
More DoI Thoughts
A recent post on the Agile Project Management forum suggested that the PMBOK processes were not processes, but phases similar to those found in the Microsoft Foundation. As Bill Duncan was fond of reminding me in our early days - this was an ill-informed understanding of PMBOK. He used stronger words, but I got the point. Chapter 3's title is Project Management Processes. It can't get much cleared than that. The illustrations in Chapter 3 and other areas could use some scrubbing so as to not confuse the reader between process and phase, but the text is quite clear what the fie processes are: Initiating, Planning, Controlling, Executing, Closing. As well in this chapter are several illustrations of how project managers interact with their "customers." Interestingly not one of the illustrations has the PM at the top of a pyramid. As Frank Patrick has mentioned - "if only it were true."
My first conclusion is that the poster has not read PMBOK or at least not understood PMBOK. But many have read PMBOK and not understood, therefore mis-interpreted it. I did just that with the illustration of a somewhat obsolete spiral software development methodology. My mistake was interpret this as the "suggested methodology for software" and get all wrapped around the axel about how PMBOK recommended methods - not agile methods BTW - rather than just define processes. Duncan (he goes by his last name) the principal author if PMBOK 2000 clarified my mis-interpretation in short order. PMBOK is still not my preferred starting point - CMMI IPPD PM has a better framework from which to extract processes into methods.
What's of bigger concern is the apparent ill-informed approach to the use of PMBOK and other process focused guides. The quoted materials from BLOGs of "burn your PMBOK," "melt down the Iron Triangle," which BTW is poor representation of a multi-dimensional "trade space" for project management but more on that latter. This approach of "setting fire" to the underlying process in the name of paradigm shifts may be part of an "extreme" mentality for a branch of the software development community. I can't really say, since my software development management experience is based in CMMI IPPD processes which does use XP as an execution method. Radical behaviors are somewhat restrained in our clearance-centric development environment. But having attended and even spoken at Denver XP outings I appreciate their point of view. I don't agree, but I can appreciate.
The challenge comes when moving extreme programming into the project management domain. One view of Project Management is about guiding, illuminating, and keeping score over the money, time, and staff, not about value deliverly - this is the role of the developers or manufacturers of products or services. The blending of project management with product development has caused much confusion of late. Some see the two as the same role - the agile PMers, others see a clear separation between process and product - the PMBOK definition. I'm in the middle at times. Some PM processes having been absorbed into product development methods, other remaining independent of product development.
PM's are not "in charge" or should not be from the point of view of technical content. In some firms Project Management is called Project Controls (this is common in large construction management first). In aerospace, Planning is the domain where you find cost and schedules. In aerospace, Cost is managed by Cost Managers. This aside, project managers, as Frank Patrick reminds us, in many business domains are service providers to the project leaders. As such the processes used for managing projects need to fit the needs to the "customers" of project or program managers. Here in aerospace the Program Manager needs information about cost and schedule. This comes from earned value metrics, schedule structure metrics - late starts / late finishes - which personally isn't very useful. But TOC style metrics are very useful in this domain. We call this margin erosion, since the buffers are explicitly placed inline with the critical path.
Since I earn a living trying to manage projects ranging from ERP deployments, large and small software teams, and now systems level integrations of hardware and software - any improvements to the tools and processes is of vital interest to me personally and professionally. But agile project management - although a nice sounding phrase - needs some further definition.
First is Agile Project Management the management of Agile Projects. Those projects being almost exclusively software development projects. Many XP or Scrum based firms have some form of "project management" methodology they use to wrap XP to isolate it from the larger business process of funding, contractors and the like. This allows to users of XP to do what they do best - write code, high quality on time on budget code. The other approach to Agile Project Management is the Agile Management of projects. There are already some methods that approach this - Last Planner for construction.
As a side bar there has been mention of "value production" in the DoI. In most management literature these processes would be found in "production management" rather than project management - but that's a whole other topic to argue about. This and the other DoI principles seem to fit into this categorization - from my experience with production management and production strategy - better than in project management. Project management at least in the domains I work is about cost and schedule. The DoI principles being found in broader business management processes. Being a fan and user of Balanced Score value production is an objective of Financial and Customer portions of BSC. I realize there are those who may want to redefine this connection as well as redefine processes of PMBOK and phases, but this is ill-advised simply because if confuses everyone who works with these definitions.
This brings me to the paradigm shift suggestion. Being a physics person by training and early practice, Thomas Kuhn is popularly quoted when paradigm shifts comes to mind. The critical concept from Kuhn - as he observed - is that the new paradigm must support the experimental outcomes of the previous paradigm. The theoretical aspects are replaced in whole or in part, but the experimental numbers, laboratory pictures, and measurements need to move forward and be explainable by the new paradigm. Using paradigm shift words in Agile Project Management discussion would seem to lead to the question - where are the 5 PMBOK and the similar process areas defined in IPPD PM found in the new paradigm. This is not addresses DoI but to any suggested new paradigm. In the new paradigm how does the PM initiate a project, connect cost with progress, interact with partners or subcontractors? Even partners have contracts, a marriage contract comes to mind. Even consultants have contracts or certainly should. The suggestion that contracts are somehow evil usually comes from those who have not experienced a legal dispute - either from the lawn mowing company or procuring of millions of dollars of software.
So independent of the DoI, what is Agile Project Management? How can agile business and development process be moved into the project management domain? How can the current project management processes be made more agile? These are the concerns of project managers. This is hopefully the basis of discussing agile project management.
My first conclusion is that the poster has not read PMBOK or at least not understood PMBOK. But many have read PMBOK and not understood, therefore mis-interpreted it. I did just that with the illustration of a somewhat obsolete spiral software development methodology. My mistake was interpret this as the "suggested methodology for software" and get all wrapped around the axel about how PMBOK recommended methods - not agile methods BTW - rather than just define processes. Duncan (he goes by his last name) the principal author if PMBOK 2000 clarified my mis-interpretation in short order. PMBOK is still not my preferred starting point - CMMI IPPD PM has a better framework from which to extract processes into methods.
What's of bigger concern is the apparent ill-informed approach to the use of PMBOK and other process focused guides. The quoted materials from BLOGs of "burn your PMBOK," "melt down the Iron Triangle," which BTW is poor representation of a multi-dimensional "trade space" for project management but more on that latter. This approach of "setting fire" to the underlying process in the name of paradigm shifts may be part of an "extreme" mentality for a branch of the software development community. I can't really say, since my software development management experience is based in CMMI IPPD processes which does use XP as an execution method. Radical behaviors are somewhat restrained in our clearance-centric development environment. But having attended and even spoken at Denver XP outings I appreciate their point of view. I don't agree, but I can appreciate.
The challenge comes when moving extreme programming into the project management domain. One view of Project Management is about guiding, illuminating, and keeping score over the money, time, and staff, not about value deliverly - this is the role of the developers or manufacturers of products or services. The blending of project management with product development has caused much confusion of late. Some see the two as the same role - the agile PMers, others see a clear separation between process and product - the PMBOK definition. I'm in the middle at times. Some PM processes having been absorbed into product development methods, other remaining independent of product development.
PM's are not "in charge" or should not be from the point of view of technical content. In some firms Project Management is called Project Controls (this is common in large construction management first). In aerospace, Planning is the domain where you find cost and schedules. In aerospace, Cost is managed by Cost Managers. This aside, project managers, as Frank Patrick reminds us, in many business domains are service providers to the project leaders. As such the processes used for managing projects need to fit the needs to the "customers" of project or program managers. Here in aerospace the Program Manager needs information about cost and schedule. This comes from earned value metrics, schedule structure metrics - late starts / late finishes - which personally isn't very useful. But TOC style metrics are very useful in this domain. We call this margin erosion, since the buffers are explicitly placed inline with the critical path.
Since I earn a living trying to manage projects ranging from ERP deployments, large and small software teams, and now systems level integrations of hardware and software - any improvements to the tools and processes is of vital interest to me personally and professionally. But agile project management - although a nice sounding phrase - needs some further definition.
First is Agile Project Management the management of Agile Projects. Those projects being almost exclusively software development projects. Many XP or Scrum based firms have some form of "project management" methodology they use to wrap XP to isolate it from the larger business process of funding, contractors and the like. This allows to users of XP to do what they do best - write code, high quality on time on budget code. The other approach to Agile Project Management is the Agile Management of projects. There are already some methods that approach this - Last Planner for construction.
As a side bar there has been mention of "value production" in the DoI. In most management literature these processes would be found in "production management" rather than project management - but that's a whole other topic to argue about. This and the other DoI principles seem to fit into this categorization - from my experience with production management and production strategy - better than in project management. Project management at least in the domains I work is about cost and schedule. The DoI principles being found in broader business management processes. Being a fan and user of Balanced Score value production is an objective of Financial and Customer portions of BSC. I realize there are those who may want to redefine this connection as well as redefine processes of PMBOK and phases, but this is ill-advised simply because if confuses everyone who works with these definitions.
This brings me to the paradigm shift suggestion. Being a physics person by training and early practice, Thomas Kuhn is popularly quoted when paradigm shifts comes to mind. The critical concept from Kuhn - as he observed - is that the new paradigm must support the experimental outcomes of the previous paradigm. The theoretical aspects are replaced in whole or in part, but the experimental numbers, laboratory pictures, and measurements need to move forward and be explainable by the new paradigm. Using paradigm shift words in Agile Project Management discussion would seem to lead to the question - where are the 5 PMBOK and the similar process areas defined in IPPD PM found in the new paradigm. This is not addresses DoI but to any suggested new paradigm. In the new paradigm how does the PM initiate a project, connect cost with progress, interact with partners or subcontractors? Even partners have contracts, a marriage contract comes to mind. Even consultants have contracts or certainly should. The suggestion that contracts are somehow evil usually comes from those who have not experienced a legal dispute - either from the lawn mowing company or procuring of millions of dollars of software.
So independent of the DoI, what is Agile Project Management? How can agile business and development process be moved into the project management domain? How can the current project management processes be made more agile? These are the concerns of project managers. This is hopefully the basis of discussing agile project management.
Saturday, February 19, 2005
Declaration of Interdependence a revolution or "still forming" concept?
"... Declaration of Interdependence. Burn your PMBOK guide as a sacrifice to the gods of uncertainty! Melt down your iron triangle and embrace the flow of value! ..."
"What we believe is that projects still need to be managed. However, the formal PMBOK style role of project manager (as the head of the hierarchical pyramid) is almost certainly the wrong model."
Are these the motivational words of a paradigm to produce dramatic changes in project management processes? These principles - not matter how noble - seem to have little connection with practice managing projects at the planning and execution level. Are the authors suggesting we toss out the process of initiating, planning, controlling, executing and closing. Not these are "processes" executed in any order needed for the problem domain.
I'm obviously on the outside looking in - and annoying those who's idea this is - but it seems to me that rhetoric around DoI has set the tone that we in the profession need to abandon our past in order to improve our processes. There are certainly problems in the project management world, but tossing out PMBOK (not my favorite anyway), CMMI IPPD, and the best practices of finance and business operations (that's where project management lives in aerospace)? Like any good agile project, the authors should have gotten some feedback from some project managers in the field before completing the iteration.
Please tell me this is not way to improve the profession of project management.
"What we believe is that projects still need to be managed. However, the formal PMBOK style role of project manager (as the head of the hierarchical pyramid) is almost certainly the wrong model."
Are these the motivational words of a paradigm to produce dramatic changes in project management processes? These principles - not matter how noble - seem to have little connection with practice managing projects at the planning and execution level. Are the authors suggesting we toss out the process of initiating, planning, controlling, executing and closing. Not these are "processes" executed in any order needed for the problem domain.
I'm obviously on the outside looking in - and annoying those who's idea this is - but it seems to me that rhetoric around DoI has set the tone that we in the profession need to abandon our past in order to improve our processes. There are certainly problems in the project management world, but tossing out PMBOK (not my favorite anyway), CMMI IPPD, and the best practices of finance and business operations (that's where project management lives in aerospace)? Like any good agile project, the authors should have gotten some feedback from some project managers in the field before completing the iteration.
Please tell me this is not way to improve the profession of project management.
Wednesday, February 16, 2005
Declarations of Interdependence for PM or General Business
I came across Alistair Cockburn's site with a quote that sums it up for me.
"Also, many of you will notice that there is precious
little about these 6 sentences that are unique to 'project' management; and more
they are common across all managment. Perhaps this should just be called the DOI
of modern management?"
Although there are many definitions of Project Management it is not General Management
