My Life in an Enterprise Software Startup!

Kanban and the Focus on Fundamentals

singhmahesh — Tue, 27 Sep 2011 11:00:30 +0000

Our Kanban journey began early in 2010 when we decided that we would build a product in the Kanban space that would address some of the basic issues we saw our prospects face in adoption of Agile methods such as Scrum and XP within their organizations that were historically used to doing waterfall or iterative or some hybrid Agile method that combined more than one type of processes.

While the presence of established competitors was a strong reason to look beyond the ‘popular’ Agile methods, we also felt a strong appeal for Kanban existed because of its focus on 3 key fundamentals:

Evolutionary change
Improvement of existing processes
Engineering rather than Management processes

We have seen numerous organizations and teams take on large (revolutionary) process improvement initiatives – be it 6-Sigma or CMMi or even Agile. We have seen them become consumed with “the task of process improvement” over and over again. As a result, while there is improvement in the interim, in terms of consistency with which a process is followed in the team or the organization, the overall magnitude in terms of the time, effort and cost, of making the transition becomes huge and management begins to question the benefits! Kanban, with its promise of evolutionary change, with one stroke, takes care of this fundamental issue. It allows teams to take on only those aspects of change that they can comfortably handle.

Secondly, with an evolutionary approach, Kanban necessarily tackles current processes in an organization and helps improve them, rather than force a range of new processes on it. This is fundamental to understanding how Kanban can be applied not just to traditional software processes – but also to popular Agile processes such as Scrum and indeed, to non-software processes – bet they within IT or in general business functions such as Sales or Marketing or Legal! So besides being attractive to software teams, their pull for non-software teams, presented us with a much bigger opportunity, which we are already starting to see materialize!

However, the one aspect of Kanban that excites more than others is that it forces teams to focus on the “engineering” or the “delivery” processes rather than the “management” processes. This is where, I feel, Kanban truly distinguishes itself from its ‘competitors’, if one may terms them as that. Through the use of statistical control charts, Kanban helps teams identify their normal performance and their deviations from the normal – the outliers. Rather than advise teams to simply do better documentation or better management or better reviews, it encourages teams to do better root-cause analysis – and attack root causes for poor performance – be that better or more specific testing, better development or design practices or better collaboration and requirements elicitation from customers. And in doing so, I believe Kanban shows itself to be far more effective than any other framework to start making incremental, lasting improvements in the final quality of the product or service being delivered.

Far too often, after initial gains have been realized through ‘traditional’ Process Improvement initiatives, teams start to question the extra overhead of ‘following process’ and wonder ‘what is in it for them’. With Kanban, these teams are much more likely to realize lasting gains through evolutionary, (incremental) improvements to basic existing delivery/ engineering processes and measuring their own performance in a much more meaningful manner.

Filed under: Agile, Agile ALM, Kanban, Lean/ Agile, Process Improvement

Join the Kanban Conversations!

singhmahesh — Mon, 21 Mar 2011 11:20:23 +0000

It has been an exciting 3 weeks since we launched the GA release of Swift-Kanban. Clearly, Kanban for software development and IT teams is being seen as the elusive weapon that promises to take Agile to the enterprise. From the volume of queries and the common themes of the inquiries, it is clear Agile practitioners know what they are looking for and will be demanding the right solution to help them make the transition to being an Agile enterprise.

Three key themes are emerging, which we find very interesting and are excited to learn more about through our interaction with our Beta users as well as prospects who are in discussions with us after the GA release:

Kanban for Distributed Teams

One of the most common reasons we are hearing when we ask why, is that the organization has distributed teams around the country, indeed the world – and simply cannot work with a physical board. In spite of time zone differences and multiple locations, these teams have managed so far by getting onto conference calls at the same time – and comparing notes and providing updates in prolonged interactions! With a Kanban tool, while these meetings may not go away (at least initially!), they get a powerful tool that visually communicates the same status of the project or a specific work-item and of course the entire project. That in itself is a huge benefit when teams have hitherto struggled with text reports/ email updates!

Kanban tools in conjunction with other Tools

Clearly, while Kanban tools provide significant efficiencies in project operations, projects continue to use a variety of tools including requirements management tools, testing tools and integrated development environments. Most of our interactions are helping us educate how potential Kanban practitioners propose to use these tools in an integrated fashion. With our extensive experience in integrated Agile ALM, we are certainly able to share our experience with existing customers; at the same time, we have learnt a lot about the possible integrations we may need to provide for a full solution. Irrespective of whether it is used on a development or a maintenance or a IT Helpdesk type of a activity, these integrations will ensure that not only does work flow smoothly within the Kanban board, but also outside of it!

Kanban and “Other Methods”

Kanban is not a software engineering method; however, it would appear that many organizations are approaching it as a software engineering method – be it against a traditional waterfall or iterative method or an agile method such as Scrum or XP! To us, it is clear that irrespective of the overall methodology being followed, Kanban provides a way to visualize “project operations” workflow and smoothen the flow of actual work. Thus, we are sure organizations will use a combination of software engineering, project management and operations processes that help them optimize throughput and increase output quality. This is fully in line with the principles of Kanban, that says that each (self-organizing) team must define the process that best works for them!

Our Kanban journey began more than a year ago and has just become much more interesting! We are having regular discussions with our early/ Beta customers. With David Anderson as our Advisor, we also launched the David Anderson Webinar Series and have seen a tremendous response to that. Come join us in these conversations and help us learn how we could better help you scale Agile in the Enterprise!

Filed under: Agile, Agile ALM, Kanban, Lean, Process Improvement, Software Project Management

Is Agile ALM on SaaS for you?

singhmahesh — Sun, 06 Feb 2011 11:27:48 +0000

In the last 2 years, Software-as-a-Service (SaaS) as a delivery model for corporate applications has found a significant amount of support. In the aftermath of the 2008 economic crash worldwide, there has been a surge of interest in exploring the SaaS model for a variety of reasons – mainly around reducing up-front investment typically associated with on-premise license purchases (operating expenses vs. capital expenses), ease of getting up and running, the ability to opt-out if you didn’t like the software, and several others.

At the same time, customers were cautioned about the key issues to keep in mind while adopting the SaaS, such as:

Peripheral applications, that did not touch core business activity/ processes, such as HR, CRM, Payroll, etc. were easier to deploy on SaaS, rather than core applications.
Even if applications were deployed on SaaS, they would need integration with other enterprise applications, whether in-house or SaaS, and customers would do well to evaluate SaaS vendors for the capability to integrate with other applications/ providers
Even if applications were available via the SaaS model, associated implementation effort such as user training, organization change management, data migration and interfaces with other apps remained. Thus it would be a mistake to assume that SaaS would significantly reduce implementation effort and costs.
Application security, scalability and performance; and vendor track-record (longevity, number of paying customers, financial strength) were other factors to look for.

Where is SaaS being adopted the most?

Common wisdom was that SaaS applications would typically be adopted by Small and Medium enterprises since they are usually more cash-strapped than Large Enterprises. However, in an interesting research article published by Saugatuck Technology Inc., a well-known SaaS research services provider based in Westport, CT, in September 2010, it appeared that SMEs were “much more likely to still be learning about SaaS – and to not have SaaS plans in place”.

Based on responses to several key questions, shown below, it would appear that only 24% or SMEs had implemented or were implementing SaaS applications against 43% of LEs!

What Apps are most Likely to be on SaaS?

Clearly, the peripheral vs. the core argument made a lot of sense. Customers would be much more likely to trust an external service provider to manage corporate data that was not critical to its core business. At the same time, they would be much more likely to outsource apps that were not core to the business.

In a recent article, CIO.com refers to a detailed Forrester research that finally acknowledges that not all software will be successful on SaaS! Among others, it says Application Development software is successfully finding its way on SaaS. Our experience with project management software is the same!

At Digite, we have found substantial interest in our Agile ALM products in both SMEs and LEs and we have a healthy mix of both. Given our customers’ focus on collaborative software development using geographically distributed teams, both our on-premise (but web-based) and SaaS offerings have found widespread acceptance. Given the global trend of distributed technology teams, this is hardly surprising!

