Tuesday, December 31, 2013

Happy New Year!


Happy New Year!
 
 

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

Sunday, December 29, 2013

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.

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

Friday, December 27, 2013

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!

Check out these books I've written in the library at Square Peg Consulting
    Posted by at
    Labels: ,

    Tuesday, December 24, 2013

    Happy Holidays!


    Happy holidays to all!
    H

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

    Monday, December 23, 2013

    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.



    Read in the library at Square Peg Consulting about these books I've written
    Buy them at any online book retailer!
    http://www.sqpegconsulting.com
    Read my contribution to the Flashblog
    Posted by at
    Labels:

    Friday, December 20, 2013

    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.


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

    Wednesday, December 18, 2013

    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)

    Read about these books I've written in the library at Square Peg Consulting
    You can buy them at any online book retailer!
    Posted by at
    Labels: ,
    Subscribe to: Posts (Atom)