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!