System Integrator (SI) Owner's Rep

---

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!

My backlog is blocked!

---

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 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 transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none 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.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from 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; this is sort of a "us vs them" approach, some might say stovepiping.

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!

---

Bookmark this on Delicious

Experience from synergy

Mike Cohn has a nice posting on something he calls "communities of practice" but which I think of as experience from the synergy of multiple players. Regardless of how you label it, I think his diagram says a lot:

Looking carefully at the diagram, notice both cross team and intra-team (vertical) participation in the "communities" (horizontal). Mike is Scrum-centric, so his diagram has a Scum master community. If I'd done the drawing, I would've been less prochial since there are many competing methodologies, other than Scrum, that provide quite good agile experiences.

And, by the way, this is not an agile idea per se. I've been doing things like this in the defense and aerospace business for years (old wine, new bottle?). However, Mike's presentation is very effective. (Remember: communications = message + messenger + presentation)

And, of course, the diagram is only a hint at what you can do. It's probably best to extend this to a program or portfolio. The PMO often instigates and sponsors such collaboration.

Many groups call such a matrix "birds of a feather". I have attended many "birds of a feather" collaborations at conferences and such. But Mike is saying: make it a regular and sustained practice, not just an occasional get together.

Good advice!

Bookmark this on Delicious

Portfolio management and Agile

The Question

Are agile practices, like dynamic backlog, persistent teams, and emergent outcomes really compatible with the more laced up space of portfolio management?

The Answer

Perhaps....

Is there more?

With my colleague Alex Walton, we recently had an occasion to address the Central Florida PMI chapter with that question, and to give our perspective on the answer.  I've posted a link to the presentation in the slideshare below (see also: slideshare.net/jgoodpas )

We looked at two primary points that are in every portfolio manager's charter:

1. Drive business value, and
2. Take measured risks to do so

And we compared these with a few things that agilists really guard:

1. Maximum decoupling of outcomes from a big bang vision
2. Flexibility to subordinate cost and schedule to an emergent scope driven by the customer/user
3. Persistent teams that stress personal accountability and commitment, and engender high cohesion as a consequence of high trust.

Portfolios in the agile space (or perhaps the other way 'round)

Portfolioists (a new word: you read it here first) are all about getting maximum coherence among projects, between projects, and with any legacy system or product they have to support or tie into.  Coherence is a relatively simple concept: get mutual reinforcement; the sum is to be more better than the parts individually. 

Portfolioists want loose coupling among these otherwise coherent projects, and they want the coupling, such as it is, to be a network.  Why? Loose coupling traps bad effects from propagating; in effect, a rip-stop in the overall portfolio.

 Each project--network node--has a feature/functionality onto itself, but it also has relationships with other nodes (projects).  If a project (node) fails, as one must expect given the Standish numbers, then other project should have some capability to fill in. 

Portfolioists have a lever they can push and pull to cause redundant capability to spread among projects.  Thus, given a node failure, the portfolio value proposition presses on.  Agilists may not be too happy about being signed up for such redundancies!

And portfoliosts want to be able to allocate and distribute the assets of the business to effect the biggest bang for the buck.  But of course distribution may not be compatible with persistent teams: so another tension.

Agile in the portfolio space (corollary to the above)

Agilists may be sympathetic to the advantages of coherence, but that takes some of their flexibilty off the table.  So there's a tension to be sure.  However, to be effective in an enterprise environment, agilists have to suck it up a bit and be respectful of legacy requirements and API's or other interfaces already in production.

Agilists buy into loose coupling of projects on the network, so check off on that.

Agilsits are not loose coupling bigots of course.  Their preferred team architecture is about as tightly coupled as you can get.  All together physically in close proximity, an embedded customer/user, and a war room to put all the communication in one place.

To some extent, agilists are going to resist portfolioists who want to move resources around to meet business and risk objectives.  But, agilists are realists (there a lot of ...ists in this post!) and so will support the larger good; after all, it's their business also.

Anyway, here's the presentation for more reading:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.