Happy New Year!

---

Happy New Year!

 

 

---

Bookmark this on Delicious

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

Periodic elements table for PM

---

Here's an interesting take-off on the periodic table of elements, as developed at Shift Happens

Now author/artist Mike Clayton tells us that these project elements are "indivisible" like the chemical elements they emulate. And, like the chemical elements, hydrogen and oxygen for example, they can be combined to make interesting elements, as H and O combine to make water.

Not exactly!

I think anyone with a bit of experience would look at any of these project elements and see that most are readily divisible, though yes they can be combined.

And so the utility of this chart is: (drum roll goes here) Well, it's an interesting and entertaining display, somewhat like an infographic. Maybe something for the warroom wall. I thought you might like as did I.

---

Bookmark this on Delicious

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

If you can't draw it... (and other system engineering stuff)

---

Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.

Fair enough -- no news there. We've talked about storyboards, etc before.

But then the heavy lifting begins. How to fill in the details? Where to start?

My advice: Draw it first.

If you can't draw it, you can't build it!

And so the question is begged: What's "it"

Three elements:

1. Narrative
2. Architecture
3. Network

And, one more for the PM:

• Methodology

Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.

Narrative: (an example)
Bridge stanchion with strain sensor and sensor software

Architecture:
Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):

Black Box

Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)

And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:

Interface

And then we add content (white):

Content

Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:

• Black: Boundary
• Blue: Interface or API
• Grey: Buffer
• White: functional content

You could call this an architecture-driven approach and you would not be wrong:

1. First, come the boxes:

• Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
• Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software

Then comes the interface:

• Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?

And then comes the "white box" detail:

• The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
• And then there is the actual functional content, to include feature and performance.

Network

2. Second big step: networks of boxes

• Think of the boxes as nodes on a network
• Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
•  Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
• That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.

3. Third big step: white box design.

Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts marterials to build out the box.

• Expect to refactor the network as the white box detail emerges
• Expect to refactor the white box once development begins. See: agile methods

And, not last: Methodology:

The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!

The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:

Interfaces and boundaries are sacrosanct!

Now What?
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Happy Holidays!

---

Happy holidays to all!

H

---

Bookmark this on Delicious

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

Thank you for your readership!

---

Thanks to all the readers of the stuff we write here at "Musings". And, apparently there are a fair number of you, such that we humbly find ourselves on this most impressive list compiled by projectnewstoday.com.

1. Herding Cats
2. PMI Blog - Voices on Project Management
3. QuantmLeap
4. Arras People - How to Manage a Camel
5. A Girls Guide To Project Management
6. Virtual Project Consulting
7. Zilicus
8. The Tao of Project Management
9. ProjectManager.com
10. Ron Rosenhead
11. Leadership Freak
12. Mike Clayton
13. The Program Manager
14. Brad Egeland
15. Musings on Project Management
16. Leadership Thoughts
17. Gina Abudi
18. Sensible Project Manager
19. Better Projects
20. Software Project Management
21. Ahha Moments
22. Guerilla Project Management
23. Lazy Project Manager
24. Henny Portman
25. EarthPM

---

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

Agile project template

---

I get asked a lot for my version of an agile project template. I suppose everyone has their own version, but I like this one:

• 0.1 Charter
• 0.2 Architecture
• 0.3 Non-functional requirements
• 1, 2, 3 iterations for product development
• 0.4 Release buffer
• 4 Release
• 0.5 Tech Debt

Of course, this template can be scaled for more releases, etc. And, if there is legacy product, then there are going to be integration tests therewith. Thus, the 'release' might be a couple of iterations  -- or even more -- to cover the full scope of release-to-production testing.

A bit about the nomenclature, which is pretty simple:

--Iterations with no customer deliverables are often denoted with a leading '0'.
--Iterations with customer deliverables, including the release event, are numbered from 1-up.
--Each release is often 'buffered' with a '0'-scope iteration so that any spill over in the backlog for the release can be handled at the last minute, and 
--A technical debt iteration is usually scheduled as part of the release, or immediately afterwords, to clean up small problems. You could expand this to cover customer support for some short period after release. That would depend entirely on the charter scope and your support model.

---

Bookmark this on Delicious

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

Scope is a fact; value is an opinion

---

One of the mantras I learned early in my business career is:

"Profit is an opinion; cash is a fact!"

reflecting the fact that there are a lot of non-cash expenses that go into the profit calculation, many of these are informed opinions that interpret the GAAP (Generally accepted accounting principles)

 

Now, having written the book on maximizing project value*, I feel qualified to advance the parallel idea:

Scope is a fact; value is an opinion!

So, if you are trying to set down some plans, some controls, and some degree of predictability, would you pick on scope or value as your control mechanism? And, would the CFO pick on cash or profit for the project's business case?

