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?

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!

The HR manager at my last organization and I have a long-running joke about what our country would be like if our president were hired by HR instead of being chosen by popular vote. To make a long story short, the joke goes that we would have no president, because HR would add a requirement to the job description that the person have, “4+ years experience running the country.” As there would be no way to obtain that experience without first being given the job, there would be no qualified candidates.

I don’t mean to pick on HR. In fact, I love HR and believe that the director of HR should sit atop the org chart right next to the CFO (Yes, hiring, growing, and retaining the right people is THAT important to organizational success). But I’ve also noticed a troubling tendency among recruiters (and sometimes functional managers) to automatically reject candidates who don’t have experience doing the job which they are filling. The legendary story of the General Electric HR manager who recommended against hiring Jack Welch should forever haunt recruiters everywhere.

I hate to state the obvious, but people cannot obtain certain kinds of experience until someone gives them the opportunity to do so. Most successful managers for example, were at some point a regular staff worker with no formal management experience. Someone looked at their past performance (which–for humans–is a good indicator of future success), looked at the opportunity, and took a calculated risk by placing them into a “bigger” job.

I’m not suggesting that you should put your landscaper in charge of your IT department because they do a great job on your hedge rows. What I am saying is that whenever you encounter someone who has taken on stretch assignments, undergone training, and reached outside their formal job responsibilities, you should take notice. Many of these people will be tomorrow’s successful managers and simply need the right break to become stars. You could be the enabler who spots the next Welch.

Crisis management is one of the most undervalued management skills: It’s rarely taught in business school and no one cares until things hit the fan. But when they do, a steady hand at the helm can guide a team through the stormiest of waters. The most important thing is to be systematic and to keep making decisions. I wanted to step through the anatomy of a recent crisis and explain what I did and why it worked.

The crisis: This particular crisis began on a quiet weekday when a customer sent us an email out of the blue stating that our system — which was installed at their site — was hogging all their network bandwidth and freezing their computers. Apparently, it was so bad that their employees could barely work. And the problem coincided with use of our system earlier in the day.

Yikes!!!

Step 1: Re-prioritize and compartmentalize.

A potential crisis must be bushwhacked with great force. If you hit it hard enough and fast enough, you can sometimes avert the crisis altogether, or at least minimize its impact. I pretty much dropped everything I was doing to focus entirely on this issue.

Meanwhile, I did everything possible to compartmentalize the issue and maintain the impression of normalcy with the customer. Crises have a tendency to take on a life of their own (if you let them) and it’s important to carry on as if everything is under control. After acknowledging the email with a quick phone call to the sender, I made a point of speaking with other people at the customer’s office about unrelated issues. They didn’t mention anything about the network and nor did I.

Step 2: Plan for Sea Animals

When someone accuses you or your team or your products of causing a problem, it’s only natural to react skeptically. Your people are good and your widgets work just fine–thank you very much.

A good manager has to fight that urge. It’s possible the whole thing could be a misunderstanding, but it’s equally possible the crisis could be real. Real crises often turn out to be bigger than their initial boundaries. They’re like those foam capsules you drop in a sink full of water, they turn into two foot alligators.

With that in mind, I assumed the worst. Maybe our system was somehow causing total work stoppage. Maybe it was interrupting crucial business process. Perhaps it had been affecting their network even before today. Could the system have been compromised? It might get even worse. By thinking through these possibilities, you help ensure that the scope of your response is sufficiently wide. And mentally, you ensure that you’re not going to be caught off guard by unexpected bad news.

Step 3: “Trust, but verify.”

In the famous words of President Reagan, it’s time to figure out whether this crisis has any teeth. Using your enlarged scope from step 2, you do some fact-finding and gather hard data. A good starting point is simply the five W’s (who, what, where, when, and why).

In this case, we delved into the system logs in question, looking for activity indicators. Of course we also looked at past days, kicked off virus scans, and asked for more details from the customer contact.

Step 4: Report

If the crisis looks legit, the next step is to immediately notify your boss. You don’t want to shirk from delivering bad news. Better now than later. I walked over to my bosses office with a fistful of data showing that our system had definitely been active around the same time that the customer experienced issues. I also notified the project manager currently using the system as well as the salesperson who sold it to the customer to begin with.

