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!