Presumably you would go for a control mechanism that is non just an opinion. Who wouldn't?

Not so fast!

Jim Highsmith, an agilist with a new book "Adaptive Project Leadership" tells us (in Chapter 3) that scope is a very poor control mechanism -- but he doesn't say exactly what scope is to control, or why it is poor.

Highsmith does say that a lot of scope that is delivered goes unused and thus does not contribute to business value. Fair enough. We all know that most of us don't/can't use the majority of functions in MS Office!

He idea -- similar to what I say in my book -- is that a better payoff for the business is focus on controlling value -- that which the customer finds useful and important, and for which a customer is willing to pay. Thus, value -- again, a matter of opinion -- should be the control mechanism.

Consequently, we need a way to come to a common opinion. The great leveller is money, and so monetizing value is the default. We see this in the start-up business valuation as well: it's all an opinion as to what the company is/will be worth.

And, as I posit in my book and elsewhere: the value of a project is really the impact it has on the value of the business... and that might take some time to materialize. Thus, history may be the ultimate judge!

---

* "Maximizing Project Value: A project manager's guide" (See cover image below)

---

Bookmark this on Delicious

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

Safety critical principles

---

At Critical Uncertainties there is a very good posting of some 21 principles attendant to managing risk and providing for safety in systems where safety criticality is predominant.

Here are a few I picked out that seem to come up often when doing a risk register of unlikely but severe risk events and outcomes.

I add this bit of editorial: the principles lead directly to the so-called "1% Doctrine" that posits that peremptory action is justified to neutralize a risk source, not just mitigate consequences.

The 1% Doctrine is Principle 1 in different words. 

We see this played out in the security arena big time, everything from preempting WMD to preempting travellers at the airport check-points.

But on the project scale we see peremptory action to avoid a project budget cut or resource reassignment. In other words these principles have both strategic and tactical application:

1. Where risk exists there also exists an ethical duty of decision makers to eliminate if practical or, if it is not, to reduce such risks to an acceptable level.
2. The greater the potential severity of loss associated with the system the more likely the organisational and societal focus will be on prevention ... rather than mitigation of consequences.
3. Risk ... is a social construct and can never be evaluated in a totally objective fashion.
4. Some unknown risks may disclose themselves in the life of the systems, some may never be identified.
5. The greater the severity of a [risk] the lower the required occurrence rate and the greater the .... uncertainty of estimation of probability.
6. The greater the .....uncertainty of probability estimates the more the focus should be upon the reduction in the severity of consequences.
7. The more complex a system the more likely it is that an accident will be due to the unintended and unidentified interaction of components, rather than singular component failures or human errors.
8. One can never absolutely ‘prove’ the safety of a system as such arguments are inherently inductive.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Change and Collingridge's dilemma

---

A simple but profound observation:

When change is easy, the need for it cannot be foreseen; when the need for change is apparent, change has become expensive, difficult and time consuming.

David Collingridge"The Control of Technology"

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Necessity drives invention

---

From one of my agile students:

Traditionally my organization -- a healthcare insurance company -- adopts the waterfall approach, but with the projects related to healthcare reform and participation in the new Health insurance exchanges we had to adopt the Agile methods, especially because lack of clarity in requirements and ever changing rules and regulations from the state and federal government.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Fallacies, illogic, and bad arguments

---

I came across this ebook (free) that is a good, fast read... with humor... about "bad arguments", logic, fallacies, poor reasoning, wrong conclusions, and more....

Recommended to all!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Shakespeare on risk v opportunity

---

Shakespeare had some interesting insight to the dilemma of whether to see an event/condition as an opportunity that defines the future, or a risk that we may well regret:

There is a tide in the affairs of men,
Which, taken at the flood, leads on to fortune;
Omitted, all the voyage of their life Is bound in shallows and miseries....
And, we must take the current when it serves,
Or lose our ventures.

William Shakespeare, "Julius Caesar" 

In hindsight, this is a lot easier said than done. Indeed, we may well recognize a flooding tide... who could miss all the boats being lifted? ... but when is the tide at its flood (maximum lift)? That's a hard one to judge in real time as it happens -- perhaps if we wait, the tide will go a little higher! (if it doesn't ebb)

But, the issue is not really about missing the peak... that happens a lot with no catastrophes. The issue is about missing the whole damn tide event.... not taking a risk when opportunity presents itself.

How many projects are too risk averse to really be successful? I'll bet more than you might imagine... or admit to.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Project Histories..

---

"The young Alexander conquered India
On his own?

Caesar defeated the Gauls.
Did he not even have a cook with him?

Excerpt from Bertolt Brecht's poem: "Fragen eines lesenden Arbeiters"

When the campfire stories of your past projects are told, who will get the credit? It never hurts to give credit to the little people, the staff, and the technicians that helped make it happen.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting