I've got to write a RFP

---

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. 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 more better, 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.

Of course, 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 as your contractor), 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 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 via the RFP, 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.

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 are you?

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: Specs are where you can speak to measures of "how" insofar as you tell the contractor how something is to be measured; or you can speak to measures of what insofar as you tell the contractor what the metrics are and what the metric limits are

Requirements: And last but not least, the infamous Requirements backlog or matrix. Requirements are usually made a part of the SoW  as detailed "what's" or they can be a specification onto themselves.

Requirements are where problems surface on almost every project:

• 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

---

Buy them at any online book retailer!

Kanban at the Kitchen Table

---

Dana Rousmaniere and Frank Saucier collaborate in an interview to talk about kanban methods for the home. And, of course, it's all built around a kitchen table white board with some sticky notes.

Have you done this at home? I have; and it works... you wouldn't expect otherwise.

But, Frank carries it a bit further than I want to go. He has structured family meetings with a checklist agenda, and then daily check-ins on project tasks.
Whoa! that's a bridge too far for my wife ... no micromanagement here.
In fact, Frank admits: "There's sometimes some moaning and groaning... "

The larger point

But, of course, there's a larger point here: Almost everything we do, formally or informally structured, as some sequence and flow -- just think about driving to work, or walking in to open your home office at the beginning of the work day (or night)

Flow and process... sequential steps; they are the building blocks of everything

Now, the lean and kanban advocates are all about improving flow, thinning out the non value-add, and simplifying the process so that work flow and work process are pretty much birds of a common feather.

Then comes scale, even in the kitchen
Who can argue with lean? Does anyone really want to do the non-lean stuff, even if they have to? No one so long as the work flow on the kanban does not require coordination with other kanban's... in that case, we move on to scale, and scale brings overhead, and overhead brings flow control, and so we all slow down.

You don't see this much on the kitchen table, unless your home project is part of a larger project for a community organization -- then comes the bureaucracy of scale.

You might say that velocity and scale have a inverse correlation, perhaps even a causation -- larger scale, lower velocity

Is it too low tech?

"I like to use low-tech tools, because it’s more important to learn good habits than it is to learn to use a tool. That said, there are plenty of digital ways to do the same thing — a good, free tool is Trello, which is essentially an online Kanban board.

But, I find that with digital tools, a lot of great ideas get buried, and the simple act of moving a post-it across a visual board is very kinesthetic. I’ve also noticed that teams have better discussions when they’re around a physical board." Frank

What's the payoff?
With Frank I agree (from personal experience in the kitchen)

• Get priorities squared away
• Manage distractions
• Teach others the tools as a life skill
• Richer communications

---

Buy them at any online book retailer!

Measure the measurable

---

Without Metrics you're just another guy with an opinion - Stephan Leschka, Hewlett Packard*

I get it; and mostly, I agree with Mr. Leschka
BUT, there are a few other rules:

• Don't measure -- meaning: don't invest the effort to collect and analyze -- that which you don't manage
• Don't measure the unmeasurable -- meaning, don't assign false values and dimensions to that which is fundamentally subjective and intangible.
• And, if your metrics are not statistically significant, you may still be just a guy with an opinion

What about this?

• In spite of many books to the contrary: Everything is not measurable. 
• And, even it is measurable, it may not be necessary or important to measure it. 
• It may not be practical or economically sensible to measure it. That's why we invented sampling!

 

It's not always just about the numbers! (But, we knew that, didn't we?)

 

Of transactions and strategy

One might say: In the capitalist environment we manage, most of us subscribe to the school of transactions and dollars: all (most?) things of value have a price. And, if that is so, then all things of value can be measured. 

 

BUT: all is not transactional!

Some think long-term (are we shocked by such a claim?)

Some opinions and some issues are strategic: a blend of interests, principles, values not held in dollars, and effects which are to be legacy for those that follow. 

*Look here

---

Buy them at any online book retailer!

Shakespeare on project management

---

When we mean to build,
We first survey the plot, then draw the model;
and when we see the figure of the house,
Then must we rate the cost of the erection
which if we find outweighs ability,
What do we then but draw anew the model
In fewer offices, or at least desist
To build at all?

William Shakespeare
Henry IV, Part2, I.iii,1598

First seen at heardingcats

---

Buy them at any online book retailer!

Quantitative risk for the new guy on the street

---

