Money can't buy you love -- but the right roadmap can

I am at an open source software conference this week, called JA-SIG. JA-SIG is a community of technologists in higher education that has developed uPortal, a standards-based portal for higher ed. It recently announced its version 3, which is a significant milestone in setting a course for the future of the community.

Getting to version 3 was pretty dicey. One key reason was that the original plans for version 3 included a rewrite from the ground up of the architecture. But the rewrite was not demanded by the community. Instead, it was the response of some in the community to funding that it had received to enable uPortal to integrate with Sakai, an open source Learning Management System that ostensibly would compete with Blackboard, the commercial leader in the space.

One seasoned community member told me the cautionary tale of how that happened, and what he learned from it.

At the time, uPortal 2 was really getting traction in terms of adoptions, use and community members investing in making it better. But the architecture really didn't easily allow it to integrate well with Sakai to be its portal -- a goal that the Sakai funders had in exchange for providing uPortal more funding.

The result was that the market for uPortal -- the uPortal 2 adopters -- were disconnected from the funding for uPortal's future. This gap could have been bridged, but it was a painful way to get there. I asked him why.

His take was that the community lacked the governance to marry the joint goals of innovation (funded by the Sakai project) and support for the customer base. By "governance" he meant the ability to set goals for the project as to how to use the funding provided to accomplish two seemingly divergent things: improve the software and transition the legacy stakeholders in the process. The new uPortal 3 does this, but it took a lot more time and money as a result.

I think that governance would resulted in a different roadmap -- one that better aligned the legacy and the future. But, in retrospect, it seems that there was another factor that has played in over the years: the world has changed. And that changing world included some important market forces that may have shifted the legacy uPortal adopters away from their old architecture.

The most notable market force may have been web 2.0, AJAX and the concept of mash-ups. Before web 2.0, portals were highly relevant as the integrator of the user experience. After web 2.0 got hot via MySpace, Facebook, Google and others, portals -- and the technology issues they thought were important -- seemed to fade in significance. As the director of portal initiatives myself, I started to wonder whether we needed to move to a new technology.

These conversations about the relevancy of portals were happening with uPortal folks, too. uPortal 2 couldn't handle AJAX -- the new web 2.0 user experience that allowed for a much richer web applicatino experience -- which put its future into question. And the original uPortal 3 could, but it couldn't easily enable uPortal 2 users to come along for the ride.

I think it was a combination of three things -- the leadership's recognition of the need to move to new technology, with the market impetus forcing legacy users to get with the times, as well as an innovative "Solomon's choice" of cleverly compromising the goals of uPortal 3 -- that resulted in this new uPortal 3, which has given the community a viable path forward. The proof of the pudding is still in the eating, as institutions are just now starting to migrate to uPortal 3. But I think most in the community sees the path forward. And because that path forward has uPortal 3 aligned with the industry's best technology practices, the future looks bright for both legacy users and newcomers to the community.

---

The lesson here for me is, "Money can't buy you love." uPortal 3 had the money, but not the love. uPortal 2 had the love of the community, but not the money to advance the platform. Thankfully for the community, something happened beyond them -- the success of web 2.0 -- that brought love and money together, eventually. If not for that outside influence, maybe uPortal 3 would never have seen the light of day.

As I think about other projects, I realize that the promise of getting them funded often makes people lose their heads. They lose sight of the whole equation that makes software innovation successful:

• The innovation must be funded (whether by cash or by sweat equity or whatever)
• It must solve a problem worthy of the investment in it
• When that worth is determined by adoption, the adoption must happen convincingly enough for momentum to build and be sustained
• The momentum is the result of solving enough people's problems at the right time so as to continually grow the base of adoption
• The timing of priorities is expressed in the product roadmap
• The roadmap must be a collaboration between what is desirable ("marketing") and what is possible ("engineering").
• The collaboration between marketing and engineering is the great challenge for successful technology innovation.

The "right roadmap," then, is a manifestation of the collaboration between marketing and engineering sensibilities. Sometimes that's embodied in a single individual. Usually, it's a partnership between close collaborators -- Jobs and Wozniak, Gates and Allen. Rarely is it the result of committee work -- not if it's innovation. Committees are fine for incrementally inching along something that is mature. But the kind of roadmapping that needs to happen for "love and money" to come together requires a creative spark and collaboration that is more organic.

Thankfully for uPortal, that spark and collaboration occurred amongst community leaders last year.

Hidden benefit of SaaS: Better investment psychology

A friend, who runs a software consultancy, and I were talking about Salesforce.com, its new Platform as a Service (PaaS) called Force.com and its Development as a Service (DaaS) environment called Apex.

I just came back from a "Tour de Force" seminar, and I must admit that I was slurping down the Kool-Aid. Salesforce has done a masterful job of implementing their CRM platform that can configured by anyone and programmed easily. I think of their concept as a 4GL for cloud computing. I know -- 4GL dates me. But there's not much new under the sun...

Anyway, my friend asked me why I thought Salesforce.com was more successful than Siebel, the dominant CRM platform for years that is sold primarily as licensed software. He described several Siebel implementations that were train wrecks, and he was curious as to whether I thought Salesforce.com would run into the same fate. After all, both are CRM platforms, and their designs (at least at the software object level) are not all that different. Yet, we have not heard of the same kinds of disastrous projects implemented using Salesforce.com.

After talking about it for a while, we stumbled upon an explanation for why there may be a disparity between Salesforce and Siebel -- a difference that has resulted in Salesforce's increasing success in the market.

