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.
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
No comments:
Post a Comment