PM's FAQ about System Engineering

---

A lot of PMs know they need systems engineering, or think they might, but aren't sure who these folks are or what they do.

Here's my FAQ I used when I was a Director for systems engineering for an aerospace and communications firm

(And, I tried to make this not too stuffy!)



What is this thing called system engineering?

• What is system engineering? Here's the way NASA defines it: "System engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system"
• What do systems engineers  (SE) do? Primarily, they have three work areas: system architecture; system feature, function, and performance; and system validation. Included in these three work areas are the system 'ilities', system risk management, major interfaces, and optimization among competing constituents. And, SEs contribute to the major project plans as directed by the PMO. 
• Why is system validation one of their responsibilities? First, SEs are independent of the developers -- and independence is a good thing for validation. Second, the SE is charged with maintaining a holistic view of the system; this view should inform system validation procedures. And, third, this puts accountability into the mix: SE is actually in the workstream that makes it work!
• Are there standards and protocols for what SEs do? Yes, like the body of knowledge for project management, there is a generally accepted body of knowledge for SEs. For instance,  INCOSE -- the SE counterpart to PMI or APM -- maintains a body of knowledge in their System Engineering Handbook. Among free resources are those in the public domain from the US DoD/SE and NASA.  Of course, there's also the ISO standard 26702, among other ISO standards on various disciplines with SE.

There's always the planning issues:

• Do SEs have their own workpackage or swim lane? Yes, it's customary to uniquely track cost, schedule, and deliverables of the SE activity
• Who do they report to? Typically, SE reports to the PMO
• What's a good benchmark for cost? Benchmarks depend on the nature of the project. For studies, the SE could be the whole project; for a typical development with a generous system validation activity, SE could be as much as 40% of the cost, but probably not less than 8%.
• Do they have deliverables? Yes, SE is not a level-of-effort; the deliverables depend on the specifics of the project, but for the most part they are plans, specifications, and procedures.

I get questions on this stuff also:

• If SE are the architects, what is architecture? Architecture is that which defines/specifies/describes the overall boundaries of the major components and defines/specifies/describes the interrelationships and behaviors among the components. In some situations, the overall physical appearance and presentation may be part of the architecture
• What are they thinking when a SE talks about a system? I've answered this before, but here's the simple answer: a set of 'things' -- constituents -- interconnected in such a way that they produce their own pattern of behavior over time. The way a system responds to stimulus is a characteristic of the system itself and not necessarily that of any of its constituents
• Should I use SEs to pursue new business? Yes, many have good customer skills and can communicate conceptually to the thinkers in the customer community
• Can I innovate without them? Anyone can be the innovator, but SEs are often cast in the role of coming up with unique and discriminating ways to do things.

And, of course, there's always the questions to end on:

• What do I give up if I don't have them? Many projects don't have a SE per se and do just fine. However, on larger projects with complexity and scale, the architecture function is essential. If not an SE, then someone else with that role is needed for the activity
• If my project team does this anyway aren't just redundant? Not really; they bring a mindset, attitude, bias, and skill that is unique to the SE tradecraft.

---

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

Firing your client -- free at last?

---

Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

This essay gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:

• They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
• They say it's an easy job they can do themselves.. unless you want to be micromanaged
• They want to talk about themselves instead of the job task... unless you want to be their counselor
• They say they've tried to get the job done with many others, and they all failed.. so might you!
• Rude, insensitive behavior.. unless you like the bad-ass type
• Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!

---

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

Perceptions on risk -- a perfect storm of problems .....

---

The messenger: “Unfortunately, my King … here I am, unwilling and unwanted … because I know that no one ever welcomes a bearer of bad news.” —Antigone by Sophocles, circa 442 BC
 

The surprise: “It is pardonable to be defeated, but never to be surprised.” —Frederick, the Great

Pedro C. Ribeiro, writing in ASK magazine for NASA, has a nice posting on risk perception. He reports on a study that tells us that nearly 3/4ths of all those that report a risk condition to the PMO feel as they are not heard or listened to.

The messenger of bad tidings is not welcome! Hello! No news there, to be sure!

And, of course, this is all too common:

Postmortem analyses, inquiries, and audits of failed projects often uncover streams of unheeded warnings in the form of letters, memos, e-mails, and even complete reports about risks that were ignored, past lessons not learned, and actions not taken—a failure of leadership that creates the conditions for a “perfect storm” of problems that could and should have been prevented, but nevertheless catch leaders by surprise.

