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

Writing a conference abstract

---

e n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. Translation: I would have written a shorter letter, but I did not have the time. -Blaise Pascal

Pascal had it right! It's much harder to write efficiently than to write. Anyone who has tried to get a lot of ideas into a constrained page count knows the issue.

In the public sector, where answering an RFP is something everyone gets into one time or another, the proposal instructions are the Bible, and the page count is law.

Bill Nichols has a suscint presentation about how to write an abstract for a conference presentation. I have done a lot of these myself so I can attest to the worthyness of Bill's suggestions. Abstracts, like proposals, are a sales tool; like proposals, they're often page limited, or word limited, or some such.

So being efficient and suscint is hugely important. I always say: follow the directions and give no excuse for disqualification. Make it easy for them to pick you!

Here's the essence of Bill's ideas

 At a minimum, answer the questions that correspond to these four sections.

• Background: Why did you do this?
• Approach: What did you do?
• Findings: What did you learn or discover?
• Conclusion: What does it mean?

Here are some questions to consider when you’re drafting your abstract.
Background (Why did you do this?)

• What is the problem you are addressing?
• How are things done today?
• What is the difficulty and why?
• Why has this problem not been solved before?
• What did you expect or what is the hypothesis?

Approach (What did you do?)

• What kind of data did you collect and how did you collect it?
• How did you assess the data?
• Who were the subjects? How many?
• Is this a case study? An experience report? A pilot? Did you set up experiments?

Findings or Results (What did you learn?)

• Did a new technique or approach work or not?
• What new information or data is provided?
• What was confirmed or refuted?
• Were there surprises?

Conclusion (What does this mean?)

• What can we now do differently or that we couldn’t do before?
• Who will be affected by these results? Does this apply to team members? Team leads? Coaches? Other stakeholders?
• Will something be cheaper, faster, or better?

Bookmark this on Delicious

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

Driving a data center

Did we all know this about the Chevrolet "VOLT" all electric automobile?

When you push the start button, you’ve got 10 million lines of software running. On an F-15, it’s about eight million lines of code. You’re really driving a modern data center, and a lot can go wrong

Jon Bereisa, former G.M. systems engineer

Good grief! What ever happened to the VW Beetle? I could pull the whole engine in less than an hour!

If General Motors doesn't do much better than other large software developers, drivers of software-complex vehicles might expect 1-3 thousand coding errors per million lines of code (0.999 to 0.997 error free, or about 3 sigma), although a successful Six Sigma program might improve on that by almost 1000:1 and get to 3-5 faults per million (0.999997 error free)--certainly more reassuring as you speed down the highway.

The problem, of course, is that physical systems always work the way they are designed to work. The problem lies in complexity: complexity is all about complicated systems (systems with a lot of parts) that have many--really, too many--interrelated interactions that are all but holistically unpredictable. As designers, we simply don't know what we've designed and thus we can't predict how the systems will actually work. Even chaotic systems work the way they were designed, but who knew?!

An interesting study on the sources of errors, the rate of discovery, and the point in the life cycle when the discovery is made is given in this industry consultant's study done in 2008.

This study is all done in function points; then are a non-physical relative measure of functionality, something like a story point in agile metrics. Like story points, you can measure velocity and create benchmarks. One wonders if we have had FPs for about 30 years, why do we need SPs?  If you want to know more about FP, here's a tutorial that'll get you started: click here.

By the way, Capers Jones, who wrote the report, puts agile projects sort of in the middle of the road vis a vis quality. Of course, you don't find agile projects in high reliability safety centric systems; there're great for designing games, but I'm not sure I want to go down the highway with my electronic brakes depending on the whim of a customer's idea of how it should work.

Bookmark this on Delicious

Imagine!

---

Creativity is the residue of wasted time

Albert Einstein

Jonah Lehrer has a new book: "Imagine: How creativity works".  At NPR, there's a good interview with the author that explains the book from his point of view.

His first book was a great insight to decision making: "How we decide"., which I briefly reviewed here and have quoted elsewhere.

For project managers, this is all about innovation and new ideas, and how to make a project situation fertile ground.

Jonah reports on the way many innovators and people of great ideas work. Here are a few points from a recent TV interview:

• First, epiphanies often come at times of great relaxation. "You have to make time to waste time" 
• Second, it takes a village in a manner of speaking. We socialize for success or fail alone is Lehrer's way of putting it.
• And third, the way we communicate and interact has great bearing: the most imaginative things come from the most casual and informal events. Bumping in the hall; gathering informally for coffee. What others have called communication by osmosis. Think about this the next time you think about a virtual team.

Lehrer reports that Steve Jobs put the restrooms at Pixar in a central place, and then allowed only two for each of men and women so that interactions would have to occur. Living and working in close quarters is something Lehrer calls the "friction of humanity". The energy of the friction is the fuel of imaginative solutions.

See this great little video that in amusing way illustrates the book.

IMAGINE: How Creativity Works from Flash Rosenberg on Vimeo.

Bookmark this on Delicious

Back to the future: Morse code?

OMG! Now we learn that to "simplify" typing on a smart phone, Google has introduced a variant of Morse Code they call TAP.

Don't remember your Morse? Perhaps you remember this:

Of course, on a smart phone, it's much "simpler". You merely 'tap' on two large buttons, one for dot and one for dash. The code is simpler also:

So, what's the connection to project management? Well, consider the ideas of simple,complicated, and complex:

---

• Simple: The least complicated or complex possible (for the situation)
• Complicated: a lot of parts
• Complex: complicated, but also burdened with a lot of part-to-part interactions, many of which are difficult to predict

---

If you were the project manager working with the product manager on TAP how would the conversation go? Presumably the goal is a faster typing experience, one attuned to the world of digraphs and trigraphs like LOL and OMG, etc. And, faster is supposed to be better--less overhead for the same message content.

