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!

Activities, Results, Methdology

---

Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics now become less important; outcomes rise to the top

• Activity becomes not too important. Where and when they worked could be delegated locally
• Methods are still somewhat important because Quality (in the large sense) is buried in Methods. So, can't let methods be delegated willy nilly
• Outcomes now become the biggie: are we getting results according to expectations?

There's that word: "Expectations"

In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day

• I had 800 on my team
• 400 of them were in overseas locations
• 400 of them were in multiple US locations
• I had multiple offices
• It all worked out: we made money!

---

---

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

"Against the Gods"... a risk perspective

---

If you are in the project management (read: risk management) business, one of the best books that describes the philosophy and foundation for modern risk management is Peter L. Bernstein's "Against the Gods: the remarkable story of risk".

Against the Gods is historical, somewhat philosophical, and void of math!

It's a book for "thinkers"

Between the covers of this "must read" we learn this bit:

The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us.

Peter Bernstein

"Against the Gods: The Remarkable Story of Risk"

Knowledge and control

Dealing with risk necessarily breaks down into that in which more knowledge will help us understand deal with risk (climate change), and that in which effects are truly random and no amount of additional knowledge is going to help (rolling dice).

Bernstein goes on to develop one of the key themes of the book which is the idea that probability theory and statistical analysis have revolutionized our ability to understand and manage risk.

Picking apart Bernstein's "essence" separates matters into control and knowledge:

• We know about it, and can fashion controls for it
• We know about it, and we can't do much about it, even if we understand cause and effect
• We know about it, but we don't understand the elements of cause and effect, and so we're pretty much at a loss.
• We don't know about it, or we don't know enough about it, and more knowledge would help.

Of course, Donald Rumsfeld, in 2002, may have put it more famously:

" ....... because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know."

No luck
So there is an ah-hah moment here: if all things have a cause and effect, even if they are hidden, there is no such thing as luck. (Newtonian physics to the rescue once again)

Thus, as a risk management regimen, we don't have to be concerned with managing luck! That's probably a good thing (Ooops, as luck may have it, if our project is about the subatomic level, then the randomness of quantum physics is in charge. Thus: luck?)

Indeed, our good friend Laplace, a French mathematician of some renown, said this:

Present events are connected with preceding ones by a tie based upon the evident principle that a thing cannot occur without a cause that produces it. . . .
All events, even those which on account of their insignificance do not seem to follow the great laws of nature, are a result of it just as necessarily as the revolutions of the sun.

Bernstein or Bayes' (with help from ChatGPT)

Following up on the idea of the knowledge-control linkage to risk management, Bayes' Theorem comes to mind. Bayes' is all about forming a hypothesis, testing it with real observations, and using those outcomes to refine the hypothesis, eventually arriving at a probabilistic description of the risk.

LaPlace, mentioned above, is one of the architects of the probability theory that underlay Bayes'.  Thus, one of the most interesting discussions in the book centers on Bayes' theorem, which Bernstein describes as "one of the most powerful tools of statistical analysis ever invented."

Bayes' theorem is a manner of reasoning about random and unknown effects and a mathematical formula that allows us to update our beliefs about the probability of an event occurring based on new evidence. It is a powerful tool for making predictions and decisions based on incomplete information, and it has applications in fields ranging from medicine to finance to engineering.

Bernstein's discussion of Bayes' theorem in "Against the Gods" is particularly interesting because he highlights the fact that Bayesian reasoning is often at odds with our intuition. Humans have a tendency to overestimate the likelihood of rare events and underestimate the probability of more common events. Bayes' theorem provides a framework for overcoming these biases and making more accurate predictions.

Cognitive Bias in risk management

Bernstein talks a lot about cognitive biases and their impact on decision-making under uncertainty.

According to Bernstein, cognitive biases are mental shortcuts that people use to simplify complex decisions. These shortcuts can lead to errors in judgment and decision-making. Cognitive biases can be influenced by a number of factors, including emotions, personal experience, and cultural values.

Some examples of cognitive biases that Bernstein discusses in the book include the availability bias, which is the tendency to overestimate the likelihood of events that are more easily recalled from memory; and the confirmation bias, which is the tendency to look for information that confirms our existing beliefs and to ignore information that contradicts them.

One key point Bernstein makes is that humans have a natural tendency to be overconfident in their abilities to predict and control events. This is known as the "illusion of control" bias. People often believe they have more control over events than they actually do, leading them to take on more risk than is rational.

Another common cognitive bias is the "confirmation bias," in which people seek out information that confirms their preexisting beliefs, while ignoring or dismissing information that contradicts those beliefs. This can lead to a lack of objectivity in decision-making.

Bernstein also discusses the "hindsight bias," in which people tend to believe that an event was more predictable after it has already occurred. This bias can lead to overconfidence in future predictions, as people may believe that they could have predicted the outcome of an event that has already occurred.

Overall, Bernstein suggests that understanding and being aware of cognitive biases is essential to making better decisions and managing risk effectively. By recognizing these biases, individuals can take steps to mitigate their impact on their decision-making processes.

---

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

RaaS .. It's about results

---

It's been around a few years, but RaaS ... Results as a Service ... is getting more play in projects. RaaS is a play on the more familiar and older SaaS, Software as a Service. So the difference is, among other things, that RaaS is end-item focused; tools and processes are in the black box; and the customer is buying a result they can use.

Wait!

Have we just relabeled the firm fixed-price (FFP) contract?

• FFP has been around since the beginning of time it seems.
• The customer contracts for an outcome, a result, and end-item, at a fixed price.
• The customer does not weigh in on process, methods, and tools
• The customer does not weigh in on staffing or schedule details. Major milestones, perhaps only one milestone at the end are all that count.

If Agile Methods are part of the FFP contract, then the customer may be in the loop for partial product evaluation and course corrections, but such has to be within the envelope of the original scope, or the dreaded change order comes out. And if that happens, there goes the "fixed price".

In any event, beware of old wine in new bottles, unless the wine is really different, along with the bottle!

---

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

The ideal number of workers

---

Wow! Is this true?

The ideal number of human workers in any business is zero. The purpose of companies is to make as much money as possible with the lowest possible expenses. So AI and other types of automation are not disruptions to a human-based Capitalism—instead, they’re revealing that today’s Capitalism is not fundamentally human in the first place.  Daniel Miessler

"... in ANY business ... "? Emphasis added by me. 

I have no idea how you could do projects with such a situation. So, I'm hopeful Miessler's idea is not an end-game for the PMO.

---

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

Best-and-Final-Offer Strategices

---

You're in a competitive bidding situation for a new project contract.

The buyer-customer calls for BAFO submission (Best and Final Offer)

What's you game plan and BAFO strategy to be?

Game Theory

You could fall back to game theory ideas:

• You can't cooperate with your competition, so you are adversaries
• You and your competitor both view the situation as zero-sum; there's not a win-win compromise solution
• Everyone has about the same tools to manipulate (Cost, Schedule, Scope)
• You may have some intelligence regarding customer's expectation of what is a winning BAFO strategy re cost, schedule, and scope.
• You may have some intelligence about the bidding history at BAFO of your competitors.
• Everyone has the same timeframe-- there is only one due date for the BAFO.
• The game is fundamentally unstable: You're seeking maximum optimization, not some sub-optimum stability point with your competitor (assuming the customer is only going to make one winning award, which is not always the case) 

Making it to BAFO in the first place

If you've made to the BAFO, then you've made the cut on minimally acceptable cost, schedule, and scope. 

If you're bidding to a government agency, you've also made the cut on past performance, financial strength, and regulatory compliance. 

If you've got subcontractors and specialty SMEs then that cast has made the cut with you.

Do's and Don'ts

• Do read carefully the invitation to submit a BAFO. The bias of the customer may well be exposed in the wording of the invitation.
• Don't bait and switch at BAFO key personnel, labor mix, or technical approach unless you can point to specifics from the customer's feedback to you that suggests that such cuts would be welcomed.
• Do offer a bottom line discount to price if you're bidding fixed price, but 
• Don't jiggle labor rates, labor mix, and labor participation unless you can point to customer comments that justify such. You should anticipate there will be change orders and you will not want rates, mix, and participation to be compromised for the future opportunity.
• Do wiggle the schedule if there are productivity improvements you can point to down the line
• Do rearchitect the schedule to remove constraints and improve probability of success on the critical path. Justify this with analysis you've done since the initial submission.
• Do take advantage of any independent R&D that will feed into the project.
• Don't do anything unilaterally that will damage your credibility in the eyes of the customer. Unsupported changes are often viewed as unworthy business practices and new risk.

---

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

NSA on deep fake detection of video conferencing

---

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

Classified projects ... claiming credit

---

Most of my career has been working in the black and grey world of classified projects. 

If that is your domain, heed these words:

It is the nature of classified projects that "successes are unheralded and .... failures are trumpeted"

JFK

So, if you have an idea of putting your successes on your resume, looking for your next job, gig, or career move, beware!

 

---

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

Collaboration ... virtually

---

" ....virtual collaboration is like evaporated milk with 60% of the water removed; safer; mostly up to the job, but a sterile version of face-to-face that leaves an unsatisfying aftertaste"

"Bartelby" columnist in the "Economist"

Our columnist goes on:

"There are downsides to being a clinically efficient worker. They include relinquishing the daily banter and complicity among colleagues..... Hyper efficiency and distance mean less opportunity for interpersonal tension but also less gratuitous job, which is hard to replicate on Zoom."

But then, on a business channel, I hear a start-up guy talking about developing a software application (alternative to Zoom, or Skype, or Webex) that has 'humanity built-in' 

"Humanity built in"! Perhaps, but let's wait and see ....

---

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

U.S. Gov Cloud Security... An architecture

---

Have you got a project providing software services to the civil agencies of the U.S. Government? 

If so, you should be aware of the 'technical reference architecture' authored jointly by CISA, USDS, and the Federal Risk and Authorization Management Program.(*) 

Some of its provisions are likely going to find their way into RFPs and RFIs from the civil agencies.

From the document, we get this insight from the introduction:

This technical reference architecture is intended to provide guidance to agencies adopting cloud services in the following ways:

• Cloud Deployment: provides guidance for agencies to securely transition to, deploy, integrate, maintain, and operate cloud services.
• Adaptable Solutions: provides a flexible and broadly applicable architecture that identifies cloud capabilities and vendor agnostic solutions.
• Secure Architectures: supports the establishment of cloud environments and secure infrastructures, platforms, and services for agency operations.
• Development, Security, and Operations (DevSecOps): supports a secure and dynamic development and engineering cycle that prioritizes the design, development, and delivery of capabilities by building, learning, and iterating solutions as agencies transition and evolve.
• Zero Trust: supports agencies as they plan to adopt zero trust architectures.

This technical reference architecture is divided into three major sections:

• Shared Services: This section covers standardized baselines to evaluate the security of cloud services.
• Cloud Migration: This section outlines the strategies and considerations of cloud migration, including explanations of common migration scenarios.
• Cloud Security Posture Management: This section defines Cloud Security Posture Management (CSPM) and enumerates related security tools for monitoring, development, integration, risk assessment, and incident response in cloud environments.

 

---

CISA is the operational lead for federal civilian cybersecurity and executes the broader mission to understand and reduce cybersecurity risk of the nation
The United States Digital Service (USDS) is a senior team of technologists and engineers that support the mission of departments and agencies through technology and design.
Federal Risk and Authorization Management Program provides a cost-effective, risk-based approach for the adoption and use of cloud services by the Federal Government.

---

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

Resourcing the critical path

---

In project management school, the lesson on Critical Path includes this rule:

Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.

Beware this hazard: Resources may be real people:

The problem of applying resources arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. 

Alas! The "resources" are not interchangeable. Mary and John are unique. Consequently, consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Considering Mary and John uniquely

Take a look at the following figure: There are two tasks that are planned in parallel. If not for the unique situation that Mary and John can't be applied to two paths simultaneously, these tasks could be completely simultaneous.

In fact, the critical path could be as short as 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration. But for the assignment of Mary and John pushes Task 2 to the right.

But with only Mary and John as resources, the schedule plan stretches out to 65 as shown.

 Here's an idea:

Reorganize the network logic to take into account unique staffing applied to schedule tasks.

Now the schedule plan is shorter, though not as short as it could be if there were resources other than Mary and John. 

And that is actually the embedded lesson learned: With only Mary and John, the two tasks are no longer independent. 

And with a lack of independence, there is a "co-dependency" that is a phenomenon that has to be scheduled also. Thus, we form the rule that interdependency always stretches the plan!

---

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

Agile "DONE" defined

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... Definition of Done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my definition of "Done" has been framed by the answers to these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical definition of done would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. But it's very tactical. There's more to a product than just the code. In other words his theory is proven when, in the crucible of a trying to make money or fulfill a mission by writing software, you are strategically successful (deployable, saleable, supportable product) while being simultaneously tactically successful. How swell for us who read Cohn!

---

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

Project Toys

---

I generally do not endorse products on this blog, and this posting is not an endorsement per se, but more of a "heads up" because in the PMO there are always a lot of documents and things to write, many to a multi-lingual project team. Here is a tool that might be of use.

Text Processing "toy": I was attracted to a recent headline that in the Microsoft "Power Toys" suite of tools for Windows11 (*) is a capability -- "Advanced Paste" -- that provides automated text translation and other "processing" in the "cut and paste" function. (All aimed at keeping the PC relevant I would guess)

According to CoPilot, Advanced Paste has these functions:

1. Functionality: With Advanced Paste, you can select the desired text format for pasting, but it goes beyond simple copy-paste. Here’s what you can do:

   • Summarize Text: Request a summary of the text.
   • Translate: Translate text into another language.
   • Code Generation: Generate code based on data from the clipboard.
   • Rewrite Text: Modify text in a different style or structure using natural language.

2. AI-Powered: To enhance these capabilities, the app communicates with OpenAI servers. However, this requires paid access to the OpenAI API.

___________

(*) Note: You can download the Power Toys suite from the Microsoft Store for Windows 11. The download is free, but the AI features required a paid access to the OpenAI API. 

---

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

Statisticians

---

A humorous dig at statisticians:

"A statistician is one who draws a straight line from an unwarranted assumption to a foregone conclusion"

Quoted from the book "The Wise Men"

---

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

Innovators v Bureaucracy

---

Recently heard: this lament from IT innovation workers:

[We] encounter ironclad corporate hierarchies and resistance to change, a paradox in [our] industry that thrives on innovation and risk-taking.

