Part Four in the Series: Software Development Guide for Business Leaders

For larger development projects, using the Incremental Build Model for software development can improve project success and get useful products into production quicker. By using an incremental build model to develop smaller, fully functional components, you are breaking the project into smaller, more easily digestible chunks. This model leads to greater success, improved client approval, and better functionality.

Why Break the Project into Smaller Increments?

The project management team may break a larger project into smaller pieces when delivering, delighting and getting customer feedback are important. Accomplish this by having the project entirely defined, scoped and then chunked into deliverable components.

Sometimes the best plan of attack on any large project is to use a divide and conquer technique. Using this approach helps to deliver good software solutions to the customer quickly. Using this strategy produces customer goodwill, a feedback channel from the client and helps the project team achieve a series of small successes which is great for morale.

We suggest that for any big project you consider breaking it down using the Incremental Build model so you can divide and conquer it and delight and deliver to your customer.

The solution starts to sound like an Agile project, but it has nothing to do with the project management technique employed. It’s a strategy to deliver quickly and get valuable customer feedback.

Use of Incremental on Larger Projects

Project managers and clients can decide to break a larger a project into smaller increments. An Incremental Model’s success hinges on a complete scope and requirements. Once detailed and documented, the project can be broken into smaller, deliverable, pieces and delivered in stages throughout the project.

Breaking a larger project into smaller increments can reduce the cost of initial product delivery but may increase the cost of the whole project.

Another benefit of an incremental build is the stream of customer feedback on each increment that can help to identify deficiencies, additional features, and product changes which lead to a better final product.

By breaking the project into smaller increments, then using a traditional waterfall project management technique, the project manager can plan, define, develop and test each increment.

Because few changes are made within any single increment complete regression testing to identify development deficiencies can happen quickly.

How Does the Incremental Build Strategy Improve Success, Client Approval, and Functionality?

Your customer, whether an internal department or an external client, wants to get their hands on their applications as soon as they can. When you deliver, using an Incremental Model, you delight them by delivering; then engage them for feedback. The result is a better product and a stronger relationship with your customer.

On your next larger development project, use the Incremental Build Strategy to break it down into smaller chunks to delight your customer, deliver quicker and to develop better projects.

CoreSolutions of London, Ontario, is a locally acclaimed software development firm with over 25 years of experience. CoreSolutions’s team of experts, including developers and project managers, build web or mobile applications using the latest technology and tools and will assist you through all phases of the project including brainstorming, requirements planning and project management. Connect with CoreSolutions today to start your project with a Free Business Systems Requirement.

As a business leader, you may be considering developing a web application for your team, your company or customer use. Congrats! Let’s get your project off to a good start with a clear and concise Software Requirements process.

Throughout this series of Software Development Guide for Business Leaders, we will help you to understand the elements of success in a software development project.

As the leader, (aka project sponsor), your contribution will be paramount in defining the software expectations and your input will be required throughout the project lifecycle to ensure that everything stays on track and there are no surprises at the end of the project.

Finding the Aces – What is a Software Requirement?

Project Managers break software requirements into functional and non-functional components.

Functional requirements are simple documents that outline the inputs, the behavior of the software and the outputs. An example could include a login screen. You will have very specific inputs (typically username and password fields) and actions for different scenarios (login success, login failed, reset password, etc.)

The non-functional requirements include details such as performance requirements, security, or reliability. A good example would include a requirement for role-based security. This would change the features of the system depending on which user level an individual has logged in (administrator, contributor, general users, etc.)

Seems simple, right? It’s critical that we get these software requirements right before we start developing. Product quality, delivery timelines, and budget are all dependent on the quality of requirements. So, what can we do stack the deck in our favour?

Shuffling Methodologies – How to Develop Software Requirements

There were two studies performed in the 1990’s that help us create better software today. A study by the ESPI in 1995 found that 40 – 60% of all defects discovered in a software project traced back to errors made during the requirements stage. An earlier study in 1994 by the Standish Group helped us understand that 13.1% of projects fail due to incomplete requirements and 8.8% of projects fail due to rapidity changing requirements (Girase, 2012). It may have been a long time ago… but this is largely still true today.