Remember: even Nassim Taleb defines a black swan from the eye of the beholder. What's a calamitous surprise to some may be foreseeable to others.  So, even though the PMO may not be able to see around the next corner, they may be some with extraordinary powers of sight that need to be listened to. Ignore them at your peril!

---

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

Keeping a sense of Fidelity

---

Fidelity, faithfulness, and commitment often seem to be the tension between:

• What the customer/sponsor/user want, and
• What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and then the project team is off to do the deliverables. Simple, right?

Wrong!

It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? First, it's should always be a decision and not just a consequence of wandering off track; and second:

• If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment.
• If the decision process takes into account expectation as well as specification, then both of these should be on the list of "inputs" to the decision. And,
• Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)

Keep this thought close by: what is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."

---

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 as a recursive methodology

---

In the past in my describing the adoption of Agile by conventionally trained managers and sponsors  I've described the "grand bargain" that has to be struck between sponsor and project. In effect, to repeat a bit, the "change" is first with the management paradigm of fixed-scope for a fixed price.

The essence of agile is unfixed scope -- tactically -- with a fixed scope (product framework) strategically.

Thus, by example which is simple enough we can all grasp the point, if we enter into a project to build a software shopping cart, a functional cart is the strategic objective of the project.

• There is a general framework of functionality for such a cart agreed to in the business plan and the project charter, but
• Many of the detailed feature/function/performance artifacts and objects will "emerge" as conversations go forward during the course of the project;
• In other words, feedback of early deliverables will influence later deliverables.

In that sense, agile is a recursive methodology in that results are applied to the process of creating results. Thus the backlog somewhat begets the backlog -- a classic case of recursion.

Consequently, first: the agile backlog is constantly changing, at least in theory. In practice, a lot less so.

And, second: agile dismisses the idea of structured requirements (shalls and wills) so as to substitute "conversations", put down as vignettes in the form of stories and use cases.

Conversational requirements obviously requires some creative thinking about verification and validation (V-and-V) that is often part of a downstream activity, quite apart from development.

And, third: agile is realistic vis a vis a project of intangibles wherein there are really no physical limitations to constrain requirements.

All this takes us back to the challenge discussion: When is agile project "done"?
My counsel is: agile is a best value delivery, within constrained budget and time, of the highest priorities that the money will afford. All else, see V2.0.

---

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

So, who's responsible for Customer?

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive, Business, Technical and Users requirements.
Securing the sign off on the requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities, in order of increasing importance, and determining the “fit to need” alignment of the requirements
d. Map solution requirements to the vendor solution/product portfolio, and determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team, and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as needed in various verticals that are needed to address the solution design and product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

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

Leadership without impulse

---

Point: Impulsive and unpredictable are some leader's styles. Such keeps managers -- who revere plans -- off guard and even defensive, but it wreaks havoc on strategy (ever changing) and metrics (rebaselining at every turn).

Of course, your competitors may also be constantly off guard. In some businesses (start-ups, sports) and some military situations (See: General George Patton), "impulsive and unpredictable" is a great offense.

Counterpoint: 

[Leadership] .. comprises a number of moral qualities among which may be mentioned: force;initiative; determination; a strong sense of justice; loyalty, to both superiors and subordinates; good judgment; generosity; self-possession; energy; decision.

The qualities of leadership inspire loyalty in one's subordinates; and this loyalty, accompanied by confidence in the [leader's] professional ability, gives [the leader] such an enthusiastic support from them that [the leader] is, in times of crisis, able to demand and accomplish what might appear to be the impossible.

History abounds with instances where great leaders have inspired such confidence and enthusiasm .... It requires both the moral qualities and the brains and knowledge to make a great leader. Both may be improved by application, study and reflection.

Raymond Spruance
Admiral, US Navy
Force commander at the Battle of Midway, June 1942

 

---

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

Design-build

---

If you're in the construction industry you probably know about and have experienced "design-build". Notice that there's a word missing after "design", to wit: competitive bidding.

Ooops, a typo? No, there is a body of knowledge around this that says that it's faster-cheaper for the same quality to go "design-build" than "design-competitve bid-build".

In effect, one team -- architect, general contractor, and owner rep -- carry the project all the way through.

Faster-cheaper
The "faster" thing is obvious: there's a missing step, so the cycle has an inherent time advantage. The "cheaper" thing is not so obvious. Why should it be cheaper? There's nothing built in to drive the cost.

Best Value
Maybe it's not cheaper (though the track record over years seems to say it's cheaper), but it should be a best value project. 

