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