"They" want things in a particular order; they want case studies and past experience. IT doesn't work like that. There is no past experience. We have to reinvent ourselves every day.

As reported by Joseph Coleman

Golly! I think the corporate masters must have missed the Agile memo. 

They may also have missed some principles of risk management in the context of 'new to the world' development, to wit: 

Some things never work out; some things are a home run. Setting artful limits to the balance sheet is the key skill if you aren't willing to bet the business.

On the other hand .....

There's a case to made for a business case, even in the context of Agile methods. 

Unless you are spending your own money, you have an obligation to the financier to show some respect and responsibility for the funds they are providing, even if you keep overrunning and going back for more. In effect, "innovation" never met a budget it couldn't bust!

---

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

Cost: Let's review

---

How many ways are there to say "Cost"?

Certainly, more than one!

When "they" ask: 'How do YOU manage cost?", your answer is: 'It's complicated' because there are so many varieties of 'cost'.

Project managers certainly have at least this list:

• Estimated cost (of course, an estimate has to be made in the context of a plan: scope and schedule and resource plans)
• Baseline cost (estimated cost at the beginning of a planned period)
• Re-baseline (Sunk cost, plus a "new" estimate for the ensuing period)
• Cost variance (the difference or departure of actual cost from the baseline)
  
  
• Planned value (baseline cost input to the project, over time, allocated to planned functional or feature achievement)
• Earned value (as a proportion of Planned Value actually completed)
• Cost performance Index (as a 'cost efficiency' measure of how well cost input earns value)
• Estimated Cost to Complete (ETC): the marginal cost to complete the remaining baseline
• Estimated Cost at Completion (EAC): the sum of all the actual costs, usually including both direct costs and those indirect costs allocated to the project.
  
  
• Actual cost (measured at a point in time, regardless of achievement)
• Sunk cost (aka actual cost incurred)
• Direct cost (costs attributed to this project, and this project only)
• Indirect or overhead cost (common costs shared across many projects, proportionally)
  
  
• Labor cost (a component of direct cost; does not include overhead labor)
• Standard cost (used by service organizations and Time & Materials proposals to 'fix' or standardize the "labor cost by category" to a single dollar figure within a range of costs for that labor category. *)
• Material and contracted services cost
  
  
• Throughput cost (only that part of direct cost required to actually construct value outcomes; often used in combination with Standard Cost)
• Construction cost (aka Throughput cost, but sometimes also total of direct costs)
  
  
• Incentive cost (paid as direct payments to individuals and contractors for specific performance achievements)

Finance, accounting, and business management have a few more:

• General and Administrative cost (G&A), mostly for "top-level headquarters" expenses
• Marginal cost (cost of one more item that does not require more of 'something else' to enable)
• Cost margin (difference between cost of sales and revenue associated with those costs)
  
  
• Discounted cost (cost after a reserve for risk, usually calculated over time)
• Depreciated cost (cost accumulated over time, as different from cost in the moment)
• Cost of sales (direct cost to generate sales)
  
  
• Activity Based Costing [ABC] Overhead costs allocated to specific activity, plus direct costs of the activity.

---------------------------------

(*) Standard Cost: As an example, for Labor Category 1, the salaries may range from $1 to $10, but the Standard Cost for this category may be $7 because most in this category have salaries toward the upper end. Standard Cost is not necessarily an arithmetic average within the category; it is a weighted average

---

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

Innovation Power

---

Did you know your project might be at the nexus of geopolitical power, military power, and economic power? Wow! That's a big menu for the project office.

Eric Schmidt, formerly a top executive at Google, puts it this way in an essay in "Foreign Affairs", not your usual project read. He calls is INNOVATION POWER.

Innovation power is the ability to invent, adopt, and adapt new technologies. It contributes to both hard and soft power. High-tech weapons systems increase military might, new platforms and the standards that govern them provide economic leverage, and cutting-edge research and technologies enhance global appeal

He goes on: "There is a long tradition of states harnessing innovation to project power abroad, but what has changed is the self-perpetuating nature of scientific advances. Developments in artificial intelligence in particular not only unlock new areas of scientific discovery; they also speed up that very process"

In effect, Schmidt is saying that what's different is that whereas in the past there were plateaus of innovation: Bronze, steel, steam, electricity, telecomm, stored-program stored-data computing. Once you mastered the technology of those plateaus, there was a long period of technological stability.

No more. AI has properties of "positive feedback". Its possibilities just keep on growing. There doesn't seem to be a plateau or stability. And everything is driven by a need to be first .... speed! 

OODA loops
Remember the OODA loops: Observe, orient, decide, act? Well we are just on the cusp of doing that autonomously  self-driving vehicles; autonomous drones; pick-pack-and ship robots; and a myriad of other tasks where speed and accuracy are key.

Quantum Computing
And then comes quantum computing which, when in the positive feedback loop, will drive innovative breakthroughs that are almost unimaginable. 

