Public access to Government research

---

Since at least 2013, there's been a push from the President's Office of Science and Technology Policy to make as much as possible of government sponsored research available to the public for free.

On August 25th, 2022, this policy initiative of access to government research got another push when OSTP published more detailed and aggressive guidance to the executive departments.

What was behind pay walls and other barriers may now be in the free public domain. 

Your project might benefit.

Check it out.

---

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

Working for an enterprise with Agile

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc. come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the enterprise has money!

And where does that money come from? Not you, most likely. Other people! So Other People's Money (OPM) is what is funding you.

Who are these people? If an enterprise, then there are going to be a wide variety: Customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise imposes expectations

So, here's the thing: even if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations up front .... starting with: expected value return on resources invested.

It's natural that Agile people resist too much "up front" definition; we're about evolution and iteration. But there has to be a compromise.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is more than expected; it's required.

Enterprise expects estimates (gasp!)

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience, unless you're just a researcher working on your own small project.

Enterprise brings scale

What makes an enterprise an enterprise is size and scale. 

And what makes a project "enterprise" in it's scope is size and scale.

And there is the rub: Size and scale is always more than what a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. 

Scale is not just a lot of one thing, like a large code base. Scale brings breadth, meaning a lot of different things involved and integrated, and scale brings then brings rules, procedures, accountability, etc. into the frame because a lot of people have to work somewhat anonymously ... according to rules and procedures ... to bring it together, repeatedly, within predictable limits.

The question: "Can it be done what your doing 'at scale'?" Hand-crafted, job shop, one-off are not descriptions of scale.  

Enterprise brings rules

There will be a lot of rules. 

There will be a lot of rules because there will be a lot of people involved, many you will never meet, doing jobs for the enterprise you may not even be aware of, but these jobs will nevertheless touch your project or product.

Enterprise requires a narrative

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard elements of the narrative you've heard before:

1. Vision: What is envisioned as the benefit to the enterprise? Who are envisioned as the beneficiaries?
2. Scope: What is it you're going to do (and what are the ancillary or consequential impacts elsewhere in the enterprise that you don't consider part of your scope?)
3. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
4. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

Narrative, estimates, rules, value commitments?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

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

Methodologies: more than one way to do it

---

Did everyone catch Glen Alleman's posting on LinkedIn about the 'Waterfall Myth'? If not, here are a few value-adds from that posting. 

First up: Glen's definition of sundry methodologies for developing software systems, whether stand-alone, as it were, or embedded with hardware development:

• Waterfall Approach: Development activities are performed in order, with possibly minor overlap, but with little or no iteration between activities. User needs are determined, requirements are defined, and the full system is designed, built, and tested for ultimate delivery at one point in time. A document-driven approach is best suited for highly unprecedented systems with stable requirements.
  
  
• Incremental Approach: Determines user needs and defines the overall architecture, but then delivers the system in a series of increments (“software builds”). The first build incorporates a part of the total planned capabilities; the next build adds more capabilities, and so on until the entire system is complete.
  
 
• Spiral Approach: A risk-driven controlled prototyping approach that develops prototypes early in the development process to specifically address risk areas, followed by assessment of prototyping results and further determination of risk areas to prototype. Areas that are prototyped frequently include user requirements and algorithm performance. Prototyping continues until high-risk areas are resolved and mitigated to an acceptable level.
  
  
• Evolutionary Approach: An approach that delivers capability in increments, recognizing upfront the need for future capability improvements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly.

A long legacy

Now Glen goes on to let us know that some of these ideas go back almost 50 years, if not or more. So if you recognize some Agile concepts in the words above, you would be right. And, their provenance is a trail much longer than the infamous Agile conference --  at the turn of the millennia -- that more or less launched Scrum and XP and others into the public domain. 

What's to like?

Looking at all of these methods conceptually, it's hard not to like a combo of Spiral -- which has a strong focus on risk management of testy requirements that may be impractical at first blush, but might yield to some clever prototyping and evaluation -- and Evolutionary which has an up-front bias toward early value-add for users, but with recognition that these same users are going to provide insight to future capabilities and needs.

The hard part

If you go with some version of the incremental or evolutionary method, or some version of classical Agile, like Scrum or XP, they all presume flexibility on the PM's part to approach and engage the customer or user in product evaluation and value development. 

That's easier said than done in many situations:

• In the public sector, cost often is first priority, and users have to make do.
• In the contracting domain, the engagement with the user if often proscribed, limited, and arm's reach remote
• In the commercial sector, "first" often wins, but what's to come "first" is often a big corporate secret not to be shown to anyone outside the 'green room'. 

And, don't forget: I wrote the book ... see the cover below. You'll find it wherever you buy your books with e-commerce.

---

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

Is your PMO worried about 'quantum supremacy'?

---

What kind of a question is this? 

Is your PMO worried about 'quantum supremacy'?

Actually, some are.

Some of the world's largest banks' IT PMOs are staffing to get answers about how the coming .... but not here yet .... supremacy of quantum computing may affect their projects. And that's to say nothing about comparable PMOs in the law enforcement and intelligence communities, pharmaceuticals, weather, and others.

And before 'supremacy' there comes 'quantum advantage' according to Marco Pistoia, who runs JPMorgan's global technology applied research group. 

• Quantum advantage means competitive but not overwhelming benefits from quantum computing (Some of this is happening now at Oak Ridge National Laboratory, for instance)
• Quantum supremacy means overwhelming capability that brings into the frame computing tasks that would never have even been attempted.

What are the issues for PMOs?

For purposes of discussion, they break down into three broad areas:

1. Threats
2. Benefits
3. Operations

Threats

The threat comes from bad actors who acquire quantum capabilities and seek to break into (by solving the decryption, etc.) secure project or business communications, or to break into secure project databases that might have valuable intellectual property or privacy information, to name just a couple of computing-intensive tasks.

So security, heretofore provided by the awesomeness of the computing task to overcome encryption and other security barriers, won't be enough. Many PMOs have to communicate over broad areas, so physical exposure of sensitive communications and data is inevitable.

Of course, quantum encryption by the bad guys of their own stuff may also threaten conventional means to decrypt their nefarious communications.

Benefits

The benefits are almost self-evident: projects that were stymied or impractical by conventional computing capabilities may come into the frame. There may be new science, perhaps even new physics (gasp!)

And certainly a new level of risk management may become available for the truly hard-to-model and understand risk events.

Security techniques that might have been uneconomical may become attractive. 

Data warehouses may provide some residual or latent value that was hidden behind the lack of capacity and capability of conventional computing. 

Operations

Operations break into three categories:

1. "Keeping up with the neighbors". If you're a big bank, big pharma, big weather, or big anything you have to keep up with your competitors, if not beat them. So your project office, as a component of your enterprise, needs to keep up as well
   
   
2. "Move to the cloud". It's more likely than not that your quantum computing experience is going to be cloud based. Such is already in place for some government and educational projects at Oak Ridge in the "quantum computing hub".
   If now you don't understand the cloud as an enterprise computing platform useful in the PMO and the projects generally, now is not too early to get yourself a project based in the cloud and acquire some experience. 
   
   
3. "Staff for expertise". First, you'll need advisors that can keep track of the technology and explain the utility in terms understandable in the PMO. That's where the banks are starting. Then, you're going to need software people who can architect tasks to fit quantum computers, and other software people to write the code and spin the wheels. 
   And, consider strategic partnerships, especially with the early adopters which tend to be in the research universities, national laboratories, and certain other research centers.

And then there's "entanglement"

Entanglement, somewhat pooh poohed by Einstein, is no-lag-time communication between quantum units without wire and wireless. Literally instantaneous, as it were.

And, such was recently demonstrated over a distance of 20 miles! 

Entanglement brings a new dimension to quantum computing, which may be even beyond "supremacy".

---

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

 

You pay for others to watch you work

---

There are a lot of collateral and unforeseen outcomes to the pandemic-driven remote workplace. 

One that I certainly did not foresee is the phenomenon, now a for-profit business, of you yourself paying a fee so that others ... strangers for the most part ... can watch you work.

Or perhaps it should be said the other way around: Some people need a social environment in order to work effectively; they need to know that they are being observed, watched, or evaluated. Without such, virtual loneliness sets in; spirit and productivity plunge. 

Our need to be a part of a professional social environment is important. It's tough to be a loner. So, now you can pay to have a crowd around you. And to be effective, it seems these environments need not be teams, not even groups. Minimally, they are just random collections.

And so now it is possible to join --- for a fee --- Zoom groups of strangers who can  observe you as you also observe them, all working asynchronously and independently on various somethings in their professional lives.

And if it pays off, literally, with improved outcomes that are monetized, who can fuss with the ROI, or the process?

---

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

Is trust essential? Is the answer obvious?

---

"They say" that trust is essential to any project team working effectively. To not trust is to layer on ineffective and non-value add efforts at surveillance, double checking, micro-management, etc and so on.

Yet, if there was universally trust everywhere you do business, you would not need nearly all the structure that goes along with people working in groups. But the fact is that projects of any significant scope are organized with hierarchical structure (minimum trust required):

• Some one is in charge
• Others "report to ..."
• Rules are a tool; they can substitute for face-to-face encounters
• Trust is not really required because 'rules' enforce acceptable behaviors
• Break the rules, and there are consequences. But, the consequences are usually time-limited. You get out of the dog house after you've served your time
  

