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

Wednesday, July 17, 2013

NIST Cloud Computing Security



In a somewhat timely release, given all the press about hacking into corporate and public sector databases, comes an updated reference architecture from NIST on cloud computing security

If you are doing a project to build a cloud, or to build cloud security for your enterprise, or if you use a cloud in your project, you might want to have your IT staff go through this document. It is rich with models and tradeoffs and recommendations.

As often the case with such government reports and recommendations, the first umpteen pages are government blah blah, but in the latter part of the document and the appendices, it gets down to business.

First up of real interest is the so-called reference architecture, complete with host of acronymns.
Then, a bit later comes the "security conservation principle" which in a few words says that no matter how you arrange the boxes, actors, and flows, security should be preserved.

There's 204 pages in this document, so I think I'll not review the whole document here, leaving it you and your staff to follow up.


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

Monday, July 15, 2013

What is strategy?


Marc Sniukas has put some time and effort into assembling and summarizing the ideas of several thought leaders in the strategy business. He's put this all in a slideshare that's a pretty good read: "What is Strategy?" -- see the embedded reader below (however, if you want to download it, bring money... sharing only goes so far.)

My suggestion is pay attention to the attribution in the small print on each page. You'll find that there are a hand full of references -- some free, some reasonable, some pretty expensive -- that are the intellectual underpinning of this presentation. It's not clear if Sniukas has added any original thought, but nonetheless, this is a good presentation.

And, before I leave you to the slideshare, let me add my own value: here's my personal definition of strategy, as given in my new book: "Maximizing project value"
Strategy is a plan that integrates continuous improvement of oper-
ational effectiveness with a vision and narrative for differentiated
innovation.





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

Saturday, July 13, 2013

Bring your own intern (BYOI)


We learn from Ian Webster that some enterprising project people, having noticed that companies are more and more letting bring-your-own-device onto the company networks, have also noticed that "bring your own" is extensible...

In the latest turn, it's bring your own intern. Ian writes:
"I rediscovered a news story this evening about a US software developer who outsourced his entire job to China without his employer knowing. The deal cost him just 20% of his six-figure salary. He then spent his days “working from home” watching funny cat videos on YouTube, surfing Reddit and buying & Selling stuff on eBay, whilst an outfit in China did all the heavy lifting on his projects for him."
How clever is that? Maybe not at all. Let me count the ways:
  • Intellectual property transfer (unintentional)
  • Undisclosed risk
  • Software bots or hacking hooks
  • Configuration control errors
With friends like that guy, you won't need a nemesis


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

Thursday, July 11, 2013

About the PM's Mission



Ever tried to write a mission statement for the project manager (not project management, per se)? I have. Here's what I came up with:
The project manager’s mission is to manage assigned resources to deliver the value expected, taking measured risks to do so
Why do I like that way of putting it? Because:
  • It's got input, output, and risk all tied in
  • It's not about scope, it's about value
  • You can't do projects if you have no appetite or tolerance for risk
  • It works in the private sector, but it also works for public sector and non-profit or NGO sectors
And, you can link the mission with what I think of as the project equation:
Project value is equal to, or greater than resources committed to the defined scope and risks taken to achieve favorable accomplishments
I like that "equation" idea because it segues nicely into this idea:
The cost of the project is not it's value; it's value is what difference it makes to the enterprise, either on the balance sheet or the mission scorecard.

Mission and value... that's the whole package!

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

Tuesday, July 9, 2013

About options and plans


"...part of [the] job was to make alternate plans in case [the project plan] proved impractical to carry off, or if strategic objectives changed in a way that brought that particular option into doubt. ... several options must be kept open at the same time; if only one option is on the table, it is not an option"
General Eisenhower

That was all good and well for Eisenhower; he got the result he wanted. But how does it work in our domain? In our business, we have:
  • One vision or narrative of "done"
  • One project charter
  • One baseline plan
Do we need options? Of course, yes we do. The practical effect of General Ike's thinking for project managers is this: Every plan is an option selected: there's always more than one way to get there.  Indeed, every plan should be an option in a larger set -- until it (the plan) is carried out -- unless it's the only plan, and then it's not an option: it's a mandate.

Now, playing the options is both an art and a science. In the financial markets domain, playing options can be an exercise in prescient risk management, or just a hunch. But, the financial player has to put something down to get access to the opportunity.

In the PM domain, it's similar: we want options but not obligations. We have these option tools:
  • Rolling wave planning
  • Probabilitic event chains
  • Iterative development and spiral methods
  • Prototypes, experiments, and red/blue teams

Obviously, to act on these things, the PM has to put some resources on the line. It's about putting something down -- aka, down payment, or contingent action -- to preserve the flexibility for future actions. To read more about options and PM, click here.

Of course, Eisenhower was not the only guy making plans. He had to contend with Winston Churchill, a man said to carry about his own china shop. WSC said about plans:
"It was all very well to say that everything has been thought of. The crux of the matter [is] -- has anything been done?"
"Done" is, indeed, the crux of the matter! WSC was all about the 'ends'; he was very flexible on the 'means' -- aka, options.

So whereas strategy and plans close the door on some flexibility, codifying constraints, and vectoring the project down some path, they also are the set-up for 'done'. The "done" thing is pretty important; in the end, it's the only thing that will be remembered and the only thing with lasting business value.


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

Sunday, July 7, 2013

Portfolio cards and dots and colors









Today's lesson: How to plan a portfolio.

1. Assemble in the war room: We're going to do brainstorming in the war room; we need a lot of wall space for cards and notes.

2. Begin work at the portfolio level: Get the narrative for each project on a colored card... different color for each project... Project Orange; Project Blue; Project Green, etc. Create a project area in the war room for each project.

3. Work on getting the scope right in the portfolio. Examine redundancy, coherence, and diversification among projects.

-- To reduce single point failures in the portfolio, we looked at ways to put redundancy into each project -- similar but independent capability. We used colored dots on (project) colored cards to indicate where the redundancy came from (example: Project Orange might have an orange card with a blue dot indicating that this was capability redundant with Project Blue but placed redundantly in Project Orange)

-- For coherence we looked at the ways that one project could support another (dependency, but also synergy) such that both together were of greater business value. This may lead to adding some scope to some projects to get the inter-project coherent support

-- To further look at risk, examine the big scope in each project and decide how to divide it up and spread it around so that a common threat does not take down a big chunk of scope. Thus,  the big stuff is diversified by dividing it into littler stuff and spreading it around in different projects.

-- And, look at inter-project coupling: the degree to which a problem is blocked from propagating from one project to the other, or the efficiency with which dependencies are conveyed from one to the other

4. Decompose the scope of each project with some task statements, each at the same level of complexity/importance etc, and each colored according to project. Of course, you could do user stories at this point. (Though some might argue for a product decomposition at this point -- and they would not be wrong -- my experience is that in a brainstorm session, people are more creative and attentive to tasks than products: e.g: Create a chart of accounts, rather than 'chart of accounts' (product))

5. Look for dependencies, both intra- and inter-project.

-- Ask people to say what dependencies there are on each major scope statement, either intra- or inter-project.

-- For inter-project dependencies, duplicate the other project's card in the other project's color and put it with the project we were examining. Thus, if the Project Orange project had a dependency with something in Project Green, put a duplicate green card in the orange project area. Thus, a mosaic is formed. The more colorful the project with other color dots and cards, the more complex it is deemed to be.

-- For intra-project use card stacks and card-to-card strings or attachments to show the major dependencies


Then, we put it all in a PDM schedule (aka, MSProject or equivalent) and build the real WBS (matrix of products)

A few observations: The project complexity, as given by the degree of color mix of cards and dots, is a indicator to make some staffing decisions, putting your best managers on the most complex projects.

