j e s r u s h . c o m

A friend in IT recently asked me to explain cloud computing to them. It’s a complicated question because 1) personal cloud computing (think Sugar Sync, etc.) is very different from enterprise cloud computing (think Amazon S3, etc.) and 2) The vendors offering cloud services are offering really different products from each other.

I gave my friend the best summary which I could, but later I referred him to this old but excellent summary of the state of cloud computing. It has great great play-by-play on the offerings from each of the major vendors.

Things have shifted a little bit since then, but this is still the best summary I’ve seen on the web. And Amazon is still kickin’ everyone else’s butt with their simple image-based solution.

The other day I witnessed a major misstep when a vendor serving my own employer recommended a solution to us which was incompatible with one of our key business constraints.  Fortunately we caught the problem, and the proposal was scraped.

But not everyone is so lucky.  Insane sums are spent on rework for systems which were built with bad or missing information.  As someone who builds and implements these systems myself, I can’t say that there is a foolproof method for uncovering every constraint, assumption, requirement, and interface which might affect the solution I propose.

But I can say that there is a process of due diligence which must be systematically followed to try and fully understand the target business.  I decided to sketch a brief list of things which the project manager, business analyst, and technical lead should look at when building and implementing a solution:

•  Corporate objectives.  The suits might be leery of sharing the three or five year plan with a vendor team, but the more information you can get about the organization’s strengths, weaknesses, opportunities and threats — the better!  Is the organization growing, innovating, changing, and/or trying to cut costs?  If so, how are they accomplishing these things?
• Competitors.  Who competes with this organization?  What does market share look like and how have these competitors designed their systems?  How can they be outdone?
• The Industry.  Checkout the trade journals, attend a conference, and join any industry organizations.  You need to become a kind of insider who can help lead the customer to a solution which they never even considered.
• Org Charts 2.0.  You need to take the plain old org chart and dress it up with some key details for each department or entity: mission, function, and current initiatives.
• Infrastructure Charts.  How do the existing systems communicate with each other?
• Location Models.  Geographically, where does everything sit?  And what laws, cultures, and locale-specific variables change from one location to the next?
• Business Events.  What events drive the business? Do they come from customers, partners, suppliers, regulators?  Who springs into action when these things occur? Do they occur on a regular schedule?
• Process Models.  Workflows and interactions.

While so many customers (and providers) want to dive directly into the requirements gathering phase, there are huge benefits to first researching these domains.  It can mean the difference between a well conceived proposal and an expensive disaster. But more than that, it can lay the foundation for a customer-provider relationship which goes beyond this project.

Imagine if you (as a provider) noticed a trend in your customer’s industry which led you to design a solution for a problem which your customer didn’t even realize they had!

Project managers are usually thought of as analytical types and as people who execute things.  In their analytical moments, they survey a field of options, risks, and opportunities, determining the optimum path through the landscape.  When they execute, they move mountains to get things done.

But there is a third archetype which ought to describe the project manager.  Project managers ought to be creative.  Not creative in the sense of managing their projects (e.g. finding a better way to crash a schedule), but rather creative in the sense of  strategic product and service innovation.  Let me explain.

In today’s cutthroat business world, organizations must constantly improve.  They are in  an endless cycle of cost cutting, value adding, and creating new products. No matter how well your business is doing now, it is just a matter of time until a competitor catches up and duplicates–or even improves on–your success.  Your profits shrink.  As Robert Reich has explained, at the end of the day there are essentially three strategies to stay in the game:

1) You can figure out how to cut your costs and offer your X for less than competitor’s Y.
2) You can figure out how to produce a much better X for the same cost.
3) You can use whatever expertise gained along the way to be first out with entirely new product Z.

What does this have to do with project managers?  Simply put: Everything.  Project managers are in the incredibly unique position of having one foot in their supplying organization, and one foot in the customer’s organization.  They can gather customer needs and match those up to the supplier’s offerings.  But more than that they can  identify unstated customer needs and find innovative solutions which haven’t even been built yet (but which the supplier has the capability to build).

The key of course is creative thinking and relentless focus on the three strategies.  When is the last time you asked yourself and your project team, “How can we cut costs?” “How can we add more value?”  “Is there an opportunity for a new product here?”

COMING SOON:  Part 2 — Tools for Creative Product Innovation

In Steve McConnell’s classic, ‘Rapid Development,’ he talks about the benefits of versioned software development.

The basic idea is almost a kind of psychological trick: Instead of promising one version with five features, you promise five versions with one new additional feature in each. Either way, the customer expects they’ll end up with the same thing. But by doing this, you force the customer to ruthlessly prioritize the most important features into the early versions. Guess what happens next?

By the time you’re into version two or three, the customer realizes that what they planned for versions four and five is all wrong. They need something different. So plans can be adjusted and the new revised requirements can be met. Now imagine that we had originally built the entire application (all five features) in one version. At this point, the code for the original features four and five would have to be thrown out, and the new revised features would have to be built.

The benefits of versioned development are obvious. But after watching this process unfold a couple of times now, I’ll go a step further: Not only does versioned development bring the utility of rolling wave planning to bear on software and reduce wasted effort, it reduces work entirely. What do I mean? I mean that I’ve seen customers end the project early because they realized that the functionality in version one, two, or three meets their needs entirely. They certainly don’t need the features originally planned for versions four and five, but nor do they need a different set of features.

And as everyone knows, project size has a linear relationship to risk. If you can reduce the size of your project with the psychology of versioned development, then you can reduce your project risk. Your project is more likely to be successful. Beautiful…