System Integrator

---

Here in the USA, we've heard a lot about the 'system integrator' of late, mostly having to do with large-scale government projects run awry.

The questions at hand: what is a system integrator and what do they do?

Point 1: the term is "SI"; and they are independent from the system engineer "SE" and the architect
Point 2: the SI works directly for the PMO, not the SE or the architect in most cases... thus, maintaining a degree of independence from the SE
Point 3: the SI comes on the job early, typically from day-1, working down the project definition side of the "V" chart
Point 4: the SI is first responsible for the coherence of the specifications and the test plan. Thus, the SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

Point 5: the SI is an independent technical reviewer for the PMO of the progress on technical and functional performance. They can be an independent trouble-shooter, but the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

Point 6: 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.

Point 7: the SI is an independent integration tester and evaluator, typically moving up the "V" from verification to validation
Point 8: 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.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

El-Erian speaks on project disasters

---

Mohamed El-Arian is the well known and respected CEO of the investment firm PIMCO who has a blog on linkedin.

In a recent posting, he uses the ongoing project mess of the US healthcare.gov website rollout for some sage advice for CEO's. In fact, this is good advice for senior project managers who are engaged in "bet the business" project initiatives.

Click here to have a read for yourself, although the highpoints are these five points of executive action. This is El-Erian's action plan when facing a project near-failure with far reaching business impacts:

First, ensure that the destination is unquestionably sound and visible – and do so by repeatedly reminding stakeholders (both internal and external) of the validity of the strategic initiative; and by making it crystal clear to opponents that key elements are non-negotiable.

Second, work backwards from the destination to specify and communicate the key steps in the journey of re-establishing comprehensively the credibility of the initiative.

Third, seek some quick wins in implementation to illustrate that the initial slippage, while meaningful, is indeed temporary and reversible.

Fourth, do not allow this whole issue to consume every other part of the business, activities, public interactions and internal discussions.

Fifth, be totally open with your constituents, including by recognizing that the initiative’s full recovery is probably months in the making. Properly managing what are now unanchored expectations becomes a key tenet of leadership and corporate strategy.

---

Scaling down... way down

---

Most of the posts I read are about scaling up to ever larger projects, but what about scaling down? What if you are doing bug fixes and small scale projects with just one or two people? Is a methodology of any help, and if you're working with software, can Agile be helpful scaled down?

To the first point, my answer is: Sure! A methodology -- which is just a repeated way of stringing practices together -- can help. Why invent the 'string' (methodology) each time you do something? Just follow the same practices in the same sequences each time. Thus, you can have a methodology for just driving your car... perhaps the ultimate team-of-one.

Re agile and small scale: Really, the agile manifesto does not inherently break down at small scale; nor do the agile principles. It's actually easier to go smaller than to go larger.

But, not so fast! What about:...

• Teams and all the stuff about team work if you are only one or two people?
• Pair programming?
• Redundancy and multifunctionalism?
• Collaboration and communication by osmosis with others?

Admittedly, you give up a few things in a team-of-one situation -- perhaps pair programming and redundancy -- but there's no reason to give up the other ideas of agile:

• close coordination and collaboration with the customer/user
• a focus on satisfying expectation over satisfying specification
• quick turn around of usable product
• personal commitment and accountability
• collaboration with peers and SMEs on a frequent and informal basis
• lean thinking
• Kanban progression and accountability

The hardest thing to deal with in a too-small team is lack of redundancy -- or not being anti-fragile -- and lack of enough skill and experience to work over a large domain. It's pretty obvious that one person team has a single point failure: when you're away, the team is down. Such a failure mode may not tolerable to others; such a failure mode is obviously fragile, unable to absorb large shock without failing.

And, one person's experience only extends so far... thus limiting the domain and extent of possible solutions (leading, sometimes, to: "if all you have is a hammer, then everything is a nail" misuses and abuses of whatever your skill set is. I once had a person who was a loner and also an expert with MSAccess... no matter the problem, he seemed to solve it with Access!)

As managers we are responsible for making it work. So in the situation of really small teams, there can still be, and we should insist upon:

• an opening narrative
• a conversation about requirements and approach (to include architecture)
• peer review by other experts
• code inspections and commitment to standards
• rotation of assignments among context to drive broadening
• reflection and retrospective analysis

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Frameworks, frameworks... let me count them

