j e s r u s h . c o m

Jason Hiner has a fascinating article at TechRepublic arguing that Google’s approach to software development is fundamentally incompatible with enterprise business requirements:

Google’s organization and corporate culture are radically decentralized. There’s not a lot of structure, process, or bureaucracy. The focus is on innovation and freelance creativity. That can make it a great place to work if you’re an engineer and it makes Google great at building Internet widgets and exciting new features for its search platform.

[. . .]

However, when IT departments do mass deployments of applications for business-critical tasks, they expect a high level of service. They expect the software to be bug-free, and if they do run into problems then they expect to be able to quickly connect with a customer support representative to resolve any issues immediately, if not sooner.

In order to pull off this type of experience that corporate IT demands, a software maker needs excellent attention to detail, strong processes and systems in place, and software that is “good enough” to provide a seamless experience for users. Again, delivering fully-packaged, mostly-bullet-proof software is not part of Google’s DNA.

Jason makes some interesting points here and on some level — I follow his reasoning. On the other hand, Google Apps has been a pretty big success by most accounts. Perhaps Google is a little more organized/process-driven than we’re giving them credit for?

Forrester has rolled out new cloud-computing survey results which turn some existing assumptions upside down! Among the findings:

Larger firms are more interested than smaller firms in leveraging external IaaS capability. This flies in the face of conventional wisdom that the SMB market will be the most eager adopter of cloud computing, because it will enable them to avoid extensive internal IT investment and skills.

Firms are slightly less interested in internal clouds than in external IaaS. By a margin of 10 percent, companies of all sizes prefer to focus on external providers rather than implementing a cloud internally. This is really surprising, for two reasons: (1) it indicates that companies feel they have enough information to make a decision, which is somewhat surprising given how early in the process we are; and (2) despite how early in the process it is, most companies are not opting for the “safer” choice, which is creating an internal cloud.

Interest in production app placement in external clouds is nearly as high as for test/dev. Again, the conventional wisdom is that companies will migrate test/dev to clouds as the initial use profile, because test/dev is often a pinch point in provisioning, requiring resources quickly and for indeterminate durations; the thinking goes that this type of use profile meshes well with cloud computing characteristics but also sidesteps other issues associated with external clouds like security, data privacy, and SLA needs.

Who knew?

Sometimes it’s hard to be a leader, but when people “buy-in,” it can make you smile. A great video:

Most day-to-day project or operational decisions don’t require grand meetings and circumstance, but there are some situations where gatherings should be called to make decisions:

• Whenever group input is likely to significantly improve the quality of the decision.
• Whenever the problem is complex and requires multiple specialists.
• Whenever team members might have difficulty accepting a decision

So how does a project manager or leader facilitate these decision-making sessions? I’ll share my basic framework:

1. Identify the problem. Clearly state the fundamental problem and its context. The key thing here is to avoid framing the problem in terms of choices (predefined choices kill creativity). The WRONG way: “Should we abandon the mapping component entirely or substitute an alternative map module?” The RIGHT way: “The mapping component difficulties have put us ten days behind schedule. We need to determine the best way to move forward.”
2. Generate options. Begin by establishing a moratorium on criticism. All ideas–even the craziest ones–are wanted here. Make the point that all ideas belong to the group, nobody “owns” an idea, and everyone is free to twist and extend ideas suggested by someone else. Try to gather as many ideas as possible (quantity over quality) and be sure to prompt/include anyone who is naturally shy or not participating. Put all ideas up on a whiteboard as they come in.
3. Set evaluation criteria. The team needs some way to sort through the options. If you established an expectations management matrix with the sponsor (which prioritized scope, schedule, or budget) or if you defined a project vision (e.g. “Put a man on the moon by 1975″), then you have your basic criteria there. For example, an alternative which pushed you past 1975 would score poorly.



4. Facilitate a Decision. Provide summaries of progress and keep the group on track. Protect minority opinions and ensure that everyone has a say. Test consensus and re-state your understanding of what is being said (silence does not equal agreement!). Some conflict here is acceptable (even desirable), but if tempers flare or it becomes dysfunctional — then end the meeting and reschedule another one.
5. Follow Through. After the decision has been made, the group should later be called together for a miniature ‘lessons learned.’ Did the decision turn out to be the correct (or best) one? If not, what threw the group off? How can a better decision be made next time?

   The bottom line is that if you want good decisions, you must follow a good decision-making-process!

I always thought that making pizza was a huge, three hour ordeal because of the dough. Turns out I was completely wrong. I’ve been going crazy with this insanely simple pizza recipe which involves beer (really!) and has step-by-step pictures. Great stuff.

You don’t have to use Twitter to appreciate the genius of historicaltweets.com:

martinlkjr: Bought a sleep journal. I keep having dreams but forget to write them down.

or…

JOHNHANCOCK: Why did everyone write so small? Now I look like a jerk.

or…

jamesjoyce: 140 characters? A sentence of such fractured length would have barely begun to scratch the thin surface of man’s vain, insignificant pligh-
jamesjoyce: Damn.

I love it! Also see this outrageously funny article on slate about people who tweet once, and never return.

I was watching the NBA finals the other night and caught a new Canon EOS commercial featuring an original composition by instrumentalist Michael Montes. Instantly hooked. A little digging around on YouTube and some genius managed to reverse engineer the entire song and recreate it just by listening to it. Amazing stuff: