SaaSmaster

SaaS Customer Life cycle - Contract Renewal

2009-04-06T23:11:00.010-04:00

This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about new releases here. This is the final installment in this series.

This final step in this series is crucial for all SaaS organizations. That is not to say that installed software companies aren't interested in renewing contracts, but the financial implications are slightly different. I have written about monthly recurring revenue (or more importantly contracted monthly recurring revenue) in previous posts. This is one of the key measurements of a SaaS organization's health and worth. If there are investors this is one of the key numbers they will likely focus on. If your organization is looking to take on investors this is a key number they will likely focus on. Did I mention this is an important number?

Hopefully contract renewal was an issue that was addressed during the sales process. The initial contract certainly included terms like price and length of contract, but hopefully also included language around how the renewal process will work. There is a balancing act to walk here in that obviously the longer the contract the better for the organization providing the software, however enterprise clients may resist lengthy contracts, especially if they are still new to the SaaS concept.

The flip side of a lengthy contract is that it will likely also lock in pricing to some degree during the term and subsequent renewals. It doesn't really matter what your pricing model is: a per seat basis, a feature basis, or some other model the contract price will likely be allowed to increase some set amount with each subsequent contract renewal or calendar year. This means that a client who is an early adopter of your services may end up with a very modest increase in their fees if they continue to renew for a long period, say an additional two, three or four contract terms. This may or may not be a big deal, however it is one that should be entered into with eyes open.

Since this blog is focused on SaaS for the enterprise I would be remiss if I didn't mention procurement. It is likely that at renewal time there will be a formal procurement process that is invoked. It is important to understand this process as much as possible and rely on your internal champions within the client to help guide this process. Many enterprise organizations have a procurement process that runs in cycles, say every 2 or 3 years, so if you have a one year contract with the option to renew at annual intervals it is important to understand how that will work. If you are lucky it might mean no formal procurement process until the next cycle or until the contract dollar amount hits a certain threshold.

One way that you can help your internal champions make the case for contract renewal is to ensure that there are tangible numbers that can be referenced when speaking to budget holders. This falls into the best practices / relationship management category but helping the internal units who are using your software build a case with metrics that are legitimate and easy to understand should help make the renewal process smoother and more likely.

There shouldn't be any surprises about whether a client is or isn't going to renew their contract. Speaking with clients about contract renewal well in advance is to everyone's benefit. The more transparent the process the better it will be for all involved. If there are issue with the product offering, or issues with service levels, etc the sooner they can be addressed the easier it will be to ensure contracts get renewed.

I would also strongly encourage internal teams to be transparent and honest when looking at contract renewals. This should also follow into the revenue projection and budget process. If a large client is unlikely to renew then having a revenue plan and budget impact if they choose to renew as well as if they choose not to renew is a worth while exercise. This also helps set internal expectations and a better informed internal leadership team. If your organization has investors or board oversight transparency around contract renewals is crucial for honest communication about the financial well being of the organization, as well as for where budgets might need to be adjusted to fit new goals (say increased client retention or ability to increase billing by rolling out new features on a more frequent basis for example).

Clearly this series of posts is far from exhaustive in relation to SaaS customer life cycle. I will follow up on some of the concepts presented in this series of posts over the upcoming months.

SaaS Customer Life cycle - New Release

2009-02-09T11:47:00.044-05:00

This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about going live here.

So at this point client is up and running, let's assume they are wildly successful and the relationship is going well. As the account management team (or whatever language your organization uses to describe this function) has been focused on sharing best practices and hitting all metrics the product team has been busily hammering out the latest version of the product.

Product Management and Product Development are discrete functions that are separate from managing implementations and relationships. This probably sounds like another obvious statement, but worth making. As tasks related to the core product require a different skill set than deploying and managing clients it is likely they are different teams within an organization. I am planning some future posts on both of these topics so I'll follow up on this thread later.

The challenges associated with pushing this latest version begin at the most seemingly innocuous place: What is this called? Is this an upgrade? Is this a migration? a push? some other word?

Upgrade and migration will typically trigger a whole host of associations for enterprise clients. Many of those associations are not pleasant ones, remember many enterprises are likely to still be involved with installed software. Think about the pain and costs associated with a migration or upgrade of some large installed software product, such as an ERP or HR system, especially if the system has been customized in any way (which is likely).

In addition to the possible negative associations words like upgrade and migration are likely to have, many enterprises are also likely to have a number of internal processes and procedures that are invoked once these terms enter the conversation. Some of the possible events that an upgrade or migration might trigger could include another round of UAT, additional security tests, and possibly having procurement getting involved if there are any costs associated. Ideally this issue will have been addressed during the sales cycle and also covered at the end of any implementation cycle, however it is pretty likely that the people involved in those cycles are either no longer attached to this project or have completely forgotten what was said during earlier phases.

All that being said there are three major aspects of all upgrades / migrations:

Client facing communication
Production migration for code, and I'll lump DB into this category
Production migration for infrastructure.

Each of these should be considered carefully with a detailed plan that is shared between all parts of the organization.

Client facing communication is seemingly straight forward, but the decision to communicate at all to clients is one that will likely come up internally, especially If many / most / all of the product changes are focused on items that clients would never know about (say security upgrades, or changes to the way the application handles requests, or communicates between layers, etc).

In those instances it is theoretically possible that a client would never know. It could be tempting to simply perform these upgrades without any notification to clients. I would say this a mistake. Long term relationships with clients are built and trust and trust requires transparency. The possible downside of communicating to clients far outweighs the risks of not communicating. If something were to go wrong during the process that impacted uptime, or any other metric, you would then be forced to communicate to clients that something went wrong while upgrading. This would certainly not contribute to an atmosphere of trust and partnership.

Clearly any significant new release that would impact end users in any way must be communicated to all clients and are subject to all the same concerns.

The specifics of what exactly to include in client facing communications and the tone will vary from release to release. It is a bit of a tight rope act. The goal is to help clients understand what is coming, all the great new stuff that is included and how it makes their lives (and programs) more successful. This is the true power of SaaS. At the same time by making a release seem like too much of a big deal can generate concern and/or any of the issues mentioned previously. Most enterprise clients are risk averse by nature so that is important to keep in mind.

The communication should go out with plenty of time for clients to absorb and ask questions and have the majority of their fears / concerns addressed. If your release cycle is once a quarter client facing communication is one of the things that could be a challenge.

The specifics of a release will need to be locked down and guaranteed to be included if they are to be communicated to clients. In many cases this may not be known until all coding and internal QA has been completed. If clients need time to absorb release information then an organization needs to set some specific internal policies around completed QA. For example if it is determined that clients need 2 weeks to absorb release information and ask questions and internal teams need one week to draft and finalize client facing communications that means the product team should have a milestone that says 3 weeks prior to live all features should be through QA and a determination as to the status (in or out for this release) needs to be made. This is a pretty tight schedule for a quarterly release timeline.

Production migration for code varies depending upon what stage of maturity of their SaaS offering. If there are multiple client instances running different code bases then that strategy would need to be different than singe instance of code for all clients. It seems most likely that most SaaS organizations are somewhere in between with multiple instances of clients running the same code base. Running through some test migrations in a development or QA environment should be considered a necessary milestone prior to any production changes. The product team would be well served by engaging with the implementation teams to determine what would be the best candidates for testing (which implementations are the simplest? Which are the most complex? Which have the largest user population, etc are all questions that can help find the right implementations for testing).

A cautionary note here: No matter how diligent any development team is about ensuring dev and/or QA mimics production as closely as possible there are likely differences. These can be seemingly small (say slightly different versions of an application server or lack of monitoring software) to large (say no clustering or load balancing in dev / QA). These differences, even the small ones, can lead to failure once code is moved to production.

Up to date and quality documentation of the production environment as well as dev and QA environment can help here, however it is rarely done. This kind of documentation is boring and dull. No one want to actually sit down and write this documentation, even fewer people are willing to keep it up to date. A good policy is to add a formal step to any production change procedure to update the production documentation. This at least increases the chance that production will be properly documented.

It is also important that all hands are on deck for production pushes. This should include the QA and dev team as well as the implementation teams and client services teams. Frequently the people who deal with specific client implementation on a daily basis are best positioned to know the most crucial things to check. Don't underestimate the value of those additional eyes and make sure there is a clear process for those people to report any issues they uncover as quickly as possible.

Production migration for infrastructure is related but slightly different than migrating code. A natural tendency is to try to link changes to infrastructure to an upgrade window for all the application code. I would argue this is a bad idea, unless the new infrastructure is tied to the new code specifically. This introduces another variable into the process that exponentially increases the effort required to troubleshoot any issues that might arise. Ideally an organizations standard contract will include some sort of monthly maintenance window. It would be best to confine infrastructure changes to those windows as much as possible.

So this post turned into a much longer one than I initially thought. I should have probably broken it up into two parts. There is clearly more to say about this specific stage of a SaaS customer life cycle and I will try to expand upon these ideas in future posts. If you are still reading then kudos to you.

SaaS Customer Life cycle - Live

2009-02-07T16:34:00.016-05:00

This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about implementation is here.

At this point some measure of congratulations are in order, right? The customer has moved from a prospect to signed contract and through implementation. The client is live. This is a significant milestone.

An important factor is that all monthly recurring revenue can now begin billing. It also means that all implementation costs (assuming there are any) can be billed, this does not mean that all implementation costs can be recognized in the month the client goes live. According to current accounting principles for SaaS organizations all implementation costs must be spread out over the first year of the contract. This is a fairly important item to make note of, especially when working on revenue projections and budgets. While it doesn't really need to be said, I will say it anyway: The faster you can get a client launched and live the better for everyone.

Aside from the financial considerations of going live, there is another important issue to keep focused on at this milestone. The hard work of building a strong relationship with all clients (to ensure they continue to choose your organization as their vendor of choice in the future) begins. All enterprise organizations will require departments to provide a cost justification of all contracts, especially in these tough economic times.

As a means to that end it is important to have developed best practices (previous post on this topic here.) to ensure that clients are succeeding and growing. This should include metrics. Since clients are looking to SaaS vendors in large part for their domain expertise in addition to access to their products this means that SaaS vendors need to take an active role in setting metrics for clients.

Part of the role of a SaaS vendor is to not only help clients succeed, but to help clients prove that success internally. One thing that all enterprise organizations can understand are clear metrics to indicate that a specific contract is worth keeping and continuing in the future. Ideally these metrics include some hard numbers in addition to any soft numbers (items such as increased awareness, brand improvement, morale boost, etc). Ideally all metrics that can be generated from within an organization's solution will be calculated and delivered directly to clients in some automated fashion. Monthly is the most common time period for these sorts of metric reports.

The less work any given client administrator or internal champion at the client has to do in order to put together a solid business case for your contract the better off you will be. This is not because anyone at a client is lazy, but more likely they are tasked with a number of other responsibilities. The more you can make program administrators and other champions within your client's organization look like a rock star, the better for everyone.

While going live is certainly something to celebrate, it should be looked at as the start of some more hard work.

SaaS Customer Life cycle - Implementation

2009-02-05T16:57:00.008-05:00

This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about contracts here.

This post will focus on implementation. I won't delve into methodology this pass ( I have covered this in more detail here. It doesn't matter whether you have a 2 hour implementation or a 6 month implementation is dependent on a number of factors:

The simplicity of the business problem being solved
The maturity of the solution
The input / decisions required by clients.
Expectations of product that have been misunderstood during the sales cycle.

Nothing earth shattering or particularly revealing on that list, but I want to spend a couple of moments to go a bit deeper into each of those items.

The simplicity of the business problem being solved will impact the length of your deployment time. Note I did not say the simplicity of your solution. You may have a complex solution to a simple problem, however hopefully that complexity is all under the hood and doesn't need to be exposed to any implementation team. It is always easier to use examples, so for example if your software is geared to helping an enterprise simply track the number of hits to a specific page this is a fairly simple business problem. Now consider a suite of software that handles ERP. These two examples are vastly different in the scope of the problems they are solving. I would expect the implementation time for the ERP system to be significantly longer. As the trend is for software to become more and more feature laden it would stand to reason that software complexity will only continue to increase. This is not necessarily an encourage trend in terms of implementation times for SaaS solutions, however simplicity / complexity is not the only factor.

The maturity of any given product will impact deployment. In theory the more mature the product the more experienced the implementation teams and the more time the product and development teams have had to address any technology challenges related to implementations. There are some notable exceptions. As products mature they tend to add to the feature set, which again invokes the issues mentioned above. On the whole a more mature SaaS solution should be faster to implement than a less mature solution in the same space solving the same problems.

