In the world of software development, what does it mean to deliver a system? If an application is deployed and executes flawlessly but doesn’t meet customer needs, has it delivered successfully? How many projects and products have failed in real world terms because they didn’t mean customer requirements? Likewise how many systems that really nailed the requirements failed on delivery because quality was poor? Or what about the system that perfectly meets requirements and has high quality but completes months late and over budget? Do these examples represent successful delivery?
Often times software professionals confuse system delivery with project management. That is easy to do because the topics are related. One definition of a project is "an activity of fixed duration that will produce a specific product or result." So, if you can successfully execute a project, you should be able to deliver a system, right? Of course there is the issue of those pesky requirements—if you don’t capture them correctly how can you know you’re really delivering the right thing? Some methodologies (can you say Waterfall?) dictate that all your requirements are gathered at the beginning of the project, and everyone agrees on them. That works well as long as the captured requirements are comprehensive and correct and nothing changes along the way. But there is always the possibility that something went a little (or a lot) haywire in the requirements gathering, and you won’t know until the project ends. For long projects this can represent a risk that is not only significant but can remain buried until it’s too late to change.
Other methodologies use development iterations to provide regular review of the “end” product. If a review uncovers something the customer doesn’t like, it can easily be adjusted in the next iteration. This allows changes to be made along the way. It is a great way of ensuring the customer is engaged throughout the project and that the final product conforms to the fickle finger of shifting customer wants.
But is this successful delivery? We know that iterative methodologies (Scrum being the primary example) don’t provide hard and fast commitments for timing or content. The customer has to take it on faith that the review process will allow the right features to be built in as the project progresses. That’s fine and dandy, but it ignores an integral part of system delivery—the necessity for accurate estimates. Most customers want to know in advance what features their application will have, how long it will take and how much it will cost. In fact, most would say a successful delivery must live up to the initial estimates. By that definition, any methodology that allows for loose estimates cannot deliver successfully.
At Stout we know that successful delivery is critical to our business. It is very important that we all agree on what successful system delivery looks like—what are the criteria that define it. That is why we spend countless hours (okay, not really countless, but significant) sharpening our concept of delivery and establishing criteria that will guide our work and help us measure success. At present, our list of necessary (but perhaps not sufficient) attributes for a successful delivery methodology include
As you can see this is not so much a complete methodology as it is a means of gauging our success. At Stout we pride ourselves on remaining agnostic in terms of technology or methods. We seek to maximize our human capital to solve customer problems. The criteria above represent our shared vision of what successful system delivery looks like.