Org models and Out on a flat limb!

---

Flat is cool. Delayering is in. The CEO works in an open space with everyone else. What's not to like?

Maybe nothing is not to like, but....

One aspect of delayering often not addressed well is that trust and layers are usually inverse relationships: to wit, low trust organizations can substitute C&C through layers, each defined with protocols -- authorities, responsibilities, escalation, appeal, etc., but high trust organizations find that these things scattered among layers are really not necessary.

Now as you delayer, what is the mechanism to build trust as protocols fall by the wayside along with their companion C&C structure?

Suddenly people who were accustomed to the crutch of bureaucracy find themselves more less out on a flat (delayered) limb! See: "deer in the headlights" phenomenon, and related insecurities attendant to exposure and decision making.

Now the question: can these people -- newly flattened -- now be trusted to do the right thing; summon appropriate wisdom; apply reasonable judgment; and not be panicked by circumstances?

Obviously, there's no answer in general. All is in the particular. Suffice to say, however, that many won't make it flattened. They simply need the bureaucracy in order to function personally. If they didn't, many -- but certainly not all -- would be working somewhere else. They really can't be trusted to work effectively without the structure.

After all, the structure absorbs a lot of the shocks and stresses of everyday work -- do these now fall on the individual?

An obvious exception to flat: the military (or first responders, like police and fire, etc) -- the largest bureaucracy for many.

Duty, honor, country... they still count for something, thank goodness! 

But even there, many summoned to high (or higher) command with fewer layers above them and fewer dependencies beside them simply don't make it, particularly under high stress.

---

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 volunteer projects

---

Some assembly required!

Does everyone recognize this as a Lockheed PV-1 Ventura, circa 1942? It's mission was coastal reconnaissance, anti-submarine warfare, and light-duty bombing. The payload was a few small bombs, and the self-armament was a couple of machine guns in a top-side turret.

Restoring this aircraft -- as a museum queen -- is one of my volunteer projects. I'm not the "director of restoration", just one of the rivet guys -- and the not first to work on this. In fact, when we took the wing skin off to restore it, we found "Rosey's" signature inside, dated in 1942!

 

News you can use!
Volunteers are not paid staff -- no kidding! But... Actually, there's a lot to know about doing a project with volunteers because they're different from paid staff -- their training, motivation, accountability, commitment, and willingness to follow directions -- all different!

So, I've been reading the Kindle version of "Practical project management for agile non-profits" by Karen R. J. White. Her experience pretty much tracks with my own.

I recommend her book if you're getting into the volunteer thing. It's got a lot of stuff that is spot on.

What's important to know?
Write this down; you'll need it later:

• They don't always show up, and they don't often give notice or reasons... just don't show
• Virtual teams of volunteers are almost unthinkable. You've got to meet and greet in person.
• If they do show up, they may leave at odd moments, right in the middle of something important, but not important enough to trump their need to leave
• They can be territorial; prone to settle into something they like to do; and sometimes hostile to help or direction
• But, if volunteers are working outside of their normal identity and comfort zone, they'll usually take direction readily if they perceive it's value-add. (I had not driven a rivet since 7th grade metal shop, so I needed some training!)
• They're really not committed strategically to the host organization -- they don't get a paycheck, benefits, promotions, a corner office, or a place to hang out long term.
• But, my experience is that volunteers can be very committed to organizational success for the project they are working on, putting in longer hours and working harder than the formal demands made by the project.
• There's always the "faithful forty" as we say in the church volunteer project domain: they show up; work hard; get something out of it for themselves; and leave behind a good product.
• Volunteer teams bond just like any other; leaders emerge like they always do; and sometimes there's an issue of dominance to be settled. Having a paycheck or not doesn't seem to alter these factors very much
• Be aware that volunteers are grown children, sensitive to being played for an advantage since they often do not have access to senior paid management and organizational escalation and appeal. And, volunteers can be very sensitive to being the teacher's pet -- or not. Don't play favorites!
• There's often an age difference, and an experience difference, that can be quite stunning: Seniors who were executives volunteer and are "supervised" by 20-somethings. And, the young supervisors need to be aware that age has a toll -- the older guys may move a little slower, etc.
• Take care with obvious inefficiencies: the labor is cheap; there's more of it if you need it, so the pressure to be lean is much relaxed. Consequently, the overhead may be a lot higher and its impact not anticipated in the schedule.
• Benchmarks attained with paid staff are often way too optimistic; see my points above about inefficiency, overhead, and commitment.
• And, last but certainly not least: put away the jargon and speak in the local dialect. Volunteers may not be former pro's in the project domain; may not know the inside jokes and acronyms; and probably don't know the inside politics.

---

Bookmark this on Delicious
Check out these books I've written in the library at Square Peg Consulting

Get your team from the little pond

---

For the ambitious, there's always this conundrum: Be the big fish in a little pond, or be a smaller fish in a bigger and presumably more prestigious pond?

Malcolm Gladwell explores the consequences of this choice in his new book "David and Goliath", and he also explores it quite dramatically in this TED presentation to a Google gathering.

His bottom line -- born out by research he quotes from extensively -- is that there are clear advantages in choosing the smaller pond when you can't be the very best in the bigger show. 

His main point in support of this thesis is that a really good talent, but not the very best talent, will have higher self esteem and achieve more because of their higher self assessment than if they measure themselves against a different and more challenging standard.

This is really a form of the cognitive bias psychologists call "prospect theory". The big idea: value, esteem, confidence, despair, joy and the like are all relative to a reference point, not to an absolute standard. (The wealthy can be unhappy and the poor can be happy, etc... it all depends on the reference from which you are measuring)

So, the data support this idea: the bottom third of performers in a pool of truly outstanding people may be in that bottom third because of self-inflicted feelings of inadequacy. Change the pool, and they may be stand-out performers.

For project managers:
Gladwell counsels: Always recruit the best from any pool, but keep in mind that the pool itself doesn't really count for much. So, regardless of a university's standing in a particular field -- say STEM because it hits so many project teams -- go to any program with STEM and get the best in that program. They'll all be winners and self-starters, accustomed to success.

Fair enough, but....

Now that you've got them, they're all in a new pool, and some of the winners are going to find themselves in the lower tier of their new pool.  Ooops, prospect theory cuts in, and problems arise!

This may call for some reshuffling, restructuring of the pools, and other incentives and encouragements to offset the effects of relative position. So, don't be blindsided by this little HR issue as you recruit your team.

---

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

Recharging your leadership battery

---

David Brooks opines on leadership from time to time, and thus we fell upon one of his essays on recharging your leadership battery.  Brooks' essay is specifically pointed at public sector leaders, and to be sure, there are many project managers and program executives in the public sector, but the points made work in any domain.

Brooks suggests three things you can do to revive any sagging motivation to push through and get things done:

1. Apprentice yourself to a master craftsman
2. Get real again; go off and become a stranger in a strange land [domain]
3. Close off your options so as to not be "master of none"

Point 1:
No one who is a professional in this game stops learning; there's always someone better or someone who has a better way of doing it. So, seek out the master craftsman; the person who has an exquisite grip on the job, and learn from the best. And, if you're the craftsman, take on a protege... you still might learn something

Point 2
Break the mold; be a rebel. Do something different, but do it differently in a different domain. Brooks makes the point that when you return, you'll see things all differently through the prism of a wider experience.

You could, for example, go over to the dark side and leave public service to become a contractor. Or, almost as hard: leave the regulated government contractor business and go into back-office IT..... talk about a domain change!

Point 3:
The conventional advice is "keep your options open", be nimble, and ready to change direction or capture an opportunity at the drop of the hat.

But, then there's the paralysis of analysis. "Open" is often the antithesis of commitment, and a lack of commitment is not that hard to detect by others looking for your commitment. But managers today want you "all in", fully committed, and accountable. You can't do that if you don't close something off.

---

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

Statistics Done Wrong

---

I've stumbled onto a web-based primer on applied statistics that makes for a good PM's guide to the subject... easy reading, short chapters, and a decent table of contents.