The difference, I think, lies in what drives the cost of CRM initiatives, and the expectations that surround them.

To illustrate, let's consider two projects, each costing $10M over 3 years, with the following characteristics:

Project A

• Development life cycle: 18 months
• Time in use: 12 months
• Cost breakdown: $2.5M software license / maintenance; $5.0M customization and integration; $2.5M project management, requirements definition, etc.
• Number of users: 20,000

Project B

• Development life cycle: 6 months
• Time in use: 24 months
• Cost breakdown: $130/user/year; $0.250M customization and integration; $0.100 project management, requirements definition, etc.
• Number of users: Ramps up to 35,000 in year 3

Project A is a big project team working for a long time: at $150K/person-year, that brings the project in at about 50 person-years, about 15 person-years defining the system and managing the project, and another 35 person-years building and deploying it. That's a lot of time for a team to have on its hands. What kinds of expectations does one think there would be with that amount of resources? The temptation to add scope and complexity beyond the out-of-the-box solution is almost palpable. Sure the system can handle 20K users, but the real investment is in getting all the features the business can digest. Furthermore, the capital appropriation of $10M over 3 years means that we've paid for an asset, and most managers will expect that asset to have what they need from it -- again, irresistable urge for complexity.

Customizations and complexity increase project risk, however, so the failure rates of projects like Project A likely increase with the customizations and complexity -- driven by investor expectations of "value."

Project B, on the other hand, suggests about 2-3 person-years to make the project work. There are, then, much lower expectations regarding customizations and support for complexity beyond what the out-of-the-box package provides. Furthermore, the costs scale with the number of users, so the perception of value is per user. At $150 per user, there is not the same pressure or set of expectations as to what the software has to accomplish to deliver value to the organization. (In fact, more money is probably spent, per user, on training and effective use of the software than on the development and licensing / rental of the technology).

With lower customizations and complexity, the project risk for Project B would be substantially lower than for Project A that costs the same amount over 3 years. And, Project A folks, don't fool yourselves that the costs of Project A go down after year 3. If Project A succeeds, the next major version (including all those features that never made it into the solution) is just around the corner.

It would be nice to actually look at some data as to Siebel vs. Salesforce project success rates, but my friend's on-the-ground perspective seems to bear our this difference in outcomes. It is fascinating to me how the psychology of technology investing has so much to do with determining project success.

In any event, it seems that SaaS / PaaS / DaaS may have a hidden benefit to the sponsor of the initiative: by aligning investment cost with users, it may reduce the need for initiative sponsors to seek their returns in the investment in an asset (which investment, through complexity, increases risk).

The Epiphany

"I just had an epiphany!" remarked a friend of mine yesterday. What a great way to start the day. She had my attention. "Now I know what happened..."

Connie is a product marketing manager at a media company. Her job is to develop and bring to market media-based solutions for her specialty segment. She's incredibly bright, talented, hard-working and great to work with. Her colleagues are amazed at what she can get accomplished. But recently, she ran into challenges that seemed insurmountable.

Her last project was a the launch of a new technology product into a market segment where her company, a leader in the industry in general, has been trailing behind the leader of this segment, with a third of the leader's market share. Her hope was that this new technology product would launch the business forward to seriously cut into the market share gap she was facing. This product had the chance to be a blockbuster, a game-changer. And everyone knew it -- her president, her colleagues and even some of her competitors that got wind of the project. So, a lot was riding on this new product launch, and she was laser focused on its success.

Her company had committed to her that a new technology platform would be available for her new product, and that platform would have key features that distinguish it from the competition. Furthermore, she and her division president sat on the steering committee for this platform as it was being developed, to ensure that her product's needs would be reflected in the platform.

That was nearly two years ago. Recently, she sat frustrated at how things had played out with her high-profile project that was now struggling.

"Tell me about your epiphany," I said.

"Marketing and Engineering are like oil and water. I thought everyone was working together on the same team for the same goals. We had all of these great steering committee meetings, and they listened to all of my requirements for my new product. But when it came down to delivering what I needed into the market, they just couldn't do it. Their bosses were asking them to do things that were not aligned with my mission. It was like the whole world worked differently for them -- all the rules of what made the project successful for me seemed no longer to apply to them. And the frustration I am feeling right now is that our paths seem to have separated -- like oil and water."

I sat and listed to Connie's story, and I thought back to how many of them I have heard like this. But not just from the marketing people like Connie. I've also heard them from engineers like Mark.

"I thought this was a strategic initiative. I thought we had buy-in from the executives. I thought the business people had figured out where this thing was supposed to go and they had to be there as soon as possible. But now I can't get them to stick to a decision on any of the features of this platform. We were fine going into the final checkpoint, and now they're throwing everything up in the air again. We have 500 pages of requirements -- with their signatures signing off on them -- that we spent months hammering out. And now they're telling me that they can't launch with the features we have. It's maddening. I want to quit, and so does my team."

Oil and water. Sound familiar? It does to me. As someone who has been a product manager and an engineering manager and an executive and investor in new technology initiatives, I have lived in this oil-and-water world for several years. I have had my own epiphany, which is why I have started this blog.

My epiphany is that this situation is entirely predictable, and it is at the heart of most new ventures and new initiatives. Some learn to navigate it and some get smacked in the face by it. I'd like to explore what's going on, why it happens and what managers facing these kinds of challenges can do about them.

I've got to run. The morning commute beckons.