It would be great to hear of your perspective on which applications have worked on SaaS and which haven’t.

Filed under: Agile, Agile ALM, ALM, Application Lifecycle Management, Cloud-Apps, On-Demand, SaaS

When is a project too small or too short for ALM?

singhmahesh — Fri, 21 Jan 2011 11:17:58 +0000

Someone recently asked that question in a community forum. Their own answer was – ‘Never’. There are 3 aspects of this question that I can think of and respond with while agreeing fully with their answer.

Application Lifecycle Management (ALM) is an Activity

To my mind the phrase Application Lifecycle Management naturally means managing the lifecycle of an application. An application’s life begins humbly – with a request from a user or a customer, which fights for its survival amongst scores of similar requests. Once it wins, an application – however small or large – gets implemented/ developed to meet that request. Once deployed, an application has a life, the length of which is determined by a number of factors such as TCO and conformance to changing business requirements. The moment these factors weigh against the application, out it goes, upended by another request to replace that application!

A specific project which deals with an application – its selection/ prioritization, its development or implementation, or a making an incremental maintenance release of that application – is inherently ‘part of’ that application’s lifecycle management, however short or small. So, the question itself becomes redundant from that perspective. Organizations are executing projects (that deal with applications) as part of that application’s lifecycle, whether they realize it or not!

ALM is a category of Tool(s)

From an Application Lifecycle Management tools perspective, different vendors have taken a different tack. While some have focused on purely the development or software engineering aspects of it, others have taken a broader meaning which includes the portfolio and project management aspects of managing an application’s lifecycle. Still others have included a process-management aspect as well, that allows organizations to define processes for different aspects of the application lifecycle management, and use those processes in an integrated and standardized manner throughout the application lifecycle. Depending on the nature of the project, it will consume some or all of these aspects of ALM tools.

Various analysts such as Gartner, Forrester and IDC see it similarly; IDC actually has graphic that defines ALM as a combination of all three areas identified above. At Digité, we believe in that same vision. Thus, Digité provides a set of tools that allows our customers to manage the entire lifecycle on Digité or using a combination of ALM tools that Digité integrates with.

ALM is (part of) Organization Culture

A lot depends on an organization’s culture, their approach to workforce productivity and quality, and what some of their key performance parameters are. Organizations focused on multi-geography/ department workforce productivity, Total Cost of Ownership of an application, and quality will typically consider any project to be part of ALM rather than see it in isolation. Every organization that understands the true nature and breadth of application lifecycle management will agree.

It would be great to hear some more perspectives!

Filed under: Agile, Agile ALM, ALM, Application Lifecycle Management, Project Management, Software Project Management

How ALM Tools Can Help Key Software Processes

singhmahesh — Mon, 01 Mar 2010 03:00:17 +0000

In a recent exchange, I was asked what the typical ALM tools do to address three key challenges around process improvement and compliance in software/ IT organizations, and more specifically, what we at Digité do about them. I felt these would be of interest to others as well, so here is a summary of that exchange.

Effort Estimation

Most tools lack any (effort) estimation capability and most estimates falter. This is one area that remains a challenge for most organizations and application/ software projects are notorious for not meeting their original effort/ cost/ time estimates.

Our experience at Digité has shown that there is very little standardization in the use of estimation methods, except perhaps the bare minimum use of Function Point Analysis, so it is not easy to select any specific methodology and incorporate into the tool. However, the fundamental problem that I believe we (as also most PPM/ ALM vendors) help resolve is of helping our customers build historic data, one of the most common reasons for poor estimates. By using Digité across the organization, our customers capture process and project data and help successive projects do better in terms of estimation. We do have specific but basic functionality around capturing Phase level estimates and then automatically assigning to WBS tasks – which the PM can then tweak as needed.

Standardized Measurement Systems

