Wednesday, July 31, 2013

A bridge to a black swan

I live in Orlando: the city's Central Park lake is home to many black swans -- we also have the white kind too -- thus, I'm ok with black swans. On the other hand, Orlando doesn't any big bridges -- you have to drive 90 minutes to Tampa on the Gulf coast to get to a big bridge.

But, we read about bridges, and some of the black swan events that go along with big bridge projects.
So, here's one of those "Who knew?!" project events that most would call a black swan:

Remember the earthquake in San Francisco in 1989? Some of us do; it came right in the middle of a major league baseball game on television. The upshot was that major damage was done to the bay bridge that connects SF with Oakland. (Not the Golden Gate, but the other bay bridge)



Now we learn:
... in the San  Francisco bay bridge project ... [it] seems there are these bolts.  No ordinary bolts mind you but rather critical mission failure bolts in the bridge's earthquake design ....

The new bridge, whose foundation will reach the bedrock underneath, will be the world’s largest self-anchored suspension bridge, ... That is why the failure of some high-strength steel bolts attaching shock-absorbing devices called shear keys to a concrete crossbeam under the roadway raised alarms. When workers tightened the 17- to 24-foot-long bolts in March, 32 in a batch of 96 snapped.

Engineers blamed hydrogen-assisted cracking, in which atoms of hydrogen infiltrate steel and make it brittle, but they have yet to determine its cause.

I really can't remember the last time I put hydrogen-assisted cracking on a project risk register... perhaps never! Indeed, I can't ever remember discussing it, so -- prima facia -- it must be a black swan: Something not envisioned; something with devasting effects; something evident in hindsight.

Monday, July 29, 2013

Quipper


As project managers, we are always on the scout for excellent project resources. If you're in a matrix environment, then you probably depend on functional department managers to train their people and provide projects with the latest skills.

Competence in the programming language QUIPPER may be one of the skills you'll be looking for. It's a new language developed to handle quantum computing. In an essay in New Scientist we learn that Quipper is the first practical, high level programming language for the quantum class of computers.
Quipper is designed to express instructions in terms of bigger concepts, and to make it easy to bring together multiple algorithms in a modular way
Peter Selinger of Dalhousie University in Halifax, Canada, and colleagues have brought the field up to speed by creating Quipper ,
Quipper's creation was funded by IARPA, the US Intelligence Advanced Research Projects Agency, in order to pin down how many bits a quantum computer would need in order to outperform a classical one on certain tasks.  

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

Saturday, July 27, 2013

Mystery, secrecy,and privacy

This blog is not about politics, so we'll keep to the knitting and wax on about mystery, secrecy, and privacy in the project management domain.

For today's screed, I took a few thoughts from an unlikely source of PM advice I found in an 2013 article by Jill LePore entitled "The Prism" (a term in the news of that time)

I, for one, had not thought a lot about the subtle but substantive differences of our three title terms insofar as they have their individual effects on governance, understanding, communications, and perhaps even innovation.

By Ms LePore's reckoning, we can divine the following:

  • Mystery is knowledge held by a very few, perhaps only one -- the project's "Almighty" -- with the intent of creating a mystique around the idea or the individual. In other words, the mystical knowledge has no overt operational purpose since it is never to be revealed on acted upon. It's all about aura and mystification.

    Politicians love mystery and mystique, isolating them a bit from challenges. Autocrats love mystery too: mystique amplifies power. And, believe or not, the marketing department loves mystique -- mystique sells!
  • Secrecy is the way we compartmentalize knowledge intended to be acted upon and drive operational outcomes -- but only by a selected few actors.

    For whatever reason, secrecy can move the project forward when otherwise acting in a fishbowl with this knowledge is judged to be ineffective... some will be inhibited from full discourse; others embarrassed to show weakness or ignorance; and some will use the information against us.

    In business, secrecy often goes by the name "proprietary". In projects, to take one example -- but there are many legitimate examples -- competitive proposals are always held secretly from the competition.

    And, the flip side is that if your project is in receipt of proposals from vendors vying for your business, then you need project protocols to protect their competitive secrets.
  • Privacy is about our own stuff, our own thoughts, and our own biases that we can live with but choose not to share. Although we are social in our relationships, everyone needs their moment and place of privacy.
    (See: issues with open space project space)

    Of course, sometimes privacy crosses over into a personal secrecy to compartment things you are doing. That's where the trouble begins because governance, understanding, communications, and perhaps even innovation are surely threatened by personal secrecy just as official secrecy can have debilitating effects.
Bureaucracy begets mystery
Mystery accumulates around bureaucracy, whether intended or not. The larger the structure the more mysterious are those in the head office -- including, by the way, the PMO. Open door policies and other communications are partial anecdotes, but the real anecdote is a flat organization.

