Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

No shortcuts! Do cloud requirements discovery right

David Taber | June 13, 2017
The discovery phase is the weakest part of any cloud project, but getting it wrong can cost you dearly.

man looking around

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.

 

1  2  Next Page 

Sign up for CIO Asia eNewsletters.