In Part I of this series on Software Project Killers, I described three risk factors that help account for why so many software projects miss their time lines, run over budget and don’t deliver promised functionality / ROI. This article, Part 2, looks at an additional set of four factors. If you are a VP of development or C-level executive, you will want to assess how you plan to address these factors in relation to your own current and upcoming projects.
Project killer #4: Try to re-create desktop software in the cloud
One of the most common software project killers is to design and develop a Software-as-a-Service (SaaS) / cloud solution as though it were just a desktop application delivered over the Web. The companies most likely to fall victim to this project killer are those that already have on-premises or desktop applications. They recognize that they need to offer a cloud-based solution in order to remain competitive. So they try to “port” the full functionality and workflow of their desktop solution to their new cloud-based software. The rationale is that they already have invested in the R&D to create a rich feature set that clients know (and love?), so they should be able to leverage this functionality as their competitive advantage in the cloud.
But in most cases, nothing could be further off target. For a cloud-based application or SaaS to succeed, it must be more streamlined, with a simpler, more intuitive design than its on-premises counterpart. The most successful SaaS / cloud applications focus on doing a few things incredibly well rather than doing many things adequately.
The risks of not simplifying an implementation are well documented: You will burn through a lot more money than you really need to spend, It will take a lot longer than is necessary to get to market and, most importantly, you will end up with software that is far too complex for a cloud service / SaaS. Customers simply will not use it. Switching costs are low for cloud software, so customers will find a more user-friendly vendor; or if they are within an enterprise, they will simply bring their own service.
But what if your current users tell you they want all of these features in the cloud? Reality is what users ask for, and what they really want and will actually use can differ significantly. Focus group research and tech support reports may tell you one thing. But there is no substitute for user studies, user validation and data metrics/observation to reveal what users actually do. It is essential to design application functionality and the user experience for these validated scenarios.
As a general rule, we advise clients to start with limited, extremely well-designed services rather than expansive, complicated offerings. Determine which activities a typical user will do 90 percent of the time and then make those tasks perfect. Limited-function, high-value services that become part of a user’s daily routine can be used to establish a track record, build trust, engender attachment and encourage recommendation.
You can subsequently add refinements, additional innovation and new features based on user data/requests later, when you push updates. But simplicity and focus always remains a priority.
Project killer #5: Allow complex customization of SaaS
One of the most compelling benefits of delivering B2B software via cloud computing / SaaS is economies of scale. Essentially the cost of providing the service to 1,000 customers is not significantly more than the cost for 100 customers. To achieve this you aggregate customers onto a common set of servers, a common user interface, and a common set of business processes. This “Walmart-ization” of software extends beyond the core application to the entire customer life cycle – everything from acquisition to support.
Of course, every customer will request the ability to tailor their service to their own unique operations and workflow. And herein lies the potential for a project killer — allowing customization of a SaaS product at the application code or database level on a per-customer basis.
As soon as you start spinning off instances of unique code, you run into trouble. The maintenance cycle becomes complex and costlier. Source code management becomes a challenge. Updates or fixes have to be analyzed across customization to minimize regression. Support becomes costlier. Customers become wary of vendor lock-in. The list goes on. Even if you can charge a premium for each customization, in the era of cloud services, this is not a sustainable business model.
So how do you meet customer requests for customization options? You build in data-driven “mass customization.” This is not customization in the traditional sense. No one fiddles around in the database, modifies schema or creates custom code (hoping nothing breaks). Instead each customer adds meta-data — “data about other data” — to configure the way the application works and how it provides a unique user experience and feature set in order to achieve a certain business function.
Customization/configuration using meta-data can run the gamut from terminology/lexicon and branding/layout, to individualized workflows, to data model extensions, to user provisioning and role-based access, to integration with other systems and even to business logic.
The challenge for the cloud / SaaS architect is to design and define the requirements for customization/configurability early in the application definition cycle and then design easily configured UI components that can manipulate in a self-service manner by non-technical clients.
Project killer #6: Work through requirements in sequential, prescribed phases
I think it is safe to say that almost everyone in software development has heard of Agile release methodology. They may not know the specific details of an implementation, but they understand the idea of continually delivering working software at regular iteration cycles, with each iteration closing in on reducing the overall uncertainty of the project.
However, thinking in an “agile way” doesn’t come naturally to many software development projects. Given the complexities of projects and the desire to standardize, many companies continue to follow a set of sequential, prescribed steps:
- Nail down requirements from the start.
- Design, build and test software in distinct project phases that can easily be tracked in a highly predictable manner.
But with the rapidly changing, competitive nature of cloud-based software and the fact that user experience is the single greatest predictor of whether a company will retain and grow its customer base (or see customers defect to a competitor), not using an Agile / adaptive release methodology puts your software project at risk. You can’t afford to take months or years to finish a project and then find the user requirements have changed or that the original requirements were off the mark to begin with.
Which variation of Agile you ascribe to is not critical (we use a combination of Scrum and Lean). The key point is that you use highly collaborative teams and build the idea of change, waste reduction and incremental, meaningful deliverables into the release process itself. This enables the flexibility to respond to customer testing (see Software Project Killer #2), changing business priorities and the rapid pace of innovation driven by the digital world.
Project killer #7: Design for the PC and browser; deal with mobile later
You may think your software project will be used primarily on desktop/laptop computers. Or maybe you are just not ready to address the mobile product. In any case, you design your new software project for the desktop and plan to tackle the “mobile issue” at some later date. Welcome to project killer #7: designing a new product with the PC and browser as your reference, without planning for mobile.
The PC market is now growing 5-10 percent per year, while mobile is growing at rates exceeding 100 percent. No matter how you conceive of your product today, within a very short time that product will absolutely need to be available to smartphone and tablet users. You should design any new product with mobility and mobile form factors as key initial parameters to build against.
If you target desktop systems as your starting point for a new software release, you will invariably design applications that take advantage of a large screen, keyboards and pure horsepower. For example, my desktop machine has a 3.1 GHz quad-core processor, 16 GB of RAM and 27-inch HD display. My peers, who are gamers, have significantly more powerful systems. The high level of baseline hardware specs on modern desktops/laptops means users can run some incredibly sophisticated and computationally powerful applications.
If you then later try to scale down the application to mobile input, screens and processors, you will spend a significant amount of effort trying to shoehorn the high-performance desktop design into a mobile device.
In contrast, if you begin your strategic planning/design with mobile development in mind and, in fact, optimize the application for mobile delivery, the application will always have mobility as part of its core DNA. The high performance using limited hardware, precise user definition, laser-focused workflows and clean design that are the hallmarks of successful mobile user experience can also greatly inform the design of desktop apps. It is much easier to add features and functionality to take advantage of more horsepower and more screen real estate on the desktop than it is to shoehorn an existing resource-demanding application to deliver a successful experience on a mobile device.
An overly simplistic but still useful rule of thumb: Use mobile as a starting point and design outward from there.
Paul Giurata is the managing partner for Catalyst Resources, a user experience and application design firm headquartered in Silicon Valley. He and his teams have worked on more than 450 software projects in Financial Services, SaaS, Life Sciences / Biotech and mission-critical Systems. For more information, contact info@catalystresources.com.