Repetition and review are good--Malcom Gladwell says it takes 10,000 hours to be expert at anything--so here's a few words that will take a few minutes on three important quantitative concepts every risk manager should know:

Concept 1: Centrality
Most phenomenon of interest to projects, particularly naturally occurring phenomenon, tend to cluster around a central value, given enough samples or examples. Obviously, this let's out the so-called long-tail 'black swans', but project managers can go a long way if they understand that central clustering is the norm ... in effect, the default.

The measures are average and expected value. The former is applicable when the data is known; the latter when the data is probabilistic and the numerical value is not known until an event occurs. In calculating the average, each value is equally weighted; in calculating the expected value, each value is weighted by its probability.

Concept 2: Variation
Yes, things cluster, but that simply means that around the central value there is a range within which things are nearby the center, but not exactly on the center.

It's more likely things are close to the center than not: that's an effect of centrality on variation

The measures of variation are variance and standard deviation.  Variance is a figure-of-merit related to the distance, or error, between a point in the range and the central value. Standard deviation is a more direct measurement of distance, having the same dimensions as the points in the range.  Engineers refer to the standard deviation as the root-mean-square, or RMS value.

Concept 3: Position
Sometimes it's enough to know just the position of a data value in the range.  Names associated with position are quartile and percentile, and the so-called 'Z' position. 

Z is just a value in the 'standard range' divided by the standard deviation.  [A 'standard range' has a '0' average] For project management purposes, the 'Z-position' extends +/- 3 units from the average or expected value for most situations.

Dividing a range into 4 quartiles requires defining 3 boundary points: Q1, Q2, and Q3.  Quartile is all about count, not value per se.  Just rank all the values in the range in ascending order.  Divide the count into quarters.  Q1, Q2, and Q3 are the count values that divide the range.

If a value is in the first quartile, that means that 75% of all the values in the range are greater than the Q1 value, and by extension 75% of all the values are greater than any value in the first quartile.

---

Buy them at any online book retailer!

Agile strong -- a reveiw

---

Trying to remember how you got here?
Perhaps
Understanding why you're sticking around is also important

So, here's my top ten reasons why agile has worked for me

1. Agile is a "best value" method: it's doctrine is centered on value and accomplishment for the customer and user, not so much adherence to cost and schedule--though the sponsor's investment can not be exceeded, so cost is at least capped

2. Agile respects the urgency and importance of priorities conveyed by the customer/user, most prominently by incremental delivery and flexible sequencing

3. Agile respects the power of emergence and iteration to drive innovation, provided the customer buys-in

4. Agile puts the customer in the driver's seat for the value agenda of the project.  By doing so, the project is more "Juran" than "Deming" in its quality orientation.
Thus the PM's mission: deliver the most value for the invested resources, taking reasonable risks to do so

5. Agile is more bottom-up than top-down as a matter of doctrine.  There's a bit of the "wisdom of the crowds" in the way that small teams are given opportunity to find solutions, and there's a bit of small unit tactics--as practiced by the largest command and control organization of them all....the U.S. military--that put a lot of minute to minute decision making with the bottom of the WBS.

6. Agile has the potential to more effectively align business planning-and-execute cycles with project cycles.  Business cycles are often scheduled well in advance and are often calendar driven [it's July, so let's kick-off the annual planning process for the next FY].

7. Consistent performance by small teams of participants that work together continuously is highly valued. Such consistency means that PMs can depend on throughput benchmarks that are statistically meaningful.

8. Agile respects the objective behind earned value: Say up front what you are going to do, and then do it.  No partial credit.  Either it works or it doesn't. 

9. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.

10. Agile gets the benefit stream flowing sooner, so the time displacement between need and delivery is manageable at lower risk.

---

Buy them at any online book retailer!

Bigger pie, or more slices?

---

Leadership v Followership
I've been revisiting Michael Porter this week here at "Musings".
I was struck by Porter's description of leadership v followership in technology:

About that pie:

• Leadership increases the size of the "pie", but 
• Followership only reslices the pie.
   
• Followers accept "zero-sum"; 
• Leaders change the sum.

---

Buy them at any online book retailer!

F.W. Taylor: should we care?

---

How many project managers are still laboring with the aftermath of Fredrick Winslow Taylor, more popularly known as F.W. Taylor?

Taylor Who?
You might ask: Who was Taylor?
Good question
F.W. Taylor was one of the first to study business systematically -- an original "operations research" guy. He brought 'Taylorism" into the business culture in the years leading up to World War I. By 1915, his ideas were considered quite advanced.