---

And, here's your test for today: how many project frameworks can you count?
Mike Clayton has done us a bit of a favor by gathering up some links:

• PMI.org
• Mike Clayton's Eight Steps
• The Association for Project Management planning process
• Glen Alleman’s Five Immutable
• James Leal’s Seven Secrets
• Nick Jenkins’ Ten Axioms
• The Afterburner Combat Mission Plan

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The 'estimate' thing -- again!

---

Likely you not looking forward to another posting on estimates, either here or elsewhere, since that topic seems to have burned up the PM space over the past few months. Nonetheless, Jurgen Appelo, never to lack for humor and pithy commentary, has weighed in with a few words that sum it all up.

He tells us:

When I made my breakfast this morning, I estimated (based on my experience) that two slices of bread and a glass of orange juice would be enough.

I’m glad that nobody asks me to do a #bigestimate and prepare my total food intake for the whole year of 2014. That would be silly.

But #noestimate, or walking back and forth to the kitchen or hotel buffet for each individual bite, doesn’t sound very practical to me. I prefer to estimate just enough to fill one plate, with a good chance of not having to walk back but also not leaving anything uneaten.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile and R&D

---

I was recently asked if Agile and 'R&D' go together. The issue at hand: how do you reconcile agile's call for product delivery to users every few weeks with the unknowns and false starts in a real R&D project?

Good question! I'm glad you asked.

Let's start with OPM ... Other people's money ... And the first question: What have you committed to do? There are two possible answers: (1) apply your best efforts; or (2) work to "completion".

Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts? -- but in the R&D domain (2) is often not a requirement and may be a bridge too far: -- got a completion cure for cancer? "Completion" means more than just effort; it has elements of accomplishment and obtained objectives.

"Completion" is problematic in the R&D domain: completion implies a reasonable knowledge of scope, and that may be impractical depending on the balance of the "R" with the "D". Heavy "R" implies very limited idea of the means to accomplish; "D" is the flip of that.

The best example of "best effort" is "Time and Materials" -- T&M. If you're working T&M your obligation -- legally at least -- is best effort, though you may feel some higher calling for completion.

The most constraining example of "completion" is Firm Fixed Price -- whether by contract or just project charter. FFP is almost never -- dare I say never? -- appropriate for R&D

And so now let's layer on Agile ... what's in and what's out vis a vis R&D:
Among the agile practices that are "IN" (in no particular order)

• Conversational requirements ("I want to cure cancer")
• Prototypes, models, and analysis (even, gasp! Statistics and calculus, though some would argue that no such ever occurs in an agile project)
• Periodic reflection and review of lessons learned
• Small teams working on partitioned scope
• Trust and collaboration within the team
• Skills redundancy
• Local autonomy
• Persistent teams, recruited to the cause
• PM leadership to knock down barriers (servant leadership model)
• Lean bureaucracy
• Emphasis on test and verification
• Constant refactoring
• Frequent CI (integration and regression verification with prior results)

And, among the agile practices that are "OUT"

• Definite narrative of what's to be accomplished (Nylon was an accident)
• Product architecture
• Commitment to useful product every period
• Intimate involvement of the user/customer (who even knows who they might be when it is all "DONE"?)

There may be a longer list of "OUT"s, but to my mind there's no real challenge to being agile and doing R&D.

---

Bookmark this on Delicious

Read about these books I've written in the library at Square Peg Consulting
You can buy them at any online book retailer!

Read my contribution to the Flashblog

IT and the PM...

---

How close to the truth is this?

A man flying in a hot air balloon suddenly realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts to get directions, “Excuse me, can you tell me where I am?”

The man below says: “Yes. You’re in a hot air balloon, hovering 30 feet above this field.”

“You must work in Information Technology,” says the balloonist.
“I do” replies the man. “How did you know?”
“Well,” says the balloonist, “everything you have told me is technically correct, but It’s of no use to anyone.”

The man below replies, “You must work in project management.”
“I do,” replies the balloonist, “But how’d you know?”

“Well”, says the man, “you do not know where you are, or where you are going, but you expect me to be able to help. You are in the same position you were before we met, but now it is my fault.”

---

Thanks to Alex Walton, 3pmLLC.com

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting