No shortcuts! Do cloud requirements discovery right

In a cloud project of any size, discovery is the crux of project risk.  Although the discovery and architecture phases of a project may represent only 15 percent of the overall effort, an error or omission early on can cause overruns of 150 percent or more.

Unfortunately, this is also the honeymoon phase of the project, where over-optimism and a false sense of security can mask the inherent risk.  This is the time when the vendor’s project lead must be most assertive, guiding the client through tough decisions and forcing the client to acknowledge unpleasant tradeoffs.  Serious client hand-holding is a key success factor during discovery.

It was 50 years ago today, Sgt. Pepper’s saw the light of day.  So may I introduce to you, the weakest part of any cloud project … that old requirements discovery!

Magical mystery tour

Even if the client has done a lot of requirements gathering and created a big requirements document in advance of the project, these tomes inevitably suffer from four critical problems:

1. The documents are influenced too much by vendor propaganda and industry analyst checklists, and aren’t influenced enough by the actual needs of the business process.  This leads to technical “feature-itis” and a blindness to the preferences of real users.
2. The requirements aren’t sufficiently prioritized, providing weak guidance about the hard tradeoffs that will be needed to meet the project budget and schedule. 
3. The requirements are incomplete, missing important transitions in the end-to-end business process.  Too often, gaps are uncovered only as the project progresses, with “invisible” requirements discovered long after the end of the discovery phase.  This is most dramatic when a major requirement pops up during system acceptance testing.
4. The business evolves over the life of the project, and each re-org or policy change can invalidate or even contradict the original document.  Not amusing, but real.

Because pre-written requirements documents tend to be unreliable roadmaps for the full journey of a big project, consultants prefer to break the project into several phases, each of which should begin with its own discovery and requirements sign-off cycle.  The agile project method takes this to its logical extreme, with a micro-discovery at the beginning of each sprint.

A day in the life

Even the agile method can get the project in trouble if the consultant has not taken the client through a “day in the life” exercise that explores the end-to-end business process from the perspective of the actual users and (horrors!) the customer.  As often as not, executives don’t know the details of how the business actually runs, and lower-level people really know only their part of the puzzle.  With customer-facing apps, sometimes only the customer knows how frustrating your systems are, and nobody internal has taken the time to connect all the dots and see the process end-to-end.

The starting point of deep discovery is to express the system as a series of business processes such as:

• Target marketing to sales-qualified lead
• Selling and pipeline management
• Quote to contract
• Delivery, installation and customer onboarding
• Invoicing and collections
• Warranty and service entitlements
• Case management and service scheduling
• Problem resolution and service calls
• Follow up and customer survey

Larger companies undergoing this analysis will quickly discover that they do not have (and perhaps can never have) a single process stream for the whole business.  Multinational operations probably have significant variations to accommodate, including:

• Regional or even national business practices (e.g., U.S. vs. Europe vs. Asia)
• Vertical industry norms and regulatory regimes (for customer privacy, contract rules or accounting)
• Distribution channels and joint ventures
• Legacy systems that aren’t part of the project (e.g., ERP or eCommerce)
• Political fiefdoms both inside and outside the company

Each of these variations needs to be mapped out as a parallel process with its own requirements. 

Companies want to believe that a cloud project can radically simplify the systems mess they’ve built up over the years.  And they can, but only if somebody does serious homework to simplify the process mess they’ve built up over the years.  Simplification means understanding the purpose and interactions among all the moving parts that are there now…and coming up with an intelligent unification and replacement strategy.  Short-cuts only cost you in the long run.

The long and winding road

This all sounds involved and expensive and time-consuming because, well, it is.  Both the consultant and the client are well served by a deep discovery process that takes more than the “standard 15 percent” of overall project effort. This is particularly true when a cloud system is replacing one or more legacy systems that have evolved (in both healthy and unhealthy ways) over the years. 

Upper management’s desire for a rushed project must be firmly countered with the knowledge that rushing will produce a new system that automates old habits and reinforces obsolete business rules.  To truly transform the business means doing enough work on the business processes to turn them into an advantage.