That's the segue to: How do you decide which team is the team you are going to go with?  Certainly not lowest-cost, because the cost is not known until the design is known. So you decide on the basis of "best value"

Ah yes! Recall what value is: the best combination of quality, feature, and function that fits a budget. (Did I mention I wrote the book? "Maximizing Project Value". See the cover below)

And so, best value must mean value optimized for one or more of the variables. Of course, your bias will be different from mine, so your optimization will be different from mine. Nonetheless, each opportunity does have a "best value"

And, best value could be "lowest cost, otherwise acceptable". But, often it's not. There are other considerations other than cost. (We'll leave corruption off the list)

Public sector
But, if you're in the public sector, where the public expects probity when expending funds, how do you explain "best value"? Can it even work in the public sector?

Answer: Yes, it works.  In the U.S., some 20 states have made it legal, even desired, to go design-build. So the arguments that convince are out there.

If you read through the Wikipedia article under the link above, you'll see a pretty good to-and-fro on the good, the bad, and the marginally acceptable about design-build. There's even a design-build handbook and of course a design-build society.

---

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

Information asymmetry

---

The playing field is not level; there are asymmetries all around.  Life is not fair, etc

The news, if it is news, is how asymmetry has crept into the project office or project management generally

•  Not an efficient environment, meaning everyone does not have all the same information to make decisions. Some have access to 'big data' results; others do not
• Price does not reflect marginal cost, meaning that project labor, at least, doesn't reflect a broad market cost for the next unit of labor; rather, labor is often paid a premium wage, justified as an investment in quality
• Deals are blocked because of information asymmetry; opportunities go unfulfilled
• Risks are assumed where risks may not exist, thus putting one project office in a disadvantage compared another PMO with a better handle on the situation. Why? Lack of credible information. Some have it; some do not.
• Advertising ... sometimes called "signaling" --  distorts value, or redirects it.  A PMP, college degree, or other certification may create value for the certificate holder, but does it create value for the employer?
  Perhaps. But, there's a value-asymmetry at work. How many worthless, or more kindly worth-less-to-the-employer, PMPs are there who have the certificate, etc and thereby command the premium?

Some of the theory on this goes back to the work of George Akerlof, Michael Spence, and Joseph E. Stiglitz for their "analyses of markets with asymmetric information" for which they jointly won a Nobel Prize.

George Akerlof also wrote a book, "The Market for Lemons", in which he applied the 1970 used car market as example of the application of asymmetric information and the value distortions therefrom. Nobel prize. Anyone who has bought a used car understands this asymmetry between buyer and seller .... lemon or not? Only the buyer knows

And then, to layer on some more stuff, we have these:

• Regulatory and statutory limitations on information sharing
• Moral hazards (distortion of incentives or rewards)
• Behavior ... are interests aligned? How can you even tell if information is asymmetric and the relationship is not efficient?

For more on this, check out this essay in Wikipedia: Principal-agent relationships -- construction industry
 

---

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

Project Management in the US Federal Agencies ... it's the law (now)

---

EXCEPT FOR DoD (there's always an exception for DoD)
In the U.S. federal agencies, project management is now the law:

You can read a summary of the bill, Program Management Improvement Accountability Act at this link

(Sec. 2) This bill establishes as additional functions of the Deputy Director for Management of the Office of Management and Budget (OMB) requirements to:

• adopt and oversee implementation of government-wide standards, policies, and guidelines for program and project management for executive agencies;
• chair the Program Management Policy Council (established by this Act);
• establish standards and policies for executive agencies consistent with widely accepted standards for program and project management planning and delivery;
• engage with the private sector to identify best practices in program and project management that would improve federal program and project management;
• conduct portfolio reviews to address programs identified as high risk by the Government Accountability Office (GAO);
• conduct portfolio reviews of agency programs at least annually to assess the quality and effectiveness of program management; and
• establish a five-year strategic plan for program and project management.

.....

The head of each federal agency ..... shall designate a Program Management Improvement Officer to implement agency program management policies and develop a strategy for enhancing the role of program managers within the agency. .....

The Program Management Policy Council is established within OMB to act as the principal interagency forum for improving agency practices related to program and project management.

Of course, DoD has had formal project management practices for years. And, this is not unique to the United States; other countries have similar statutes on the books.

In the age of Agile, one always wonders if the "fix" is more regulation. We'll see if this goes the way of the "cost benefit analysis" that was introduced to much fanfare some years ago, but had only marginal effects in the political environment of the federal agencies

---

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