We believe that ALM tools are at the front and center of solving this problem – that’s where work happens! So ALM tools are the ideal candidate to be the measurement system in a software/ IT organization. Through Digité’s integrated combination of Process Governance, Project Management and SDLC functionality, we provide all projects a consistent method of data capture across all phases of the project and across all types of projects – be it development, maintenance, implementation, etc. So, every activity in the project is codified, and reduced to a WBS task or a workflow step – and baseline, plan and actual effort against all project work – whether planned or unplanned – gets captured against these tasks/ workflow steps. These then get rolled up based on the WBS hierarchy or by the metrics/ reports that use that data to provide a variety of metrics from quality, defect, earned value, variance and so on

Different organizations have differences in the way they may measure even a simple metric like Defect Density or Defect Leakage; large organizations may have that problem even across business units! However, using a system like Digité, they are able to standardize the measurement and reporting

Compliance to Process

Compliance to a process is the biggest issue that our customers deal with – and I sincerely believe that is where we at Digité provide very unique functionality that no one else provides. Digité’s integrated Process Governance module has what we call the Universal Process Framework (UPF). This is a flexible framework that allows you to define CMMi/ 6-Sigma, PM-BoK or other framework compliant process templates (PTs) easily and flexibly for different types of projects that you do.

Each PT is a combination of the project WBS, various functional processes (workflows) like requirements management, defect tracking, test management, etc. (depending on the process or project type), deliverables, phase gates, roles, process artifacts, etc. These create what we call ‘actionable processes’ – the critical component missing in most process improvement initiatives that automatically convert process definitions to project work-items. When the process template is used to create a project, all of these become available to the project team. As the team does its work, the process automatically gets followed! Very little ‘extra’ work needs to be done to follow the process and project managers/ teams love that!

If you have any insights to share, I’d love to hear from you.

Filed under: Application Lifecycle Management

Digité Goes On the Cloud!

singhmahesh — Tue, 19 Jan 2010 10:47:52 +0000

At Digité, we have been a web-based application right from the start. Before Cloud, before SaaS, there was ASP – and our initial product launch was as an ASP – Application Service Provider. As luck would have it, a majority of our customers preferred to host the application ‘on-premise’ and simply wanted to buy the license from us. This worked very well for us – because it gave us invaluable experience in a variety of areas, from the challenges of implementing an enterprise software across the organization, to testing the software for the scalability and robustness needed for a deployment such as Infosys, our largest customer, with a 100,000 users on a single Windows/ SQL Server based installation of Digité Enterprise.

Over the last 8 years, we have implemented Digité at Corporate IT, IT Consulting and Services as well as ISV organizations. And, amongst the many lessons we learned, we picked on two – the challenges an organization is trying to overcome by implementing a solution such as Digité – and the challenges an organization goes through trying to implement an enterprise solution like Digité.

Structured Chaos, Unstructured Innovation

Our customers are in the business of developing or maintaining or implementing software – in-house or third party, custom or off-the-shelf. This is hard work that usually involves defining requirements and building or assembling software solutions that meet those requirements. This is by itself a tough job; introduce geographic, cultural, logistical and technology barriers of today’s global economy, and the job becomes tougher by several magnitudes. Our customers have seen the value that Digité provides by giving them a flexible, easy to use, lightweight and cost effective mechanism to quickly get organized in their development processes so that they can get on with the far tougher job of building great software! Over the last 8 years, we have been amazed over and over again at how our customers’ teams have innovated to build great software to delight their own customers, internal or external. And we have learned from those experiences. Key amongst them – that people don’t want to reinvent the wheel. If someone has already done it, reuse and build on top of it! And two, keep things simple, yet comprehensive enough. “Just enough process” is a recurring theme.

The Small Matter of Organizational Change Management

Implementing ANY enterprise software is not easy; implementing Digité Enterprise – which pretty much touches everybody in a software/ IT organization, can be even tougher. When you are coming off a culture of using email, spreadsheet and some basic project management software, the job of moving everyone to a somewhat standardized way of doing things – managing projects, building software, measuring progress – can be daunting. More than technical learning challenges, more than software challenges – quality, integration, migration, performance, etc. – people simply have a hard time doing something they have been used to doing one way to a new, even if better, way. Yet, in spite of conventional wisdom, an overwhelming majority of our customers have succeeded in meeting this challenge through a combination of process, scope control, phased implementation planning, management buy-in, user buy-in, and more. More often than not, two of the key ingredients to success have been to keep things simple – and to aim for speedy, short cycle-time implementation milestones. The resulting success and the perceived (and real) progress of the implementation itself provides a positive reinforcement which further propels further implementation!

