70-30 and 90-10

---

A lot of project work is bid and won competitively, in effect beating out the other project team that wants the work.

Fair enough.

But, how do you win? How about this:

Bid the job with only a 70% confidence that you can do the job for the price... thereby taking a 30% risk that the actual cost will be higher (How much higher? You probably don't know).  

Ok, sometimes that's what it takes to win; I get it. But then, if you win, you might be heard saying: "OMG, what do we do now?"

But the worst is when the sponsoring executive says: Congratulations! Now, do the job for 90-10!

Translation: "Give me a project plan that brings the cost in for less than 10% risk that it will be higher than bid." (How much less: it probably doesn't really matter ... except: your bonus -- and perhaps your job -- only depends on not overrunning the cost)

Now with this scenario, we have the classic "project balance sheet" case:

• Sponsor's side of the balance sheet, top down: 90-10 cost confidence required of the PM
• PM's side of the balance sheet bottom up: 70-30 on cost; so the only way to obtain balance is to take a risk.

And, in the best traditions of risk manage, "taking a risk" doesn't mean listing it on a register and then just standing around looking at it. Taking a risk means: Do something to defeat the forecast! That's the project manager's mission:

The project manager’s mission is to manage assigned resources to deliver the value expected, taking measured risks to do so

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Creeping Risk Averse behavior

---

John Adams has an interesting post on his perception that in society generally there is a creeping aversion to risk -- given the number of plaintiff lawyers in the U.S. this should not really come as news. 

Nonetheless, he gives us a ppt presentation that's got some interesting view points -- you can get started on pages 4 and 5 with Adams' idea of perception sources and his formulation of balancing behavior among risk and reward:

The Public Perception of Risk from jguadams

 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Three bodies, but should there be four or five?

---

At HerdingCats, there is really good posting of the "iron triangle" described as the "3-body-problem". I recommend you click over and read it. (And, that's where I got the swell graphic)

But, not so fast!

 But -- there's always a "but" -- the triangle famously leaves out quality as an explicit trading variable, and also "effectiveness-for-business-value" -- the PMBOK dropped the triangle some years ago -- after all what's the point of a doctrinally successful project if it's the wrong thing to do vis a vis business value?

Actually: There's no point in such a project.

This is true whether in public or private sector, where in the public domain, business value is often "mission").

And, by corollary: is it all bad to be off according to project doctrine, but spot-on re the business?  I think not.

So, perhaps it would be best to all spring for quality and business value as a five-element system.

On the other had, it's a great graphic. Looks like an independent suspension apparatus, which I suppose what it's supposed to be: independent trading variables.

Ooops! They're not independent: As a general matter in most practical projects there are correlations between them -- not always strong correlations; perhaps not even material correlations, but nonetheless, not truly independently sprung.

Thus, we can expect some compression/expansion of the springs without necessarily affecting the other balls. And that, of course, is the point of such an architecture -- isolation and pseudo-independence.  By the way, the automotive guys have been using such independent suspensions for years, and to good effect.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Sketching architecture, etc

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it.

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The illusion of stability

---

It's human nature when faced with a chaotic environment ... to filter out most of the noise to focus on a single trend. The resulting illusion of stability gives us a context we can understand. But it's still an illusion.

The reality is that there are many different interrelated trends -- areas of change that impact us as well as the other trends. There are also discontinuities: sudden shifts that force us to rethink our assumptions.

Jason Bloomberg*
"The Agile Architecture Revolution"

Amen! to that sentiment. One often wonders if we're the engine of change, or the victim -- change leading us, rather than the other way 'round.

In the statistical world, it's much like finding the regression line amongst a lot of seemingly random or chaotic data points. The regression line is kinda the place we would like to be if we were the next thing to happen.
(Note: regression isn't filtering, but the line itself is a nearly noise-free representation of the "message of the data", so to speak)

Of course, a word of caution: it's not actually so swell to speak of filters narrow enough to smooth out the noise, and yet leave enough bandwidth to be disturbed by a discontinuity or sudden shift. Such phenomenon have very high frequency components which would likely be smoothed to the point of unrecognizability at the filter output.

Therein lies the hazard: big shift at the input... and little notice at the output. (See: Microsoft misses mobile and the tablet shift, or worse: Blackberry misses everything. ) One wonders if the Microsofties have been living on the wrong side of the filter.. perhaps a little exposure to the chaos of small business would be a tonic.

 

---

*Bloomberg is President of a consulting firm that takes the position, roughly, that a SOA (services oriented architecture) that is very loosely coupled to accommodate ambiguity and emergence of function and performance when the user is part of the system and in-the-loop is an "agile architecture". Bloomberg has coined the development of such architecture as "Complex System Engineering" (CSE); it is the heart of the "revolution". He contrasts CSE with traditional system engineering which he more or less equates with integrating a number of small objects into a large system.These views, and his company offerings in this regard, informs the content of his book.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Talk about the weather!

---

The weather in the US and Canada this winter has been a huge risk to projects... polar vortex and other phenomenon have made a mess of project plans, supply chains, outdoor painting, oil drilling, and all the rest. Talk about a chaotic stimulus to the system!

So, here in sunny Florida where we at "Musings" hang out, and where we do have hurricanes -- though not every year, and not for a few years -- this photo from my daughter in cold! Wisconsin seemed to sum it all up:

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Friction: social debt + technical debt

---

And, so now we've all come to the point the art and science of project management that we have various debts to go along with a myriad of biases. The new one (for me) that I've just come across is social debt, as described by Philippe Kruchten

He tells us:

Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop].

Social debt is .... the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc

Now, put social debt together with technical debt -- all the myriad of little things left undone -- and you get the idea of the friction in the project.

So, what price -- actually, for the PM: cost -- is friction? First, friction spreads the tails of the Monte Carlo simulation of cost and schedule, and potentially shifts the mean cost and schedule to the right. Second, and certainly a root cause of the first point, friction holds back productivity and gives rise to lost energy (to overcome friction) and lower velocity (less throughput)

Fair enough. But, what do we do about it?

• New project? Take a look at the history of overcoming debt and make adjustments to the knobs and switches of your project model
• Got flexibility? Reorganize, retrain, change environment or tools, or add SMEs (or dismiss the high-friction nemesis)
• On-going project? Rebaseline. That may cancel a lot of the social debt built up in the existing project. In effect: reboot
• Risk management? Sure, think of both technical and social debt as a risk to be managed

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog