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.

As I discussed in my previous post, when we start a project at Phase 2, we always start by looking at the people involved. We look at the different constituents, both internal and external to the organization, what each wants and needs as well as the current problems each face. After we understand what particular groups of people are looking for, we ask the tough but essential business question: If the goals are met and the problems are solved, how does it positively affect the organization’s bottom line and/or mission? What is the measurable success the business will see upon the successful implementation of the software system? This question is so essential to a successful software project it sends my stomach in knots when I think about how often it doesn’t even get discussed. It’s easy, especially for technologists, to fall to the temptation of justifying software just because it’s cool, it seems needed or someone else is using it. It is equally tempting for businesses to reject software recommendations because it seems too expensive, too new or because the benefits aren’t clear. Technologically impressive but ineffective software doesn’t make for good business partnerships but, neither does unimaginative software that misses opportunities for real innovation. In our information age, businesses large and small need great software partners to survive.

The only way to manage a great partnership is to create win/win situations, which is patently impossible if there is not a deep understanding of how each component in a software project will impact the bottom line success of an organization. Clear measures of success, or MOS, provide a common language between a business and their software development partner, help to justify innovation and facilitate long-term relationships by providing quantifiable return on investment.

Creating common language is often difficult between business partners, but is particularly challenging between businesses and their software partners. The intangible nature of software and the obscurity about how it’s created adds tremendous difficulty to the communication. Here’s a real life example: We developed an application for a directional drilling company that helps them manage their drilling process. During the life cycle of the project we discovered that a single job could have multiple drilling paths or tracks instead of just one. This seems like and easy fix, just add another track, but to make the change required substantial revisions to the software. Conversely, things that seem difficult are often easy. On a different project we were asked to add a seemingly complex calculation to a list of items. While this seemed complex to the client it was actually rather easy to implement. Similar situations happen on nearly every software project. In most cases the obscurity of how software works creates a large communication and understanding barrier between a business and its software partner. The common language of Measures Of Success is the key to overcoming this barrier. If we frame our above examples in the language of MOS it will look more like this: obscure software situation A will cost X dollars and benefit the organization in Y ways. That’s an easy decision of any businessperson to make.

The MOS language also allows software developers to justify key, high impact innovations. Smarter, faster, more usable, more elegant, etc. are usually expensive, often prohibitively so for many businesses. Software that is 85% of the way to what a business is looking for but 200% cheaper is normally good enough to go with. The problem is that most software developers are artists at heart; we are in the business to add new and innovative solutions to the world. Getting 85% of the way to an elegant solution is disheartening and all to often we are right to feel discouraged. While an 85% solution based on a budget may run the business just fine, that budget is more often then not, built without a technology imagination that envisions the impact of innovation. Great software partners live in a world shaped by the results of innovations, we are often first movers and adopters of technology that actually changes how we play, work, communicate and even think. 85% doesn’t change the world and we understand this intimately. Fluently speaking the language of MOS allows a developer to help a business owner imagine and then calculate the impact real, but perhaps seemingly expensive, innovations will have on his/her business. This gives software developers the opportunity to create real innovation for their clients.

Finally, speaking MOS brings the opportunity to strengthen the partnership by creating a structure which creates a clear picture of the return on investment of a software project or component. The quickest way for a relationship to turn sour is when one partner or the other perceives real or imagined inequity. A partnership with a software company deteriorates quickly when a project is near to or over budget and there was no clear expectation of the ROI for the project or the components. While 20% over budget on a highly valuable component of a project isn’t critical, that same 20% over budget on a feature that will have little impact on the business becomes a big problem. Without a clear statement about the return on investment of each component in a project it is impossible to make these critical decisions until it’s too late and the relationship is in trouble. Measurable success allows ROI to easily be defined before a line of code is written, making it clear how to prioritize a project.

Defining and fluently speaking the language of MOS is critical to a successful software project and in developing long-term partnerships between a business and a software development partner. It’s one of our required steps and has been a key to our success in the very difficult business of improving our clients’ businesses.

I believe it is important to have a philosophy when approaching problems in all areas of life. In fact, whether it is clearly stated or not, we all approach life’s different problems with some philosophy. Over the years I’ve spent a good deal of time defining, ripping up and then redefining my philosophy of software development. In next few articles I’ll share with you the Phase 2 approach and why we’ve had such success as a result.

Software development, especially custom business software is at once exciting and extremely difficult. Two companies are never the same and so their software needs are never the same. The technology stack I would implement for two separate companies, even in the same industry could be entirely different. This makes creating a solution difficult, though probably not in the way you would think. The software part of software development is, really, fairly easy. Although, I am spoiled by being surrounded by a group of some of the smartest and most talented people I’ve met, writing code to solve a well-defined problem may take a bit of time, but it’s straightforward. The biggest challenge with software development is you and I.

Designing something that is easy for a human to use is difficult.  As a general rule, a device or piece of software that’s easy to use is the result of the design team having remarkable clarity in their understanding of their audience and of putting in a tremendous amount of hours.  In his book The Design of Everyday Things, Donald A. Norman describes design as a process of communication.  Well developed software is a process of creating something that effectively communicates with humans, how we think, and how we work.

My approach to software is that it’s simply a tool to empower humans, like a very sophisticated hammer humans use to do increasingly sophisticated things. Like a hammer, software should enhance the way people work. If your standard hammer didn’t have a handle it wouldn’t be useful. Software must not only be useful it must always be empowering, it should help us work, think, learn, communicate faster, smarter, better. It must be people centric.

When I say people centric, the first thing many think is that the software should have a good user interface, meaning it should be easy to use.  That’s right, but it’s much more than that. Taking our hammer example, a handless hammer has a rather poor user interface, and does little to empower us.  Go a bit further and we start talking about user experience. A hammer could have a brilliantly designed handle but weigh 100lbs. It’s going provide a rather poor user experience when you have a thousand nails to drive.

A brilliant user interface and intuitive user experience is still not enough.  To get elegant and meaningful people centric software design we have to start at a more fundamental level. People centric software design has to start by helping people achieve their goals and solve their problems. If I’m building a fence with screws, a perfectly designed hammer is still worthless for the task at hand.  The critical first step to successful software is developing a deep working knowledge of the wants, needs, goals and problems of the people involved. This is the heart of people centric software design. Good software enhances humans; it must solve human issues and improve human activities.

The Phase 2 mission is to improve our client’s business through software solutions; the only way to do that is by empowering the people in an organization with people centric software solutions. This is the key to success in the face of all the challenges of software development, the required first step in P2’s development process and the foundation of my philosophy on software development.