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

About micrometers, chalk, and axes

---

I'm nearing my one year anniversary working on a volunteer project to restore this Lockheed PV-1, circa 1942, short-range bomber and reconnaissance aircraft.

Some assembly is required!

Frankly, I'm trained as an electrical engineer -- Georgia Tech, et al -- but there's not much electrical/electronic on this aircraft. So, I've had to recall 7th grade metal shop: brakes, shears, rivets, etc.

One thing I've learned from my (mechanical engineer) team leader -- also a Georgia Tech wreck as it turns out -- is the 3-step process of mechanics (who knew? You can't make this stuff up!):

1. Measure with a micrometer
2. Mark it with chalk (in our case, Sharpie marking pens), and
3. Cut it with an axe! (in our case, shears of one kind or another, or (gasp!) the band saw)

Ooops! This very process shows up in project management. See: accuracy vs resolution and the spreadsheet -- estimates that are just a bit better than a guess are entered into cells with zillions of digits of resolution. Nonsense.

And, we see it as domain distortion when the defined process crowd with six sigma control limits wants to port their ideas into the domain of the one sigma program office. Again, nonsense (except for the problems defining process in six sigma that is quite portable and worthy)

So it is that I have to return repeatedly in my risk management courses to why/how the precision of a estimate in a work package -- or the less frequent but more troublesome estimate outlier -- more or less washes out at the PMO level in a Monte Carlo simulation of all the work package effects.

Monte Carlo is the 3-step process writ large:

1. Agonize over every work package estimate (micrometer, but the WP manager does this step)
2. Enter all the WP data into a simulation package using 3-point estimates and benchmarks (chalk, likely applied by the project analyst)
3. Run the simulation to get the "big picture" (axe)

What I find is those in the PMO wielding the axe seem to get inordinately excited about an outlier estimate here or there. If you're the axe-person, don't sweat the micrometers!

---

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

70-30 and 90-10

---

A lot of project work is bid and won competitively, in effect beating out the other project team that wants the work.

Fair enough.

But, how do you win? How about this:

Bid the job with only a 70% confidence that you can do the job for the price... thereby taking a 30% risk that the actual cost will be higher (How much higher? You probably don't know).  

Ok, sometimes that's what it takes to win; I get it. But then, if you win, you might be heard saying: "OMG, what do we do now?"

But the worst is when the sponsoring executive says: Congratulations! Now, do the job for 90-10!

Translation: "Give me a project plan that brings the cost in for less than 10% risk that it will be higher than bid." (How much less: it probably doesn't really matter ... except: your bonus -- and perhaps your job -- only depends on not overrunning the cost)

Now with this scenario, we have the classic "project balance sheet" case:

• Sponsor's side of the balance sheet, top down: 90-10 cost confidence required of the PM
• PM's side of the balance sheet bottom up: 70-30 on cost; so the only way to obtain balance is to take a risk.

And, in the best traditions of risk manage, "taking a risk" doesn't mean listing it on a register and then just standing around looking at it. Taking a risk means: Do something to defeat the forecast! That's the project manager's mission:

The project manager’s mission is to manage assigned resources to deliver the value expected, taking measured risks to do so

---

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

Creeping Risk Averse behavior

---

John Adams has an interesting post on his perception that in society generally there is a creeping aversion to risk -- given the number of plaintiff lawyers in the U.S. this should not really come as news. 

Nonetheless, he gives us a ppt presentation that's got some interesting view points -- you can get started on pages 4 and 5 with Adams' idea of perception sources and his formulation of balancing behavior among risk and reward:

The Public Perception of Risk from jguadams

 

---

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

Three bodies, but should there be four or five?

---

At HerdingCats, there is really good posting of the "iron triangle" described as the "3-body-problem". I recommend you click over and read it. (And, that's where I got the swell graphic)

But, not so fast!

 But -- there's always a "but" -- the triangle famously leaves out quality as an explicit trading variable, and also "effectiveness-for-business-value" -- the PMBOK dropped the triangle some years ago -- after all what's the point of a doctrinally successful project if it's the wrong thing to do vis a vis business value?

Actually: There's no point in such a project.

This is true whether in public or private sector, where in the public domain, business value is often "mission").

And, by corollary: is it all bad to be off according to project doctrine, but spot-on re the business?  I think not.

So, perhaps it would be best to all spring for quality and business value as a five-element system.

On the other had, it's a great graphic. Looks like an independent suspension apparatus, which I suppose what it's supposed to be: independent trading variables.

Ooops! They're not independent: As a general matter in most practical projects there are correlations between them -- not always strong correlations; perhaps not even material correlations, but nonetheless, not truly independently sprung.

Thus, we can expect some compression/expansion of the springs without necessarily affecting the other balls. And that, of course, is the point of such an architecture -- isolation and pseudo-independence.  By the way, the automotive guys have been using such independent suspensions for years, and to good effect.

---

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

Sketching architecture, etc

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it.

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

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

The illusion of stability

---

It's human nature when faced with a chaotic environment ... to filter out most of the noise to focus on a single trend. The resulting illusion of stability gives us a context we can understand. But it's still an illusion.

The reality is that there are many different interrelated trends -- areas of change that impact us as well as the other trends. There are also discontinuities: sudden shifts that force us to rethink our assumptions.

Jason Bloomberg*
"The Agile Architecture Revolution"

Amen! to that sentiment. One often wonders if we're the engine of change, or the victim -- change leading us, rather than the other way 'round.

In the statistical world, it's much like finding the regression line amongst a lot of seemingly random or chaotic data points. The regression line is kinda the place we would like to be if we were the next thing to happen.
(Note: regression isn't filtering, but the line itself is a nearly noise-free representation of the "message of the data", so to speak)

Of course, a word of caution: it's not actually so swell to speak of filters narrow enough to smooth out the noise, and yet leave enough bandwidth to be disturbed by a discontinuity or sudden shift. Such phenomenon have very high frequency components which would likely be smoothed to the point of unrecognizability at the filter output.

Therein lies the hazard: big shift at the input... and little notice at the output. (See: Microsoft misses mobile and the tablet shift, or worse: Blackberry misses everything. ) One wonders if the Microsofties have been living on the wrong side of the filter.. perhaps a little exposure to the chaos of small business would be a tonic.

 

---

*Bloomberg is President of a consulting firm that takes the position, roughly, that a SOA (services oriented architecture) that is very loosely coupled to accommodate ambiguity and emergence of function and performance when the user is part of the system and in-the-loop is an "agile architecture". Bloomberg has coined the development of such architecture as "Complex System Engineering" (CSE); it is the heart of the "revolution". He contrasts CSE with traditional system engineering which he more or less equates with integrating a number of small objects into a large system.These views, and his company offerings in this regard, informs the content of his book.

---

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

Talk about the weather!

---

The weather in the US and Canada this winter has been a huge risk to projects... polar vortex and other phenomenon have made a mess of project plans, supply chains, outdoor painting, oil drilling, and all the rest. Talk about a chaotic stimulus to the system!

So, here in sunny Florida where we at "Musings" hang out, and where we do have hurricanes -- though not every year, and not for a few years -- this photo from my daughter in cold! Wisconsin seemed to sum it all up:

---

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

Friction: social debt + technical debt

---

And, so now we've all come to the point the art and science of project management that we have various debts to go along with a myriad of biases. The new one (for me) that I've just come across is social debt, as described by Philippe Kruchten

He tells us:

Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop].

Social debt is .... the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc

Now, put social debt together with technical debt -- all the myriad of little things left undone -- and you get the idea of the friction in the project.

So, what price -- actually, for the PM: cost -- is friction? First, friction spreads the tails of the Monte Carlo simulation of cost and schedule, and potentially shifts the mean cost and schedule to the right. Second, and certainly a root cause of the first point, friction holds back productivity and gives rise to lost energy (to overcome friction) and lower velocity (less throughput)

Fair enough. But, what do we do about it?

• New project? Take a look at the history of overcoming debt and make adjustments to the knobs and switches of your project model
• Got flexibility? Reorganize, retrain, change environment or tools, or add SMEs (or dismiss the high-friction nemesis)
• On-going project? Rebaseline. That may cancel a lot of the social debt built up in the existing project. In effect: reboot
• Risk management? Sure, think of both technical and social debt as a risk to be managed

---

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