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!

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!

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!

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!

Hey, we can put it off until .....

---

Are you a procrastinator?
Do you procrastinate and still try to manage schedule?
Do you think of yourself as a procrastinator who can manage risk?
Do you understand that managing schedule risk is tantamount to managing the concept of schedule buffers and the critical chain methodology?

Then, you'll understand that handling your tendency to put things off, and thereby forcing upon you managing slack and schedule buffers are not that much different.

In fact, what I see most of the time is managers wasting slack by doing a "latest start".
At the other end, they've got no buffer or slack to work with.
That is all wrong.
In spite of the risk of incomplete information, getting over the inertia of getting started and getting going on addressing the issues that will inevitably arise is paramount.

So, if you need some help on this, this humorous video is for you!

---

Buy them at any online book retailer!

Job done?

---

Agile Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trust them to get the job done. What job?

• Is it the job described in the business plan and in subsequent project plans, albeit lean plans consistent with the Agile Manifesto?
• Is it the job that has been estimated and scheduled?
• Is it the job as interpreted in near real time by the functional user?
• Is it the job that evolves over several iterations and is adapted to the emergent value proposition?

Trust them to get the job done. What’s the definition of “DONE”?

• Is it done when time/money runs out?
• Is it done when the backlog is fully exhausted?
• Or, is it done when the customer says it's done, or someone else says it is done?

If you can't give a 30 second elevator speech on each of these to the satisfaction of sponsor, product owner, and customer/user, you are not ready for prime time

---

Buy them at any online book retailer!

About 'positive'

---

Keep your thoughts positive
because your thoughts
become your words

Keep your words positive
because your words
become your behavior

Keep your behavior positive
because your behavior
becomes your habits

Keep your habits positive
because your habits
become your values

Keep your values positive
because your values
become your destiny

--Mahatma Gandhi

---

Buy them at any online book retailer!