There are two mainstream project development methodologies in existence today. The older Waterfall method that has been around for decades and is still used today by many organizations and the more recent Agile Software Development Model which was established with the publication of the Agile Manifesto in February of 2001.

The Agile Software Development Model made many strides to resolve and improve project requirements gathering, however, our experience is that both Agile and Waterfall have their advantages and disadvantages and they are not for suitable for every situation. Traditional project management models, like Waterfall, still require documentation of a requirement before the coding and testing start while Agile is iterative and requirements are refined as they are built. Agile is flexible and allows for fast feedback and changes as the project unfolds.

Internal development teams should get more value from Agile as they have easy access to stakeholders who are very engaged in the software development process. Not every organization has the resources or bandwidth to be engaged through the entire process and most stakeholders will want to have the clear start and end dates (and project budget) before starting a development project.

We have used both Agile and Waterfall and while they both have their benefits, we feel that we’ve found a sweet spot in between the two methodologies. We approach our development through a hybrid model that utilizes the best from both models and focuses on a visual representation of requirements and the design of a functional prototype before any coding starts. To bring our clients software visions to life, our Milestone development process borrows the parts we like from Agile (The iterative nature of the project, and the fast feedback) and from more traditional development like waterfall (having a planned finish date). This ensures that our stakeholders are active participants in the design and functionality of the system on an ongoing basis. Through this process, we eliminate surprises at the end of the project.

The Final Cut – Defining and Documenting Your Software Requirements

So, you have developed spectacular objectives, your project is guaranteed to be a smashing success now, right? Well, no. Simply having clear and well-defined objectives isn’t necessarily enough. One of the biggest challenges in software development (or any other longer-term project) is that we have to capture and document the requirements specifically enough to limit how open they are to interpretation. Clear direction is essential, or your development team may come back to you to clarify, or worse, deliver what they “thought you wanted”. Have you ever had someone come back to you and ask you to clarify an objective or thought only to realize that they were on the wrong track?

So where do you capture requirements? Well if you’re like the vast majority, you’re probably capturing requirements in simple Excel files. However, there are much better solutions available that offer so much more. At CoreSolutions, we really focus on capturing and bringing your vision to life. Capturing requirements in a visual way is a key component to clarifying expectations and limiting revisions. We document the requirements through a software system called iRise. This allows us to develop an interactive prototype before a single line of code is written. The actual development coding is the most expensive part of any software development process so, by developing a working prototype of the system before we start development, we can more accurately estimate the development cost and stay on budget. While this is more upfront work, it does lead to greater project success and overall experience. Let’s face it, the requirements need to be captured at some point during the project so why not do that work upfront so you have a better grasp of scope, timeline, and budget. It just makes sense.

The figure above is an example of a screen that’s part of a prototype in iRise.

As we outlined throughout this article, with so much riding on effective requirements planning, it’s critically important to define and document goals and deliverables. Whichever project methodology you decide to use, capturing requirements means a lot of upfront work, but it’s worth it to ensure the success of your project. By using an effective project methodology, and really understanding and documenting your system requirements upfront, you will effectively be stacking the deck for your project’s success. If you want to stack the deck even more and need help planning out your next software project, reach out to us. We love helping prepare software visions and have been great at it for over 25 years.

CoreSolutions’ team of experts, including developers and project managers, build web and mobile applications using the Agile Methodology and tools. CoreSolutions will assist you in all phases of your project including:

·         Brainstorming;

·         Requirements Planning & Gathering;

·         Prototype Design;

·         Project Management.

Connect with CoreSolutions today to start your project by completing a Project Profile.

Works Cited

Girase, N. M. (2012, May). airccse.org. Retrieved 12 10, 2016, from http://airccse.org/journal/ijsea/papers/3312ijsea05.pdf

Mitre. (n.d.). Eliciting, Collecting, and Developing Requirements. Retrieved 12 12, 2016, from www.mitre.org: https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements