It should be clear that there is a substantial effort that goes into a successful project before the actual development work even begins. In this final segment of our 7-part series on choosing and working with a custom app developer, we offer tips to take you through the development, testing and deployment stages.

Development styles — What to eXpect

Broadly speaking, there are three common approaches to development: agile, waterfall and prototyping. All are intended to get to the finished product in an efficient manner, but each takes a different approach. The agile development style practices discovery as development unfolds and requires eXtensive client feedback during development, while the traditional waterfall method is heavy on discovery with the client then stepping back and turning the developer loose to do their thing. Prototyping relies heavily on mock-up designs to verify the functionality before actual development commences. It will help to know the approach your developer will use so you can anticipate when you will be called to action.

Agile — An iterative wash, rinse, repeat cycle.

The discovery phase is very short and informal. The intent is to understand the overall project goals and learn the details necessary to get there. For most projects, this can be accomplished in one or two interviews, which keeps the time and eXpense of a formal planning stage to a minimum.

With enough detail to have a clear idea of the goals, the developer can create an interface and first draft of the primary module to find out if they are headed in the right direction to meet the client’s needs. After that, each cycle takes the client feedback and the remaining list of features to rework the previous section and/or work on new features. Builds are presented to the client as often as every week or two to get feedback before continuing. This process repeats until the project is declared finished by the client.

Client feedback is critical to keep development on track and moving forward. The feedback acts as a critique and approval of the work completed and provides guidance for the next step. Using this method, features can be reworked again and again to tweak them and fine-tune the workflow. The agile development style works well with projects that evolve over the development lifespan or when the functionality is not crystal clear at the outset. If you don’t like it, change it.

The agile method lends itself well to estimated pricing because much of the discovery happens as development unfolds. (To review pricing models, see Part 3: Quotes, Estimates and Change Orders, Oh My! — Understanding Pricing and Billing Models)

Waterfall — A linear step-by-step process in discrete stages from discovery to design to development, then testing and, finally, deployment.

Each stage happens in order without revisiting previous stages. The success of the waterfall style is dependent on the accuracy of the discovery and design stages. Everything is outlined in as much detail as possible to produce a very well-defined and generally rigid blueprint.

Client involvement is heavily front-loaded in waterfall development and usually requires multiple meetings and back-and-forth communication to nail down the eXact details. Once discovery is complete and the final plan is approved, then the actual development can begin.

Development can often be performed relatively quickly because all unknowns should have been discovered and decided. The client may not see a lot of intermediate builds because the blueprint is pretty rigid. This method has somewhat of a “reveal” at the end because not much client feedback is required during development.

Waterfall lends itself well to quotes and fixed-bid pricing because the unknowns should be minimized and the specifications are locked in.

Prototyping — Mock-ups followed by hard coding.

With this development style, the amount of discovery lies somewhere between the waterfall and agile methods. The client outlines the requirements and describes the workflow and then the developer creates mock-ups of what was described. The mock-ups can be tweaked endlessly until they meet client approval. Once approval has been given, the developer can get to work on the actual final product.

Like agile development, there is room for tweaking during the mock-up phase, but like waterfall, once the actual development is under way the plan becomes very rigid and doesn’t allow for much modification.

This method works well with all pricing models, especially if the mock-up phase is limited to just a few iterations.

Keep Knowledge Workers in the Loop

The knowledge workers you used to provide initial information about the requirements of the app are probably the same ones you come back to for testing and feedback. They should be users who are currently performing the tasks the app comprises. They can answer questions and give quality feedback because they know how they do their job when things are slow and when things are chaotic. Allowing the end users to have input during development also reduces resistance to a new system and creates buy-in and a feeling of ownership once the app is deployed. The end users who feel their voices have been heard during development will ultimately turn into the cheerleaders and champions of the project.

Communication is Key

As development unfolds it is important to have clear and constant lines of communication. Communication was important in the pre-planning stages, but it’s even more critical now. You may have an internal vision of what the app should look and feel like. The developer is trying to turn that vision into an operational tool for you and needs detailed information to get there.

Make sure you address the developer’s questions with clear answers. Don’t ignore the requests or get ahead of the program. Developers have to build things in a particular order. Help them stay on track by answering what is asked. It can mean the difference between “dead on” and “almost” in what you end up with. The quicker you respond, the faster you’ll see results.

There will be times when you are looking for particular features that don’t seem to be in the builds you are asked to review. Ask for clarification to make sure those things aren’t missed, but understand that sometimes the part you want to see will come later in the development process. You’ll have to be patient and let the developer lay the foundation first. Work together as a team to make the work satisfying and successful.

Test, Test, Test

Testing should be an ongoing activity. Developers are at a disadvantage for testing because they know how all of the features were built to work. They will test it the way they created it. You will test it the way you want it to work. Those are hardly ever the same.

The developer’s project manager should review each build and test the newly developed features to make sure they function as the developer intended. This is the most basic level of testing. The more important testing is done by the client, particularly by the end users who know how each feature is supposed to facilitate their workflow. They will quickly be able to determine whether the features are efficient, intuitive or even properly address the task at hand. Always make sure to provide feedback to your developer of what you found. This is a very important piece of your partnership.

Deliverables & Deadlines — How You Can Help

How long should it take, what will I get, and when will I get it? These are logical questions and by now you just want to see something. Your developer should have a plan for when the stages of work will be completed and delivered for your review. However, things almost always take longer than either of you want. Generally, the timeline is affected by the speed of feedback from the client, so stay on top of it.

Deployment

Because there is always more to consider and the dream list is ever present, most projects could go on and on. At some point, the client’s point person decides that the solution is deployable and ready for use.

Even after your custom solution is deployed, eXpect additional troubleshooting and tweaking as users begin to really work with it in earnest. That is normal and should be eXpected. Full deployment is really the final stage of testing the integrity of a solution. Any issues should be cataloged and reported to the developer so they can be addressed. Make sure you leave enough time in the budget to manage this final stage of development.

A well-designed solution will be forward-looking so that as the business grows and evolves, new features and functionality can be added easily. Once your app is deployed and you begin using it, you will quickly come up with improvements or additions you’d like. That’s normal. Keep a list so that you can come back to it when the time is right.

Custom software development is an adventure and a process that can teach you a lot about your business. Having a custom solution allows you to run your business the way you want and not have to modify your workflow to accommodate a commercial software package. It gives you a lot of flexibility and the opportunity to grow into areas that might have been unmanageable without it.

The development process can be a nightmare if it is seen as a black box of magic that requires little or no involvement from you. However, with appropriate preparation and participation, you can navigate the process smoothly, taking satisfaction that you created something uniquely suited to your business. Enjoy the adventure!

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