In a cloud project of any size, discovery is the crux of project risk.\u00a0 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.\nUnfortunately, this is also the honeymoon phase of the project, where over-optimism and a false sense of security can mask the inherent risk. \u00a0This is the time when the vendor\u2019s project lead must be most assertive, guiding the client through tough decisions and forcing the client to acknowledge unpleasant tradeoffs.\u00a0 Serious client hand-holding is a key success factor during discovery.\nIt was 50 years ago today, Sgt. Pepper\u2019s saw the light of day.\u00a0 So may I introduce to you, the weakest part of any cloud project \u2026 that old requirements discovery!\n\n[ 8 project management skills in high demand]\n\nMagical mystery tour\nEven 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:\n\nThe documents are influenced too much by vendor propaganda and industry analyst checklists, and aren\u2019t influenced enough by the actual needs of the business process.\u00a0 This leads to technical \u201cfeature-itis\u201d and a blindness to the preferences of real users.\nThe requirements aren\u2019t sufficiently prioritized, providing weak guidance about the hard tradeoffs that will be needed to meet the project budget and schedule.\u00a0\nThe requirements are incomplete, missing important transitions in the end-to-end business process.\u00a0 Too often, gaps are uncovered only as the project progresses, with \u201cinvisible\u201d requirements discovered long after the end of the discovery phase.\u00a0 This is most dramatic when a major requirement pops up during system acceptance testing.\nThe business evolves over the life of the project, and each re-org or policy change can invalidate or even contradict the original document.\u00a0 Not amusing, but real.\n\nBecause 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.\u00a0 The agile project method takes this to its logical extreme, with a micro-discovery at the beginning of each sprint.\nA day in the life\nEven the agile method can get the project in trouble if the consultant has not taken the client through a \u201cday in the life\u201d exercise that explores the end-to-end business process from the perspective of the actual users and (horrors!) the customer.\u00a0 As often as not, executives don\u2019t know the details of how the business actually runs, and lower-level people really know only their part of the puzzle.\u00a0 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.\nThe starting point of deep discovery is to express the system as a series of business processes such as:\n\nTarget marketing to sales-qualified lead\nSelling and pipeline management\nQuote to contract\nDelivery, installation and customer onboarding\nInvoicing and collections\nWarranty and service entitlements\nCase management and service scheduling\nProblem resolution and service calls\nFollow up and customer survey\n\nLarger 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.\u00a0 Multinational operations probably have significant variations to accommodate, including:\n\nRegional or even national business practices (e.g., U.S. vs. Europe vs. Asia)\nVertical industry norms and regulatory regimes (for customer privacy, contract rules or accounting)\nDistribution channels and joint ventures\nLegacy systems that aren\u2019t part of the project (e.g., ERP or eCommerce)\nPolitical fiefdoms both inside and outside the company\n\nEach of these variations needs to be mapped out as a parallel process with its own requirements.\u00a0\nCompanies want to believe that a cloud project can radically simplify the systems mess they\u2019ve built up over the years.\u00a0 And they can, but only if somebody does serious homework to simplify the process mess they\u2019ve built up over the years.\u00a0 Simplification means understanding the purpose and interactions among all the moving parts that are there now\u2026and coming up with an intelligent unification and replacement strategy.\u00a0 Short-cuts only cost you in the long run.\nThe long and winding road\nThis all sounds involved and expensive and time-consuming because, well, it is.\u00a0 Both the consultant and the client are well served by a deep discovery process that takes more than the \u201cstandard 15 percent\u201d 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.\u00a0\nUpper management\u2019s 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.\u00a0 To truly transform the business means doing enough work on the business processes to turn them into an advantage.