Digité SaaS – Solutions as a Service

Agile ALM or Application Lifecycle Management has become a force to reckon with, especially in the Global Delivery Model. Most technology companies – small or large – are trying to leverage distributed resources and teams to deliver their products and services. With the events of late 2008 and 2009, interest in SaaS applications has made it a viable business model once again. We believe that we MUST share with our customers, especially the Small and Medium Business enterprises, the lessons we have learned over the last 8 years in Digité. Digité’s Agile ALM on SaaS is our new service that aims to do precisely that.

Please come check us out at www.digite.com/saas. If you like what you see, please contact us at sales@digite.com!

Posted in Application Lifecycle Management

Do ALM Tools benefit the Developers?

singhmahesh — Thu, 12 Nov 2009 23:31:02 +0000

Recently, I got asked this question by a prospect – a large bank’s SEPG head. Their exact question was – How does Digité help with the developer experience? Clearly, Application Lifecycle Management (ALM) tools have made the life of the PMO, the SEPG, the Quality group, the Project Managers and the executive management better. But how do they benefit the folks doing the actual development?!

Here was my response to them about specifically what we, at Digité, have done to improve the life of the Development Team – the Business/ Functional Analyst, the developers and the testing team.

Digité’s Unified Inbox automatically collects all the tasks and artifacts that a team member needs to work on, sorted by project, priority and urgency. No more time wastage in search and follow-up to figure out what work they are supposed to do next!
Digité’s integrated set of products ensure that there is minimal wastage of effort in learning the tool itself, in navigating from one tool to another due to an integrated UI and a single repository, other than the code repository.
Our Requirements and Change management features enable Business/ Functional Analysts and users collaborate continuously to identify, build and manage requirements collaboratively. They work on individual requirements, decompose them online, baseline and review them; and track any changes to them throughout the development lifecycle. For the Agile practitioners, Digité provides User Stories and Iterations to plan, prioritize and build their user stories in iterations assigned to specific releases.
Digité’s Integrated Traceability ensures that developers understand a software requirement along with other related items – user requirements, change-requests, test cases, documents – all thru a single integrated view – so that they can work with a holistic understanding of the business. Similarly, the developer’s ability to view a defect holistically – through viewing associated failed test case(s), the related software/ user requirements, etc. means that a developer gets a full understanding of what failed, why it may have failed and do a full impact analysis – thus ensuring that the developers do an effective job of fixing the defect. This prevents a significant amount of rework and ensures a much higher level of initially delivered quality and conformance to requirements.
Our Eclipse/ Subversion/ CVS/ VSS adapters ensure that navigation between the developer’s environment and Digité is minimal – and developers and testers can focus on doing their work rather than managing their work. Within Eclipse, they get to view all of their tasks and other work items and are also able to post their effort to Digité Timesheet without leaving the Eclipse environment.
If tracking effort is important to you, you may like this. Our customers report that their developers take anywhere from 30 minutes to 2 hours each week (!) to update their timesheets. We provide an automatically populated timesheet and integrated time-logs available alongside each work item for immediate update as soon as a developer completes working on it.

All of the above have resulted in anywhere from 20-35% direct impact on developer productivity and equally importantly, 45-60% improvement in initial quality of product delivered and overall organizational productivity.

At Digité, we use our product for pretty much everything we do – as Sudipta, our VP of Engineering and Services, explained so well in a related blog post – Are you still without an ALM Tool? I can’t tell you how many times our team members have given us the feedback about how convenient and time-saving it is for them to use Digité for managing their own development/ implementation work!

I would also love to hear from you about your experience using Digité or any other ALM tools in terms of Developer experience and productivity.

Posted in Agile, Agile ALM, ALM, Application Lifecycle Management, Change Management, Project Team Productivity, Requirements Management

Is PPM Enough?

