Building the Appian Way

---

As a project, the Appian Way was monumental for its time: Phase I, built in only one year .... 312 BCE ... the paved road (originally, a military road) cuts through the Alban hills and the coastal Pontine marshes to connect Rome to far southeast Brindisi.

But think about this: the Project Executive Officer, PEO, one Appius Claudius Caecus, did not have a couple of tools at his disposal that we so routinely use that they are not even noticeable:

• There was no "0" in the Roman system of math. "Nothing" was not a number. Roman numerals are/were for counting and positioning (ranking, or ordering), but not for measuring. Today, we say that Roman numerals are "cardinal" numbers, meaning numbers that are for counting.
  
  How did Caecus calculate his project variances? Was zero-variance not a possibility, given no '0" in the system?
  
  However, to build a road, you've got to be able to measure things. So, when it came to measuring and dealing with quantities, the Romans relied on a separate system known as the Roman system of measurement. This system was based on various units and standards, such as the foot (pes), the inch (uncia), the palm (palmus), and the cubit (cubitus), among others. These units were used for measuring length, weight, capacity, and other quantities.  
  
  
• There were no fractions in their system of mathematics, even though a pseudo-system of fractions existed in ancient Egypt. Maybe if Marc Antony has been around three centuries earlier, he could have brought fractions home.
  
  
• And, there were no negative numbers. This concept is almost middle-ages in its origin. Not until the 16th century did negative numbers really come into general mathematics. 
  
  Does this mean that Planned Value - Earned Value (*) was always positive? That if circumstances were such that at some point EV were greater than PV, a negative number to be sure, that Caecus could only describe that he was ahead of plan, but couldn't calculate it?
  
  
• And, of course, there was no concept of random effects and probability.
  Those effects were left to the Gods. (See my review of the book on risk management entitled "Against the Gods")

They did it

