Tuesday, December 16, 2008

SaaS Customer Life cycle

Understanding the life cycle of a customer is a useful thing. Are there differences between and enterprise SaaS client and other models of software delivery? Yes I think there are.

The SaaS customer life cycle can be broken down into the following parts







There is nothing earth shattering about this diagram, but there are some significant differences between SaaS life cycle and installed software life cycle.

My goal is to cover each of these parts over the course of the next number of posts.

Thursday, December 4, 2008

SaaS, Security, Privacy and Compliance

If your target market is the enterprise for your SaaS offering it is highly likely you will need to deal with issues surrounding security, privacy and compliance. These issues will likely need to be addressed in the sales process and likely during implementation.

All three of these items are typically lumped together, but in fact are three different issues so let's try to untangle them.

Security is typically related to, well security. Seems obvious right? In most instances this is referencing mitigations against attack vectors that would put data at risk. This last part of this sentence is the crucial phrase. Clients, especially enterprise clients, are taking some level of risk by passing and/or hosting data at a 3rd party. This can be a significant barrier for adaption of SaaS technologies for many enterprise organizations. 

Enterprise clients are looking to ensure that there is proper mitigation in place for attack vectors related to an organizations infrastructure as well as the software itself. There will likely be some sort of Q & A which can be informal conversations, or formal artifact. Typically areas of questions can be broken out into physical and logical security. The physical security questions will likely be focused on access to machines, data centers, etc. The logical security questions will likely be focused on things such as protection for the edge of your network, controls between tiers, and data segmentation between clients, cross site scripting, SQL injections, etc.

Privacy is a different matter entirely. There is obviously a connection; data that is stolen is clearly no longer private, but data obtained through a breach is a security matter more than a privacy matter. Issues of privacy are primarily related to applications that handle some flavor of end user data (HR, CRM, web 2.0 applications, anything related to health care, etc) as well as how back-ups are handled. Clients /prospects are likely going to question what compensating controls are in place to ensure that an end user can control how their data is used, how end users are informed about data is used, and what mechanisms are in place to enforce those data control / access policies.

Compliance can be broken down into two distinct sets of compliance questions: one related to any / all regulatory oversight a client may be subjected to and therefore any vendor must comply with (the usual suspects include HIPPA, SOX, GLB, etc). 

Another category of compliance may be focused specifically on your organization. This may include such things as employee screening and training as well as internal controls and policies. There are some specific certifications an organization can seek to provide some assurances to prospects and clients, SAS-70 is one type certification, however these types of certifications can be costly and time consuming for a small or medium SaaS organization.

As organizations become more educated around the benefits of going with a SaaS solution the market grows, however that education comes with a price. Organizations are also understanding the risks associated with SaaS solutions. If your organization is focused on an enterprise space you should be prepared to address each of these issues. 

Wednesday, December 3, 2008

Project Management and SaaS, part 3

so this post has been fairly epic. If you missed this first two part they can be found here:

Project Management and SaaS, part 1

In the last post I discussed three ways to categorize client feedback during a SaaS implementation:
  • Trivial
  • Education Required
  • Non-trivial
For each of these types of feedback and organization needs to have a strategy with a plan and tools. Each request type may require a different tool and perhaps a different strategy.

Trivial requests, in theory, are the easiest ones to handle. An effective tool to manage this type of feedback can be specification documents, or other similar artifacts. For a SaaS organization these documents should capture configuration changes that collectively determine the functionality of our software as it has been designed to function. These artifacts act as a record of decisions that have been made to ensure that the software aligns with the stated business goals.
These artifacts should have a standard set of values based on best practices. These documents should be effective at capturing configurations that have already been anticipated and built into the application. Changes made to any of these decision points can be made with confidence that they will not cause unintended consequences or impact functionality or delivery time of the project.

I feel the need to once again stress that it is the job of the PM to carefully consider requests. If it is not known what the impact of the change might be it is best to consult with engineers / developers to confirm PRIOR to committing to a client that the task is trivial. A good rule of thumb is to consider any request / feedback not captured by a standard specification artifact as a non-trivial request.

Education Required requests are, well exactly that. The tool to assist with these requests is product documentation. The nature of product documentation for client education purposes is different than the type of documentation that the product development team uses while constructing the software.

It is sometimes difficult for individuals who are intimately familiar with the product to write effective client facing documentation. If there is an end user support group within the organization they are the most likely candidates to know what the most common types of stumbling blocks for end users are and should be used as a resource to ensure any / all product documentation covers as many potential requests as possible.

Non-Trivial requests are handled with a scoping document. The document is an artifact that can serve as the communication method between organizations and their clients, however it should be created only after consulting with internal resources. This will most likely include engineering, QA, and whatever additional relationship management staff are involved. If we accept the premise we started with (that tasks we have never attempted before are impossible to accurately estimate) it is crucial to communicate to clients that estimates are exactly that, a guess.

It is also important to develop internal guidelines as to what types / levels of non-trivial requests will be scoped. The effort involved with scoping should not be discounted when looking at resource allocation across an organization. These guidelines might include some broad criteria around what clients non-trivial requests will be accepted from at all. For example this could be determined by the size of the client, the dollar value of the relationship, the strategic value of a request, the impact of this request on the project calendar and budget, etc.

Clearly there is much more to discuss about project management as it relates to a SaaS delivery model but this particular post is already way too long so I'll wrap it up for now