Friday, November 7, 2008

Some random links

In an effort to break up the seemingly endless post on project management and SaaS here are a couple of links I have stumbled across recently you might find interesting:
  • Article at readwriteweb that is focused on the types of companies that are embracing SaaS and why. They also take a pass at reasoning as to why other organizations are resist
  • I was also recently made aware of an interesting paper published by a research team at IBM led by Jonathan Appavoo called Project Kittyhawk. The team theorizes that they could build the worlds computer. Yes a single computer that would be capable of powering the entire world; think the cloud that hosts the cloud. Interesting stuff. Perhaps the most interesting aspect of the idea would be the social / economic implications. Imagine if you or I could access the same infrastructure as Google....
  • And finally what would any SaaS conversation be without some mention to the King of all SaaS (would that be KoaS?), salesforce? Here is an article summarizing some recent news from the biggest player.

Tuesday, November 4, 2008

Project Management and SaaS, part 2

Let's start with an assumption: Things that you have never done before are impossible to accurately provide an effort estimate. We can propose an estimate based on past experiences and pad it by some measure and cross our fingers. This is one approach. Any exercise to measure our estimates against the actual time taken is simply a measure of our padding. If we find that we are routinely late in delivering, then all we have learned is that we should pad more.

I am not downplaying the value of that notion, but we should be careful to not accept that as having solved the real problem. We have only adjusted our stance to include more margins for unknowns.

This is not new. It does however point to an issue that is fundamentally different for a project that is building a software product from scratch versus implementing a SaaS product.

In theory an implementation of a SaaS product should contain easily known components, tasks that have been executed many times over, and concepts that have been thought about, mulled over and vetted. This is the expectation that drives us toward the idea of having a schedule that is knowable, defined and repeatable.

However here is where the trouble lies: How can you ensure that each deployment mimics the previous deployments?

Unfortunately this means fewer choices and/or completely unrealistic expectations around the ability for a client to turn around approvals when building the project plan.

An additional challenge is around customizations. When was the last time an enterprise client did not request some sort of modification?

In a SaaS model this becomes the conflict point that can make / break a deployment calendar. The key to managing this conflict point involves some framework around client feedback.

A client will likely provide feedback they deem appropriate and necessary to make the solution align with their ideas of what they need. Some of those modifications will be trivial (and we need to be extremely cautious of this word, as seemingly trivial requests are typically the ones that we end up in trouble over), some will be requests that require further education and some will be nontrivial, but the client can present a valid business case for the necessity of the modification. We should look at each of these cases individually:

  • Trivial: these changes can include such things as cosmetic changes, changes to field labels, etc. The trick with these requests is that requests that seem trivial may in fact have very far reaching implications to the way the product has been constructed. This is where the notion of the PM having some level of detail about how the product is constructed is crucial. There are occasions where simply changing the label of field is trivial, and other instances where the change of the label might have a functional impact. Without getting into a long tangent about subtleties of language and the nuances that inhabit our world suffice it to say that what clients think of as A, what the deployment team may see as B, and even more importantly the product team may have build like C. If the product is designed with SaaS at it’s core then the bulk of these requests from clients are simply configuration changes that can easily be accommodated.
  • Education required: These are tough ones to wrangle and they also frequently deal with issues of language. A client is requesting that the product accommodate X, but in a specific manner. The product may indeed already accommodate X, but in a slightly different manner. The more a client uses the product, the more education they have around the functions and abilities of the product the easier this set of requests is to handle. This will not happen organically. There needs to be a training aspect to any / all client delivery methodologies.
  • Non-Trivial: In some ways these requests are a little easier to deal with, which is not to say these requests do not have the largest potential project impact. In a SaaS model the answer to these requests is, well, no. An organization needs to have a feedback mechanism to the product team so that all of these types of requests can get back to the right people. These requests then need to be considered and either rejected or placed on the product road map. If the request is rejected then a solid justification should be provided. In either event this loop needs to be closed with the client. By providing responses to clients it provides credibility, even when the request was denied.
For each of these three types of requests the organization needs to have a strategy with a plan and tools. Each request will require a different tool and perhaps a different strategy. I’ll touch on that next post….