One wonders if the usual project rails are up to the tasks ahead

---

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

AI F-16 Dogfight

---

Now here's an interesting project: Designing the code for a real F-16 fighter aircraft dog fight. 

As reported in "Breaking Defense", DARPA -- the Defense Advanced Research Projects Agency -- "In a ‘world first,’ DARPA project demonstrates AI dogfighting in real jet"

In late 2023 at Edwards AFB in California we learn: "In the span of a couple weeks, a series of trials witnessed a manned F-16 face off against a bespoke Fighting Falcon known as the Variable In-flight Simulator Aircraft, or VISTA. A human pilot sat in the VISTA’s cockpit for safety reasons, but an AI agent did the flying, with results officials described as impressive — though they declined to provide specific detail, like the win/loss ratio of the AI pilot, due to “national security” reasons."

This stuff just keeps on coming, changing the face of warfare in near-real time.

 

---

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

Work 4, Take 3 off

---

Could your project handle a 4-day workweek? 

The principle of "get it done, no matter what it takes" would have to step aside I think. 

But during more routine periods, productivity might actually go up with no additional cost.

Obviously, there's lot to debate.

Here's what 'Management 3.0' thinks are the advantages (paraphrased from a recent newsletter)

Improved Well-being

Evidence shows a shorter workweek leads to reduced stress, lowered risk of burnout, and a significant boost in work-life balance.

Environmental Benefits

Less commuting translates directly to a reduction in carbon emissions. 

Enhanced Productivity

When time is compressed, focus intensifies. Studies, including those by 4 Day Week Global, indicate that employees become more efficient, prioritize effectively, and streamline their workflows, often maintaining or even exceeding previous productivity levels.

Economic Advantages

Improved well-being leads to reduced absenteeism and staff turnover

---

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

By the rules, or not?

---

A lot of great outcomes are directly from emergent innovation

• Emergent meaning the properties were not predictable from analyzing the constituents; they surprise us all when the integrated constituents all came together and something new appears!
• Innovation meaning that risks to norms were deliberately taken; a form of destruction-construction

But not everybody is comfortable for destruction-construction; and indeed, there are many industries where the rules and regulations prohibit departure from the norms.

And so if you are managing a rules-based rules-driven project, what's the profile of the staff you need?

The question begs the answer: people who have been successful obtaining quality outcomes while still following the rules ... staying between the hedges, as it were.

So, who are 'they' that can get it done within the rules?

Look here first for the "rules" people:

• Former military and police
• Former government agencies staff
• Former very large corporate leaders
• Former staff from major 'safety' projects (where the stakes were life-threatening)
• People who value discipline, even if not one of the 'formers'
• Athletes from team sports, particularly if not the star of the team
• Socially moderate, and so likely to fit well into a heterogeneous team

Now, of course, there are a lot of 'formers' from rules-based organizations that are 'former' because they can't follow the rules. It's likely they have been invited to leave and apply their spirits elsewhere. Your job is to filter these rules-misfits out of your hiring plan.

Rules don't necessarily quash innovation

Rules generally go to methods and limits. Rarely do you find a rule about an outcome.

So, within the allowable methods, and within the allowable limits of disturbance, sustainability, availability, and quality in the large sense, any innovative outcome is possible.

You just need to hire the 'rules people' to get there!

---

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

Risk Management: Chains and funnels

---

What to make of chains and funnels? And, if I also stick in anchors, does it help?

What I'm actually talking about is conjunctive events, disjunctive events, and anchor bias:

• Conjunctive events are chains of event for which every link in the chain must be a success or the chain fails. Success of the chain is the product of each link's success metric. In other words, the chain's success probability degrades geometrically (example: chain of 'n' links, each with probability 'p', has an overall probability of p*p*p* .... for 'n' p's.)
    
• Disjunctive events are independent events, all more or less in parallel, somewhat like falling in a funnel, such that if one falls through (i.e, failure) and it's part of a system, then the system may fail as a whole. In other words, if A or B or C goes wrong, then the project goes wrong.
  
  
• 
  

The general tendency to overestimate the probability of conjunctive events leads to unwarranted optimism in the evaluation of the likelihood that a plan will succeed or that a project will be completed on time. Conversely, disjunctive structures are typically encountered in the evaluation of risks. A complex system, such as a nuclear reactor or a human body, will malfunction if any of its essential components fails.

Daniel Kahneman and Amos Tversky

"Judgment Under Uncertainty: Heuristics and Biases"

Fair enough. Where does the anchor come in?

Anchoring refers to the bias introduced into our thinking or perception by suggesting a starting value (the anchor) but then not adjusting far enough from the anchor for our estimate to be correct. Now in the sales and marketing game, we see this all the time. 

Marketing sets an anchor, looking for a deal in the business case; the sales guy sets an anchor, hoping not to have to give too much away post-project. The sponsor sets an anchor top down on the project balance sheet, hoping the project manager will accept the risk; and the customer sets anchors of expectations.

But in project planning, here's the anchor bias:

• The likely success of a conjunctive chain is always less than the success of any link
• The likely failure of a disjunctive funnel is always greater than the failure of any element.

Conjunctive chains are products of numbers less than 1.0.

• How many of us  would look at a 7 link chain of 90% successes in each link and realize that there's less than one 1 chance in 2 that the chain will be successful? (probability = 0.48)

Disjunctive funnels are more complex.
They are the combinations (union) of independent outcomes net of any conjunctive overlaps (All combinations of OR less all AND). In general the rules of combinations and factorials apply.

• How many of us would look at a funnel of 7 objects, each with likely 90% success (10% failure) and realize that there's better than 1 chance in 3 that there will be 1 failure among 7 objects in the funnel? (probability = 0.37 of exactly 1 failure)*

 The fact is, in the conjunctive case we fail to adjust downward enough from 90%; in the disjunctive case we fail to adjust upward from the 10% case.  Is it any wonder that project estimates go awry?

_________________________
*This is a binomial combination of selecting exactly 1 from 7, where there are 6 conjunctive successes and 1 conjunctive failures: factorial (7 take 1) *conjunctive failure * conjunctive success

---

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

Flat organization, or Not?

---

The world was flat, but perhaps no more.

Leadership-Risk linkage

---

When applying the principle of "calculated risk", leaders should pick subordinates with the intellectual subtlety to evalutate strategic and operational problems in their full context.

They should be given the latitude to judge just how much risk is appropriate given the value of the objective and the balance of resources.

Paraphrased from the writings of historian
Craig L. Symonds

---

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

Non-compete agreements disputed

---

Most projects apply non-compete agreements when key project people leave with competitive-sensitive and proprietary information that could help the competition.

 

The U.S. Federal Trade Commission has issued a rule to prohibit such agreements.

The U.S. Chamber of Commerce has sued to have the rule nullified.

The two sides seem to see it this way (as reported in the WSJ)

• The Chamber’s lawsuit says policymakers and courts have for decades recognized the value of noncompete agreements, and the federal government has never regulated them. 
• An FTC spokesman defended its authority to issue the measure. The agency argues that noncompete clauses hamper competition for labor and result in lower pay and benefits for workers.

It will take a long time for this to wind its way through the legal system.

---

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

ISO 42001 AI Management Framework

---

Late in 2023 ISO published ISO 42001-2023 "Information technology Artificial intelligence Management System"

To quote ISO:

ISO/IEC 42001 is an international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS) within organizations.

It is designed for entities providing or utilizing AI-based products or services, ensuring responsible development and use of AI systems.

For project offices and project managers, there are some points that bear directly on project objectives:

• The standard addresses the unique challenges AI poses, which may need to be in your project's requirements deck, such as properties or functionality that addresses ethical considerations, transparency, and continuous learning. 
• For organizations and projects, the standard sets out a structured way to manage risks and opportunities associated with AI, balancing innovation with governance.

Learn More
Of course, with something like this, to learn more about this you need not go further than the ISO website (more here) for relevant PDFs and FAQs. But, of course, you can also find myriad training seminars, which for a price, will give you more detail.

---

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

Efficient product quality design

---

I'm borrowing shamelessly from an essay by D. Miessler about efficiency in security design for user products by generalizing to the quality -- in the broadest sense -- of a product. That is to say: quality as evaluated by a user (quality is in the eye of the beholder, as it were)

And, I might observe that the principle explained below corresponds closely with the Agile idea of "enough, but not more than enough"

The Efficient Quality Principle

1. The quality baseline of an offering or system faces continuous downward pressure [i.e. less quality demanded] coming from customer excitement about, or reliance on, the offering in question.

2. The baseline for an offering’s quality will be set at the point at which people will not stop using the offering because it’s quality is not pristine.

3. The better the offering is, the lower the quality baseline can be without losing customers.

In other words, the way we know something has the “right” amount of quality built in is when people just keep using it. People use these offerings or systems because the value they provide massively outweighs the quality lapses  in user's minds.

The moment enough people stop using something due to quality being too bad, the baseline goes up. And not before.

---

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

Mary and John on the Critical Path

---

In project management school, the lesson on Critical Path includes this rule:

Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.

Beware this hazard: Resources may be real people:

The problem of applying resources arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. 

Alas! The "resources" are not interchangeable. Mary and John are unique. Consequently, consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Considering Mary and John uniquely

Take a look at the following figure: There are two tasks that are planned in parallel. If not for the unique situation that Mary and John can't be applied to two paths simultaneously, these tasks could be completely simultaneous.

In fact, the critical path could be as short as 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration. But for the assignment of Mary and John pushes Task 2 to the right.

But with only Mary and John as resources, the schedule plan stretches out to 65 as shown.

 Here's an idea:

Reorganize the network logic to take into account unique staffing applied to schedule tasks.