Not so fast!

Hierarchies may be the on-paper way of organizing, but 'getting things done' requires networks; and networks are definitely not hierarchical. 

But networks run on trust, not rules. No trust ... no network, or least no network membership.

• Oh, yes, there are consequences, but, no, there are no time limits. 
• You may be in the dog house a very long time.

 And so here we are:

• On paper: hierarchies and no trust required. Rules are all that is needed; and consequences if the rules are broken
• In fact: networks are how people work; rules aren't need. But, if trust is broken, there are consequences. And those consequences are very long term.  

---

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

Density of value

---

Density, if you're wondering, is always a ratio of "something" per unit of "something else". 

You probably recognize such a construction as a ratio. 

Value is a more complicated idea:

• It's in the eye of the beholder (I value it, even if you don't)
• It's subject to bias (one in hand vs two in the bush)
• It's susceptible to the effects of utility compression (more is better, until it's not)
• It's what you're willing to pay for (willingness and capacity and capability are different ideas)
• It advantages cybernetics (the outcome is more valuable than the collection of inputs)
• It's usually 'most bang for the dollar', not necessarily lowest price. To wit: "best value"
• It may have a wholly social dimension, as value in the public sector, which may be completely subjective
• It may combine, or entangle, with the closely related concepts of "quality"   
• It's a lot of different stuff, all at once

Connect the dots: if density is a ratio (it is) and value is a lot of different stuff, what then is the combo: "the density of value"?

Like value itself, there's more than one idea:

• Pack it all in: How many different things, each separately valuable, can be packed into one container, device, or app, to wit: valuable 'items' per 'container' 
  
  The smart phone is the poster child for this one: phone, camera, scanner, database, browser, network connector, mobile operating system, myriad apps, compass, geolocator, clock, timer, and endlessly more it seems
  
  
• Compress it by transforming it
  Though vinyl is coming back a bit, cubic mountains of vinyl are obsolete, but the music plays on digitally, but in a lot less real estate
  
  I still buy printer paper, but a lot less! I 'print' to pdf and electronically store it (and retrieve  it) more efficiently and more densely (hundreds of searchable pdf's on my smart phone rather than file cabinets full)
  
  My smart phone is no longer a 5-pound brick
  From vacuum tubes, to transistors, to dual-inline, to integrated circuits, I can build an amplifier on the head of a pin; everything needed is just denser!
  
  From millions of miles of telephone cable, to microwave telephone relays, to microwave cellular, the density of calls per unit of bandwidth is dramatically more.
  
  And the information density in a communication channel is approaching the Shannon limit of irreducible entropy. To wit: Transfer the entropy elsewhere! Claude Shannon would be pleased no doubt that so many are working on that very idea.

The question

As you create value, are you creating world class value density?!

Because 'value density' itself is valued!

---

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

The asymmetry of value

---

I've written a couple of books on project value; you can see the book covers at the end of this blog.

One of my themes in these books is a version of cybernetics:

Projects are transformative of disparate inputs into something of greater value. More than a transfer function, projects fundamentally alter the collective value of resources in a cybernetics way: the value of the output is all but undiscernible from an examination of inputs

But this posting is about asymmetry. Asymmetry is a different idea than cybernetics

"Value" is highly asymmetrical in many instances, without engaging cybernetics. One example cited by Steven Pinker is this:

Your refrigerator needs repair. $500 is the estimate. You groan with despair, but you pay the bill and the refrigerator is restored. But would you take $500 in cash in lieu of refrigeration? I don't know anyone who would value $500 in cash over doing without refrigeration for a $500 repair.

Of course there is the 'availability' bias that is also value asymmetrical:

"One in hand is worth two in the bush"

And there is the time displacement asymmetry:

The time-value of money; present value is often more attractive than a larger future value. The difference between them is the discount for future risk and deferred utility.

Let's not forget there is the "utility" of value:

$5 is worth much less to a person with $100 in their pocket than it is to a person with only $10

How valuable?
So when someone asks you "how valuable is your project", your answer is ...... ?

 

---

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

Detecting deep-fake video calls

---

As I previously posted, there is a growing threat that the person to whom you are video conferencing is really a deep fake. For projects, this threat arises in recruiting strangers remotely by video call, but also in other situations when the 'familiar face' is really fake. (But I know that person! How could the image I'm seeing be fake?)

Here is a report of new research by NSA and UC Berkley about a new tool -- 'monitor illumination' -- that can 'fake the fakes' in a way that gives better assurance that the fake is detected.

Of course, now that this has been widely published, the counter-counter-measures are probably already on the drawing board, so to speak.

---

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