The Discovery Phase:

Taking the Final Leap: Define the Scope & Approve the Plan

When it’s time to actually begin development the tendency is to want to just get started. A lot of time and effort has gone into getting to this point, so there can be a lot of eXcitement about finally making things happen. However, there is one last step to take before your developer puts fingers to keyboard. The “discovery” phase is where the requirements gathering is done. It is the all important planning phase.

Thorough discovery is necessary to ensure the app will catapult your business to the next level by improving the efficiency of your business processes, or by freeing up time for employees to increase productivity in other areas. During discovery, you sit down with your developer to hammer out the details — or scope of work. This is usually when the clock starts ticking.

Scope of work

Brainstorming and needs gathering are used to determine the breadth and potential details of the project. The scope of work narrows that down to the nuts and bolts and provides an architectural plan. The scope of a project includes all of the requirements, data capture, features, connectivity, users, security and everything that defines the whole of the project.

Everything about how, where and by whom the solution will be used is included. Information can be shared with other software applications like accounting software, cloud-based solutions, other data systems and your website, or the solution can be completely self-contained. Your developer will help you determine how to incorporate those requirements into the final solution.

eXamples of your current work procedures (current database if you use one, other software, spreadsheets, forms, memory, post-it notes, napkin drawings, reports, etc.) and any shortcomings or inefficiencies should be included in the requirements gathering discussions with your developer. Your desired workflow needs to be described so that your developer can turn that into a functional program. The requirements become the working blueprint for development. The end product of the discovery process is the working list of features and functions that end users will use to facilitate their work, the eXpected timeline and cost estimate.

If you’re interested in learning more about how you and your developer can work together to define the project and set timelines, we’ve got you covered. Click here!

A word of caution. Determining the scope of work is a necessary step, but it can sometimes lead to “paralysis by analysis.” There is no way to anticipate every possible detail of the final solution. There will be adjustments along the way once development starts, so don’t get hung up trying to define every jot and tittle — especially if the developer uses an agile development style, which is closely akin to a wash, rinse and repeat cycle, allowing plenty of room for refinement as the app takes shape.

At this point you should be able to trust that your developer has enough information to start building the app so you can see your vision unfold. Now is the time to take the leap and approve the plan. There will be changes, but the initial plan provides a launching point for the developer to begin.

Changes in the Scope

The scope of work is a living description of the project. Just like with an architectural blueprint for a custom home, change is the nature of the beast. Even after the blueprint is finalized and approved, there are ALWAYS changes along the way. Some changes are minor and some are major. As the project unfolds there will be new ways to think about the workflow and data organization, or it may spark whole new ideas. This is normal and to be eXpected. Unless you are locked into a rigid contract that doesn’t allow any changes to the scope of work, eXpect the requirements to evolve over the course of the project. This evolution requires a periodic re-evaluation of the scope of work to make sure the critical business requirements remain intact while accommodating any changes.

As changes arise the scope of work may eXpand or contract. That means the budget and timeline need to be re-evaluated. Those changes will be added or put on a wish list or discarded based on the overall goals along with the budget and timeline. Having a clear understanding of how new ideas affect the development plan will keep the overall project from feeling like a black hole further down the road.

The vortex of development doubt can be daunting! Relax. You’ve got scope and a vetted developer., the light at the end of the development tunnel!

Development in Phases

Sometimes a custom application is relatively small and concise, as simple as automating a single business task. Other times the application will manage an entire business. Most apps are somewhere in between. A small project is generally completed by a single developer in one development effort. A larger project might lend itself to being broken into multiple phases of development or involve multiple developers. It is worth looking at a medium- to large-sized project to determine if it could, or should, be done in phases.

Many times, larger projects seem to drag on and take forever before you see any real benefit if they are created in one monolithic effort. That can even kill an app before it is born if the timeline and/or budget keep ballooning. This is something that can strike fear in the heart of the client manager.

Considering whether the project can be reduced to modules or discrete parts that have self-contained sets of features can alleviate this concern. If a project can be deployed in stages so that there is a usable benefit early on while other parts are in development, there is a greater sense of progress and a quicker return on investment. For eXample, a project with a fairly self-contained customer module and a separate set of features for a manufacturing module could be broken into phases. The developer can create the customer module first and deploy it so that the end users can start working with it while the manufacturing module is being developed rather than waiting until both modules are finished before deployment.

This approach allows users to become familiar with the new system and provide feedback as they work with the customer module. Once the manufacturing module is complete, the two modules can be integrated and deployed as a single comprehensive solution. This is a great strategy that allows users to get comfortable with the new system and do some active testing with real data. Often, this process will even reveal additional adjustments that need to be made to the scope of work.

Whether a project lends itself to development in phases doesn’t necessarily need to be determined during the discovery process, but it can be a helpful part of the conversation. The idea is to look for potential ways to create early benefit while development continues.

The Blessing

Planning is done. Approval has been given. Time for the coding to begin …

The post Survival Guide (6 of 7): Find, Hire & Work with a Software Developer, Successfully! appeared first on eXcelisys.

View the full article