Software Development Methodology & Principles

Delivering 'value' in a software project might sound straightforward. We (humans that is) have been building software for decades now. We have Universities to teach the profession of software development in depth, we have millions of developers world wide and endless books and guides on the topic.

Why is it then that on average, software projects fail at horrendously high rates? Depending on which reference you cite, approximately 50% of large projects are deemed 'failures' by those who purchased them with something in the order of 10% of large projects abandoned around the time of launch. Imagine if 10% of the new buildings built could never be inhabited or 50% were deemed failures such that people eagerly sought to replace them. Such is the current state of software development and these figures replicate themselves around the globe and up and down the budget scale.

Delivering a complex software project is in fact not straight forward. One of the most common issues in our experience is the willingness of both the developer and the client to invest enough time to truly come to a common understanding of requirements. Over the 10 years we've been in business we've trialed a number of processes. The following is our current process and represents our best thinking on this complex topic to date:

Step 1. The Initial Price Estimate.

In talking with clients, we generally get a feel for the approximate cost of a project based on their initial description of system requirements. At this point, we share our estimate with clients. Both parties acknowledge the likelihood that the final price will vary, but logic is straightforward. If our expectations and those of the client vary widely, an honest and frank discussion can be had and if appropriate, the process ends here on good terms.

Client Investment: None

Step 2. The Prototype / Wireframe / Mockup

Based on a common expectation for the kind of investment a project may require, next we move to Prototyping. Here we create a dummy version of website, a mock up that shows all the functionality required by all user types, but where none of this is actually operational.

The beauty of this process (compared with our previous approach of writing up large specification documents) is that clients can see a visual representation of the final product. Our overwhelming experience is that clients, upon reviewing the prototype quickly identify misunderstandings, ideas that won't work well in practice and a broad range of general improvements. Clients often thoroughly enjoy the process too. Then, the prototype is updated based on feedback and presented again.

This process continues until you, the client, sign off that the software does indeed represent a useful tool. It should be noted for the software purists out there, we also internally document a database schema and "use cases" for the project.

Client Investment: Hourly Rate, typically 25% - 30% of the estimated development budget.

Aside: You, the client, own the prototype. You have the right to shop it around for competitive quotes or use it for demonstrations as required. You've paid for it, so you own it.

Step 3. Itemised Quote

We'll provide you with an itemised quote for the project. Often clients will elect to include and exclude various elements to fit budgetary or time constraints.

Client Investment: None for producing the quote.

Step 4. Build the smallest 'usable' version of the software possible.

This part is critical. Often clients stretch themselves financially to afford everything they want in their new website up front. This is a recipe for disaster. The reason is that every successful application of significance got that way through refinement over time. Spend all your money in one hit and you'll rue the day.

You see, it's only through experience in using software that we really learn what's useful and, just as importantly, what (despite great planning) needs modification.

Instead, if you build and deploy the smallest, most simple version of the software possible you can use the feedback of your staff and customers to refine over time.

Client Investment: Agreed fixed price.

Step 5. Move to a prioritised two week development cycle.

For any medium to large system, once the software is live, you'll have consistent feedback and the priorities almost always change quickly from those discussed during the initial development. That's fine, in fact it's healthy.

We're having great success at present with one to two week development cycles. We break tasks down into small deliverables and live by the mantra 'deliver small, deliver often'. This approach maximises the capacity for clients, their staff and their customers to give rich feedback through the process.

Also, keep developers and users as close as possible. We like to let developers be part of conference calls or do work onsite. Remember, software developers need to learn your business before they can build a solution for you. The closer developers are to their customers, the more often they'll intuitively make the right choices.

Indeed, in our Noble Samurai business, we have developers do tech support periodically. It's often comical to see a developer dive into fixing a problem after they've had to answer a number of queries related to it.

Client Investment: Whilst these smaller phases can be developed on a series of agreed fixed prices, in most cases clients, who by this time now trust our capacity to deliver good value, prefer to be billed on a time and materials basis.

Step 6. Maintenance

The maintenance phase of a project is often simply a slower version of the above step, where enhancements are made at a slower rate.

Justifying the Alliance Methodology

We've found the above methodology has the following benefits:

1. Common price expectations are established early in the process to avoid time wasting for both parties.
2. Prototypes help clients explore and think deeply about their requirements and ensure that customers actually get the system they want. We previously found that if we only gave the standard set of written specifications to clients we'd often find ourselves in an argument with customers about the interpretation of a specific point of detail in the estimate.
3. Happily, this is now far less common.
4. Fixed price gives security - clients, especially new clients, feel secure in having a fixed price quote for their proposed application.
5. Budget allowance and feedback enables our clients to refine the application to more closely meet their users requirements.

Have a project you're looking to develop? Contact us for a quote.