The input required by clients will most likely have the greatest impact on implementation times. As the focus of this blog is on the enterprise it needs to be acknowledged that many enterprise clients have a culture where people who make "bad" decisions are frequently punished. This leads to a culture where people are sometimes afraid of making decisions, or to a culture where there are multiple people are required to sign off any decisions. This is very likely to be the primary cause of delays in implementations. The best way to mitigate this challenge is to have the fewest number of client inputs as required and try to gather as much information as possible during the sales process.

The final item listed has the potential to be the biggest challenge to implementation. No matter how clear you think you are being during the sales cycle it is still possible that what a client hears isn't exactly what you meant (let's assume the best intentions for both the sales teams and the clients). When these sorts of mismatched expectations occur it will almost always require escalation to more senior resources on both sides. Once that has occurred it is highly likely that delays will occur but more importantly confidence will begin to erode. This is the most detrimental part for establishing a long term relationship. In a perfect world this would never happen, but alas sometimes it does. One strategy that seems to be effective at minimizing these sorts of issues is to have a member of the implementation team present at the appropriate point in the sales cycle. Ideally it would be the same implementation team member who will be responsible for that client's implementation. This helps avoid the he said she said that these kinds of miscommunications can sometimes turn into. Clearly if the implementation time for your solution is only a day it's less of an issue, but if it is longer it is worth considering integrating implementation with some part of the sales process.

While some or all of these may be factors in any given implementation process the faster an organization can implement their solution the better. This will allow you to get to the all important revenue recognition as soon as possible.

SaaS Customer Life cycle - Contract

2009-01-27T12:52:00.008-05:00

This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about pre-sales can be found here.

This post will focus on SaaS contracts. I feel like I have covered this ground in previous posts but in the effort to cover the entire life cycle of a client I will spend a little time on this topic again.

In the best case scenario any topics of discussion or concern will have been addressed during the pre-sales process so that contracts become a formality. In reality it seldom works this way. As this blog is focused on SaaS for the enterprise we should keep in mind that the notion of an adhesion contract that a client will just sign doesn't apply. There will be some level of negotiation for every contract, at least in my experience. The negotiation can sometimes start with which parties standard contract language gets used.

No matter what boilerplate contract gets used there are a few things that should be spelled out clearly.

How upgrades / migrations are handled.
Who owns what data
Pricing model, including any custom requests if such thing even applies
Scope of work, as much as possible without getting bogged down into specifics
Clearly spell out any / all SLAs and how reporting on those SLAs will be handled
What browsers, technology your application will support. Avoid specifics like IE 7 is also advisable. The language could be something more generic like "the latest stable release of IE" or "the most common 3 browsers on Windows".

Here is a short list of things that I would suggest NOT putting into contract language.

Any specifics of the technical solution. I have found that many large firms like adding this language, it provides some sort of comfort to lawyers in some way. The truth of the matter is that adding the specifics (think what DB server, or presentation layer technology, etc) in a contract can lead to potential issues if/when those technologies change. My advice, just leave it out if possible
Code escrow agreements. I have written on this in the past (see post here) and the honest answer is that even if a company goes out of business having source code is useless to the client. If a customer insists on such a term then clearly spell out it is the responsibility of the client to bear those costs and agree to a specific calendar time that the code will be updated.

There is obviously much more to contracts. I am not a lawyer and so I won't even bother trying to cover all the other stuff (liability, etc etc etc) as it lies beyond my subject matter expertise.

The most important thing is that the contract language matches the information what has been delivered during the sales process. The next team to follow shouldn't be hindered by contract language. Contracts are another tool to help set expectations with clients.

SaaS Customer Life cycle - Pre-sales

2009-01-05T10:39:00.006-05:00

Let me start by saying sales is certainly not my area of expertise. I couldn't do what sales does. I couldn't convert a lead to a prospect if my job depended on it, and I am certainly not the person who is going to come in and make sure a deal is closed.

I have spent plenty of time doing pre-sales support, and that is what I will focus on in this post.

I am going to state what seems like it should be obvious:

The sales team should understand what SaaS means. The sales team should be able to not only understand what it means but also how to communicate the value proposition to prospective clients, at least at a high level.

