Discovery Phase in the Software Development Life Cycle (SDLC)

Anyone who has completed a few software development projects should recognize most or all of the Design and Delivery activities listed on this software development life cycle (SDLC) slide. However, in my experience, a much smaller percentage have been involved with projects as early as the Discovery phase. In some cases, Agile projects are so anxious to get to coding that they skip this phase altogether because they want to get to the nitty gritty details as soon as possible. However, a little time spent on Discovery activities can save lots of time, and is therefore agile in my book.

I drafted a big long blog about this phase, but realized that even using the word “Phase” made it sound like some long, drawn out waterfall project, when in fact it is a quick exercise meant to narrow scope and focus the design effort. With smaller projects I’ve spent as little as a few hours on this phase. Even for larger projects I usually don’t spend more than a week or two. The main goals are simply to identify the business case (current problems, proposed solution and expected benefits/ROI), identify the high level project scope, and provide a resource and budget plan for the Design phase).

Here is a sample Design phase proposal, which I have posted in html format. If you'd like a soft copy of the actual document, send your request to aaronhsmith@gmail.com.

During the Discovery phase I conduct interviews with the sponsor and key stakeholders, including eventual system users. The Design phase proposal is the key deliverable of the Discovery phase. As you complete the tasks in this phase, keep a few things in mind:

• 
  Identify what is in AND out of scope - It can be just as important to list what is out of scope as it is to list what is in scope. This helps clarify some big misunderstandings right out of the gate. I’ve witnessed a few projects and skipped right over the Discovery phase and found themselves moving ahead with designing and even developing features that the business may want but that the sponsors consider to be out of scope. At this high level identifying what is in and out of scope isn’t a perfect, but it can definitely save time.
• Ensure technical oversight – Often, project and account managers, or even sales and marketing people with no concept of software development, attempt to tackle the Discovery phase on their own. However you resource the Discovery phase, make sure that you have oversight from a senior technical person. They should at least review the high level scope and identify potential risk points. Since I believe pretty strongly in doing technical proof of concepts (POC) during the Design phase, they can identify which POC’s will be of value, and provide estimates for these exercises.

Spending a little time in Discovery at the outset of the project can help you focus your design efforts and get to delivering valuable, working software as soon as possible.