System Integrator -- Owner Rep roles

---

In the government domain, the government often contracts for an SI -- system integrator -- whose scope of work is to be an independent evaluator of program plans and progress, an expert adviser to the program executive for risk management and value engineering, and a voice in the project office not beholden to the prime contractor(s), system architect(s), or other implementers. 

In large programs, the SI may work simultaneously with multiple prime contractors, overseeing their coordination, communications, consistency in approach, integration of scope, and guarding for "white space" gaps. The SI may even evaluate the integrated program for 'chaos' ... the unintended outcomes of an integrated 'whole'. 

In some limited situations, the SI may even develop an interface that seems tagged to white space.

In the commercial domain, a similar scope and role is often given to an "owner's representative". 

Necessary or Nice to Have?

Your first thought may be: Another scope of work .... do I really need this for project success? If I don't engage with a service provider for this scope, is this something I am going to have to learn how to do myself, and then allocate my resources to the task? Or, can I get by without it?

Quick answer: It's work that has to be done ... to some level of scope ... so either the PEO or PMO does it with in-house resources, or the PEO/PMO engages an SI who is expert in the scope and presumably not learning on the job on your nickel.

And, by the way, if you do engage with an independent SI, then cooperation with the SI on the part of your architect, prime contractor, and perhaps other stakeholders has to be made part of the Statement of Work (SoW) with those parties. Question worth asking: Does that cooperation come at a cost, monetized or functional?

What's the ROI on the SI engagement

So, whether you are a government program office or a business unit with a large capital project, what's the value-add of having an SI or owner's rep on the scene? Is there a monetized ROI to the cost of a SI, or is the advantage with a DIY model (do it yourself)?  

In many respects, it's the insurance model: High impact with low probability, to take a square from the risk matrix. Thus, a low expected value, but nonetheless the impact is judged unaffordable. 

The usual risk management doctrine is this: You've got a big (big!) project with a lot of moving parts (different contractors doing different stuff). Get yourself an SI! (At a cost which is usually a small multiple of the expected value, if you think of it in terms of insurance)

SI Scope

The SI is on alert for these 'black swan' impacts that could derail the program, extend the schedule, impact performance, or cost big bucks for rework. 

The SI comes on the job early, typically from Day-1, working down the project definition side of the "V" chart (see chart below)

The SI is an advisor to the PEO or PMO regarding threats to the cost, scope, schedule, or quality. If there are value engineering proposals to be fit into the program, the SI is usually the first to evaluate and advise about their applicability.

The SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

The SI is an independent technical reviewer for the PMO of the progress toward technical and functional performance. The SI may provide much of the data for earned-value analysis.

The SI can be an independent trouble-shooter, but mostly the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

The SI may be an independent integrator of disparate parts that may require some custom connectivity. This is particularly the case when addressing a portfolio. The SI may be assigned the role of pulling disparate projects together with custom connectors.

The SI may be independent integration tester and evaluator, typically moving up the "V" from verification to validation

In a tough situation, the SI may be your new best friend!

What about agile?
'Agile-and-system-engineering' is always posed as a question. My answer is: "of course, every project is a system of some kind and needs a system engineering treatment". More on this here and here.

And, by extension, large scale agile projects can benefit from an SI, though the pre-planned specification review role may be less dominate, and other inspections, especially the red team role for releases, will be more dominate.

V-model
Need to review the "V-model"? Here's the image; check out the explanation here.

---

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

When value is assymetrical

---

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

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

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

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

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

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

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

"One in hand is worth two in the bush"

And there is the time displacement asymmetry:

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

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

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

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

 

---

---

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

ISO 42001 AI Management Systems

---

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!

Risk on the black diamond slope

---

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!

The people are told .....

---

---

In the beginning, "people" are told: "It's too soon to know where we are in this project"

After the beginning, "people" are told: "It's too late to stop the project; there's too much sunk; we have to keep going"

---

Sampling the data

And so the bane of big projects comes down to poor sampling technique: 

Either the early details are not predictive because the early "efficiencies" of cost per unit of value earned have too little history to be useful as a long-term predictor; or you've accepted the first idea for too long, thereby failing to update efficiency predictions until the late details are too late to pull the plug on a bad bet.

Sunk cost decisions:

It's easy to write this, and far less easy to execute, but never make a decision about the future based on the sunk cost of the past. You can't do anything about recovering the actual expenditure, but you do have free will -- politics aside -- regarding more spending or not. 

History has value

On the other had, sunk cost has a history, and if you are good at what you do, you will use that history to inform your decisions about the opportunity of the future

---

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