Hub and Spoke

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and as an EE, I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

---

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

About complexity

---

Shim Marom has interesting post on complexity wherein he says this:

"A lack of an intellectual capacity to grasp a complex system is not a sufficient argument or drive for simplification.

If you artificially simplify a complex system you end up with a different system that, while simpler, is fundamentally and conceptually different from the one you started with and thus, simplification ends up with destruction."

So, what are we to do about a system we don't understand? Should we:

• Get a smarter guy to understand it for us? Possibly; we can't all understand the particle collider
• Design in some fail-safe stuff so that even a chaotic outcome is contained? Yes, fail-safe is always a good idea if you have the right assumptions (See: Fukushima, March, 2011)
• Design a different system altogether -- one that we can understand? Yes, that might be a good idea (See: HAL in 2001: A Space Odyssey)
• Do the destructive simplification Marom talks about?

A system engineer would say: "Yes" to all of the above, situationally, as required.

About destruction
I suggest that "destruction" could be the intended end-game insofar as if you can't understand a system you may not be able to control it, and certainly can't predict its behavior. So, "destruction" to a simpler device may be an important and required objective. Lord knows, we have enough stuff we don't really understand!

CAS is not for everyone:
Also, when discussing complexity, especially adaptive complexity, one must be careful not to cross domains: CAS in biological and chemical systems, and others like weather systems, is not a phenomenon we have to deal with in man-designed physical systems that operate within reasonable physical limits. To impute CAS properties improperly is one of the common errors I see.

---

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

Another entry for the agile practice dictionary

---

Jim Highsmith has defined CD -- continuous delivery cycle time -- this way, a practice you can add to your GAAP -- Generally Accepted Agile Practices:

Finally, the newest perspective, brought about in great measure by the advent of Continuous Delivery (CD), is that of cycle time. Furthermore, there are at least three versions of cycle time:

• Deployment frequency (days, weeks, x times per day),
• Feature cycle time (release from backlog to delivery), and
• Project cycle time (similar to planned versus actual).

Deployment frequency and feature cycle time are becoming very important performance metrics in our current era of CD. In fact, value and cycle time are rapidly replacing the Iron Triangle (scope-schedule-cost) as the critical metrics to use in building responsive systems responsively .....

Brother Jim may be a bit ahead with his last statement about critical metrics for "responsive systems". On that last term, I'm not sure it's made it to mainstream yet, but in an unrelated posting, my attention was drawn to this missive on building out a "responsive site":

---

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

What price complexity?

---

Complexity: the myriad interactions and influences between pieces and parts that gives rise to performance and functionality not discernible from just an examination of the pieces and parts

As an aside, keep the idea of complexity and complicated separated: Complicated is a bunch of stuff, but if the interactions are minimal, then something really complicated may not be too complex.

Three questions that should come to mind:

1. Are the effects of complexity in this project predictable?
2. Should we -- the PMO -- count on some effects always being amongst the unknowable -- and thus, unknowable risks? If so, how much reserve to set aside? 
3. How do we -- the PMO -- plan for the effects of complexity?

Fair enough: It's all well and good to have three questions, but here's the important point: You can't just end it here... Some action required! And, as you might imagine, this stuff doesn't come free.

So, here are a few answers:

To point #1:

• The only way to predict complexity is to build it or simulate it -- presumably at moderate cost and effort. Build it: prototype, or some such; simulate it: various action models, like a Monte Carlo, for dynamic behavior.
• Of course, in any simulation, some calibration is required, especially if a model is involved -- to wit: you don't want to have model artifacts mixed in with the real predictions.
• If the system is biological or chemical, then complexity may include dynamic adaptation, popularly called "complex adaptive systems" (CAS). Probably nothing but a small scale but fully functional prototype is going to do the trick
• If the system includes a "human-in-the-loop", then some of the CAS behavior may be in the offing... humans are very adaptive and quite unpredictable when not scripted. This where testing for error traps is really critical, because we humans do the damnest things! 

To point #2:

• In a word: Yes, especially if your project and its deliverables are complicated. Latent complexity is likely lurking! Of course, you can't be lazy about this. You should expend effort trying shed light on latent effects. Again, prototypes and simulations are the best tools.

To point #3:

• First, you don't want the project or the system to be fragile -- that is, unable to absorb shock. So, you need some redundancy
• Second, you don't want all the eggs in one basket where there could be catastrophic damage: thus, diversity (distribution of risk into independent containers or to independent actors -- and the stress in on "independent")
• Third, if the bad stuff happens, you want it contained: thus, loose coupling! (In the sailboat racing analogy, sailors build sails with "rip-stop" seams that contain a failure to one section of the sail. See also: Titanic, for watertight compartments, an example of the violation of the "independence" principle... there was coupling between compartments that was unforeseen)
• And last: there's a hidden cost: integration cost arising from complexity

