Friday, February 10, 2017

Flocking to quality


Ever wonder how you know you're impressing people; doing a good job; producing a good project outcome?

Watch the flocks
"People know quality and flock to it"
David brooks

No flocks? Hmmm, that sucks. Assessments are needed; perhaps even root-cause analysis, etc
Here's the important point:
If people are not flocking, it's not their fault. If they don't get it, it's your job to fix it so they do. The heavy lift is yours!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, February 7, 2017

Gambling leadership


Every [leader] is a gambler
Admiral John McCain 
 (the senator's father)
Admiral Halsey's air commander, WW II in the Pacific

And, so what do we make of that idea?*
  • To exert leadership, do we layer a propensity to gamble on top of the usual uncertainty that goes along with projects? Is it additive, or compounding?
  • As a gambler, should we expect certain rules to apply ... as in poker?
  • Should we put aside reserves since "the house always wins ... in the long run"**
  • What if we are naturally risk averse ... can we be an effective leader nonetheless?
  • Are managers just leaders who are not gamblers? (Ouch! if you're a manager)
To the first point, it's situational, but certainly risks compound, though you won't see that in a traditional risk impact-likelihood matrix which considers each risk independently. Compounding makes risk management in the real situation much more an "adult" manager's task
To the second point: No! The rules that govern probability examples in textbooks and games in the casino don't really apply to project management. Why? Because in projects, coins aren't fair (see: politics), they have more than two sides, and projects are not stationary over long periods (see: stuff happens!)
To the third point: "It's reserves, stupid!". Of course you need reserves. If you need an explanation, you're really not managing a project, you're hoping
To the fourth point: That's actually hard. Yes, some can adopt a "professional" risk profile different from their natural profile, but it's exhausting and hard to maintain over time
And, to the last point: Not exactly. See the fourth point.


*Admiral Halsey, as a WWII Pacific fleet commander, was perhaps the greatest naval gambler America had -- he even gambled with typhoons; and, he lost his share of bets
**The Las Vegas strip is financed by losers


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, February 3, 2017

Shared values or power relationships?


John Traphagan has a different idea on organizational culture.
"A common set of shared values" has always been my working definition, though I admit that, like multiple "identities" at home and work, there is a culture at work and there is a culture at home, and they may not be the same, and thus the "sharing thing" may have -- likely has -- borders.

But Traphagan goes further. He asserts that trying to impose or enforce a sharing of values thus to make a common culture is possibly a divider rather than a unifier. (There's a rebel or a rogue in us all)

Have a read from an essay he wrote:
Fundamentally, a culture is not a set of (marginally) shared values; it’s a web of power relationships in which people are embedded and that they use to meet both personal and collective goals but that can also restrict their ability to achieve goals.

Those power relationships can function to pull people together, but they also can pull them apart because they are the product of differential access to resources. And differences in power influence how we respond to and think about values espoused as being shared by members of a group.

That's certainly different than the way I've thought about organizational culture. Doesn't sound like sharing, commonality, or other attributes are present, or certainly not dominant.

Of course, Traphagan works in an academic environment. It's been my experience that on the teaching side -- different from the university business -- such is somewhat feudal and not at all common.

Which is not to say that there's not value competition within projects and the business generally -- to be sure there are. And power webs certainly exist. But my experience is that there is an arching culture even over the largest organizations that sets tone, ethics, morality, etc for the organization.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, January 31, 2017

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, January 28, 2017

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, January 24, 2017

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, January 20, 2017

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog