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.
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.
Planning is done. Approval has been given. Time for the coding to begin …
If you missed any of the installments in our series, access them here:
Part 1: Embracing the Development Mind-Set
Part 2: What Should You Consider When Selecting a Development Partner? What Questions Might You Ask a Potential Developer?
Part 3: Quotes, Estimates and Change Orders, Oh My! — Understanding Pricing & Billing Models
Part 4: Making the Plan for Planning Your Plan of the Project Plan — What Do We Need to Get This Development Party Started!
Part 5: Rassling with the R’s — Roles and Responsibilities
Part 6: Taking the Final Leap: Define the Scope & Approve the Plan
Part 7: Find, Hire & Work with a Software Developer, Successfully!
Website Content and Design
Website Content and Design
Copyright © eXcelisys, Inc., all rights reserved. No unauthorized use permitted; all derivative works must have prior approval. All content – including design and copy within the eXcelisys website is protected under international copyright laws. eXcelisys will prosecute ANYONE who borrows or steals any derivative or facsimile of the content and design of eXcelisys’ website without written approval or permission. Read More
FileMaker®, FileMaker Pro® and the referencing FileMaker® logos are trademarks of FileMaker, Inc., in the United States, the European Union and other countries. MySQL® and MySQL® Logos are registered trademarks of MySQL AB in the United States, the European Union and other countries. The PostgreSQL elephant logo “Slonik” is a registered trademark of the PostgreSQL Global Development Group. Read More
We will never give or sell your email address or contact information to anybody, for any reason. There are no eXceptions. We do not make our customer list available to anyone outside of eXcelisys at all, ever.
There is no way that submitting your information to eXcelisys will result in you receiving “spam” or other junk mail from eXcelisys if you have requested us not to do so. Read More