The marketing line is: "Statistics Done Wrong is a guide to the most popular statistical errors and slip-ups committed ... every day. ... Statistics Done Wrong assumes no prior knowledge of statistics, so you can read it before your first statistics course or after thirty years of ... practice."

Entitled "Statistics Done Wrong",  by Alex Reinhart, here's what you'll find:

• Table Of Contents
• Introduction
• An introduction to data analysis
• The power of p values
• Statistical power and underpowered statistics
• Pseudoreplication: choose your data wisely
• The p value and the base rate fallacy
• When differences in significance aren’t significant differences
• Stopping rules and regression to the mean
• Researcher freedom: good vibrations?
• Everybody makes mistakes
• Hiding the data
• What have we wrought?
• What can be done?
• Conclusion
• Bibliography

---

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

When the evidence doesn't compute...

---

Oops! Something went wrong... the project analysts followed this standard paradigm in three steps, given as:

1. There is a scientific or policy question of some theoretical or practical importance.

2. Researchers gather data on relevant outcomes and perform a statistical analysis, ideally leading to a clear conclusion ..

3. This conclusion informs policy.

Think of this as PLAN A.

But Andrew Gelman asks: "What happens if Step 2 fails?"

Well, we could take Jurgen Appelo's advice: "Measure everything; Conclude nothing". Off hand, I don't see how that moves the ball very well, or very far, but hey!.. Appelo has his reasoning.

Nonetheless, Step 2 does fail -- in fact, in the project domain Step 2 fails fairly often -- and then what's a PMO to do? Yogi Berra's advice comes to mind:"When you come to a fork in the road, take it!"

Enter PLAN B:
Here's Plan B: Invoke your policies and protocols for decision making in the face of uncertainty. If you are a bit short on these, take a look at the work of Tversky and Kahneman: they've written some very informing papers on this very topic.

In short, even if the conclusion is not clear, not unambiguous, not not self-conflicting (wicked), make a judgment as informed as possible and press on! Franklin Roosevelt: "Try something!"

---

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 ultimate low-tech risk management tool

---

Can anyone image doing serious risk management without a checklist? (The answer, of course, is No) Actually, any procedural management can benefit from a checklist.

There's been whole books written about checklists. In fact, one of the more prominent books -- "The Checklist Manefesto" by Dr. A. Gawande -- entitles Chapter 1: "The Problem of Extreme Complexity", recognizing the contributors of breadth and depth and interdependencies (check on this before you do that....) are more than we can reasonably keep in mind.

PDM Heresy
Here's some heresy for the MSProject geeks among us: PDM tools are great for laying out the schedule architecture and getting estimates -- via simulation -- of likely outcomes, but they suck at day-to-day management. Why so? In a word, complexity.

You can't practically put all the dependencies in the tools or the logic would be byzantine. No one could understand or follow it if you put it down (why did you do this? why did you do that?..). Some interactions are best left to the unit commander/team leader.

What's a PM to do?
And, so how to manage those interactions and day-to-day requirements? Checklists! Check off on this and check off on that.... And, it's a great tool at a daily stand-up

Here's some specifics:

• Small lists... No list too large; keep the near-future in sight
• Lots of lists; make a new one every time the situation changes
• Coordinated lists; I have this one.. do you have it's companion?
• Reusable lists; once a list is validated by actual use, archive it for reuse
• Validated lists; get SME input to validate the list... a list can be just as wrong as any other tool
• EV lists; Don't put aside earned value... the sponsor and everyone involved wants output, and they want output commensurate with its value
• Kanban lists; teams push things along through a sequence of steps... did everything get DONE?

Schedule and WBS
And now to application: checklists are found between the milestones.

Fair enough.

It's all about situational awareness, look-ahead strategies, and understanding the constituents of getting from here to there. There's no new scope; just go to the WBS for the parts and go to the schedule for the milestones. Then: checklists!

The end.

---

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

That "trust" thing... again!

---

Here's a point about trust that recently arose in my agile class.  A student said traditional methods lack trusting relationships, whereas agile teams are more likely to embrace trust.

Maybe/probably so; history would be seem to be on the side of the student