Step 5: Imagine it’s High School

Although you’re trying to maintain the appearance of normalcy, you have to plan for the possibility that in short order — everyone will know: Everyone at your customer, all of your employees, maybe even your competitors, or (gulp) the press.

If/when they do, you need to have something prepared to tell them that will maintain control and nip the rumors. I worked up a short memo laying out the facts and explaining that no link had been proven between our systems and their network problems — yet. Sure enough within a half hour, another manager was asking for information about the situation. Click! Memo sent.

Step 6: Build a Project Plan/Team

The simplest way to tackle a multi-headed dragon is to break it down into small, concrete tasks and assign them to specific people. Usually a gantt chart with tasks/due dates and a RACI chart outlining roles & responsibilities is sufficient.

I doled out a couple of tasks to the PM with a next day deadline, and outlined the steps which we would be taking to further investigate the issue.

To make a long sleeve short, over the next week we ultimately discovered two things:

1) Their network slowness did not perfectly correspond to use of our system. Meaning, they had *other* unrelated issues contributing to the slowness.

2) They had changed their network architecture, reducing throughput in the process. This was news to us and information which would’ve been useful yesterday.

So in the end, it turned out that our system was behaving normally and was fully exonerated. It was doing the same things it had always done, but the environment it operated in had changed (for the worse). After explaining this to them via a teleconference, we dialed back our system activity until they could get their network\throughput issues worked out. We followed up with a written explanation reiterating the same things said on the phone. Fortunately, they understood.

Step 7: No Pain — No Gain.

Lastly, you want to use the momentum from the crisis to change the processes (or even people) so that it never happens again. Be a change agent.

In this case, the crisis had more bark than bite since it really wasn’t our fault. But nonetheless we still used the energy to improve our system testing/planning process, so that we would be more likely to detect an environment change at the customer before things go south.

Wrapping Up

This particular crisis turned out well and they don’t always go so smoothly. The steps above sound incredibly simple in retrospect, but it’s amazing to me how few people actually follow them. Ultimately a crisis should only make you and your organization stronger, but things can and will spiral out of control if you’re not careful.

After using his super PMP study guide some time back, I picked up Andy Crowe’s other book, an obscure little text, ‘Alpha Project Managers,’ published in 2006.

This has to be one of the most under produced books I’ve ever seen.  Crowe essentially self-published on his own Velociteach label.  It shows.  The graphics are third rate and the cover is pretty bad. 

But no matter.  The information inside is fascinating. Crowe surveyed over 3,000 project managers and their co-workers/supervisors in order to identify the “top 2%” of project managers (”alpha project managers”). He tried to identify PMs who were consistently rated as excellent by the people they worked with and their customers. Once he found them, he zeroed in on their work habits and PM techniques.

Some of the interesting findings:

CIO.com has a great new article on a recent survey from Panorama Consulting Group about 670 ERP implementations which Panorama studied.  Among the nuggets:

The majority of respondents (77 percent) had chosen a Tier I provider (SAP 35 percent; Oracle 28 percent; and Microsoft: 14 percent). The rest (23 percent) went with the Tier II.

So, what was the total cost of the average EPR implementation? SAP $16.8 million; Oracle $12.6 million; and Microsoft $2.6 million. Tier II average: $3.5 million. (Microsoft’s figure is pretty impressive.)

And how long did it take respondents to fully implement the ERP solution? SAP 20 months; Oracle 18.6 months; and Microsoft 18 months. Tier II: 17.8 months.

Now, the multimillion-dollar question: How satisfied are the executive team and users with the ERP solution? SAP 73 percent (Panorama’s “satisfaction rating”); Oracle 62 percent; and Microsoft 69 percent. Tier II: 70 percent.

Fascinating stuff, especially the low cost of Tier II ERP implementations (NetSuite, etc.) and of Microsoft!  I expect SaaS ERP to really begin taking off this year.  Now that security concerns have been mostly allayed, the value proposition on turnkey, hosted, no-license-fee ERP is just too good.