The technical sales support is crucial. Enterprise clients are becoming increasingly familiar with SaaS. This increase in familiarity is both good and bad. The good news is that as the SaaS delivery method matures prospects are not in the situation of needing to be convinced SaaS is valuable or viable. The bad news is that the types of questions that you are likely to face seem to be more focused.

Any technical pre-sales support should be ready to explain basic architecture (both network and application) as well as security and privacy issues. It would be helpful to be able to explain how the upgrade or migration process works once a client is up and running. This may go hand in hand with questions about product road map and the methodology your organization uses to develop and share that road map.

A mature SaaS organization can use the pre-sales period to distance themselves from less mature competition. This can be a significant differentiation point. An important part of Software as a Service is the service part. If an organization has an advantage in that area it should be something that prospects understand.

This period is also the time to set expectations with a prospect. This can make all the difference for the relationship and the teams that follow after signature.

Things to be clear about during the sales cycle should include implementations (how long, what is required from client, cost, etc) as well as how migrations or upgrades will work moving forward.

Any ambiguities about implementation and/or future upgrades will likely lead to incorrect expectations. This can damage a relationship right from the start if there are significant relationship challenges around deployment.

If both of these issues can be clearly communicated and expectations set correctly then the relationship has a much better chance of turning into a positive long term relationship.

SaaS Customer Life cycle

2008-12-16T14:02:00.014-05:00

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.

SaaS, Security, Privacy and Compliance

2008-12-04T13:25:00.014-05:00

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.

Project Management and SaaS, part 3

2008-12-03T11:14:00.005-05:00

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

Project Management and SaaS, part 2

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

Some random links

2008-11-07T10:03:00.005-05:00

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.

Project Management and SaaS, part 2

2008-11-04T11:25:00.008-05:00

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….

Project Management and SaaS, part 1

2008-10-28T16:10:00.012-04:00

There are a glut of IT Project Management methodologies in the world. In fact there are even publications that focus solely on comparative project management methodologies. The majority of those methodologies are focused on a project life cycle as it relates to either custom software development or some other blue sky / green field type project .

Is there a difference between a development project for any custom system or large integration project and a Software as a Service deployment?

On the most basic level the answer is most likely no. Virtually all of the same fundamental issues, concerns and strategies are the same. The goals are certainly the same: deliver the project on time, on budget to a happy client.

The principles governing the success or failure of both types of projects are subject to all the same conditions: time, scope and budget. The pitfalls are certainly similar: clear definition of business goals and what constitutes success, scope creep, managing expectations, gathering complete business requirements, finding the right stake holders to provide input for those requirements and having strong senior backing to ensure project success (among others).

There are however some small differences, and those small differences can have a big impact on the efficacy of a project manager and the delivery of a successful project. This is an attempt to identify some of those differences and provide some strategies and tools to mitigate the risks they present.

While the range of projects that encompass the IT industry as varied and vast a large majority of the work that project managers are involved with are not projects involving brand new products. Many projects involve working within the confines of a system that has already been defined and constructed in some manner. This is especially true of organizations with Software as a Service business model.

As with any organization there are different types of projects that managers will need to be involved with. These might include: initial deployment for new clients, ongoing support requests, ongoing requests for customizations and upgrades. This conversation will focus on initial deployment for new clients, however it is important to keep all of the additional project types in mind, especially the upgrade, while rolling out the initial deployment.

At the end of the day all project managers and all project management methodologies have the same goals and intentions.

Limitations of Project Management when dealing with Software as a Service

Unlike a project that begins with a clean slate and blue sky all projects in a SaaS model will begin with a majority of the systems functionality defined. This may include things like data model, business logic, user interfaces.

While this may seem obvious the importance of this cannot be overstated. It is crucial that project managers understand the core functionality as thoroughly as possible. This does not mean that the project manager needs to have the same level of technical detail as the system developers do, however knowing as much as possible provides the project manager credibility with the client.

The PM at a SaaS vendor involves a combination of subject matter expert, client services and project management (with a small percentage of sales throw in for good measure).

Understanding the high level business objects is crucial in every project, however in SaaS the PM needs to be able to present lucid and valid business value propositions when any deviation from the standard product configuration is encountered. Education is the key, and the earlier and more comprehensive the education process can be the more efficient the process will be.

It is the PM's role to understand the business need from the client and demonstrate how that business need is address with the standard product functionality.

This may not be an easy task as frequently clients will not be able to separate the process used internally to accomplish a specific business objective with the objective itself. A large part of this process is educating clients about the core capabilities of the product.

The level of configuration that is available for a client varies depending on the organization's maturity level. The more mature the organization the more configurable the product may be, however there will be less flexibility to introduce customized features. Additionally the more mature an organization is the longer the cycle to add new feature to the product.

It is important to remember that unlike many software projects the SaaS client implementation is specifically designed to be upgraded in the relatively near future. Any customization for a specific client that is not incorporated into the code base for every client will likely present a barrier when the organization moves to the next version of the software.

Working with restrictions involved with SaaS, requirements gathering largely becomes an exercise in gap analysis. Where are the true differences between what a specific client needs to make their program a success that all of your other clients do not? If the product / organization is mature those gaps should become increasingly small.

There are of course exceptions. One exception might be a client that operates in an industry that has never used the product before. When deploying these clients an important factor to consider is how representative is this client for their industry? For example are business requirements being driven by government regulations that would apply to every organization in that industry or are they being driven by specific corporate mandates?

If one of the organization's goals is to attract more clients from this industry investment in implementing new features might be worth developing, however any schedule would need to be adjusted to ensure that proper QA time is being incorporated for new features.

up next time, how to handle feedback from client, further discussions around customizations and other random thoughts...

How the Service part of SaaS can help out in troubled economic times (say like now for instance).

2008-10-16T12:59:00.010-04:00

So as the pool of money organizations has to spend on external programs shrinks does this have an impact on SaaS providers?

The honest short answer is, of course it does. However with lower initial costs and quicker times to deployment SaaS solutions also begin to look attractive as compared with installed software solutions (there is an advantage to a SaaS solution), however lower spending means fewer new opportunities.

The big challenge for a SaaS organization revolves around the ability to quickly recognize contracted recurring monthly revenues. This means the sooner you can move from contract signature to deployed solution the better.

What are the barriers to a quick deployment? There are the internal barriers for any SaaS provider; things like how long can you actually roll something out? Does it take a team 6 months of work, or can you roll out a solution to production in a matter of days? These factors are entirely within the control of the provider.

In my experience some of the biggest barriers to launch (the key milestone to recognize revenues) are clients, especially in the enterprise space. The more dependent upon a client your deployment process is, the longer it will take. That is a pretty straight forward equation. This seems to be easily solved by limiting the number of decisions clients need to make, however as each product offering becomes increasingly complex the number of decision points increases.

This is where the Services part of Software as a Service can come into play. Having a set of well defined best practices around configuration of your product is crucial to shortening deployment times. These best practices need to be well documented, and backed up with demonstrable experiences (i.e. stats, research, metrics, etc).

All of your best practices needs to be able to tie back to the specific business goals the client has purchased your product in order to attain. If your product can address multiple business goals then you need multiple sets of documented best practices and all client facing deployment teams need to be confident they know and understand them and all the nuances that entails.

Large enterprises are used to being able to dictate requirements, however in a SaaS model that flexibility doesn't necessarily exist. Large enterprises also can get stuck being focused on minutiae and lose sight of the larger goals. It is the job of the services team to keep clients focused on the larger business goals to stay on target for the quickest possible deployment.

That is an easy statement to type, harder to realize. I recognize that, but the services side of the Software as a Service is a crucial component that should help ensure that time to recognize that monthly recurring revenue decreases. Documented best practices is often a tool that is overlooked and underutilized.

Formal UAT thoughts

2008-09-12T17:19:00.009-04:00

If you have spent any time with enterprise clients you know there are a number of things that are inherent in the process of rolling out a 3rd party hosted technology solution. These can range from the relatively minor challenges like the numerous approvals required for seemingly mundane items that add to the project calendar to more fundamental challenges, like formal user acceptance testing.

The requirement for formal UAT is one that puts enterprise clients directly at odds with SaaS. If a client insists on running formal UAT for every new release before it goes live this puts a significant burden on the vendor to support this requirement.

A formal UAT process involves creating test plans and test cases and standing up a test environment to perform the actual tests. Even if a client has a vetted set of test cases for regression testing, there will be new features that require creating new test cases.

In theory the 3rd party vendor can simply send over the test cases that have been developed in house to the client, and in fact many clients may ask for such cases. I am personally skeptical of the value here. If the vendor is sending over the test cases and the goal of UAT is to provide a legitimate independent certification that the application is functioning correctly then those two things seems to be at odds with each other, no?

The truth of the matter is that in many instances internal resources at large organizations are overwhelmed with the amount of work they need to accomplish. Having the vendor send over the test cases saves them a significant amount of work.

Creation of test cases aside the process to execute a formal UAT cycle with an enterprise client can easily take 4 - 12 weeks, depending on the size of the project.

If a SaaS organization has a release cycle of once a quarter the UAT effort is one that will never end, and will add to the overhead of any SaaS organization. This means resources in terms of relationship management staff, project management staff as well as possibly other technical resources, and this is just the effort to handle the UAT portion of a migration to a new code base.

This is a potentially significant hidden cost to the client. It is one that is rarely discussed when an organization is considering the total cost of ownership with any SaaS solution.

None of this should be taken as saying that formal UAT is not valid, or has no place for an enterprise organization with a SaaS vendor, but carefully spelling out what the impact of such requirements can / will be moving forward is crucial. The right spot to address this is pre-sales of course, but that rarely happens as this conversation is too detailed for a sales cycle.

Setting some threshold at which a formal UAT would need to occur could also help. For example no formal UAT required for small incremental releases, but for all major releases some version of UAT.

Finally there has to be some level of trust between the enterprise client and vendor. This trust can only come with a history of successful migrations to the latest version of the code that occur without incident. This can only come with time.

SaaS market to collapse in 2 years

2008-09-12T10:54:00.001-04:00

I am always willing to read ideas that contradict my own.

Here is an interesting interview with Harry Debes, CEO of Lawson software. I don't think I agree with much of what he is saying, but worth reading.

Time will tell if he is right, and two years go by really quickly.

Chrome and the enterprise

2008-09-08T09:28:00.005-04:00

I have run across a number of posts lately that are touting how Chrome will change the browser landscape. This may very well be true, however I just cannot see how any enterprise will really start allowing their employees to this browser officially.

Just a point of reference: most of the clients we deal with on a regular basis are still officially using IE 6 as their corporate browser. Enterprise IT approvals move slowly. As frustrating as this may seem it is for good reason. These departments are responsible for the stability and safety of the corporation's infrastructure (and all of the assest that represents). While moving slowly cuts into the ability for an organization to react quickly it also means that things are stable. If I am in charge of the infrastructure at a large enterprise I will value stability at the cost of agility in most instances.

There a number of posts I have seen lately that are excited about Chrome as it relates to SaaS, try this one for instance. I just can't see how any privacy / compliance manager at any enterprise organization will allow their employees to use Chrome, if for no other reason than all the instances where Chrome is sending browsing information back to Google. Read the privacy policy and the EULA carefully.

Let's not even mention the potential security holes.

I just cannot see how any enterprise will embrace Chrome. I am not the only one who sees things this way. Dennis Howlett at ZDNet has a good post that aligns with our exeperience in the real world here.

upgrades and contracts

2008-09-03T09:59:00.004-04:00

I have been spending a fair amount of time lately thinking about contracts. If you are delivering a SaaS solution to the enterprise there are a number of challenges that exist that aren't there when you are delivering a consumer service. That statement seems obvious enough, right?

The essential challenge is around how to provide protection / assurances to normally risk averse organizations (the Fortune 100 set) around upgrades and yet ensure your organization is not stuck supporting old code bases indefinately.

I started writing a post about some of the nuances, but it quickly became too long for even me to remain intersted.

I think ulitimately the best answer to ensure your client base wants to upgrade. This can only be accomplished by continuing to provide the right features, the right enhancements so that clients are excited about upgrading.

Ultimately if you can't make that happen and you are reliant upon a contract clause to force a client to accept the latest version of the code you have a much larger relationship issue. Those issues aren't going to be fixed by any contract clause.

Why Code Escrow provides no protection

2008-08-18T01:30:00.006-04:00

Escrow provides little to no protection for a client. There I said it.

The reasons for this are numerous, however here are a couple of the main reasons:

1.) If the company providing the service does default in some way and the customer receives the code in escrow there is very little chance they will have the ability to re-create that application. I realize in a perfect world the code would be so perfectly documented that anyone could re-constitute that application, however that just isn't the case. No matter how diligent and well meaning a development staff may be there is still so much knowledge that is institutionalized and not in any documentation that it would be impossible to simply take that escrow code and make it work

2.) Even if the code was perfectly documented it is unlikely the infrastructure is. As web-based applications become more complex, the ties to infrastructure become specific. Even if the client knew much about the particulars (for example what web server, application servers, OS, DB, framework, etc) the work effort to recreate it exactly would be far from cost-effective

3.) In a SaaS model the escrow code is most likely outdated by the time an customer would need to re-constitute anyway. In a perfect world this would also not be the case, but in reality this is just the truth.

I could go on, but you get the idea. What an educated client really cares about is the data, or at least what an educated client should care about. If the customer owns the data, and receives it on a regular interval they stand the best chance of protecting themselves in the event an escrow clause would need to be invoked.

If a customer has their data they can either move to a competitor more easily, or evaluate what the work effort to internally build the application. In all likelihood the best choice would be to move to a competitor. If the customer were moving from one SaaS solution to another that work could most likely be leveraged across multiple clients for the new vendor, and as such the effort wouldn't be "one-time" work for the new vendor, if it wasn't done for a previous client already..

That provides protection for the client, but also the mechanism that most likely will get them up and running as soon as possible.

If the ultimate goal is to provide some level of protection, code escrow just isn't going to do it. If your SaaS vendor doesn't have a mechanism in place for a customer to get their data on a regular schedule through some process (self-serve, asynchronous or synchronous data transfer) then choose another vendor.

"Delivery over the Internet"

2008-04-26T18:20:00.004-04:00

One of the key concepts of SaaS is that the application is "delivered over the internet".

This seems simple enough, however there are some significant talking points hidden in that sentence. This is not boxed software that is purchased at some retail outlet, in fact this means the only way to purchase this software at all is through whatever sales channel the SaaS organization has set up. In most instances this means directly from the organization that has produced the software.

Another challenge is licensing and pricing. Unlike boxed software that can be controlled with required serial numbers it is not possible to limit. This poses challenges to an organization to secure their IP. There is also additional risk assumed by the organization in terms of having confidential information for users.

The primary means of limiting use/controlling access to features, etc is through the application of roles and privileges. This requires users to log into the application which now necessitates the need for the application to store that information in some way. This also means that it is possible for the application to track usage and behavior patterns which boxed software companies would normally not have access to. What additional legal / moral / ethical obligations does that entail?

Another factor around delivery over the internet and that is around performance. As a company cannot be responsible for performance of any of the vat network that makes up the total access to the application it is impossible for an organization to truly control any performance related issues and end user may have.

The final thought is around security. Any application that is delivered via the internet must contend with all the security issues that entails.

SaaS Defined

2008-04-26T17:53:00.002-04:00

I am the SaaS Master. This is tongue in cheek of course, however there is an awful lot of discussion lately around the notion that SaaS is taking over the world. I am endeavoring to define what exactly SaaS means. This seems like a reasonable starting point.

This definition is from wikipedia:

"Software as a service (SaaS) is a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a a third-party) the application for use by its customers over the Internet. Customers do not pay for owning the software itself but rather for using it. They use it through an API accessible over the Web and often written using Web Service or REST. The term SaaS has become the industry preferred term, generally replacing the earlier terms Application Service Provider (ASP) and On-Demand."

This sounds simple enough, although I have some doubts around the issue of Web Service / REST as requisite to be considered SaaS but I will leave these doubts aside for the moment. I don't have any doubt that to be a successful SaaS organization this would be required, but to make this part of the definition seems to be limiting.

The key concepts here are the delivery over the internet, developed and hosted by a vendor, possibly some ability for the application to be extended in some manner using APIs and the notion of a fee to access the application as opposed to a one time cost to own a copy.

What I think it interesting is that the ASP term is being used in a manner that indicates it is interchangeable with SaaS. I am not so convinced that is true.

Over the next few posts I want to explore how each of those key concepts actually work as well as the differences between SaaS and an ASP organization.