Process breakdown structure

---

A coffee shop discussion on process redesign and process improvement led me to state the obvious to my caffeine-charged debaters:

Managers responsible for the business buy results [and outcomes], not process. Process, by itself, does not sell well; what sells is results.

Process per se is a tool.  For the most part, business people hire experts for their ability to deliver results; what tools they use are somewhat immaterial [to the business person]. The same for process redesign: the design per se is not the objective; the objective is better business results.

To help the discussion along, I postulated a "process breakdown structure", an obvious play on the WBS (Gasp! WBS! I can hear the agiliers running away .... come back! It's ok)


Of nouns and verbs
Just like a WBS is an organization of 'nouns' [outcomes or deliverables] that beget 'verbs' to explain the "how" of it, so also in a PBS

The PBS is fundamentally 'nouns'....outcomes of the process....arranged  like a WBS.  The PBS has elements of hierarchy--parent/child--and relationship [example: we all have a temporary relationship to each other because we are all engaged in this blog...I wrote it and you're reading it]

The first process improvement is to do away with nouns that aren't valuable.  Lean out the clutter and reduce the complexity

And just like for a WBS, for every noun there is a verb: the activities of the process.

Sequencing the verbs
We all know there is no schedule or time dimension to a WBS.  It's as if the WBS is the 'present value' of the schedule results; all deliverables brought back to the present.  Thus, sequencing has to be done elsewhere, and that is usually in the schedule

So also in a PBS: for each noun there is a verb, but the repository for verbs is the process activity list.  Take the nouns from the PBS and verbs from the process list, and you can just about write the narrative of the process.

Just add to the nouns and verbs the sequencing, durations, and dependencies that are properties [adverbs and adjectives] of the activities in the list.  String them out in a network and you then have the process in the usual format.

Resource the verbs
Verbs require resources. Minimizing the resources; leaning out the non-value verbs and sequences that consume resources; and resolving dependencies that add more friction than value is the way to improve the process.

---

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

C.R.A.C.K. customers

---

Barry Boehm on the C.R.A.C.K. Customer

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Sprial methodology, writes about the ideal customer for agile projects. They are:

-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.

Take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004

---

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

Can agile teams be virtual?

---

Somebody asked: can a virtual team do Agile?

• 15 years ago, the answer might have been no. 
• Seven years ago, more less pre smart phone and smart-phone networking, the answer was probably yes, but with reservations. 
• Now, the answer is "Of course", with some adjustments. 

Here are my thoughts on this.

The communications channel:

Virtual teams often begin by emulating the behavior and circumstances of real teams. But can they?

The first thought is communications. Real teams can handle a much greater N2 communication intensity because much communication is person-to-person, and much of person-to-person communication is non-verbal.

What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.

Non-verbal face-to-face is a very high bandwidth channel -- speed of light really -- capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding among strangers or nearly strangers. Nonetheless, it's much easier to sort out the cacophony of discussion if you can put face and voice and context together. (Anyone who's participated in a large video conference knows the difficulty of segregating voices and getting them associated correctly)

Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth. Even with up to date video, the non-verbal is communicated in a lossy channel. And here's the thing: you don't know how much is lost. Thus, more time is needed in the schedule to compensate for the bandwidth constraints.

Velocity impacts:

Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virtual velocity before beginning the first iteration. Look for virtual velocity to be slower, and productivity less. 

Perhaps the virtual team needs to be larger, or given smaller bites to work on. (Ooops: Adding people to a slow team makes it slower ... Read: "The Mythical Man month, 20th anniversary edition")


Assigning team work:

Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces.

Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple".

But over simplification is hazardous also. Who's got the "big picture" in mind? The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.

Iteration Planning and tracking:

The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.

Tracking progress and identifying problems:

Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.

The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.

I end where I started:  "Of course", with some adjustments.

---

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

Illuminating the path

---

Here below I shamelessly reprint a posting from herdingcats.
Why? Because Glen's point about the purpose of plans is to illuminate possibilities; not to constrain critical thinking, common sense, and accommodation for changing facts, is profound.  Everyone who practices project management or team management should understand that.

From herding cats:

In the space of two days I had evolved two plans, wholly distinct, both of which were equally feasible. The point I am trying to bring out is that one does not plan and then try to make circumstances fit those plans. One tries to make plans fit the circumstances 

George Patton

General, U.S. Army

"Any suggestion that plans and planning are not part of project management, no matter the approach - agile or traditional - wilfully ignores the purpose of a plan. That purpose is not the force the team to follow a path, but to illuminate the possible paths that can be followed to reach the goal."

end quote (emphasis added)

---

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

Organization v management

---

We organize with hierarchies; we manage through networks

 More or less, that idea is the theme of historian Niall Ferguson's book "The Square and the Tower".

Simply said, the orgainizing principle of bureaucracy is the hierarchy  -- span of control; process flow-down; interchangeable people (to an extent) such that no one is indespensible -- everyone ages out!

But effective management more or less ignores the organization chart. Effective management reaches and influences any and all who can make a difference.

Hierarchy is way too restrictive for effective management; it promotes stovepipes and "we/they" stresses that are not value-additive. And, it's one dimensional: command and control. Networks, on the other hand:

• Are multidimensional: cultural, financial, personal, professional, political (and, all of the above)
• Are fluid with circumstances
• Respond to multiple cultures -- virtual, domestic, foreign, business
• Convey power in multiple ways: real power (hierarchy); associative power (who you know, and how well you know them); cultural or personality power
• Facilitate promotion: way more people get to know you  

"They" say: if you can't effectively network, you can't expect to be influential and consequential. "They" are probably right
 

---

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

Accurate v Fairness

---

Do you use a lot of data in your project? Most everyone does.
Things to keep in mind:

• All data has some bias(es) built in
• Because it's objectively accurate doesn't make it acceptably fair

Bias in data

There are library shelves full (or virtually full at library websites) of papers explaining biases that get built into data, even if unwittingly. Kahneman and Tversky probably have some of the best reading on this subject. Factors:

• (Planning) Experiment design flaws
• (Collection) Measurement and counting method error sources
• (Collection) Expectations influences on observations
• (Analysis) Statistical errors and data selection errors (bias)
• (Interpretation) Framing to make a point
  

Accuracy v Fairness

You probably ran into this in school: grading on the curve. Grades were objectively one thing, but in fairness--we are told--grades posted were something else.

What's fair isn't what's accurate, necessarily

Fairness is about impact--what the downstream causation and consequences are for having applied data results to an issue. When people are in the loop, all the harder: race, class, win-lose, antimosities.

In the project office, the first instinct is (or should be) objectivity.

Risk management
But then objectivity meets management goals (*), and before you know it, we're back to "grading on the curve". If "fair" and "accurate" are not the same, then there is a gap. And, what is the nature of this gap? Risk! And, who is the risk manager? The PMO, naturally

(*) Political, humanitarian, economic, social justice, or competitive factors enter the picture.

---

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

Bitcoin project budgets

---

Cryptocurrencies are coming to a project near you! Indeed, you could be first on your block to budget in a cryptocurrencies, of which there are now hundreds according to a study by NIST

It's all magic you say? You're in good company: Arthur C. Clarke once wrote, “Any sufficiently advanced technology is indistinguishable from 130 magic”

Now, I've worked on projects with foreign currency funding; that put's the company's treasurer on the project team. The treasurer works the currency hedges and other exchange related stuff.

Would a project paid for in Bitcoin be different? Yes, and no. Yes, the volatility of cryptocurrency values adds a degree of risk not usually on the risk matrix. No, currency-hedged projects are not that unusual. We've done it before.

What is money?

This question doesn't usually arise in project management circles, but hey! It's a new monetary world. 

Most of the world's money today, some say 90%, is virtual: no paper, no coinage, no gold or other tangible back-up. Virtual money that is one of the five world exchange currencies has properties that transfer well to cryptocurrency:

• Convenienty portable, more so than gold bullion for sure
• Persistent, never wears out or can be destroyed like coinage and paper (the Canadians have gone to a plastic replacement for paper, but nonetheless....)
• Value universally understood by comparison to tangibles (we know the value of a Coke the world over)

Ergo: cryptocurrencies can qualify as money

The blockchain
The thing that makes a cryptocurrency work is an underlying technology called a "block chain". The important take away understanding a block chain is that it is a secure distributed database with no central authority but with enforced data integrity.

Now, a secure distributed database can be useful for a lot of stuff, and for distributed projects it could be very useful indeed.

Here's what NIST says about what a blockchain is:

Blockchains are immutable digital ledger systems implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority. At their most basic level, they enable a community of users to record transactions in a ledger that is public to that community, such that no transaction can be changed once published.

A blockchain is essentially a decentralized ledger [database] that maintains transaction records on many computers simultaneously. Once a group, or block, of records is entered into the ledger, the block’s information is connected mathematically to other blocks, forming a chain of records.

Because of this mathematical relationship, the information in a particular block cannot be altered without changing all subsequent blocks in the chain and creating a discrepancy that other record-keepers in the network would immediately notice.

In this way, blockchain technology produces a dependable ledger without requiring record-keepers to know or trust one another, which eliminates the dangers that come with data being kept in a central location by a single owner.

---

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

Collingridge's dilemma

---

A simple but profound observation:

When change is easy, the need for it cannot be foreseen; when the need for change is apparent, change has become expensive, difficult and time consuming.

David Collingridge
"The Control of Technology"

---

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