Mystery can be a tool
On the other hand, companies exploit mystery to create an aura in the marketplace and enhance their competitive posture, especially on competitive project proposals. Every proposal I ever led had a marketing guy attached whose job was not only to develop information on the competition but also to create mystery in the marketplace -- scaring the competition and attracting the prospective customer.

Secrecy requires definition
Secrecy is about deliberate compartmentalization. And "deliberate" is the operative term. To be deliberate requires definition in advance of the criteria to invoke compartmentalization. In some domains, the requirements and definition come by contract and are imposed on the project. But there's also a lot of proprietary activity -- see pharma R&D for instance -- where corporate secrecy abounds.

Privacy is a late comer
In the genealogy of these things, privacy is a late comer. As mystery became less religious and more secular as Europe exited the Dark Ages, privacy in personal affairs became more of a main stream idea. But in the United States, it did not acquire a legal definition until late in the 19th century. Now, projects have to address privacy issues left and right, and with all manner of cultural and geo considerations. And, the culture of privacy is a shifting ground, so projects are always in a demand-driven mode vis privacy requirements.

In some respects privacy is a wicked requirement: circular, no apparent point of entry, and self conflicting in many respects. No small matter as you try to contain scope, cost, and meet milestones!

Thursday, July 25, 2013

Agile mixed with oil and gas


There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what've got here?
  • A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
  • A need to run with pilot projects before committing to production
  • A need to tie into legacy systems (in the OGM case, distribution systems)
  • A lot of deliverables that can be done incrementally and then integrated
  • Small (it's all relative re small) teams, co-located, personally committed, with risk hanging on every move.
  • A degree of local autonomy required to meet the challenges of the moment
Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":
You can't go around self-organizing (agile speak) willy-nilly! There's regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!


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

Tuesday, July 23, 2013

Of slack and buffers

If you're like me, when you went to PM school one of the exercises was to hand calculate the critical path in a PDM schedule network. I think I even had such a problem on my PMP exam -- back in the last century.

And of course the question is begged: "what's a critical path?" . Quiz follows:
  1. Is it the most important string of tasks (judged by project objectives)?, or
  2. Is it the path with no slack?
And the answer is "2". And, by the way, the critical path could be a no-slack path of least important tasks -- critical but unimportant!

Fair enough -- but what about the "we've got slack" paths? If they are potentially important but not critical what is the management protocol to be applied?

Protocol choices for slack
There are two choices:
  1. Start everything as soon as possible with finish-to-start precedence
  2. Start everything as late as possible
Another way to state these protocols is:
  1. Smart
  2. Dumb
Or, how about this rendering?
  1. All risk is in the future; issues are in the present
  2. All risk is now and the future is certain
Or yet another:
  1. Action
  2. Procrastination
It seems patently obvious to not plan your project as a latest start, flipping the whole "cone of uncertainty" thing on its head... but it happens!

In a recent blog, I gave three ideas on planning... Your choice!

Sunday, July 21, 2013

Cicero on risk

"... Any rash fool can be a hero if he sets no value on his [business or fellow colleagues] or hasn't the wit to appreciate danger. But to understand the risks, perhaps even to flinch at first, but then to summon the strength to face them down -- that is the most commendable form of valor"
Marcus Tullius Cicero
 
A project manager who is rash is also probably a fool, and worse if he/she hasn't the wit to understand and appreicate project risks. But the the PM of commendable valor is the one that may flinch or draw back from risks .. at first, but then summons the strength to face them down ...
 
In my risk management courses, I hear all too often that sponsors and others may be a bit short on valor, even as they may not be witless, when they:
  • Look the other way on risks,
  • Kill the messenger,
  • Fail to fund mitigations, and
  • Then are the first to look for scapegoats.
Of this group we can truly say: Valor was not a common virtue. 

Friday, July 19, 2013

Mobile device security


What project is not running these days with some number of mobile devices? In fact, the question may be put the other way around -- what projects are running with laptops or desktops? Likely the answer to this is "all of the above"

With that in mind, you might be interested in this blurb from the NIST:

The National Institute of Standards and Technology (NIST) has published a mobile device management guide...
Employees want to be connected to work through mobile devices for flexibility and efficiency, and managers can appreciate that. However, the technology that delivers these advantages also provides challenges ... because these devices can be more vulnerable.
...
Guidelines for Managing the Security of Mobile Devices in the Enterprise helps ... organizations struggling with this dilemma.
The revised guidelines recommend using centralized device management at the organization level to secure both .. issued and individually owned devices used for ... business.
...
Other key recommendations include instituting a mobile device security policy, implementing and testing a prototype of the mobile device solution before putting it into production, securing each organization-issued mobile device before allowing a user to access it, and maintaining mobile device security.

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