But is two-button TAP really simpler than a 26 letter keyboard, 10 more for numbers, and a few more for special characters? It would seem so: 2 is surely more simple that 36+. Of course, the information content behind each of the 36+ is much greater than the information content behind one tap of TAP. Thus, it seem from an information encoding perspective TAP is going backward to 1890.

On the other hand, just as Morse was developed with efficiency in mind (the most common letter in the English alphabet is "E", so the Morse symbol is one "dot"), I imagine that TAP will go the same way. Whole thoughts, like LOL, will be simply encoded and perhaps the actual throughput will go up. We'll have to see how the smart phone generation handles this.

On the other hand, it could go the way of other Google innovations. Perhaps the Google folks should read Everett Rogers "Diffusion of Innovation".

Bookmark this on Delicious

8 qualities of remarkable employees

Jeff Haden at the Owner's Manual on Inc.com has a great posting on the 8 qualities of really remarkable employees.

By Haden's telling, great employees have these qualities:

• They ignore job descriptions. .
• They’re eccentric...
• But they know when to dial it back.
• They publicly praise...
• And they privately complain.
• They speak when others won’t.
• They like to prove others wrong.
• They’re always fiddling.

I like the fiddling thing. This means curiosity. And, it could mean a propensity for innovation. If companies play into this, they'll give the fiddlers some space and time. Somewhat like Google's "20% of your time to do anything" policy.

I have managed units that had eccentric people. I'm careful to say I didn't manage people, and certainly not an eccentric. As oft said: "things are managed; people are led". In fact, eccentrics are to be tolerated at least, and nurtured at best. You never know what will turn up.

As a case in point, take a look at the famous Bell Labs where the transistor was invented and Claude Shannon discovered the limits of bandwidth. Talk about eccentrics! Like shooting fish in a barrel

Bookmark this on Delicious

Getting ready for adoption

Sometimes, the project really has to step up and be a force getting the business ready for the project roll-outs, whether incremental or big bang.

In the end, it's all about the strategy for adoption. I first wrote about this back in 2009 where I laid out the work of Everett Rogers

What are some strategy elements that the project could be responsible for?

• Train ambassadors and support their deployment in the business to recruit disciples
• Support pilot or beta releases to test the water and gather feedback
• Develop communication artifacts, to include workshops, to inform the beneficiaries
• Plan for the influence of the customer or the sponsor to be felt in the project plan
• Actively work on project nemisis' to bring them around to a supporting position
• Keep the project sold at the executive level; anticipate change to be led from the top
• Buy into a change management strategy something like "Kotter's 8"

Not sure getting ready for adoption should be a project responsibility? Think about this: a project success without a business success is really not a success at all. Sub-optimizing on a narrow idea of project success may actually be a going out of business strategy!

Bookmark this on Delicious

Diversification for everyone?

'Diversification is a good thing. Everyone says so; so it must be true. Anyone who has an investment knows the Sqrt(N)rule:

Take any big thing and break it down into N smaller things. If risks act independently on the N smaller things, then the overall variance of the one big thing is reduced by Sqrt(N)

Variance is surrogate for riskiness: more is not good, generally speaking. The key issue is independence. In the globalized investment markets, what happens in Brazil doesn't stay in Brazil!

And, it doesn't have to be an investment; it could be a project budget. Or a project schedule. Or a work package in the WBS

But, there's a price, at least an indirect price to be paid for diversification. And, by the way, in the governance domain, diversification goes by the name "federalism". That price is inefficiency.

As the one big thing is broken down, overhead is made larger in the aggregate. If it's a WBS breakdown, to get independence you need independent WP managers. More managers means more communications, more ways to miscommunicate, and more times that someone didn't get the memo.

If it's a strategic teaming agreement, every team member is going to want their own project manager. Nobody is going to body-shop their staff. Even General John Pershing, CinC of US forces in France in WW I, refused British and French plans to simply plug the Yanks into the depleted EU ranks.

Of course, that very inefficiency has an upside: the higher more centralized functions have less power and so they are less to be feared and perhaps less autocratic. In fact, to combat autocracy, simply distribute the power. And, the less autocratic is almost axiomatically more capable of innovation. So, there's a lot to be said for diversifying the risk and federalizing the power.

As I'm writing this just as I'm finishing Robert K. Massey'stome "Catherine the Great". As a German born French speaking empress of late 18th century Russia, she was the exception to the rule in many respects. She was an absolute autocrat, but in almost everything else she diversified her risks and ruled successfully for decades. And, she was an innovator, bringing western European knowledge of modern medicine, art, and architecture to Russia. So, go figure!

Post script: for the trivia warehouse: Catherine made John Paul Jones, the acknowleged founding leader of the US Navy, an admiral in the Russian navy for her wars against Turkey. Ole Jones couldn'tt get his flag rank in the USN because there was no flag rank for the navy until the US civil war in the mid-19th century

Bookmark this on Delicious

Codeacademy

I've posted a few things about how project managers can take advantage of the free stuff at the Khan Academy, and its 3000 YouTube video's on everything from the French revolution to college level statistics, but recently I fell upon the Codeacademy, a DIY for erstwhile fledgling programmers, mostly targeted at web programming of one kind or another. Even some national newspapers have noticed, reporting on a "surge in learning". If there's a learning surge going on, I'm all for it.

I'm no programmer (that is, no one would want to pay me any money for what I know) but I do mess around with web programming on a small scale.

What I like about Codeacademy is that there is a structured lesson plan to go through and there are metrics. Some of it may be a little hokey since I wrote three lines of code and got three points for the effort, but hey!

In any event, it never hurts to know a little something about a lot of things, so throw DIY web programming on your bucket list.

Bookmark this on Delicious