singhmahesh — Mon, 26 Oct 2009 18:47:24 +0000

I have spent a lot of time over the last 10 years discussing or working with a large number of our customers who have moved away from the ‘traditional’ methods of managing software projects to a more centralized and “institutional” method. An overwhelmingly large number of these companies have evaluated Project Portfolio Management (PPM) tools as their first option for moving away from their disparate solutions, which usually would be a combination of MS Project on the desktop, email, spreadsheets and a lot of hand-waving!

The promise of PPM tools is enticing. From the capability of management dashboards that unambiguously tell you whether projects are in Green, Yellow or Red status, to being able to smoothly make Fund/ Kill or Go/ No Go decisions about a project that is not exactly meeting its objectives, the case for PPM appears crystal clear. Who would not want such capability?

The reality however has been somewhat different for a number of companies.

Can I really trust my PPM dashboard?

In other words, is the data reliable? How is it being collected, collated and consolidated? Is there a reliable process behind this? Are basic steps such as estimation, time tracking and baselining of projects in place?

When organizations and project teams attempt to move away from managing projects using office productivity tools and other point solutions, they are not just switching tools, they are very often changing fundamental processes of how they work and how they manage their work. PPM tools demand a significant level of data reliability – which translates to process maturity – at the ‘operational’ level; to ensure that all aspects of project effort are being looked at, all the project deliverables – not just tasks but various deliverables and work items – from requirements to documents, from test scripts to defects – are being considered in computing the ‘real status’ of projects. This means that execution/ operational level processes need to be in place and automated so they can feed reliable data to the PPM solution.

A lot of PPM efforts have resulted in failure due to this fundamental problem of lack of automation at the operational level of project teams and the lack of project team buy-in. Application Lifecycle Management (ALM) tools that include or integrate with PPM/ Process Governance tools can much more effectively help in this regard.

Where do I file my time for this issue?

One of the basic challenges of project planning tools such as MS Project is that they are great at project planning but not at managing project execution. While PPM tools have ensured that some of the earlier challenges of over-dependence on the lone project manager have been taken care of, they still do not take care of resolving such basic issues as tracking effort on unplanned work.

It is humanly impossible for a project manager to put down every last bit of work as part of their WBS. On the other hand, filing time in a common “Miscellaneous” task means losing visibility to where 15-20% of the project effort might be being spent, so that one could plan better in the future! Very often, PPM tools miss out on all the effort being spent on unplanned work in projects and thus relying on incomplete data for providing management status update.

Integrated ALM tools help by focusing on the project team and making them more productive rather than just providing a dashboard for senior management which may not be fully reliable.

Why are so many defects still open?

Have you run into these questions – “Is that project really green? Or did the PM omit to take into account the large number of unmet requirements?” Or, for that matter, “Is the testing task really completed? Then why are all the defects still open?”

The ability to drill down into a project’s ‘real’ status is most important for portfolio management teams. PPM tools by themselves, do not and cannot provide this visibility and still continue to rely on the abilities of the project manager and project teams to ensure that they collect data from all sources and tools manually before providing that update.

ALM tools with integrated PPM capability make the project managers far more effective by one, providing the PM a comprehensive view of the project and in fact, proactively alerting them of potential red-flags; and two, by dramatically reducing the overhead of collecting data from myriad sources and putting it all together for status reporting, resulting in as much as 40-55% increase in Project Manager productivity.

Where is the final revision of the requirement??!

The value of a single repository for all project artifacts cannot be measured. Having managed projects directly and indirectly for over 20 years, I have seen project teams struggle with the simple task of managing all the information and artifacts – requirements, change requests, documents, issues, defects, test cases, deliverables – related to their project across a combination of email, portals, network directories, configuration management systems and team members’ desktops – resulting in horrendous loss of productive hours and project delays. Just to be able to go to a single place for all of that – makes team productivity go up by as much as 20-35%! PPM tools do not address this crucial business need; and thus do not contribute to mitigating the very factors that lead to project failure.