So, somehow, the Romans built a magnificent road, parts of which survive today, without a "0", without fractions (formally at least. One can imagine half a cubit, even if they can't formally express the idea), and without negative numbers. 

I wonder if I could run a PMO without these tools? Doubtful! And, my PMO would also have random numbers and systems of probability which also did not come along until about the 18th century.

_____________

(*) PV - EV is a variance, calculated at a specific point in time, that indicates positive or negative schedule variance. You've either earned what you've planned at the right time, or you've not. Some caution, however: this formula is only valid for only the duration of the baseline timeline of the project; it's not valid thereafter. Example: It's invalid to be a year late beyond the baseline delivering all the EV, and then declare that PV - EV is 0, thus no schedule variance!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The funnel and the pyramid!

---

In every book written about project management, the PMO is at the apex of a pyramid. Sometimes, as in Agile project methodology, the pyramid is flatter than most, but always there is an identifiable top figure.

Fair enough.

But Robert Gates, former Defense Secretary [and holder of many other government titles] writes that he often felt like the pyramid was inverted and thus took the look of a funnel. In the funnel model, the 'decider' is at the bottom of the funnel, with others pouring stuff in. 

 
Funnel v. Pyramid
How can it be that the top person is at the bottom, figuratively?

Gates explains: in the pyramid model, stuff is either pushed up for political cover, or because protocol demands that the decision lies higher, or because the apex person is pulling stuff up that they want control or inspection of

But in the funnel model, the top person is like the paper at the bottom of the bird cage: everything is pouring in from the top; and everybody on the project is busy doing the pouring. Fortunately, only a bit funnels all the way through, but gravity seems to be in charge. It's inexorable.

Filters in the funnel
Fortunately, the funnel can work like the pyramid, only with gravity. There can be and should be filters in the funnel. The minor stuff is trapped early and doesn't make it through. The top person -- at the end of the funnel -- can pull stuff "down", and there is some gravity effect: stuff naturally falls to the bottom for action.

And so for the PMO, the management points are:

• In the funnel model, things move by default. There's an expectation on the part of anyone pouring stuff in at the top that it will eventually come to the attention of those 'at the bottom of the funnel'. Gravity is just the consequence of applying energy to get stuff up to the top of the funnel and pouring it in.
  
  
• But in the pyramid model, gravity works against you. The default is: nothing moves to the top. If you want it to move up, there's work to be done!
  
  

If you like the idea of a funnel, how would you create it?

Just open your door! The funnel model is somewhat like "my door is always open" (even if virtual) ; anyone can "pour" something in. 

 

But, rather than "anyone can", you move to "everyone should" pour something in. As the 'decider' you don't have to pull very much in if you operate like a funnel; stuff will get to you. If you like the funnel effect, you say that's good.

Perhaps, but only if you have the methods, tools, discipline, and staff to sort it out.

If you don't, turn things upside down and operate like a pyramid. Gravity is your friend; a lot of stuff just won't rise to the top.

---

Buy them at any online book retailer!

Hub and spoke project architecture

---

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 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!

---

Buy them at any online book retailer!

Getting "reskilled"

---

Dispatches from Davos 2019
There's a revolution afoot

The panel discussions are about "human-centered A.I", and the "Fourth Industrial Revolution" in an article reported by Kevin Roose

And, thinking about it, would you want A.I. to be other than human-centered?

Strategic thinking:

 “Earlier they had incremental, 5 to 10 percent goals in reducing their work force. Now they’re saying, ‘Why can’t we do it with 1 percent of the people we have?’”

Getting there (as reported)!

One common argument made by executives is that workers whose jobs are eliminated by automation can be “reskilled” to perform other jobs in an organization.

They offer examples like Accenture (*), which claimed in 2017 to have replaced 17,000 back-office processing jobs without layoffs, by training employees to work elsewhere in the company. 

Chat now
Got some back-office processing in your project office, or supporting your project office? The automated on-line chat is coming to a project near you!

---

(*) Full disclosure: A few years ago, I worked in a PMO largely staffed by Accenture (I was the customer; they were the consulting partner)

---

Buy them at any online book retailer!

So, who's responsible for Customer?

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive, Business, Technical and Users requirements.
Securing the sign off on the requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities, in order of increasing importance, and determining the “fit to need” alignment of the requirements
d. Map solution requirements to the vendor solution/product portfolio, and determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team, and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as needed in various verticals that are needed to address the solution design and product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

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

Security vs Liberty

---

In my change management classes we debate and discuss this issue:

How do you work with a team that has a low tolerance for high change or uncertainty?

Of course, you can imagine the answers that come back:

• Frame all actions with process and plans
• Provide detailed instructions
• Rollout change with a lot of lead time, and support it with clearly understandable justification

What's rarely -- almost never mentioned -- is lead through the uncertainty. Is it odd that PMs think first of plans and process before leadership would come to mind? My advice:

• For those in the high avoidance culture, they have certain expectations of their leaders, starting with the establishment and maintenance of order, safety, and fairness.
• Insofar as change is required, even radical change can be accepted and tolerated so long as it comes with firm and confident leadership.
• Lots of problems can be tolerated so long as there is transparency, low corruption, and a sense of fair play. In other words, the little guy gets a fair shake.

Now comes a provocative op-ed from a German journalist based in Berlin with essentially this message (disclosure: I lived and worked in Berlin so I have an unabated curiosity about my former home base):

"To create and grow an enterprise like Amazon or Uber takes a certain libertarian cowboy mind-set that ignores obstacles and rules.

Silicon Valley fears neither fines nor political reprimand. It invests millions in lobbying in Brussels and Berlin, but since it finds the democratic political process too slow, it keeps following its own rules in the meantime. .....

It is this anarchical spirit that makes Germans so neurotic [about American technology impacts on society]. On one hand, we’d love to be more like that: more daring, more aggressive. On the other hand, the force of anarchy makes Germans (and many other Europeans) shudder, and rightfully so. It’s a challenge to our deeply ingrained faith in the state.

Certainly, the German view of American business practices is the antithesis of following the central plan. To me, this is not all that unfamiliar since resistance to central planning, state oversight, and the admiration for the "cowboy spirit" of individualism is culturally mainstream in the U.S., less so in the social democracies.

In the U.S. if you ask what is the primary purpose of "the State" -- meaning: the central authority -- whether it's Washington or the PMO -- the answer will invariably be "protection of liberty" (See: the Liberty bell; "give me Liberty or give me death" motto; the inalienable right to pursue Liberty, et al)

Ask the same question of a social democrat and you get "protection and security". With two devastating world wars in the space of 30 years that wiped out the most part of all economies except the U.S. and imparted almost unspeakable population losses, except in the U.S., how could it be otherwise?

Security vs Liberty: a fundamental difference in the role of central authority. Of course, all central authority provides both, and the balance shifts with circumstances. In the U.S. during the mid-19th century civil war and during WW II, and then 9/11, security came to the front and liberty took a back seat.

Now, port all this philosophy to a project context, and in the software world, no surprise: Agile!

Certainly the most libertarian of all methodologies. And, agile comes with a sustained challenge to the traditional, top-down, centrally planned, monitored, and controlled methodologies that grew out of WWII.

And, agile even challenges the defined process control methods that grew out of the post WW II drive for sustainable, repeatable quality.

Did some say: high change or uncertainty?

---

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

Reinventing the PMO (to be agile and other)

---

Rules and tools, and perhaps schools... that was your father's PMO.

But, that's not a great recipe these days. A better idea is given by Jack Duggal who wrote a piece for PMI recently about Reinventing the PMO

I don't think he started out to be an agilist in this article, and I'm not sure he read my most recent book on "Maximizing Project Value" (you can buy it here), but he and I are certainly of a common mind on this.

Some of the highlights are given in a post at leadinganswers on how Jack's idea apply to a PMO in an agile setting. From there, we learn these tidy bits about 'from-the-old' 'to-the-new' ideas in PMO-land:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough.

2. From Delivery to Adoption and Usability 
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation.

---

Bookmark this on Delicious

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

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