What Does Delivery Mean?

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

• Light weight—any artifacts included must be absolutely necessary and add value.
• Flexible—to as great an extent possible it must call out suggested, rather than mandated artifacts.
• Scalable—it must be applicable to project teams from one member to many; for projects from small to large in effort.
• Iterative—it must include an iterative flavor because those methodologies have proven most effective for situations where value must be provided sooner rather than later.
• Ensure high quality—it must include significant measure to improve code quality as well as quality of user interfaces, documentation and integration into customer environments.
• Meet customer needs—it must include (in a flexible manner) enough artifacts and process as is necessary to fully capture and implement customer requirements.
• Containable—It must support the ability to establish high level, long term project timing and cost estimates.
• Provide accurate estimates—As experience grows, Stout project managers must be able to use the methodology, tools and processes to provide accurate longer term cost and time estimates with expected accuracy.
• Transparent—Stout project managers must be able to track projects, determine status at any time and accurately report to customer, Stout management and other stakeholders.

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.