I believe PPM tools are great management tools for executive decision making. However, they do not focus on or deal with the operational processes that need to be in place so that PPM tools get reliable data. In order to have a good executive information system, it is imperative that the operational processes are cleaned up and automated through a good set of execution/ operational tools. In the world of applications, products and software, ALM tools do precisely that. To have a good PPM implementation, ALM solutions are not only necessary but are also a pre-requisite!

Posted in ALM, Application Lifecycle Management, Change Management, PPM, Process Maturity, Project Portfolio Management, Project Team Productivity

To SaaS or not to SaaS? That is a question – for the ISV!

singhmahesh — Mon, 20 Apr 2009 19:22:00 +0000

There is much being written about SaaS, the Cloud and the whole new world of software being delivered as a service. While there is a lot of advice being dispensed to the corporate customer – about the best practices of adopting SaaS, of watching out for the big bad vendors with their greedy licensing habits, making sure to sign contracts with water-tight SLAs, selecting the right apps to put on SaaS, etc., I get a sense there is not much advice being given to software vendors – those that are not in the drivers’ seat (and by far, the vast majority are not!) about what they must do to gear up for the oncoming tsunami!

Having seen several cycles of technology hype and fads come and go, I felt obliged to share some of my own observations about the SaaS imperatives for ISVs!

This time, it is NOT a fad!

Yes, through a unique conglomeration of technology, a critical mass of vendors and customers, and of course this recession, there is now a clear need established for some applications being delivered as a service with all of the trappings of no upfront costs, no long term investment in people and infrastructure, a turn-on/ turn-off at will capability, much like contracting services. The need to “invest low and return high” has never been greater.

The operative phrase is – ‘some applications’.

Not ALL applications are candidates for being delivered on SaaS. Neither will a majority of corporate customers be putting ALL of their applications on SaaS anytime soon. Roughly about 60-65% of all apps will remain on internal, inside-corporate-firewall servers. Applications that will make it to SaaS are those that score low in their need for confidentiality, integrity and availability. Applications which score high on these factors will remain within the firewall for some considerable time to come. Vendors need to evaluate carefully where their products stack up.

The key USP for any product remains VALUE

Is their significant value of the product to the target market? Is it solving critical business problems not being solved by other competing products? Is it doing so in ways unique to the domain? If the answer to one or more of these questions is No, then it will do the vendor no good to put the product out as SaaS – and hope that that will somehow sell the product. SaaS may be necessary but not a sufficient condition for a software to sell. If the answer to the questions is Yes, then going SaaS will definitely help target additional markets (SMB for example), but it may not be as urgent as one might be lead to believe by the market hype.

Are you ready to SaaS?

Just because the software runs on a server and served up through a browser does not mean it is SaaS ready. In order to meet proposed industry standards, market expectations and – above all – successful implementation for the customer, vendors have to be ready with a number of critical capabilities. These include:

User and data security/ privacy – the ability to demonstrate clearly how they will achieve this

Backup and recovery – clear policies on what is backed up and how it will be recoverable, in case of downtime. Simple database-backups differ from application-specific backups – and recovery may mean different things to different users. For example, if it is a project management application, can the vendor back up a specific project and more importantly, can they recover a specific project only?

Ability to integrate with client applications – through a published and documented set of APIs or even simple flat-file transfers

Self-service Support – user provisioning/ administration, user/ application usage monitoring, online help and training documentation

While there are a bunch of other capabilities the vendor must provide, these are some of the important ones.

SLAs – Can you match or top what IT did?

There is a lot of attention being given to SLAs. One almost gets the impression that SaaS vendors might be subject to unrealistic levels of performance that customers would almost certainly never have got from their own IT! While this is not new or unexpected, vendors must work with clients to set some realistic expectations, goals and the associated penalties/ rewards.

Besides looking at general industry norms on uptime, response-time, etc., vendors must look at their specific situation. They must absolutely not agree to SLAs they cannot deliver on. And if they find they are behind, they are not ready to go SaaS!

One way to negotiate appropriate SLAs might be for both the vendor and the client to look at the current SLAs or performance levels the client is getting or used to, and go one – or two – ‘levels’ higher. This will require open, transparent discussion and agreement – followed of course by performance that matches the expectations.

What about Marketing and Sales?

Clearly, SaaS requires a completely different marketing and sales approach than the traditional license selling model. With the number of vendors jumping on the SaaS model – either directly or through AppExchange type of communities – how do you get “found” by the individual or the departmental team is something that requires much more than the few direct sales people you managed with in the past! Any number of viral marketing or Web 2.0 marketing approaches needs to be applied in order to build brand-awareness. In addition, traditional advertising and SEO with paid searches may also need to be used.

Do the numbers add up?

With all of the work to be done before you can even say SaaS, this is the biggest challenge for vendors – especially smaller companies. It is not easy to go SaaS without reasonably deep pockets!

Consider this – you are not only providing the software – which must now be even more defect free than when you were not SaaS, you are also taking on the responsibility of being the client’s IT organization! Granted that there is a sharing of resources across customers but to get the economies of scale takes time. In the mean time, each customer must get the experience as if it were their own IT – only better, faster and of course cheaper!

That means – hardware, software, hosting, bandwidth, administration staff – both application level and system level – besides the normal Help desk/ Support resources. And that just gets you to first base! Add to that all additional expenses of SaaS-enabling your software – from securitization to certification to audits – pretty soon, it all adds up. Finally, the Marketing and Sales expenses need to be tallied.

What about the Revenue side? You are now willingly giving up the up-front cashflows of the traditional license model – in the hope of getting larger recurring revenues over a period of time – that may extend from 18 to 36 months or even longer! While overall cashflows should become more even, ramp up to break-even point may take several months.

Vendors not only need to be prepared to invest in all this, they must have sufficient financial horsepower to be able to wait for the users to ramp-up!

Conclusion

SaaS is here to stay – and has gone beyond – to PaaS/ IaaS and the Cloud. However, not all software, especially core business applications, may go to SaaS in the short or even the medium term. Vendors who have solutions that are a candidate for SaaS must consider the option – because not having a SaaS version will be a show-stopper in many deals. On the other hand, vendors with core/ critical business applications may have a longer lead time to consider going SaaS, if at all.

Going the SaaS way will require deep pockets and a lot of preparation in terms of product, infrastructure, support and marketing.

Posted in Cloud, IaaS, Implications for ISVs, PaaS, SaaS

The Problem of Requirements and Change Management

singhmahesh — Wed, 08 Apr 2009 04:46:00 +0000

The topic of Requirements and Change Management continues to spark enthusiastic debate and discussion amongst the software community. And for obvious reasons.

I was talking to a Gartner analyst just today – and he himself drew attention to the fact that software requirements are so hard to do, unlike a bridge or a tunnel or building – where requirements were so much more easier to define. Absolutely!

Yet software teams and organizations continue to pay scant attention to this critical discipline that is responsible for the failure of such a high percentage of software projects. A recent study and analysis done by IAG Consulting (http://tinyurl.com/dldfwb) had these shocking findings:

Companies with poor business analysis were 3 times more likely to see their projects fail!
Bad project requirements can result in upto a 60% hike in project costs, and
For a $3m project with poor requirements, companies would pay an average of $5.87m!

The study concluded that projects and organizations where Business and IT worked collaboratively on requirements were much less likely to see cost and time overruns than those that did not.

The Software Engineering Institute (SEI) has determined that projects that spend up to 60% of the overall effort in Planning, Requirements Analysis and Design have dramatically lower cost and schedule overruns compared to projects that spent that level of effort in Coding and Testing.

This should be fairly obvious – after all, if you don’t know what you have to build, how can you build it well? Yet, software professionals, teams and entire organizations continue to suffer from this lack of focus on up-front and ongoing requirements and change management.

At the same time, there is no doubt that requirements change – for a variety of reasons. To manage the changes to the requirements on a continuous basis and keep an eye on the impact of these changes on project budget and contract dollars is what project managers must do all the time.

The importance of collaboration and of collaborative and ongoing requirements and change management cannot be over-emphasized. After all, in the definition by quality guru, Phil Crosby, Quality = Conformance to Requirements. And that is all there is to that!

Posted in Change Management, Requirements Management