Coupling, coherence, and other stuff

---

Has someone in your PMO suggested applying a dose of system engineering to portfolio management? If they have, I wonder if they think of it as "three C's and D"?

A bit cryptic? Well, not so much when you spell it out:
Coupling, coherence, cohesion, and diversification

The short form explanation of  three C's and D looks like this:

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. 

 

In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

Diversification

Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management. 

---

Buy them at any online book retailer!

The book of Teams for Portfolio and PEO

---

I'm willing to bet that every PEO (program executive officer) in the Pentagon has read General McChrystal's book*, titled "Team of Teams". This book is this year's book on teamwork for the big dogs: PEO's, portfolio managers, and large scale program managers.

Obviously, it's written in a pseudo-military context, covering mostly McChrystal's time in Iraq as the senior special forces commander, but the lessons are easily ported to the civilian domain of large scale projects and business or agency endeavors.

What's in it for program managers and portfolio leaders
The big takeaways are given by the title of the book:

• The payoff and advantages of teams at small scale -- shared commitment, speed, and collaboration to achieve mission and goal -- are obtainable at large scale
• By corollary, reduction-style organization (or "reductionism" in McChrystal's vernacular) -- by which is meant hierarchical work breakdown with parallel breakdown of management tasks -- is too slow and too myopic, and too prone to suboptimizing for tactical advantage
• Networks replace hierarchies; senior management and middle management are all nodes on a common network.
• As in all networks, multi-lateralism replaces stove-piped escalation.
• There is network access to decision-making data
• Complexity is a world onto itself; complexity is a lot more than complicated, because complex systems and situations defy exact forecasting and understanding

For McChrystal, and especially in a context of time-sensitive opportunities, the first point (dare I say 'first bullet'?) is the main point: it's really speed of decision-making and deployment, made possible by breadth of collaboration.

You can't get rid of some stovepipes
One thing he says that struck me is that no matter how extensive a network, at some point it comes up against the boundary of another network or a stovepipe which is not transparent. Then what?

His solution is to send someone into the other camp to be a emissary and collaborator. In the world of States, we call these people ambassadors. The concept is applicable to stovepipes and other management challenges.

ToT is not a new idea, but McChrystal's insights are worthy
In all the project management books I've written over the past 15 years, I've extolled the advantages of teams of teams, though my experiences are small set beside McChrystal's. So, in some ways, I'm a very sympathetic reader of what McC has to say:

• ToT is not efficient and not inherently lean. Teams overlap; teams have redundant staff and materials; a lot of the network communication is not useful to many who hear it. Reduction style management is F.W. Taylor's management science: everything lean to the point of no excess cost anywhere. But Taylor was not a team guy! (Attention: agile planners. Agile is not particularly efficient either)
• Reduction style plans are fragile: subject to breakdown in supply and timetables, and require expensive re-work when things go awry (who's not heard: plans are the first casualty of reality?). But.... such plans can be the best way to do something if only all the risk factors would go away.
• Complexity is non-linear and may be all but unbounded: Nobody has ever calculated how many game of chess there are. "By the third move, the number of possibilities has risen to 121 million. Within 20 moves, it is more than likely you are playing a game that has never been played before"
• Big data won't save us: Ooops! did McC not get the memo? Big D is the answer to everything. Well, except for the complexity thing. Just ask the climate people to predict the weather. But, the antidote, by McC's reckoning, is to time-box or pin things to a horizon.  Just handle the data and complexity " ... over a given time frame."
• "Prediction is not the only way to confront threats; developing resilience, learning how to reconfigure to confront the unknown, is a much more effective way to respond to a complex environment."

---

* Written with Tantum Collins, David Silverman, and Chris Fussell,

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Protecting the integrity of software

---

Breakdowns, security, hazards, etc are all over the place these days, and so Matthew Squair's presentation on Software Partitioning Integrity is very timely. He subtitles it "A short tutorial on the basic architectural principles of integrity level partitioning"

You'll learn pithy things like this:

If You Can Keep Them Separate (Partitioning)
Then You Can Bring Them Together (Composition)
Greve & Wilding HCSS 03

Of course in the world of system engineering, we talk about decoupling and coupling, the former to manage the propagation of risk and provide for independence of action; the latter to create a means for integrating actions.

And, at an even higher level, these principles are applicable to portfolios, and the way projects, scope, and security is partitioned among portfolio constituents.

A few definitions are helpful, especially when looking at the system either in terms of safety or security (perhaps attention to aircraft cockpit security could benefit by this):

Strict Protection
– Component X can be said to be strictly protected from Y if any behavior of
Y has no effect on the operation of X
Safety Protection
– Component X can be said to be safely protected from Y if any behavior of
Y has no effect on the safety properties of X
 Two-way (symmetric) protection
– Component X is protected from Y, and Y is protected from X
 One-way (asymmetric) protection
– Component X is protected from Y, but component Y is not protected from
X

Beyond software
This presentation actually goes beyond software to the very top of the architecture, to include hardware, and the interactions of hardware and software vis a vis safety, isolation, and protection.

If you're in this business (and actually who is not thinking of security these days) this is a good read.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Portfolio cards and dots and colors

---

Today's lesson: How to plan a portfolio.

1. Assemble in the war room: We're going to do brainstorming in the war room; we need a lot of wall space for cards and notes.

2. Begin work at the portfolio level: Get the narrative for each project on a colored card... different color for each project... Project Orange; Project Blue; Project Green, etc. Create a project area in the war room for each project.

3. Work on getting the scope right in the portfolio. Examine redundancy, coherence, and diversification among projects.

-- To reduce single point failures in the portfolio, we looked at ways to put redundancy into each project -- similar but independent capability. We used colored dots on (project) colored cards to indicate where the redundancy came from (example: Project Orange might have an orange card with a blue dot indicating that this was capability redundant with Project Blue but placed redundantly in Project Orange)

-- For coherence we looked at the ways that one project could support another (dependency, but also synergy) such that both together were of greater business value. This may lead to adding some scope to some projects to get the inter-project coherent support

-- To further look at risk, examine the big scope in each project and decide how to divide it up and spread it around so that a common threat does not take down a big chunk of scope. Thus,  the big stuff is diversified by dividing it into littler stuff and spreading it around in different projects.

-- And, look at inter-project coupling: the degree to which a problem is blocked from propagating from one project to the other, or the efficiency with which dependencies are conveyed from one to the other

4. Decompose the scope of each project with some task statements, each at the same level of complexity/importance etc, and each colored according to project. Of course, you could do user stories at this point. (Though some might argue for a product decomposition at this point -- and they would not be wrong -- my experience is that in a brainstorm session, people are more creative and attentive to tasks than products: e.g: Create a chart of accounts, rather than 'chart of accounts' (product))

5. Look for dependencies, both intra- and inter-project.

-- Ask people to say what dependencies there are on each major scope statement, either intra- or inter-project.

-- For inter-project dependencies, duplicate the other project's card in the other project's color and put it with the project we were examining. Thus, if the Project Orange project had a dependency with something in Project Green, put a duplicate green card in the orange project area. Thus, a mosaic is formed. The more colorful the project with other color dots and cards, the more complex it is deemed to be.

-- For intra-project use card stacks and card-to-card strings or attachments to show the major dependencies

Then, we put it all in a PDM schedule (aka, MSProject or equivalent) and build the real WBS (matrix of products)

A few observations: The project complexity, as given by the degree of color mix of cards and dots, is a indicator to make some staffing decisions, putting your best managers on the most complex projects.

For more on portfolios, click here
For more on coherence, diversification, coupling, and redundancy, click here.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Leadership without easy answers

Ronald A. Heifetz is a leading academic on the subject of leadership. I've been working through his first book  "Leadership without easy answers" looking for--what else--answers!

Here are the crib notes for those that don't want to get into the book itself.

Disclosure: the book was published in 1994; I got if for $1 at a yard sale in 2012. That's more about my shopping for a bargain than it is "why now?" for a book that's 18 years old. Even at 18, it's great stuff.

The big ideas

Heifetz gets into your head a bit with his big  ideas:

1. Leadership is an activity, less so a thing, with a take action orientation: Set direction, establish cultural values, resolve conflicts, bestow protection and security, and restore/maintain order.
2. Values and effective activity are separable: This is the "Hitler was a great leader" school.
3. Leadership can be very technocratic, bordering on--gasp!--management; in effect, leading with the solution (I've got the answer right here; follow me! model).
4. Leadership is often most innovative when driving adaptive participation, leading with the problem rather than the solution ("it takes a village" model); and
5. Authority is neither necessary nor sufficient (you know you're a leader when .....), but if you got it (authority of position) you still may not be a leader

 Here's your sign

Of course, sometimes the leader is not the "appointed one" in the corner office. (Indeed, with the open plan, there may not be an office at all to badge the leader)

 Heifetz posits four leadership profiles. The first two (really, the first three) most of us are familar with; but the fourth is less familiar but it actually holds interesting possibilities for everyday project management:

1. Trait—The “great-man/woman” or “history maker” approach. These people are "on a mission". They know who they are; they feel called to a mission. Not content with the small bore of every day issues, they synthesize the big and the bold. And, they are quite capable of leading without authority if need be.

We all have our favorite examples. In business: Donald Trump? or better yet Steve Jobs; in politics: Theodore Roosevelt (the Great White Fleet; the Grand Canyon). More recently: Margaret Thatcher (restore the "Great" in Great Britain)

2. Situational—Times and social forces “call forth” leaders. Such situation leaders usually depend on formal authority. They are put in charge and expected to restore order and set direction. The military always has these figures in the wings, to wit: General Dwight Eisenhower. Without WW II, he likely would have retired as an obscure but competent colonel rather than have led millions in Europe with 5 stars.*

3. Contingency—An attempt to synthesize the first two types: a person, born to leadership, steps forward in times of great stress or demand. Military, political, and religious figures are often contingent leaders.

But, here's the one that shows up day to day in project management:


4. Transactional—“Authority consists of reciprocal relationships.” The appointed leader, but draws authority from the confidence of, and the authority granted by those led; competent to set direction, instill order, resolve conflict. Steady in times of stress, earning the respect of followers. Great CEOs are often transactional leaders: Jeff Imelt, CEO of General Electric. Closer to home: portofolio leaders and project managers.

Situational leadership
Heifetz, at least in this book, keeps his arguments and examples more strategic. It's easy to port his examples into "change the world" projects, strategic portfolios, and the like. He doesn't say too much about might be thought of as "retail leadership". Leadership at the small unit level where person to person relationships count for a lot.

This is the stuff of  what Hersey and Blanchard called "situational leadership". In the Hersey-Blanchard model, leaders have four primary traits on a scale from totally delegating to totally directing. Any one leader has all these traits, but they are selectively applied according the situation set up by followers. Followers, in turn, have four traits from very capable to all but incapable. A matrix between leader and follower forecasts the intersection of leader-follower traits.

Leading without authority

Whether you're a situational disciple or more in Heifetz's adaptive/technocratic transactional corner, either is influenced by whether the leader has postional authority. With positional authority, you can occupy the commanding heights and direct resources towards your mission and passion.

But I'm sort of captured by the idea of leading without authority. This comes up in the agile business quite often. Leading without authority does not mean committee leadership; it doesn't mean the laws of dominance have been repealed. Indeed, someone without portfolio may well dominate the discussion, may be a "great man (or woman)", and may go for bold, even without the corner office.

And, in the case of agile, situational leadership needs may draw forward a natural leader. In Heifetz's view, leadership is an activity, meaning leadership is actionable. Leadership is willingness to take responsbility.  And, if position, authority, and responsibility are not in technical alignment, a true leader presses forward anyway.

Consider the possibilities of "no authority" as summarized in the crib notes:

Without the constraints of authority, one has, ...., more latitude for creative deviance “from the norms of authoritative decision making.” Unfettered from a broader array of concerns and “holding environment” responsibilities, the informal leader can focus on a single issue or selected, limited issues.

The leader without the formal position of authority is also usually on the frontline where he/she can get the “detailed experiences” of stakeholders. And perhaps most importantly, that informal leader has “the latitude to use himself as the embodiment of the issue,” as did Martin
Luther King, Jr.

Summary: leadership is not waiting for the in-box to fill up, whether email, txt, or paper. Leadership is activity.

Photo (Bill Engvall)
*(A wartime rank, equivalent to the European field marshall, held only by Eisenhower, Hap Arnold, MacArthur, and George Marshall in the US Army, and subsequently Omar Bradley; and a similar number of admirals in the wartime US Navy)

Bookmark this on Delicious

Agile PMO

Over at Eight to Late, Mike Griffiths has a slide presentation on the agile PMO. He tells how the PMO can go from Present Many Obstacles to Provide Many Opportunities.

It's a nice play on the words, but there are some instructive ideas in the slide deck (available for download), if you can abide the agile-is-only-way arguments.

First, Griffiths builds the presentation around 9 bullets that are the things that PMO's are supposed to do:

Then he fills in details--from his point of view--about how traditionally managed PMO's need to change--a new game theory in his mind--to be compatible and useful to agile projects.

Of course, a balanced point of view is not Mike's forte. This is a red meat "preaching to the choir" presentation given to an agile conference of agilists.

For example, under bad old way, we read:
Monitor and control project performance – track progress against
inappropriate measures such as getting requirements fully documented and
signed off

Under agile is the silver bullet, we read:
Monitor and control project performance – track velocity, track team and
sponsor satisfaction ratings, look for dangerous velocity trends, check
backlog size, monitor iteration and release plans

Now, I count myself among practical agilists, as explained in my book, but I also know that literally billions of lines of code written the bad old way are up and working fine, so whereas I agree this generation has a good idea in agile, it's not the only game in town.

For another perspective on portfolios and agile, take a look at this:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

Bookmark this on Delicious

Option management

I often hesitate to import risk management ideas from the financial sector into the project management domain--afterall, the risk management results in the financial sector have not been swell of late, and projects are not casino's--but the idea of "options" does port well to projects.

And an option is:
An option is a "right" that you buy for a small fee; then, you have the option to exercise your right at a later time. You can buy the right to buy a security at a specific price not later than a specific date, or you can buy the right to sell a security at a specific time at a specific price.

If you don't exercise the right you paid for, you lose the money you paid for the option. Obviously, you would only exercise your option if the transaction is profitable for you.

Option risk management features:
There are a couple of interesting features embedded in the option transaction that are attractive from a risk management perspective:

• Time displacement (the distance between present and future) is usually a risk nemesis, but in options, time is on your side.  Lemons become lemonade, as it where.  In order for an option to become profitable, some time must pass during which the security changes value, hopefully in your favor. (Most securities trading works this way)
• Downside risk is protected.  The most you can lose (if you act rationally) is your fee for the right to the option, thus protecting you from the actual loss of the value of the security
• Upside opportunity is amplified. Options leverage the value of the fee you paid.  For your small fee, you may be able to participate in a very large gain, which on a percentage basis, is far greater than just trading the security.

Options in projects (and portfolios)
Let's say you anticipate a make/buy juncture in the project 2-4 months out (we never use single point estimates here at Musings).  Two chains of project activities radiate from this decision event: one chain supports a 'buy' decision (essentially, outsource to a supplier) and one chain supports a 'make' decision (do all the work in-house). 

An option scenario is that you do something now to protect your right to go either way at the decision event.  You make a small investment now in order that 'no options are off the table'.

Done right, you make a friend of time: time can be used to set up the conditions for a decision that might not otherwise be available.  By protecting both eventualities, you protect agains the downside of poor alternative, or an alternative foregone because of no preparation.  And, of course, your small investment may be highly leveraged: a great outcome made more likely by a small fee for preparation.

Investment possibilities
So, what are some things you might do? A few prototypes to test your in house capability; some training of staff in skills that might be needed; some due-diligence and benchmarking on the supply chain; and some research into the various vehicles for outsourcing, like incentive contracts, etc.

If you are portfolio manager, then options in the form of independent R&D (IR&D, or IRaD) is a good way to invest a small amount now in order to have project options in the future. And, of course, investing in your customer (things you know your customer wants to do is perhaps the best use of internal investment)

Oh, and how big is "small" in the investment we are talking about?  No right answer of course, but a few percent of the value of the opportunity you are protecting is not a bad figure.

To learn more
If you want to see some numerical examples worked through, go to the Khan Academy and search for the short videos on options.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Too much already!

Mike Clayton at Shift Happens! has a nice post on portfolio prioritization. He asks this question:

Why do so many Organisations Resist Rationalising their Project Portfolios?

And, then he answers his own question with five reasons:

• Patronage
• It's all too difficult
• Is it really essential?
• Loss aversion
• Lessons unlearned

Well, Clayton thinks #5 is the one, and I agree. He goes on to expand:

1.Lack of clear links between the project and the organisation’s key strategic priorities, including agreed measures of success.
2.Lack of clear senior management and Ministerial ownership and leadership.
3.Lack of effective engagement with stakeholders..
4.Lack of skills and proven approach to project management and risk management.
5.Too little attention to breaking development and implementation into manageable steps.
6.Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7.Lack of understanding of, and contact with the supply industry at senior levels in the organisation.
8.Lack of effective project team integration between clients, the supplier team and the supply chain.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Portfolio project management

Looking for some sources on portfolio project management? Here's an aggregator site that gives a number of links to everything from 'A' to 'W' (Amazon to Wikipedia), with stops in between for numerous blogs and vendor white papers.

You might also like:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Three C's and a D

The other day, with a good friend, Alex Walton, principal at 3PM LLC, I was expounding on a favorite topic: applying a dose of system engineering to portfolio management. I call it "three C's and D".

A bit cryptic? Well, not so much when you spell it out:

Coupling, coherence, cohesion, and diversification

The short form explanation looks like this:

Can you actually manage these things from the perch of a portfolio?  Yes, so long as you're not too hung up on metrics, as in: "you can only manage what you can measure". In some respects, there are only notional explanations for these concepts with corresponding notional ideas [metrics] of success. Nevertheless, "I'll know it when I see it" can be valid as management doctrine.

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

The phasing aspect of coherence gives rise to a success criteria, phase error. We tend to think of things being "highly coherent", or exactly in phase or in sequence.

Coherence also gets its power from consistency and commonality. I once did a project with a company that claimed they had 2M customers. When we cleaned and consolidated several  customer databases, and imposed rules of consistency and commonality, the company really only had a few hundred thousand customers. The rules for sales customers were incoherent with the rules for service customers until we got the relationships right and imposed common data rules

Another idea behind coherence is optimization. In portfolio management it's common to try to optimize for the larger good. In effect, create the conditions that reinforce the highest goals to the greatest degree, even if lesser goals are foregone. If you've ever studied the Theory of Constraints by Goldratt, then you understand the idea of coherent flow-down of goals so that the organization is not working against itself.

So it is with projects in a portfolio: sometimes, real success only comes with the right phasing, the right timing, and the adherence to common rules.

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Cohesion also requires effective conflict resolution under stress, and it requires that individuals and teams are prepared to give commitment and accept accountability even if all is not as they require.  Portfolio managers establish these principles of behavior and make demands for adherence.  Managers also establish and manage the incentives for cohesive behavior, and manage the resource pool for redundancy and stress relief.

Indeed, one principle of agile methods--though not exclusively an agile idea--is that hockey stick heroics to pull the project through at the end are to be avoided.  Cohesion eventually breaks down with sustained overcommitment.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

As in the insulation example, barriers, sometimes physical barriers, are the best way to loosen coupling. A virtual team is about as loosely coupled as a team can get. A co-located team is tightly coupled. On the other hand, it's harder to get cohesion in a virtual team, and correspondingly at the portfolio level, the more barriers among projects the more loose will be the coupling, but the greater will be the challenges of obtaining other good qualities.

Diversification

Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.