So, you have to write an RFP!

---

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

Ever been asked to write an RFP (request for proposal)?

Yuk!
It may not be as easy as you think.

Top-down metric

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.

Check this out

My outline is given in the Slideshare presentation below

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

Source identification: 

Sources are those that are going to respond to the RFP and do the work if selected

Sources, per se, are not part of the RFP, but sources are its audience. And because 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 is a tool to regulate 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

RFP template from John Goodpasture

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Practicals and Virtuals

---

Have you noticed this?

Have you noticed that on many projects there is a bifurcation of the workforce that is by job class, by cultural affinity, by natural skills and interests, and by work-site and location? (*):

• The "practicals" who live and work and think in the physical world (whether in the office, or not)
• The "virtuals" who live and work and think in the remote and digital space (even if they go into the office)

Practicals And Virtuals

Leverage the differences and make it an "And":

In the best of all cases, the win-win is to leverage the conjunction of 'practicals' and 'virtuals' as a reinforcing join of culture, skills, and interests. 

How could you build a new bridge without both working together: Design, analysis, construction? 

Have you ever looked closely at a sweeping fly-over bridge? 

• How do they get those massive iron beams to gently curve over hundreds of feet and join seamlessly with the next? 
• How do they get the concrete columns to have just the right arc to give the roadway above the right degree of bank on the curves? 
• How would the CAD ever match up with the 'physicals' who drive the rivets and build the molds if they didn't work together ... rather than apart.

Practicals Versus Virtuals

'Versus' doesn't buy you anything

Instead of the joy of a 'reinforcing join', the opposite may be a dis-attraction, rejection, or tension between strangers from two spaces: physical and virtual.

In systems terms, there may be little or no throughput, poor gain on resources committed, and outright hostility. Obviously, there is nothing to be gained by being at loggerheads about the differences in experience, attitude, and values. Those who can type should also be able to use a screwdriver; but it works the other way around also. 

But, in fact, the cultural divide can be a chasm: pay, promotion, recognition, status, security to name a few of the HR issues, but also respect, arrogance, and elitism that unwittingly divide rather than unite, to say nothing about herd loyalty and commitment to win-loss.

If there were an answer ...

If there were an answer for this, other than self-awareness and walk-in-their-shoes exercises, I would put it down in the next paragraph

But, there is no next paragraph .....

++++++++++++++

(*) Credit to Ross Douthat for the idea of 'practicals' and 'virtuals'

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Bad news?

---

Is this the worst news possible in project management?

All the money has been spent, and nothing has been delivered ... nothing has been earned!

Yikes! What happened to get the project to this point?

Did you fear the data?

• Were you fearful of the data, unwilling to measure or unwilling to believe the measurements of value attainment?
• Or worse yet, you actually don't know how to measure value attainment.
• Or even more worse, you kill the messenger who has the data!

What value is to be attained?

And by the way, it's damn hard to measure increment value attainment if, at the outset, you have no idea of the value to be attained. (the so-called emergent project .... feed in money and hope! something useful comes out)

And here is another fear: Fearful of making and estimate because, actually, you have no idea of what its going to take to do the project. And fearful that as resource expenditures pile up that there is nothing to show for it.

Most often, that occurs when you've made no estimate of the value requirement ... project outputs ... and the corresponding inputs required for such outputs.

So, how to be anti-fearful?

• A priori estimates are a must
• Metrics that represent attainment are a must
• Data transparency is a must (don't kill the messenger or hide the message under a project rock)
• Aggressive reaction to metric data is a must
• Pro-active look-ahead where possible. 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The first rule of 'data'

---

The first rule of data:

• Don't ask for data if you don't know what you are going to do with it

Or, said another way (same rule)

• Don't ask for data which you can not use or act upon

 And, your reaction might be: Of course!

But, alas, in the PMO there are too many incidents of reports, data accumulation, measurements, etc which are PMO doctrine, but in reality, there actually is no plan for what to do with it. Sometimes, it's just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job.

The test:

 If someone says they need data, the first questions are: 

• What are you going to do with the data?
• How does the data add value to what is to be done
• Is the data quality consistent with the intended use or application (**), and 
• Is there a plan to effectuate that value-add (in other words, can you put the data into action)?

And how much data?

Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

And information?

Well, the usual definition is that information is data, perhaps multiple data, integrated with context, and interpreted for the current situation.

So, the rule can be extended: If there are not means to process data into information, is the data necessary to be collected?

Bottom line: To state the obvious: always test a request for data collection for value-add before spending resources!

_____________

(*) Statistically significant: Enough data to distinguish between a 'random or chance outcome', and an outcome that is really from an event, factor, or stimulus of interest. As a practical matter for the uses of PM, ten independent data points is usually enough to establish statistical significance. Other disciplines may require more.

(**) Data quality: To add value, the data must be timely vis a vis the context, as complete as practical (nothing left out), consistent over time and space, more unique than redundant, sufficiently accurate in a metric sense, and void -- to the extent possible -- of qualitative biases. The latter is a tall order since all human reasoning is biased in some way or another.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The software is never done (!)

---

The software is never done!

Certainly not news; and certainly not profound to any engineer, coder, or PM working in the software industry, writing apps, or supporting software enabled devices.

Users have come to expect routine and regular updates to all things software.

Ooops, not so fast!

What about the automobile industry?

Traditionally: the car is done! 

• Buy it; keep it; sell it, eventually. Never needs an upgrade!

But that tradition may be short-lived: Cars will need upgrades over the life-cycle

What now?

A few months after I bought a new car I got a recall notice to take it in for an upgrade to the transmission control software. That recall system is probably the way to keep software up to date for many of the in-vehicle software programs. 

• But, is this only a warranty service? 
• How long would manufactures support software upgrades for 2nd or 3rd party apps?
• The life of car is 12 years+ for new vehicles. That's 'forever and forever' in the software industry, comparable to still supporting the iPhone 4! 

Big Tech

So-called big tech is taking over much of the user interface and user apps in new vehicles (except Tesla which does all its own in-house design and does not support Android and Apple apps on its user panels)

Long term support

As a project manager, what can you look forward to as regards long-term supportability of apps?

And, as a app developer, you may be one layer removed from knowing that it will find its way into the automobile industry. 

And as a business manager or customer support liaison, which customer are you supporting most?

• The one that pays the bills (automobile manufacturer) or 
• The customer that buys the car?

In the Agile sense of value-as defined-by-the customer, who is most influential?

Long term, these are my wonderments. I wonder how they would be written into project requirements?

• I wonder if you'll be able to go to your local auto parts retailer and buy an upgrade-on-a-stick for legacy vehicles? 
• I wonder if there is not a whole industry to be invented supporting older cars with updated interfaces?  
• I wonder if its practical to expect the after-market developer to maintain currency for 'a long time'. 
• I wonder if personal security, data security (nav data, for instance, but also other data about downloads to the car like music stations and podcasts, etc), and all the rest will not spawn a whole set of requirements, support issues, and a supporting industry?

Perhaps in the future, the mantra will have to be something like this:

The software is never done!
And, neither is the car!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The principle of 'calculated risk' (updated)

---

"In carrying out the task assigned .... you will be governed by the principle of calculated risk ... which you shall interpret as avoidance of [risk] exposure ... without good prospect ... as a result of such exposure ...  of greater [benefit]" (*)

Admiral Chester Nimitz
to his subordinate admirals,
Battle of Midway, June, 1942

"You will be governed by the principle of calculated risk"
What does that really mean?

"You will be governed ..." means you've been handed the governance task; there has been a passing of (command) authority and decision-making. Whatever the strategic and most far reaching business and project considerations there are, and whomever has the responsibility for articulating the strategic vision, all that has been compressed into an instruction to "you". "You" have the authority to assess cost and benefit in the moment, and pull the trigger ... so to speak ... to take a risk or not.

"Calculated risk" is intended to convey a defensive tactic to protect a scarce or endangered asset or outcome; unless the loss of that asset begets a larger offsetting advantage. To that end, there are these constituents:

• First, a risk assessment based upon what it means for the loss of a scarce asset or a debilitating outcome vs the benefit or advantage of a favorable outcome. Call this a cost-benefit analysis and calculation
  
• Second, the quality of your knowledge base, assumptions of knowledge accuracy and timeliness, and a heads-up that there may be knowledge gaps. This is really the epistemic component of the risk: how much can the risk be mitigated by better knowledge?
• Next, doctrine, ideology, or rules-of-thumb are made subordinate to the calculation. Now to walk away from doctrine for a calculated risk takes some intellectual flexibility and maturity, to say nothing of walking out on the limb.
• If there is an adversary or nemesis, game-theory may be useful to estimate reactions (walk a mile in their shoes, etc .... )
  
• And last, if there is no scarcity which requires the protection of a risk calculation, then the principle is unnecessary.

Fair enough

What happens when it comes to actually facing the risk in a real project situation?

• Intellectual flexibility may be required. 
• Cool heads will be needed; emotion will be left at the door, hopefully
  
• Random effects will almost certainly intervene and perturb the knowledge-base calculations. You probably can't do much about the randomness; that's the nature of the it ... more knowledge doesn't help.
• Updates to game theory assumptions we be needed along the way.
  
• And, revisits to the knowledge base to update the risk calculation (the calculation may be rather dynamic in the doing ...) will be needed. (**) 

Plan B:

In spite of cool calculations, in the heat of the moment managers may blunder through the guardrails. Then what?

There should be a framework for Plan B on the shelf. Facts at the time will fill in the framework.

Ah, but who's in charge of Plan B? 

Someone should always be hanging back to grasp the strategic picture while tacticians deal with the here-and-now. And, that someone should have supreme executive authority to step in and make corrections.

_____________

(*) A Naval War College essay dissecting the Nimitz principle of calculated risk is found here.

(**) This idea of revision in the face of new information is the Bayesian approach risk calculations. That is: you have a hypothesis, "A", based on your going-in knowledge; then there's a change or there is observed evidence "B". Now you know more, and so the likelihood changes ("likelihood" being the probability that the observed evidence will support the original hypothesis, P(B/A)

 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Roll back the black box

---

It's a system engineering idea:

• Encapsulate a function, 
• Make it opaque to outsiders, and 
• Feed it inputs and external controls, biases, and offsets
• Look for and utilize the prescribed outcomes
• Voila! You've got a black box!

Ooops!

What if ...

What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

The question is begged: Do you understand how your black box works? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

Working on AI?

The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

---

Buy them at any online book retailer!

Remoting the physical job

---

Old news: Remote work on software and administrative tasks is routinely applied in projects.
New news: Remote work on physical jobs is, or will be, moving to projects from operations and production
Other news: Is this outsourcing by another name?

Assisted robotics

So, what we're talking about here is assisted robotics.

• In production, we've been flying airplanes, taking pictures, sniffing bombs, and assisting robotic fulfillment in warehouses for years ... very successfully (measured in human jobs displaced and quality of outcomes)
• Robotic-assisted medical procedures are more common place than they were

But in one-off projects, assisted robotics has been a costly thing

But, it's coming!

• Designing building a new antenna for spacecraft? Need to work in a 'clean room'? I can operate a lot of the machine tools and assembly tools from home, or least from a remote project office, and I don't have to put on a 'clean suit' to work on the antenna!
• Building cable bundles and other physical assemblies: do it with human-assisted robotics. Did I mention: no errors, ever! And perfect solder joints.
  
• Working on bio-tech, or chem-tech? Hazardous? Bring on the assisted robotics!

There's a pattern here:

• Multiple robots do most of the work
• Humans intervene to stop and start the work, and to trouble-shoot when the robot gets stuck

Computing the RoI

• There's capital investment (CapEx) in the robotic machinery (Hopefully, you can make business of designing and building one-off space craft antennas)
• There's overhead expense to train the workforce to be a robot's assistant
• And there's project direct expense to add project-specific instructions to the robot's operating system
• And don't forget that although robots can work 24/7, without fatigue and frustration, the human handlers do need time off or shift rotation
• But overall there's less labor input and higher quality output (less rework, etc) that drive the 'return'

Outsourcing by different means

Did I just say that humans are to train robots to take their jobs away?

Ooops! That may not be the right message

Is this just a different outsourcing problem?

---

Buy them at any online book retailer!

When A comes before B

---

When A comes before B

If you understand the nature of A and that of B, and if starting B depends on A, then getting A done before B sounds easy, but sometimes it makes you wonder!

• Is there a preamble to B that should be done before A is completed?
• Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
  
• Can B really start after A, or are there other dependencies on the start of B?
  
• Do I really want B to start, or do I want to pause and start C somewhere else? 
• If I start B, immediately after A, have I introduced unnecessary risk or other impacts?
  

And, there's this:

Schedule depends on sequence
So, if you're thinking about sequencing, you're probably also thinking about schedule: if I plan for "this sequence", how long is it going to take?

Or, the other way around: if you are working on a schedule, you have to get the sequence down first.

Scope is what you sequence, but ...

It seems obvious, but it's worth saying: you have to know what you are going to do. To wit: you can't sequence that which you don't know about. 

And furthermore, even then there may be sequencing errors that you discover once you understand the full extent of the scope. Leave some slack for the unknown!

BUT ... Sequencing value-add to the business may be the ultimate sequence determination. Taking care of the business may be your job-one. If you can, choose sequence in favor of the business!

Scheduling tools

Scheduling tools, like the ubiquitous MSProject, are a good planning tools for sequencing. You can work in the Gantt-chart mode and sketch out the big picture pretty rapidly, setting up key milestones as schedule goals. You need not use the precedence mode at all.

However, there is a bridge too far: 

If  you plan in too much detail, many of these tools are way too tedious to use for maintenance of the schedule once the project is under way. 

 

As a practical matter there will be "micro-dependencies" that crop up, which are worked in real time; micro-loops for feedback and checking results against the evolving construction baseline, etc. that are way too expensive to schedule, status, and maintain as they change.

Milestone focus

My advice: at the PMO level focus on the major sequences that drive toward value-add milestones.

---

Buy them at any online book retailer!