The Discovery Phase

If I had to pick one phase of a project that, when executed correctly, is the most important to project success, I would choose the Discovery Phase. At the beginning of a project implementing any O365 application, we always complete a discovery phase with the client to go over every preparatory detail- like understanding their internal processes, or teaching them about baseline configuration settings for an application. Why is the importance of the discovery phase sometimes overlooked? First of all, depending on the application, the developer is looking at different levels of complexity/customization. A discovery session for moving documents to One Drive would seem less important than that for a custom change tracking list in SharePoint, for example. And this is not totally wrong. While the discovery for a custom SharePoint list is more complex, to completely overlook a discovery phase for a OneDrive migration could set up a project for failure. To understand why this is the case, we must understand what makes a good discovery phase and what value it ultimately adds.

Tips for an effective Discovery Phase:

1. Know the system. Time and time again I have seen crippled systems that companies are trying really hard to make work, and I find out that it was because the system was designed without consideration for the compatibility of that design with the software itself. Broken down simply: understand how the tool you’re using will be compatible with what you are planning to build in it or use it for. Don’t plan to build a list in SharePoint with free-text fields everywhere if it will need to undergo auditing. The way SharePoint sorts and filters information will make reporting a nightmare with too much variation in field content, like three different entries for the same operating system ala “Mac OSX”, “MacOSX”, and “MacintoshOSX”. There’s no find-and-replace for SharePoint records to quickly normalize messy data later when it’s too late. From the beginning, you must understand what kind of use/design does and doesn’t play well with your application. See Figure 1 below.

2. Communicate the steps of Discovery with your client methodically. It’s likely that they have many internal processes that can be automated and improved upon with applications in O365. This means that once they get a feel for all the possibilities, t

he process can become overwhelming for them. If you are planning a migration to OneDrive, for example, it is important to schedule at least one session

reviewing the administrative settings that can be configured on the back end before even discussing their desired file structure. Tackle it in phases. They’ll be surprised to find that there are lots of customizable security settings in OneDrive that need to be understood and set the right way for their company prior to anything else. It’s difficult to go back and try to figure all of these out once you are dealing with a live system.

Why is this all so important? Very cliché but very true: leave no stone unturned in the discovery phase of a project. Be as exhaustive as you can possibly be in blueprinting the system prior to development. Anticipate client questions by knowing your system well, and communicate with the client methodically. It’s well known that during a project, unforeseen circumstances arise. A new audit requirement could come out, or an internal process could change, however completing a successful discovery phase will leave you with a detailed plan for the life of the project. Any unforeseen changes will be much easier to deal with and document. Not only that, when you finally arrive at testing and go-live, you will be much more successful having planned ahead from the start.

We want to hear from you - Have you ever watched a project go south because the discovery phase was not executed thoroughly? What about projects that owe their success to a good beginning? Comment below!