We began our series on custom software development last time with a discussion on why we don’t believe in fixed bids.   This time, we’ll go into more depth on the various phases of our custom software projects.

As we mentioned last time, we begin with a high-level estimate.  If a client decides to move forward based on this estimate, we then ask to be paid a reasonable sum to complete a thorough analysis of the project requirements.   Here’s a break-down of our entire custom software development process, beginning with the analysis:

1.       Analysis

During the analysis phase, we develop a more accurate (but not exact) estimate of the effort required to complete the project.  We do this by developing user stories – brief statements describing the functionality the software needs to provide.  User stories are written using this formula:

“As a <role>, I want <goal/desire> so that <benefit>”

Working with the client to develop these user stories, we also create the user acceptance tests tied to each user story.  These tests tell the designer and developer how the client will confirm whether each individual user story has been implemented correctly once development is complete.

During analysis, the project may be broken down into phases (releases).   We work with the client to help prioritize what functionality should be included in each release.  The project team also goes through each and every user story together to ensure as many questions as possible are answered up front.  It’s from these elaborated user stories that our estimates are derived.

At the end of the analysis phase, the project team has a good picture of what the project entails and the client has clear documentation of the scope of work and a better estimate of resource requirements, timeline, and cost.   At this point, we proceed with the project or (although we’ve never had this happen) the client is free to take the analysis documentation and move forward with another vendor.

2.        Design

The design phase of the project involves both technical and user interface design. On the technical side, our system architect works with the developers to determine and document the best overall application architecture. This includes details about what technologies will be used for the various parts of the application and how they will communicate with each other.

Our designer creates the user interface for the custom software.  Wireframing is important in this phase – wireframes are rough layout and process sketches that allow the client to confirm the interface will look and work as they expected.  It’s very common during this phase, as the product comes to life visually, to realize there are additional user stories needed or other requirements that fall outside the original project scope.  (More on Change Control in just a bit.)

3.       Development

The development of the software is broken down into smaller units for a couple of reasons.  First, this allows any bugs to be caught early in the development process, and to be more easily traced back to the source of the issue.  Second, it lets us deliver functionality to the client in pieces along the way, and gather feedback more frequently.  This confirms whether we are on the right track at a point when it’s easier (and less expensive) to make adjustments rather than if we’d waited to do this at the very end.

4.        Testing

 Occasionally, clients believe they’ll save money by doing the software testing themselves.  While we certainly offer clients the opportunity to review and sign off on the final product before release, we won’t take on projects that don’t include our own testing process in the scope of work.   We’ve found our own tools and trained testers are critical in ensuring a system meets all requirements, as many bugs as possible are caught and fixed prior to launch, and the system works properly in its intended environment/s.

5.        Client Review

 After we’ve completed thorough testing and before the software is deployed, the client has the opportunity to review the system in a test environment.  This offers a final chance for feedback.  Any bugs the client finds at this point are fixed.  However, if the client feels additional functionality is needed, and it wasn’t included in the original scope, we’ll need to implement our Change Control process (described below).

6.       Deployment

 After the client signs off on the product, the final version is deployed and ready to use.  We continue to monitor the error logs to make sure all is well, and check in regularly with the client.   In addition, our team has a wrap-up meeting after every project to gather feedback and continually improve how we do things.

Change Control Process

We’ve mentioned before that software projects are unpredictable, and changes inevitably come up during the process.  If an out-of-scope change arises at any point during a project, we communicate the following in writing to the client:

• Estimated effort to implement  the change
• Impact on the timeline if done in the current release
• Impact on resource allocation if done in the current release
• Estimated cost
• Our perceived priority
  • Show Stopper (needs to be completed in current release)
  • Nice to Have (could be completed in a future release)
  • Future Enhancement

The client then has the opportunity to ask questions before signing off on the priority level, timeline, and cost. The client may also decide the change is not worth making after seeing the impact to the project. This process is a great way to weed out things that don’t really add value to your product.

Adding Value to Your Investment

Custom software is a major investment, and we work to ensure we’re adding as much value to that investment as we can.  It’s the reason we’re up front from the very beginning about the dangers of fixed bids.  It’s the reason we don’t just go through the motions and do exactly as you tell us–we speak up and offer our own suggestions and ideas to make sure your goals are being met.  It’s the reason we’re responsive throughout the process (and beyond) and why we make sure to explain the technical in a non-technical way.

We hope this post helps you better understand our process of custom software development.   If you have project ideas of your own, please contact us.  We’d love to hear from you.