In my previous post I talked about why we have a  Software Bill of Rights and described in detail the first Right.  Let’s talk about the second Right.

1.  Clients have the right to working software, at regular intervals, throughout the implementation life cycle.

2.  Clients have the right to usable software.

3.  Clients have the right to clear, non-technical communication about the software being developed and the development process.

4.  Clients have the right to the best solution available.

5.  Clients have the right to be regularly involved in the software development process.

Good software should work well, but you’ll notice it doesn’t say clients have the right to working software.  “Working” software means different things depending on who you’re talking to at the moment.  To some “working” can mean the software works if you do things just right, if you enter all the correct information, you remember the correct order of operation or you’ve read the instruction manual ten times through.  To others “working” means a piece of software should do everything they can think a user will ever want, everything they can dream up or everything a competitor is doing.

“Usable” means something different and gives us the right foundation.  It implies a balance between over-engineering vs. under-engineering and feature creep vs. under-development.  Usable means the software does everything that it needs to do, nothing more and does so elegantly.

The key to “Usable” is that it puts the focus where it should be, the end user.  While most of the time the client and the developer have great ideas and intentions, neither can be the objective third party necessary to create great software.  By focusing on exactly what end users need inorder to accomplish their tasks we get an unbiased judgement about that button placement, this workflow order or the proper number of navigation elements.

Without fighting for this Right, a project will only be a success for the end user through pure luck.  Watch this video for a hilarious but oh so true example of what happens when you don’t value “Usable”: http://www.youtube.com/watch?v=jVb8EC1Y2xM

In my previous posts I discussed the way Phase 2 develops a deep understanding of our clients’ needs. Once we discover the needs and can fluently speak in the language of measures of success, we create a technology implementation plan. In the next series of posts I’ll cover my philosophies around the process of implementing a custom software project, we call it a Software Bill of Rights, credit to Jeff Palermo for articulating it as such. It’s what every client should expect from us, or any software partner.

There are 5 Rights our clients can expect during the implementation cycle of a project with P2.  While the details of an implementation will change depending on the project and the team, these are the guiding principals.

1.  Clients have the right to working software, at regular intervals, throughout the implementation life cycle.

2.  Clients have the right to usable software.

3.  Clients have the right to clear, non-technical communication about the software being developed and the development process.

4.  Clients have the right to the best solution available.

5.  Clients have the right to be regularly involved in the software development process.

Let’s talk about Right #1: “Clients have the right to working software, at regular intervals, throughout the implementation life cycle.”  I’ll make this bold statement, it is impossible to create an effective, well designed piece of software on the first pass.  Iterations are necessary and great software can only be created through iterations of actually working code and interfaces.  To meet the ultimate vision, a development project requires that the end user get their hands on the software as early and as often as possible.

There are no practical amounts of upfront specifications that will allow a development team to get a software compenent correct the first time.  Clients will forget things they needed, developers will botch routings they shouldn’t have, etc.  This first Right in the Software Bill of Rights defines the essential need for the end user to have access to working components of a piece of software throughout the develoment process.  This creates a fundamental feedback loop between the client and the developer.  Feedback is absolutely necessary for both the client, as they will gain confidence in code they cannot see, and the developers, as they will be able to craft the solution based on user interaction.  It is always a bad idea to take a software spec, have developers go build from it for a month or two, then show the results to the client.

Feedback should happen at least once a week with real working components that the client can touch.  This means developers must be mindful of error handling, bugs and UI issues at all stages of development.  Usable software early in the cycle helps keep the software on the right track, meeting the client’s needs and expectations, as well as allowing a developer to implement creative concepts which are difficult to justify without the client seeing them actually work.

As with all rights, these involve a high level of responsibility; great software implementations require a commitment to this feedback loop from both the client and the developers.  Clients must be committed to the, often substantial, time to use and test the ever changing prototype, giving valuable feedback to the development team.  Developers must be committed to the process of creating incremental, usable pieces of software, which requires a constant committment to working components at all stages, consistent focus and a willingness make user feedback a primary value.

In the end this Right facilitates great, usable software and happy clients.