Clouds everywhere!

It seems that there's a cloud everywhere you look, even here in Sunny Florida. For a good overview of the cloud services for file storage and sharing, take a look at this Online Tech Tips

Personally, I use Dropbox, and it's been a really good thing for what I use it for (which is backed-up file storage for my book manuscripts), but in the Tech Tips posting, there are descriptions for the competitors:

Microsoft SkyDrive; Amazon cloud, Apple's iCloud, GoogleDrive. All of these, including DropBox require some action on your part to store files.

For a number of years I used Syncpilicity. This service can work like the others with a set-aside folder, or it can create synchronized file images between your hard drive and its storage. Syncplicity also has some unique arrangements with GoogleDocs, which are by themselves a cloud solution for office documents. For a comparison of Syncplicity and Dropbox, check this out.


But, with all this, there are even more. For example, box.net and of course the major collaboration environments, like SharePoint.

So, you get the point. This subject is endless, and obviously has reached a tipping point, as "cloud" is now a meme

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Performance measurement and management

Sometimes I think of the traditional PM methods that we've been practicing and improving for the past decades---since really WW II when a lot of the science of PM was invented---as one of the two "grand strategies" for doing projects; the other is the Agile evolution, some say revolution.

 

Two grand strategies: is there a unifying idea that reconciles their approaches? Does there need to be such a reconciliation?

 

Glen Alleman may have hit upon a pretty decent reconciliation in his posting at HerdingCats. As an example of what I mean, he writes:

Planning of all work scope for the project to completion

 

• For traditional projects this means a master plan and master schedule for the planned work, the sequence of that work, the dependencies between the sequenced work.
• For an Agile project this means some way of knowing what done looks like in terms of User Stories or Use Cases bounded by a period of time. The planning of an Epic or a Release can be that bound.

 

Not a bad start in my estimation. His post goes on to complete his thinking on performance measurement on these two approaches.

 

Actually, I think of agile as just a risk response plan to a particular situation of unstable user requirements. Think of the usual requirements deck:

• There are foundation and non-functional requirements that are derived from the project narrative or vision. These are usually pretty stable
• There are interface requirements to existing systems, products, and processes; again, pretty stable
• And then there are user requirements that are like a fuzzy cloud floating on top of these more or less stable layers. That's where agile really comes in. And, as Glen shows, these methods, each applied to their own, are reconcilable.

 

Indeed, many (most?) that practice agile really synthesize a bunch of practices and fit them to the existing project model. Why? Well, other people's money to start with; and second: it's just common sense to take advantage of what you know that works in some situations.

 

Two grand strategies! How nice.

 

 

Bookmark this on Delicious

Requirements (again!)

Matthew Squair is a safety guy. When he writes a requirement, it's serious stuff. People and systems can hurt themselves if he gets it wrong.

In a recent posting he linked to a paper he has co-authored about writing good requirements and specifications, especially for safety and fail-safe systems.

Here's an example from that paper, entitled "What Happens when Engineers get it Wrong"

---

The following is a real example consequences of a requirements error:
• As written – “The system shall ignore all
anomalies 20 seconds prior to shutdown”

• As built – “The system actually cleared the
anomalies list 20 seconds prior to shutdown”

• What was needed – “The system should have
ignored all anomalies occurring in the 20
seconds prior to shutdown”

• What happened - The system detected an
anomaly within the window of vulnerability,
responded and as a result destroyed itself.

While this example is a safety related one, such
errors can be no less costly in terms of time and
money for less critical applications.

He then continues with some advice about constructing a requirement, saying in part:

"The most basic construction of a requirement can be expressed as an actor (the thing of interest), performing some act (the action to be taken) upon a target (the focus). So in the preceding example the system is the actor, the act is to ignore and the focus is the all anomalies. The requirement also has a constraint applied, in that the act can only occur in the 20 seconds prior to shutdown."

This really isn't too far from writing a use case in a structured way. One reference I like on use cases is by Karl Wiegers entitled "Software Requirements". In spite of the title it's quite a good tome on how structure good requirements, whether emergent, incremental, evolutionary, or foreseen.

Bookmark this on Delicious

On commas and quotes

Here at Musings we sometimes wax about the small things. Today, it's about the comma, and its usage in the American system and the Rest of the World (RoW).