Consider the  theory of "Management Science", as developed in the early industrial age around 1915 by Fredrick Taylor.  Taylor -- and his disciples -- held that all jobs could be described by a "job description" and that any qualified person could be plugged in -- so long as they were not "a square peg for a round hole" Thus: plug and play staffing.

(Aside: I took the name of my company -- Square Peg Consulting -- from the problems I observed trying to be a good "Taylorist" in the Defense and Intelligence domains in the 80's)

And, because these plugs were largely anonymous to management, bureaucracy was invented to contain and direct work, more or less anonymously, via protocols and policies -- No trust required!

Just follow the rules, or perish.

Along comes agile and replaces large scale bureaucracy with trust!  What a concept! Now, admittedly, trust is hard to scale -- requires personal knowledge in the main. So, as scale increases, trust and bureaucracy trade places.

The trend du jour is "flat" organizations and open space. Why? To get back to the virtues of a small scale -- trust and agility -- with a large organization. If everyone has to gather by a common water cooler, by and by people will get to know one another.

Steve Jobs famously put the only rest room at Pixar in the Atrium... everyone had to go there by and by. Agilist Alistair Cochburn calls this communication by "osmosis"... absorption due to being the same place.

---

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

Writing a proposal -- a checklist

---

Most of us don't write books -- this blogger excepted -- but many of us have to write a proposal to win business, or even win a job. And then, if you're on the job, there may be myriad presentations and documents to deal with.

Smart PMOs put some of us on red teams -- the independent reviewers. So, how about a checklist to guide the work along?

At Jurgen Appelo's NOOP.NL I recently saw just the thing -- though it was presented as a checklist for writers generally -- presumably books, but certainly applicable -- with a few modifications -- to almost anything you're writing.

Appelo posits four stages:

1. Brain dump for what you want to say -- Let me add: draw up some storyboards... If you can't draw it, you probably can't write it!
2. Shaped version for sharing with only your best friends
3. Polished version used for tweaking
4. Final version -- here, I offer a suggestion from my own experience: put the whole thing away for a couple of weeks. Come back to it and tweak/rewrite... you'll be surprised how different it looks from the vantage of a few weeks

If it's a paper your writing, then you'll need an abstract. And, I like to lead with an executive summary.  Add these to the checklist under Stage 1 of Jurgen's list

If it's a proposal, then you have to follow the sponsor's guidance or direction about what's to be in the proposal, but I can't imagine a proposal without an executive summary for the executive reader

And, if it's a proposal or a book, the publisher/sponsor may have author guidelines, style guides, trademark requirements, etc.... Add a look at these as a step in Stage 1.

If you're on your own, I still argue for the executive summary -- some call it a preface -- but thereafter, Jurgen's list is a good guide.

---

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

Team agile bloopers

---

Team agile bloopers from a practitioner's notebook:

We had 6 agile teams working to build a product. Each team was responsible for their component but they all needed to be integrated for the product.

1. We didn't get buy-in from 1 team to run agile. We had a team that agreed to follow agile but decided to go their own way. This caused many issues when we tried to do early integration as they were not ready. The remedy is to be more disciplined and bet buy-ins from all teams.

2. Didn't do a good enough job at task breakdowns. This is actually fine at the individual team level but needed a lot more work at the scrum of scrum level. The remedy is to develop a clear architecture and be more discipline to develop to the architecture.

3. Not discipline in our daily stand-ups. Not all teams followed this - those teams tend to have the most communication issues. The remedy is to require more disciplined adherence to daily stand-ups and complete buy-in of the agile process.

4. Inadequate time for reflection - I should have done a better job of adding buffer time for integration activities and for reflection. We were able to do reflection in some of the teams but not at the product level. This was due to some teams missing their iteration release. The remedy is to do better planning for system level integration.

5. Lack of product owner involvement - we had two customer development teams working along our teams. I thought that those customer teams would represent the interests of their product owners. It turns out that there was little communication between the real product owners and the customer's development teams. We were able to get to the real product owners but it was too late. The remedy is to identify who is responsible as product owners and require their involvement throughout the project.  

---

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

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