For more on portfolios, click here
For more on coherence, diversification, coupling, and redundancy, click here.



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

Friday, July 5, 2013

When it's something bigger


"When it's only about you, you do what's best for you. But when it's about something bigger that you, you do what's right, not what's best"
Nelson DeMille
writing in "The Panther"

DeMille is not a professional in our business, and likely has not written anything about teamwork per se, but his thought -- expressed above -- certainly drives right to the nub of the issue in teamwork: there's no personal success without team success, and that often requires subordination of personal optimization.

Of course, it (successful teamwork) also requires reciprocal trust, personal integrity among all, respect for and commitment to the mission, and personal accountability. That's all part of "doing what's right".

Agile anyone? Or for that matter: a traditional team?


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

Thursday, July 4, 2013

Fourth of July



This office is closed on 4 July due to circumstances beyond our control
Sign on British Consulate in the USA





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

Wednesday, July 3, 2013

Past or present?


A thought for the day
We look on past ages with condensation, as mere preparation for us, ... but what if we're only an afterglow of them?
J.G. Farrell 

All you have to do is substitute 'past projects' for past ages, and you get the idea here: Too often we are too arrogant of past performance -- we say: their problems won't be repeated by me, but I can repeat their success -- and so we fail to look carefully at the circumstances that made them either fail or succeed.

Be cautious about 'asking a SME'. They are not immune to such arrogance.

And, what if it's all a set-up? The next project is set-up so that their legacy is burnished by our success more so than our own? Sounds to devious and political, so I'll leave that for another day.

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

Monday, July 1, 2013

The art of invention


I take a certain pride in being an alumnus of Georgia Tech.

Without GT, there might not be WD-40 or Elmer's Glue! (Invented by GT guys) Good grief...

But, moving on from glue, the image at right is a nano-tube rendering of the famous GT logo created by a team at Tech’s Nanotechnology Lab. Nanotubes are cylindrical structures built of carbon; each “GT” is about 50 micrometers wide. (A micrometer is one millionth of a meter.)

Nano technology is great stuff, but greater still will be the practical inventions that come from it and may other budding technologies. But, who will do the basic research and the applied inventing?

By coincidence (which I pass along to you) I read an interview on this question, and shortly thereafter viewed a TED talk that are thematically aligned.

The interview was with Nancy Nersessıan, "... a Regents professor of cognitive science at Georgia Tech, .. who .. conducts ... research into the art of innovation—how scientists and inventors actually think."

Speaking of famous scientists and researchers, she says: "What we’re taught often is that you make a hypothesis, deduce a result and then test it empirically. But that’s not what they did. They went through a different process. I call it model-based reasoning. It’s the engine of creativity. It’s what drove people to their solutions."

And what is a model? (I get this question a lot): "A model is an integrated representation that provides an interpretation of the phenomena under investigation. Models are selective (you can’t model everything) and are constructed to exemplify what are considered to be the important features of phenomena, and so a good model focuses the mind on the cognitively relevant features and enables manipulation of these."

What makes a productive researcher/inventor? "A major one is cognitive flexibility—the ability to see something from different perspectives. ... I think philosophy is great training for any scientist. It teaches you how to formulate problems. It teaches you how to think—how to understand things conceptually. ... Music also fosters creativity more broadly. Einstein played the violin.

It's this last idea that brings me to TED. Ken Robinson has a very large library of videos on TED, and he is a prolific author with a new book just released. The video below is the all-time most viewed video on TED with over 4.7M views.

In this video, you'll hear this: "If you're not prepared to be wrong, you'll never come up with anything original"
And Robinson's definition of creativity: "... original ideas that have value"

About the difference between (for example in our domain) a project model and a human factors model is the difference between what he calls the industrial model and human flourishing model. The former is characterized by: linearity, conformity, and batching. The latter by the antithesis of the industrial model with one important other feature: outcomes are not predictable.

Spoiler alert: some laughing may be required!


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