I was put onto this by a posting at Noop.NL about the global comma issue (an issue that I was actually unaware existed, but hey!, we don't keep up with everything here), to wit:

• In Amercian usage, the comma goes inside a quoted passage: She said "I hate commas," and she went on to say more.
• In the Rest of the World, it's outside the quotation: She said "I hate commas", and she went on to say more.

To my eye, we in America have it wrong; RoW has it right. For the sake of clear communication in project writing, this really should be resolved.

Now, when extended to question marks, ?, and exclaimation marks, !, we follow the world rules: if the question is part of the quote, it goes inside, but if it's part of the sentence as a whole, it goes outside. In other words, we and the world follow the logic of the sentence. What a concept!

A great explanation for the background of the 'great global comma fuss' is found at Tina Blue's posting on this topic. She says (referring to commas inside the quote marks):

And just why, you may ask, do they belong there? Well, it seems to be the result of historical accident. When type was handset, a period or comma outside of quotation marks at the end of a sentence tended to get knocked out of position, so the printers tucked the little devils inside the quotation marks to keep them safe and out of trouble. But apparently only American printers were more attached to convenience than logic, since British printers continued to risk the misalignment of their periods and commas.

Bookmark this on Delicious

Extreme prototyping

Talk about extreme prototyping! If you were trying to figure out earthquake threats on your next construction project, what would you do? Well, this one made the national news: a full scale building with a hospital theme, complete with a doctor's examination room on the top floor, was shaken on a big(!) shake table.

Talk about the Spiral method: I'm not sure this is what Barry Boehm had in mind! A 6.7 magnitude quake for 60 seconds, and no broken glass... Now, that's a test.

But Boehm had the right idea in mind: when it comes to feasibility risk, you've got to set the right direction early or else you'll be doing a lot of backtracking (if you're still around to do the backtracking). The greatest hazard is often not the risky outcomes, but it's making the wrong decision about how to proceed: left, right, or straight ahead.

And, in the construction industry itself, when you get it wrong, it's often right out there in the public space where someone is going to be embarassed big time. And, that's where the political trouble starts.This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"

Bookmark this on Delicious

Brainstorming--who knew?

Boy, did I miss the memo on this one! Who knew?

There's just one problem with brainstorming: it doesn't work

Jonah Lehrer: "Imagine"

According to researcher Keith Sawyer of Washington University:

.... brainstorming groups think of far fewer ideas than the same number of people who work alone and then pool their ideas

Now, what's going on here? Since the 1940's, brainstorming--an invention more or less of Alex Osborn--has been touted as the way to get new ideas surfaced. The Osborn formula is famous for being non-confrontational:

• The first rule is "no criticism"; and
• The second rule is "everyone contributes"

But others, famously at Microsoft and Pixar, have gone the other way: everyone contributes but everyone is subject to critique and challenge. Lehrer says: "the acceptance of error reduces its cost", meaning that when you know the group will correct your errors you are less prone to avoidance.

In other words, criticism and debate is the stimulate of new ideas according to work done at UC-Berkeley by researcher Charlan Nemeth. In effect, critical inspection by others drives engagement, improvement, and innovation.

Perhaps as important is informal follow-up, is the communication by osmosis that Alistair Cockburn talks about. And, this in turn is stimulated by more open spaces and areas for informal collaboration.

In any event, to return to the top, it's not that brainstorming doesn't work, it's that the Osborne formulation of "lets all be friends" doesn't get the stuff out.

  Bookmark this on Delicious

Never stop learning

Continuous professional development is the personal reponsibility of everyone in our industry. However, everyone reading this probably has a day-job, so professional development often requires compression and fit to the white spaces.

I've extolled the virtues of Kahn Academy in this space before: it's the 10min video answer to education. It's remarkable how much you can pick up from these effectively produced snippets.

Now, comes a similar (free) offering--Coursera--from some Stanford guys (Kahn is from Harvard) that includes courses produced by not only Stanford but other universities as well: Michigan, Penn, and, Princeton.

It's produced much like the Kahn Academy: 10-15min videos, concentrating on the graphics, with voice-over from the professor.

Right now, there are offerings in a number of different fields from the humanities to computer science to health care and finance.

But, this whole idea of mainstream big league university courses online and free, or nearly so, may have reached a tipping point. In addition to Coursera, there is a new partnership between MIT and Harvard on a similar thing, called edX. And, there is another offering from Stanford alumn who took his inspiration for Kahn.

I was interested in Game Theory since I have a short introduction to it in my forthcoming book "Managing Project Value". There are, of course, many game theory videos on YouTube, and I've posted some stuff on that already, but the material at Coursera is perhaps a step up.

In any event, check it out: Never stop learning!

Bookmark this on Delicious