There's not much point in raising these questions if PM's can't deal with them in some practical way day-to-day.  Recall my favorite way to get started with both architecture and estimates: the Box Model

---

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

Calling in the militia

---

I've tried and it's hard: building a team from a bunch of independents with no core that carries the culture.

The question arises: are you in for the duration or for just a hitch?

Given enough time, those in for the duration can coalesce into a team, absorb a common culture, and attain a degree of efficiency that goes along with a common experience.

But it's really hard to shuffle the militia in and out for each battle, especially if they are independents, and even more especially if they are another firm that are in for the opportunity as a teammate. This is matrix management writ large! And, to do the hiring you've probably got the HR department in the mix... gasp!

We can all think of the reasons why militia teams are problematic, starting with Brooks' Law*: "Adding people to a late project makes it later".

But there are the other obvious points:

• Overhead to recruit/absorb new troops and to lose the temps ... hiring/ training, explanations, logistics, etc
• Realignment of relationships and new alliances
• Challenges to the culture as new ideas are brought in
• Resistance to new ideas (See: NIH, not invented here) and different risk attitudes
• New biases to deal with -- everyone comes with some baggage
• Walking out after your hitch is up with the corporate project knowledge, thereby leaving a knowledge desert (exit interviews rarely mitigate this hazard, but non-compete agreements are a must!)

If you're going the militia route, plan in the overhead! There's no free lunch that comes with working with independents.

---

*Brooks' Law from "Mystical Man month" by Dr Fred Brooks

---

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

Peer review... Red team

---

Your baby is ugly!

Ooops! Did I say that?

Sorry! Peer review is very powerful, and cheap/easy to implement, though it takes a bit of discipline and a caution because calling the other person's baby ugly is not suave.

So, some nuance is required. Some projects call this "red teaming", and then for larger efforts there are other colors to denote several sequential teams at different maturities... red, then gold, etc recognizing things improve with each review.

Family Tree
Note: there are lots of project reviews that fall in this peer review category, and they go by a myriad of names, each with their own culture, protocols, standards, deliverables, etc:

• Proposal reviews
• Peer reviews (papers, presentations, documents)
• PDR -- preliminary design review
• CDR -- critical design review
• Pair programming
• Verification and validation
• Others...

Process
To be efficient, appoint a red team leader; then run the red team like any other project -- scope, schedule, deliverables, etc. It's best to have a standing review team for each project the team reviews so as to not invent the wheel with each review.

Reviewers are usually assigned to review according to areas of expertise. And, here's a point sometimes overlooked:  protocols re whether the peer review has any power of veto or enforcement over or about the product/device/object/document under review. And if they do, then provide an appeal or escalation process/work flow.

Did I mention privacy? Red teams can't do their work in a fish bowl.

Traps
Now the hard part is to avoid "not invented here" (NIH) bias on the part of the red team. In the shoe were on the other foot, that is: if the reviewer were the designer and not the reviewer, then the whole thing might have been done differently; and some other reviewer would then be red teaming.

So the point is: if you are red teaming, put your NIH hat away and look objectively as you would like others to look at your work objectively.

Epilogue
Then the exit interview with the designer/owner -- perhaps not the most fun thing. But if you want to win in the market, the product/service/proposal has to be the best possible... so the red team has a job to do and "it's not personal" (even though sometimes it is).

---

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

Robert F. Kennedy on value...

---

.... It measures neither our wit nor our courage; neither our wisdom nor our learning; neither our compassion nor our devotion to our country; it measures everything, in short, except that which makes [... our project] worthwhile. And it tells us everything about [... about a project] except why we are proud that we are [...doing the project]."

Robert F. Kennedy

Senator Kennedy said this -- within the limits of my somewhat tortured paraphrase substitutions to port it to our domain -- in the midst of a political campaign; he was referring to the metrics of the Gross Domestic Product (GDP).

His point was one that is all too common in many domains of human exertion: the mix-up between that which we can objectively measure and that which we know subjectively as quality, value, and purpose achieved.

Now, one can make measurements on some subjective values, to be sure. But on many of the qualities that lend utility and excite interest, who can say why, really?

I've actually given it a go; I've written a whole book on finding/delivering project value. I'm not the first and likely not the last to address this subject.

But I've also written books on the objective means to measure projects.

Now, it's probably no surprise that "Maximizing Project Value" is not the first book a PM picks up; more likely it will be a subject as "Quantitative Methods"  and "Project Management the Agile Way"; but I actually think "Maximizing Project Value" may be the more important subject to know and internalize -- for all the reasons RFK spoke about.

---

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