But, here's news you can use: much of what he divined is still around and affecting projects! Read on ....

Taylorism, so called
Taylor set about to invent "scientific management", a revolutionary movement that proposed the reduction of waste through the careful study of work.

Taylor came up with the original 'time-and-motion' studies, perhaps one of the first attacks on non-value work.

Peter Drucker, a management guru par excellence who coined the term 'knowledge worker', has ranked Taylor, along with Darwin and Freud, as one of the seminal thinkers of modern times. ["Frederick Taylor, Early Century Management Consultant", The Wall Street Journal Bookshelf, June 13, 1997 pg. A1].

Ooops, what about Agile?
The essence of Taylorism is an antithesis to agile principles but nonetheless instructive.

Counter to what we know today, Taylor believed that workers are not capable of understanding the underlying principles and science of their work; they need to be instructed step-by-step what to do and how to do it; and nothing is left to chance or decision. Rigid enforcement is required.

Managers have a role
However off-base that idea, Taylor was close to the mark with his doctrine about value-adding work. According to Taylor, managers must accept that they have responsibilities to design efficient and effective process and procedures.

Waste must be eliminated!
Every action requires definition and a means to measure results.

OMG! Not a popular guy
Taylor was not well like by workers and it's not hard to see why. But Taylor's ideas and practises brought great efficiencies and profitability while providing customers with products of predictability of quality.

Do it once, right
I like what Steve McConnell says about quality and the software relationship. Building off Taylor's ideas of 'do it once right', though he does not mention Mr. Taylor, McConnell, author of the respected book "Code Complete" states the " general principle of software quality is .. that improving quality reduces development costs .... the best way to improve productivity is to reduce the time reworking..."

Beck gets it right
Kent Beck, writing in his book "Extreme Programming Explained - Second Edition" has a pretty strong idea about the legacy of Taylorism and its lingering effects on the knowledge industry.

He says of Taylor that he brought a social structure we continue to unconsciously apply, and warns against the message that Taylorism implies: workers are interchangeable; workers only work hard enough to not be noticed; quality is an external responsibility

---

Buy them at any online book retailer!

Agile C.R.A.C.K. customers

---

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Spiral methodology, writes about the ideal customer for agile projects.

Boehm's perspective:

-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.

More from Boehm on Agile:
Take a look at other Boehm'isms about agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004

---

Buy them at any online book retailer!

Dangling participle

---

Still, as Hanson Baldwin summed up the Italian campaign, “All roads led to Rome, but Rome led nowhere.”

Hanson Baldwin, Historian
describing the WW II campaign in Italy, 1943 - 44

Accomplishment without purpose -- a dangling achievement
And, the lesson for project managers is:
Beware the strategic objective that isn't actually strategic at all.

• It looks strategic at the moment
• It's called strategic
• Perhaps just a tactical diversion?
• We go "there", but the dots don't connect; or, can't be connected; or there's nowhere to go from here

AKA: "The bridge to nowhere"; a dead end; wild goose chase? Down a rabbit hole? A floating apex? Perhaps ... some may be just tactics that didn't work; the real issue at hand is strategy that doesn't connect well to business objectives

Value adding?
And so, even if it dangles, could achievement have larger strategic value in some way, shape or form?

Yes, and no.
Which is the fate of -- and means to recognize -- such dangles: arguments in favor and and arguments against; seemingly forever on both sides of the issue; each with proponents, unconvinced and unconvincing. (The campaign in Italy is still argued to this day .... why did we do it? **)

What if?
History can not be rewound and replayed; there are too many unseeable connectors and influencers that might come into play in the alternative narrative. But, the broad strokes of "what if" might be instructive, and so why not play it through?

• We achieve the objective
• Now what?

-----------------
Dangling participle? An actionable activity without an identified actionee

** Churchill's strategic vision was to defeat Germany from the east, through the Balkans, holding back the Russians from overrunning eastern Europe, and yet driving through East Germany to Berlin. The Italian campaign was a necessary entry into the Balkans, according to Sir Winston
Roosevelt's strategic vision was to drive through France for a quicker and more economical victory than slogging through the Balkans and challenging the Russians in the bargain.

In the competition of these two competing visions, Rome -- captured the day before D-Day in France -- became an objective achieved, but unconnected to the grand strategy (Roosevelt won the argument)

---

Buy them at any online book retailer!