Herding Cats

New BLOG

2005-03-04T10:06:00.000-08:00

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

The Iron Triangle and Independent Variables

2005-02-27T19:20:00.000-08:00

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?

2005-02-27T07:53:00.000-08:00

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:

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.

Another briefer description is:

Systems engineering ensures the whole product works
together with its external systems to meet the needs of the customer.

The challange here is to include the people aspects of "engineering" and "project management" into this definition. A primary goal in systems engineering is to:

Harmonize Goals, Work
Products, and Organizations.

The final definition is:

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.

Cross Talk Articles

2005-02-26T20:15:00.000-08:00

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

Value flow is Earned Value Management

2005-02-24T12:45:00.000-08:00

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?

2005-02-24T11:47:00.000-08:00

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.

More DoI Thoughts

2005-02-23T21:52:00.000-08:00

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.

Declaration of Interdependence a revolution or "still forming" concept?

2005-02-19T07:48:00.000-08:00

"... 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.

Declarations of Interdependence for PM or General Business

2005-02-16T14:39:00.000-08:00

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

What's Wrong with PM that the DoI can fix?

2005-02-14T14:13:00.000-08:00

The declaration of Interdependence has got me hooked. Some BLOG'ers and posters are suggesting we throw away our PMBOK's. Well that might a good idea no matter what the DoI, but what exactly does DoI "fix?" The project management processes described in my favorite framework - CMMI IPPD Project Management Practices - provide a starting point for describing project management as a profession.
The DoI makes sense, maybe even common sense in most areas. But it has no stated target audience, project management domain, or assessment of the problem it is trying to solve. This latter issue is important in two ways:

The Agile Alliance Manifesto (AAM) stated they are uncovering better ways of developing software. There was little doubt that better ways were needed. From the Standish reports (which have poor statistics by the way) to personal experiences, to the head lines, there is a consensus that software development practices need improvement. Do project management practices need improvement as well?
The DoI is a statement of values, but unlike the AAM it does not include the phrase "while there is value in the items on the right, we value the items on the left more." This missing leaves DoI without a "counter balancing" foil to push against.

So if I look at the DoI through the eyes of an aerospace program manager, what are the "over" phrases that AAM so succinctly uses to define it's own value:

Increase return on investment by making continuous flow of value our focus - over what? What PM would say "let's no flow value to our customers." I know this happens but these are not good project management practices. Any core business management processes identifies the need to "earn back" investments in a timely manner. Do not do so woudl violate the simplest business processes. The Waterfall (old waterfall) processes are used I'm sure. But they are a red herring in any viable (mature) organization. Even the orginators of Waterfall at TRW abandoned this approach in the late 1970's
Deliver reliable results by engaging customers in frequent interactions and shared ownership - over what? "Let's don't deliver reliable results." This happens all the time I know, but it's a poor management practice. Even our very high ceremony CMMI IPPD based project management guide requires 20 to 40 day durations for deliverables. Monthly Management Reports are mandatory. Weekly status and resulting earned value is mandatory. 0%/100% or 50%/50% earned value, no vague percent complete allowed. No viable (mature) project management method would not state that frequent interaction with the customer is required. It's the shared responsibility that's troubling. What's the meaning of shared responsibility? The AAM uses the term "collaboration over negoiation." This a noble goal. The contracting environment of most large corporations does have something to say about this though. The DoI doesn't mention the context of "shared ownership." Is it within the team, between contracting entities, between buyer and seller? Without a context, sharing is to vague.
Manage uncertainty through iterations, anticipation and adaptation - over what? "Let's not manage uncertainty." Iterations can reveal gaps between the expectations of the buyer and the provider. Anticipating is more difficult, since it requires some form of clairvoyance. Experience helps as well. Adaptation is part of good project management processes, even in my beloved CMMI IPPD.
Unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference - over what? This has merit. The Dilbert-isk management styles found in some firms can be replaced by this value.
Boost performance through group accountability for results and shared responsibility for team effectiveness - over what? The Group Acountability value is a fundamental violation of good project management practices when applied to the boundaries between the customer and the provider. A "single point of integrative responsibility" is core to the integrity any project management method. Is DoI suggesting we give up this practice? If so, who does the project owner - say a City Planner managing the re-paving the Pearl Street Mall, here in Boulder, Colorado - talk to? The road gang supervisor, the asphalt truck driver, the broom pushers. No, she talks to the project manager. This value needs more clarification to be applicable outside the agile (small team) software development world.
Improve effectiveness and reliability through situationally specific strategies, processes and practices - over what? "Let's not use situationally specific strategies." I know there are bone headed managers that take out the PMBOK and apply it without once determining the effectiveness of the result. But this is bad management.

So is the DoI designed to help us identify bad management practices? If so, this is a positive step forward. But it feels to me like an odd way to do it, since there are dozens of "good management" books already in the market. Maybe these books, courses are not working? Is DoI targeted our our IPPD practices? If so, there are big holes that will go unfilled.

My questions is:

Is DoI targeted outside agile software development project?
If so, how do these values fit with the established practices of project management?
Where does the DoI add value, by improving the current processes?

Hopefulyy the answers to these could leads to other discussions, since there are still problems to be solved in the project management domain.

Agile Project Management

2005-02-13T19:36:00.000-08:00

There has been much discussion on the agile forums in the past weeks about the Declaration of Interdependence (DoI) for Agile Program Management. DoI's have a history of being made for nobel causes mostly around a "world view" of politics and the environment.

I had several gut reactions to this announcement:

The signators to the DoI are all authors, writers and "thought leaders" in the agile movement. Since I'm on the outside of this group my first reaction was "how does this DoI impact us here on the action side of PM?" That is, project managers, managing projects. Especially managing non-agile projects, or at least projects that are not expressed as agile projects?
After reading the DoI several times, I came away with "yea that's a nice idea, but how do I put it into practice." It's like reading a "best practice" process description. Not much to disagree with, but putting the words into action seems harder to do than to talk about.

I realize that the authors of the DoI did not intend this words for "actional outcomes" at this point and I of course reacted with my normal probably annoying manner - "how does this work in practice".

But here's the bigger issue for me and each of the DoI elements:

Increasing ROI by continuous flow value is a powerful idea. Is it the Project Manager that controls the outcome here or the business manager? In our environment it's the Program Manager and the Capture Manager that control the flow of "value." PM's keep score, defome some of the rules, but mostly keep score.
Deliver reliable results by engaging customers in frequent interactions and shared ownership. Frequent interactions have become common practice in most project management methods. Even our rolling wave high ceremony process for spacecraft development has monthly reviews of progress, verification of direction and performance. We'd be hard pressed to call ourselves "agile," but weekly project status, review and adjustments are mandatory for large civil and defense programs these days. Stating this is usful - but who is the audience?
Mange uncertainty through iterations, anticipations, and adaptation. All great concepts already in place in many high ceremony project management handbooks. DoD and NASA mandate spiral and iterative program methods.
Unleash creativity and innovation by recognizing individuals are the ultimate source of value... This is simply too much motherhood and apple pie for me. No mature project organization would say anything other than this when asked how they manage their "human resources." But the "shpow stopper" here is the shared responsibility and accountability.
Boost performance through group accountability... This is highly domain dependent. Since the target domain for the DoI is not stated (as yet), I'm hard pressed to either object for find a place in our process for this other than a "cafeteria poster." This DoI needs to determine if it is inward or outward focused. Inward focus is useful, outward focus violates many good magement practices the wrap around project management.
Improve effectiveness and reliability through situational specific strategies, process and practices. This seems to say "don't do stupid things on purpose."

The Bottom Line

Soe here's the basic issues:

Is Agile Project Management - the management of "agile projects" or is it "agile" management of project?
Can agile project management be applied to non-IT projects. The answer of course is yes, since there are already several "agile" project management processes in place, but the DoI doesn't credit them - yet.
Who is the target of the DoI? Is it the traditional (PMBOK style) project methods? Is it the CMMI IPPD project methods (where I work), is it the agile software development community that is trying to figure out how project management fits in?

There don't seem to be any answers to this question yet. I'm probably too early in the process to be asking these types of questions.

Putting Cost into the Schedule

2005-02-03T13:25:00.000-08:00

Just finishing the first round of integrated schedule and cost using Microsoft Project and Artemis Cost View. What this means for those not familiar with cost management aspects is that all the tasks in the schedule have resources assigned and are baselined. Baselined means things can't change without someone approving the changes.
Once Baselined, the resource loaded tasks are assigned a control account and work package and uploaded to Cost View. This is the Budgeted Cost for Work Schedules (BCWS) which is the planned send for each task.
As each task is statused every week a percent complete is generated. Percent complete times the plan is the Budgeted Cost for Work Performed (BCWP). Both BCWS and BCWP are loaded to Cost View - in that order. Once the Actual Cost for Work Performed is available - time cards in for the week, then Earned Value can be computed.
All of this may sound esoteric, but it is the basis of agile project management, since Earned Value depends on fine grained measurements of actual "value" produced by the project.

Integrated Cost and Schedule

2005-01-27T18:00:00.000-08:00

I've just finsihed a gruling week of an Integrated Baseline Review (IBR) for our $350M program. What has become clear is that integrating cost and schedule is not only hard work it is fraught with risk, flared tempers, and dead end efforts.
In the end of course the value is there, but starting down the path, we did not realize all the pot holes along the way. First cost and schedule are not natural friends. Planners like to lay out a schedule, assign dates, dependencies, and strutcure independent of resoruce assignments.
Cost control staff like to spread costs across date ranges, define funding profiles, and allocate costs to work packages and control accounts.
When these two disciplines meet, they have completly different paradigms regarding their jobs.

Cost management wants to bound the funding profiles to discrete work packages
Planning wants to provide a flexible and adaptive schedule

In the end a baseline must be arrived at, and that's where all the hard work comes in. This is an iterative process and that needs to be understood up front. Without this understanding of itertaive and incremental development of cost and schedule all the participants will be frustrated.

In the end of course we got it together - enough to pass the IBR - and are moving on to the next rolling wave of planning. The lessons learned include:

Take small steps
Keep lots of backups
Do everything in Excel first before loading it into a real database
Have frequent discussions about "where we are headed"
Test, test, and test so more
"Never give up"

Project Management as a Systems Engineering Discipline

2005-01-01T14:28:00.000-08:00

I've started a Mind Map of the concept that Project Management needs to be seen as a Systems Engieering discipline. It can be found at:

http://www.niwotridge.com/PMasSE/index.html

Contrarian

2004-12-24T13:45:00.000-08:00

"I've always been the kind of person who starts to become suspocious when the conventional wisdom, whatever it might be, starts to take on unanimity. When everyone starts to say someting, that is the time to start thinking about something else, because whatever it is that everyone thinks, is obvious. The world never stays that way."
- William Agee

The Meaning of Planning

2004-12-23T11:55:00.000-08:00

"... on the basis of the information that you have available, you do what can be done with the resources you have to be well positioned to deal with what you expect. It doesn't mean that you can correctly anticipate every development. It doesn't mean that you have the resources to deal even with every development that is anticipated. It is the worst kind of second guessing to suggest that because things didn't happen exactly as thought they would, somehow someone is responsible for the failure."

- Richard Perle

Introduction to Herding Cats

2004-12-22T10:46:00.000-08:00

Herding Cats is the "concept" statement for all the trials and tribulations of managing projects. I'm not a project manager by profession. I'm been "trained" in physics. I've practiced computer programming - as they referred to the skill in the 70's. But over the years I've moved into the profession of Program Management and the associated project management processes. This was a backdoor move, since I've led software development organizations, consulted for a decade in ERP, and been a founding member of two startups. In the end all this experience led me to the role of Program Manager in IT and high tech businesses.

All this is an introduction to the BLOG. I currently write a column for the PM Forum hosted by David Curling (www.pmforum.org). There I get to talk about project management processes, some of the good and bad approaches to the profession, my pet peeves, and hopefully some useful information from direct field experience

This field experience currently takes place in the aerospace industry. My employer is a consulting firm that provides professional services to a major Civil and Defense spacecraft builder. Our client is a household name, so you may recognize references to current events in the news.

Prior to this position I was a VP, Program Management for a major engineering and construction company, whose contract was with the Department of Energy. I directed the efforts of Project Managers, software developers, and project controls (finance) staff in an IT department.

My intent for the BLOG to provide an outlet for ideas that is finer grained than the current column, conference proceedings, and books and chapters.

I intend to discuss the following:

Current practices in project management
Issues with tools and techniques
Field experience with tools, processes, books, and other project management domain information
Recent encounters with project management "magic bullets"

So with this in mind I'll start the process of "stating what's on my mind," once I have an original thought.