Now the schedule plan is shorter, though not as short as it could be if there were resources other than Mary and John. 

And that is actually the embedded lesson learned: With only Mary and John, the two tasks are no longer independent. 

And with a lack of independence, there is a "co-dependency" that is a phenomenon that has to be scheduled also. Thus, we form the rule that interdependency always stretches the plan!

---

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

Black diamond risk management

---

If you snow ski, you understand the risk of a Black Diamond run: it's a moniker or label for a path that is  risk all the way, and you take it (for the challenge? the thrill? the war story bragging rights?) even though there may be a lesser risk on another way down.

So it is in projects sometimes: In my experience, a lot of projects operate more or less on the edge of risk, with no real plan beyond common sense and a bit of past experience to muddle through if things go wrong.

Problematic, as a process, but to paraphrase the late Donald Rumsfeld: 

You do the project with the resources and plan you have, not the resources or plan you want

You may want a robust risk plan, but you may not have the resources to research it and put it together.

You may not have the resources for a second opinion

You may not have the resources to maintain the plan. 

And, you may not have the resources to act upon the mitigation tactics that might be in the plan.

Oh, woe is me!

Well, you probably do what almost every other PM has done since we moved past cottage industries: You live with it and work consequences when they happen. Obviously, this approach is not in any RM textbook, briefing, or consulting pitch. But it's reality for a lot of PMs.

Too much at stake
Of course, if there is safety at stake for users and developers, as there is in many construction projects; and if there is really significant OPM invested that is 'bet the business' in scope; and if there are consequences so significant for an error moved into production that lives and livelihoods are at stake, then the RM plan has to move to the 'must have'.  

A plan with no action

And then we have this phenomenon: You actually do invest in a RM plan; you actually do train for risk avoidance; and then you actually do nothing during the project. I see this all the time in construction projects where risk avoidance is clearly known; the tools are present; and the whole thing is ignored.

Show me the math

But then of course because risk is an uncertainty, subject to the vagaries of Random Numbers and with their attendant distributions and statistics, there are these problems:

• It's easy to lie, or mislead, with 'averages' and more broadly with a raft of other statistics. See: How to Lie with Statistics (many authors) 
• Bayes is a more practical way for one-off projects to approach uncertainty than frequency-of-occurrence methods that require big data sets for valid statistics, but few PM really understand the power of Bayes. 
• Coincidence, correlation, and causation: Few understand one from the other; and for that very reason, many can be led by the few to the wrong fork in the road. Don't believe in coincidence? Then, of course, there must be a correlation or causation!

The upshot?

Risk, but no plan.

Or plan, and no action

---

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

Make the maximum cost minimal

---

Full disclosure: I wrote this posting myself, but I did ask ChatGPT for some ideas to include. 

It's always a PMO objective to minimize cost if scope and quality and schedule are constant. But they never are. So, those parameters are usually intertwined and mutually dependent variables along with cost. 

But suppose for discussion that scope and quality are held constant (not to be traded off to save cost or schedule), and the primary objective is minimization of cost. Here are a few ideas.

Labor-dominant projects

I'm talking about projects where labor is 60% or more of the cost. Many software projects fall in this box, but many other intellectual content (IC) projects do as well: HR, finance, marketing, just to name a few.

Productivity

Assuming competence is not in question, the first order of business is productivity, which is always a ratio: output valued by the customer per unit of labor required for achievement. As in all ratios, the PMO can work on the maximizing numerator and minimizing the the denominator. 

Getting the numerator right the first time minimizes the cost of waste and rework and minimizes schedule mishaps. The skill required: good communications with the people who establish the value proposition. 

Minimize the "marching army" cost

But the numerator is also about finding useful outcomes for the "white space" that crops up: you have staff in place, you can't afford to let them scatter when there is downtime, so you have to have a ready backlog of useful second tier stuff. Staff you can't afford to lose, but may have downtime nonetheless, is often labeled the "marching army"

The denominator is sensitive to organizational stability and predictability, personal skills, tools, interferences, teamwork, and remote working. Anything that PMO can do about the first five is more or less mainstream PMO tasking. 

Remote working:

But the issue of large scale remote working is somewhat new since the Covid thing. Loosely coupled to that is greater emphasis on work-life balance rather than "do what ever it takes" and often for no overtime pay. 

Such has then spawned more of the "do the minimum not to get fired" mindset. All that has cast a shadow on remote working.

Cost-free synergism.

Consequently, the pendulum has swung in the direction of minimizing remote working in order to get the synergistic production (at nearly cost free) from casual contacts with other experts and innovators, to say nothing of problem avoidance and thereby waste and rework avoidance.

Risk management and scheduling

When it comes to labor, the first risk is dependable and predictable availability, particularly if the staff are so-called gig workers. Many PMOs limit W9s to less than 25% of the workforce for just this reason.

One anecdote is loose coupling on schedule tasks to allow for the occasional misstep in staffing. After all, even W2s have matters that interfere.

Material-dominant projects

