Monday, December 30, 2019

Two doors for risk managers



A narrative*

Imagine two doors to the same room: One labeled risk manager; the other labeled decision maker.
Though the risk manager's door, entry is for the inductive thinker: facts looking for a generality or integrating narrative
Through the decision maker's door, entry is for the deductive thinker: visionary with a need to connect specifics to the vision

And, consider this:
  • Pessimists with facts enter through the risk manager's door
  • Optimists with business-as-we-want-it enter through the decision maker's door
Then what happens?
Each needs to find the other. In the best of situations, they meet in the middle of the room where this is buffer space and flexibility.

How does the inductive and deductive interact?
Risk management does not set policy for the project office; it only sets the left and right hand boundaries for the vision, or for the project policies.
The space in between is where the decision maker gets to do their envisioning, moving about, perhaps even bouncing off the walls, constrained only by the risk boundaries.


Sound familiar? I hope so. You'll find a similar explanation known as the "project balance sheet" in Chapter 6 of "Maximizing Project Value: A project manager's guide". (Oh -- the book cover is shown below!)

In that balance sheet metaphor, the right side is for the fact-based inductive manager; the left side is for the visionary. And, since those two never agree fully, there is a gap.

And the gap is where the risk is. Risk is the balancing element between the vision and the facts. And who is the risk manager: the project team -- not the visionary. (That's why we pay the PMO the big bucks: to manage the risk!)


*This narrative adapted from "Playing to the Edge", pg 428



Buy them at any online book retailer!

Friday, December 27, 2019

Linus Torvalds



Here's a good TED talk with Linus Torvalds, the geek of geeks, and an early inventor of LINUX and Git

Linus Torvalds transformed technology twice — first with the Linux kernel, which helps power the Internet, and again with Git, the source code management system used by developers worldwide.  "I am not a visionary, I'm an engineer," Torvalds says. "I'm perfectly happy with all the people who are walking around and just staring at the clouds ... but I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in."






Buy them at any online book retailer!

Monday, December 23, 2019

Very short course in risk management



Need a quick introduction to risk management? Don't have much time for this?

Try this very short course on risk management (no math required!)





Buy them at any online book retailer!

Saturday, December 21, 2019

So, you've got to write an RFP


Spoiler alert! This posting may be dry to the taste...

Ever been asked to write an RFP (request for proposal)?
It may not be as easy as you think.

My metric is about 2-3 hours per finished page, exclusive of specifications. Specs are normally just imported from an engineering, marketing, or product team. So, it could take you the best part of a week to put an RFP in place.

My outline is given in the Slideshare presentation below

Beyond the outline, here's a few things to think about.

Source identification: Sources, per se, are not part of the RFP, but sources are its audience. And the RFP is written for a specific audience, so sources certainly influence the RFP

Source identification, or better yet: source identification and validation (vetting), is both a science and an art. The science part is an objective list of source attributes; the art part is judgment, admittedly not objective.

Among sources, there's sole source (the only one in the world who can do it) or selected source (the only one in the world you want to do it), but more often an RFP regulates competition among multiple sources.

Award criteria: How are you going to decide who wins?
  • Lowest cost, technically acceptable (pass/fail) is the easiest and most objective.  Just open the envelop of all those with passing technical grades and take the lowest cost -- no questions, no fuss
  • Best value is not easiest and not entirely objective, but it might get you the most optimum solution. Rather than pass/fail, you get to consider various innovations and quality factors, various management possibilities, what the risk is to you, schedule, and, of course, cost.

    Best value may not be lowest cost. That's always controversial, since cost is the one value proposition everyone understands. No one wants to spend more than the value is worth.

    The flexibility of best value (or, glass half empty: lack of objectivity) comes with its own risk: the award, if in the public sector, is subject to protest about how the best value was determined.
Risk transfer: what technical, functional, and business risks are you going transfer to the contractor, and are you prepared to pay for that transfer? In effect, you're buying insurance from the contractor.

All other risks are your to keep; you can be self-insured, or pass them off to an insurance party.

Risk methods: Here are some risk methods you can put in the RFP:
  • Contract incentives, penalties, cost sharing, and other contract cost-schedule-scope controls: all are forms of risk management practises.
  • Liquidated damages: you get paid for your business losses if the contractor screws up
  • Indemnity: your contractor isolates you from liabilities if something goes wrong
  • Arbitration: you agree to forgo some of your legal rights for a simpler resolution of disputes
Statement of work (SoW): This is the part most PMs know something about, so a lot of words aren't needed. It may be the first thing an interested contractor reads.
The SoW answers this question: what is it you want the contractor to do? A top-level narrative, story, WBS, or vision is usually included.

The SoW is where you can say how agile can the contractor can be interpreting the vision. Think about how anchored to your story you are.

Typically, unless you are pretty confident you are right, you don't tell the contractor how to do the job, but only what job needs to be done.

Specifications: How's and what's for compliance: It is certainly necessary to speak about how something is to be measured to prove compliance; or you can speak to what is to be measured to verify compliance to the specification.

Requirements: And last but not least, the book of requirements is tantamount to the infamous Requirements backlog.

Give these ideas about requirements some thought
  • Are they objective, that is: having a metric for DONE
  • Are they unambiguous? ... almost never is the answer here. Some interpretation required. 
  • Are they complete? ... almost certainly never is the answer here. But, can you admit the requirements are incomplete? In some culture and context, there can be no such admission. Or, you may be arrogant about your ability to obtain completeness. My take: arrogant people take risks and make mistakes...the more arrogance, the larger the risks... etc

    But, where you can say: Not complete, then presumably the contractor can fill out the backlog with new or modified requirements as information is developed?
  • Are they valid? Can you accept that some requirements will be abandoned before the project ends because they've been shown to be invalid, inappropriate, or OBE (overtaken by events)?
  • Are they timely? Can you buy into the idea that some requirements are best left to later? ... you really don't have enough information at the beginning. There will be decision junctions, with probabilistic branching, the control of which you simply can't




Buy them at any online book retailer!

Wednesday, December 18, 2019

Agile and R/D



I was recently asked if Agile and 'R/D' go together.

Good question! I'm glad you asked.

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?


Let's start with OPM ... Other people's money ... And the first question:
What have you committed to do with the money?
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: -- example: got a completion cure for cancer?

"Completion" means more than just effort; it has elements of accomplishment and obtained objectives. You can calculate an ROI applying OPM to "completion"

"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 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. Scope is assumed well enough known so that the price can be "firm" and "fixed".

Poor scope definition? Then, ask for "best effort".
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.

And, of course, ROI is problematic with T/M. The money may, or may not, develop anything with a dollarized business return.

And so now let's layer on Agile ... what's in and what's out vis a vis R/D:
Among the agile practises 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 practises 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.



Buy them at any online book retailer!

Sunday, December 15, 2019

Hey, it's OK


A few weeks ago, I posted about "they" as the new gender-neutral singular pronoun, as in this usage:
"When the project manager establishes a schedule, they really mean it"
Fair enough

But now, here's news you can use: OK has new partners
  • For the older set, it's still ok to use OK in text and email
  • For the younger set, KK often replaces OK, but sometimes K replaces KK
Got it? It's only a matter of a simple mapping and substitution code. OK maps to KK, which in turn maps to K, thus OK can also map to K, and the reverse holds as well.

Such coding has been going on for awhile, but now it's been long enough that we can say that the usage is mainstream with many people, even if not with the OK traditionalists!




Buy them at any online book retailer!

Thursday, December 12, 2019

Through the doors


A narrative

Imagine two doors to the same room:
One labeled risk manager; the other labeled decision maker.

Though the risk manager's door, entry is for the inductive thinkers: those armed with facts looking for a supporting generality or an integrating narrative

Through the decision maker's door, entry is for the deductive thinkers: those visionaries with a capacity to envision specifics facts or conclusions that flow from the vision

And, consider this:
  • Pessimists with facts enter through the risk manager's door
  • Optimists with business-as-we-want-it-to-be enter through the decision maker's door
Then what happens?

Each needs to find the other. In the best of situations, they meet in the middle of the room where there is buffer space and flexibility.

How do the inductive and deductive thinkers interact?

Risk managers do not set policy for the project office; risk managers only estimate the left and right hand boundaries.

The space between the boundaries is where the decision makers get to do their envisioning, moving about, pushed back only by the risk boundaries.

Balance sheet metaphor

Sound familiar? I hope so. You'll find a similar explanation known as the "project balance sheet" in Chapter 6 of "Maximizing Project Value: A project manager's guide". (Oh -- the book cover is shown below!)

In that balance sheet metaphor, the right side is for the fact-based inductive manager; the left side is for the visionary. And, since those two never agree fully, there is a gap.

And the gap is where the risk is. Risk is the balancing element between the vision and the facts. And who is the risk manager: the project team -- not the visionary. (That's why we pay the PMO the big bucks: to manage the risk!)



Buy them at any online book retailer!

Monday, December 9, 2019

If the customer is not satisfied .....



If the customer is not satisfied ...
First question: How would you know if the customer is not satisfied? Is customer satisfaction one of your project metrics? Good grief, I hope so! If not, you might want to consider this little ditty:
 
  • If the customer is not satisfied, they may not want to pay.
  • If they are not successful, they cannot pay.
  • If they are not more successful than they already were, why should they [pay]?


Niels Malotaux
Paraphrased a bit


Buy them at any online book retailer!

Friday, December 6, 2019

Rules to communicate by



I've always subscribed to the notion that the top three things for a PM to do are:
  1. Communicate often
  2. Communicate effectively
  3. Communicate widely
Perhaps I should have made "effectively" the first thing on the list. In any event, at every occasion (often, widely), here are the workflow rules for effective communications:



Two rules
Remember this
Rule 1
       Tell them what you’re going to tell them
       Tell them
       Tell them what you told them
Rule 2
If “they” don’t get it, it’s not their fault



Re Rule 2:
  • If at first you don't convey it, back out and reformulate
  • You can't show frustration
  • You can't show irritation
  • You can't blame it on the audience if they don't get it
  • You can take it off-line to try again




Buy them at any online book retailer!

Tuesday, December 3, 2019

Council for the product owner



I got this idea from a student; I think it has merit, so I'll pass it along here:
The POC
Our backlog is managed by our Product Owners Council (POC), made up of 7 voting members representing the users in the global markets. The voting members are responsible for translating their constituent user requirements into user stories for review by the council.

The council members bring their user stories to council meetings where they are reviewed using a specified criteria before admission to the backlog.

Backlog
We have a large backlog that is prioritized by the POC for each release based on the velocity the development team can deliver, usually 100 points per sprint per scrum team - there are multiple sprints and scrum teams per release.

.... in our case, there are constant trade offs taking place in what gets developed from the backlog. When functional requirements are the focus of a release, the POC meetings become very political with each member arguing for their backlog of stories.

Impacts
The final vote includes a consolidated view from each POC member on the user story's impact on our customer, regulatory environment and user productivity along with a hi, medium, low ranking.

Priorities
When the global deployment was in progress, all user stories that enabled the countries to go-live on the system where prioritized ahead of functional requirements, including some less critical defects.

Standards
Our current direction from executive stakeholders is to standardize our cloud based systems and any requirement that enables the standardization will have precedence over functional requirements.


Buy them at any online book retailer!