Data rule #1

---

The first rule of data:

• Don't ask for data if you don't know what you are going to do with it

Or, said another way (same rule)

• Don't ask for data which you can not use or act upon

 And, your reaction might be: Of course!

But, alas, in the PMO there are too many incidents of reports, data accumulation, measurements, etc which are PMO doctrine, but in reality, there actually is no plan for what to do with it. Sometimes, it's just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job.

The test:

 If someone says they need data, the first questions are: 

• What are you going to do with the data?
• How does the data add value to what is to be done
• Is the data quality consistent with the intended use or application (**), and 
• Is there a plan to effectuate that value-add (in other words, can you put the data into action)?

And how much data?

Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

---

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

Is it alright to guess in statistics?

---

Is guessing in statistics like crying in baseball? It's something "big people" don't do.

Or is it alright to guess about statistics? 

The Bayesians among us think so; the frequency guys think not. 

Here's thought experiment: I postulate that there are two probabilities influencing yet a third. To do that, I assumed a probability for "A" and I assumed a probability for "B", both of which jointly influence "C". But, I gave no evidence that either of these assumptions was "calibrated" by prior experience.

I just guessed

What if I just guessed about "A" and "B" without any calibrated evidence to back up my guess? What if my guess was off the mark? What if I was wrong about each of the two probabilities? 

Answer: Being wrong about my guess would throw off all the subsequent analysis for "C".

Guessing is what drives a lot of analysts to apoplexy -- "statisticians don't guess! Statistics are data, not guesses."

Actually, guessing -- wrong or otherwise -- sets up the opportunity to guess again, and be less wrong, or closer to correct.  With the evidence from initial trials that I guessed incorrectly, I can go back and rerun the trials with "A" and "B" using "adjusted" assumptions or better guesses.

Oh, that's Bayes!

Guessing to get started, and then adjusting the "guess" based on evidence so that the analysis or forecast can be run again with better insight is the essence of Bayesian methodology for handling probabilities.

 

And, what should that first guess be?

• If it's a green field -- no experience, no history -- then guess 50/50, 1 chance in 2, a flip of the coin
• Else: use your experience and history to guess other than 1 chance in 2
  

According to conditions

Of course, there's a bit more to Bayes' methodology: the good Dr Bayes -- in the 18th century -- was actually interested in probabilities conditioned on other probable circumstances, context, or events. His insight was: 

• There is "X" and there is "Y", but "X" in the presence of "Y" may influence outcomes differently. 
• In order to get started, one has to make an initial guesses in the form of a hypothesis about not only the probabilistic performance of "X" and "Y", but also about the the influence of "Y" on "X"
  
• Then the hypothesis is tested by observing outcomes, all according to the parameters one guessed, and 
• Finally, follow-up with adjustments until the probabilities better fit the observed variations. 

Always think Bayesian!

• To get off the dime, make an assumption, and test it against observations
• Adjust, correct, and move on!

---

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

Enterprise-quality browser for the PMO

---

The trusty internet browser that has been around since the Netscape days of the 1990's has largely been a lay person's user interface to the internet and sundry consumer internet apps accessed via the browser.

Fair enough

Let's stipulate: In the last 30 years that browser user experience has improved dramatically, to be sure.

Something different

But in recent years, and especially accelerating in 2024, the "enterprise-quality" browser had made inroads in the enterprise business world. New browser companies (*)  have formed and are addressing the heightened security needs of the enterprise as well as a myriad of other needs (see below). This opportunity is not lost on the traditional guys from Microsoft, Apple, and Google; they also have their versions of an enterprise browser. (*)

The general requirements set is this:

• The need for an easier and less complicated way to integrate business apps into the browser. 
• More of a "windows" (small 'w') look with multiple app windows in a common display, decidedly different from a row (or column) of tabs.
• Security protections that are more demanding in the enterprise setting.
• Network, IT, and data protection functions built-in 

PMO effects

So in the PMO you may see new browsers and some of your favorite apps, like Office, database engines, scheduling and costing apps, statistical apps, and others that are somewhat "bolt-on" apps to the consumer browsers (Chrome, Edge, and Safari) become a more integrated app set on the enterprise browser. 

_________

(*) Island and Here, formerly OpenFin, but also "Edge for Business" from Microsoft and "Chrome Enterprise" from Google

---

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

Clearing the backlog

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling? 

Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

 

Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?

If coupling is a benefit, how to obtain it?

First, there's buffers to loosen coupling

The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects

• To avoid coupling, buffers may not do the trick.
• But to enable coupling, we need some connectivity

In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 

 

One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.

 

Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 

Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

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

Government Research you can access

---

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!

Software: Is it ever Done?

---

The software is never done!

Certainly not news; and certainly not profound to any engineer, coder, or PM working in the software industry, writing apps, or supporting software enabled devices.

Users have come to expect routine and regular updates to all things software.

Ooops, not so fast!

What about the automobile industry?

Traditionally: the car is done! 

• Buy it; keep it; sell it, eventually. Never needs an upgrade!

But that tradition may be short-lived: Cars will need upgrades over the life-cycle

What now?

A few months after I bought a new car I got a recall notice to take it in for an upgrade to the transmission control software. That recall system is probably the way to keep software up to date for many of the in-vehicle software programs. 

• But, is this only a warranty service? 
• How long would manufactures support software upgrades for 2nd or 3rd party apps?
• The life of car is 12 years+ for new vehicles. That's 'forever and forever' in the software industry, comparable to still supporting the iPhone 4! 

Big Tech

So-called big tech is taking over much of the user interface and user apps in new vehicles (except Tesla which does all its own in-house design and does not support Android and Apple apps on its user panels)

Long term support

As a project manager, what can you look forward to as regards long-term supportability of apps?

And, as a app developer, you may be one layer removed from knowing that it will find its way into the automobile industry. 

And as a business manager or customer support liaison, which customer are you supporting most?

• The one that pays the bills (automobile manufacturer) or 
• The customer that buys the car?

In the Agile sense of value-as defined-by-the customer, who is most influential?

Long term, these are my wonderments. I wonder how they would be written into project requirements?

• I wonder if you'll be able to go to your local auto parts retailer and buy an upgrade-on-a-stick for legacy vehicles? 
• I wonder if there is not a whole industry to be invented supporting older cars with updated interfaces?  
• I wonder if its practical to expect the after-market developer to maintain currency for 'a long time'. 
• I wonder if personal security, data security (nav data, for instance, but also other data about downloads to the car like music stations and podcasts, etc), and all the rest will not spawn a whole set of requirements, support issues, and a supporting industry?

Perhaps in the future, the mantra will have to be something like this:

The software is never done!
And, neither is the car!

---

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

Is your enterprise 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!