Here is where a lot of construction projects, hardware development, and critical (or scarce) material projects come in.

Material impacts are largely mitigated by the usual strategies of earliest possible order, acceptance of interim and partial shipments, incentives for faster delivery, and strategic stockpiles of frequently used items.

The workforce for many of these type projects is often contracted by specific trades who have licenses to work on specific work. It's typical that these contactors operate in a matrix management environment of multiple and independent customers vying for a scarce and technical workforce. The impact is uncertainty of schedule and availability, and a cascade of dependencies that have to be reworked.

The customary approach to scarcity is cost incentives to direct resources to your need. 

The mitigation for cascading dependencies is schedule as loosely as possible so that slack among tasks forms risk management buffers to a slipping schedule.

  

---

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

Wanted: AI Tokens

---

12 trillion

The estimated number of tokens used to train OpenAI’s GPT-4, according to Pablo Villalobos, who studies AI for research institute Epoch. He thinks a newer model like GPT-5 would need up to 100 trillion tokens for training if researchers follow the current growth trajectory. OpenAI doesn’t disclose details of the training material for GPT-4.

Attribution: Conor Grant, WSJ 

---

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

Slack is the last thing to schedule

---

Slack, aka 'buffer', aka 'white space', aka 'early finish', is the last thing to schedule. 

After all the other stuff is scheduled.

Why?

Because slack should be used (applied) last as a way of making space for schedule extension risk.

Has to be in the baseline

But in order for it to be applied properly, slack has to be in the baseline schedule to start with. In other words a schedule without slack is not a real schedule, but rather just a hopeful schedule.

What can you do with slack?

It seems that scheduling slack is just scheduling free time and unnecessarily extending the schedule. 

Not so.

Here are things you can do with slack that are value-adding:

• Protect the critical path: There are probably a lot of tasks that join the critical path, feeding partial product into the final outcomes. If those dependencies are late, so might the CP be late if it is not buffered to absorb those problems. "Critical Chain" scheduling theory is a good example of how the CP is protected with slack.

• Relieve constraints: Sometimes there is a constraint in the workflow and stuff isn't flowing as it should. Using Theory of Constraint techniques, other elements of the workflow are usually rescheduled, changed in scope, or new tools and training is applied. To make room for these new or changed activities, slack is required. 
  
  
• Protect a milestone: Even if a milestone is not on the CP it needs to be respected for its intended finish date. If there are more than one activity that contributes to the milestone completion criteria, then slack on the various joins to the milestone will protect its date.

Latest start is a no-no

The one thing to avoid is "latest-start" scheduling. Latest-start is, in effect, putting the slack first rather than last and using the slack before any risk appears. A total waste of resources!
  

---

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

"Transformative Trinity" -- Military Projects

---

Are you working in military projects? U.S., NATO, or the so-called 'Five Eyes'?

You may run across this concept in military systems design:

"Transformative Trinity"

And so what is that?

The “Transformative Trinity” in military contexts refers to the integration of new technologies like drones, the democratization of higher-quality information, and collaboration with commercial firms to enhance military capabilities

Generals Mick Ryan and Clint Hinote

So we are talking big project picture here, strategy if you will, with three elements: 

1. an uncrewed device -- a drone --whether on land, air, or sea (we'll leave space out if for this discussion); 
2. the flow-down and flow-across of ISR to the warfighters and joint planners, and 
3. a partnership with industry (we project guys), to include the off-the-shelf-stuff, albeit perhaps modified for the battlefield (See: Ukraine)

The idea of course is to use the "transformative trinity" to transform warfare, less touch except by remote. And tech projects are going to be right in the midst of it!

So add it to your dictionary: the military systems "transformative trinity"

---

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

Why software remains insecure

---

I like a lot of the stuff Daniel Miessler thinks about. 

He has an interesting essay about "why software remains insecure". By insecure, he means released software with known functional and technical bugs at release, and even far beyond release 1.0 and 2.0 and on and on.

Why should this be?

Miessler opines: 

"... the existence of insecure software has so far helped society far more than it has harmed it".

"Basically, software remains vulnerable because the benefits created by insecure products far outweigh the downsides. Once that changes, software security will improve—but not a moment before".

And if you buy that idea, then you probably understand his point that there is no real business or user incentive to repair things to a higher standard of quality. Users put up with it; projects are bound to the clock.

This process will do nicely: Develop, quickly test, release, rinse, repeat.

Domain sensitive

Of course, there are significant and manifestly important project domains where such slack in quality would not be tolerated -- could not be tolerated -- or even understood. Think: space launches of all sorts; command and control systems that are kinetically fatal in outcome; even self-driving systems.

It's not SEI Level 5!

Without a maturity model as a regulatory tool for systemic quality, other priorities dominate.

The cart and horse are in a mixed order: release, measure the temperature of users and regulators, and then fix it -- just enough. Sort of Agile that way: do enough, just enough, to pass the sprint test and move on.

---

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