The backstory for most software projects is predictable: A business opportunity is identified, and features are listed that will exploit that opportunity. At some point the list of items starts to take shape as a tool or application. Suddenly you're staring at a full-blown software project full of ideas and promise but without a clear path to accomplish any of it.
But first a little background. This is about managing successful development projects, not how to write a program. The difference is that a successful development project will be managed toward a defined and non-technical goal. To be successful at writing a program requires more than the delivery of something technical, which ignores the business goals that prompted the effort in the first place.
To look at it differently: If every application is born out of a goal to achieve something, the success or failure of the application should be measured against that initial goal, not simply the delivery of a computer program. Describing our effort as “managing a successful development project” helps us maintain sight of real success.
We bring this perspective to every conversation, and it helps us recognize when the conversation becomes application-centric instead of success-centric. We've identified three of the most common reasons this happens; here is the first of Three Myths of Software Projects:
Myth #1: The Features Are Everything
If we build all these cool features, we'll have the best application ever.
Most people can most easily articulate their application as a list of features. At its simplest, this list includes some functions that produce some results.
A common (and cliché, at this point) example would be a blogging application. We could write that the following features would make a basic blogging application:
- Admin authentication
- Text editing & styling
- Ability to publish text
Seems pretty good, right? If you have these things, you'll have a blogging application. If you rewrite this list in sentences, then you'll have what we call stories. (This is part of the Agile approach to managing software.) These same features rewritten in natural language might look like this:
- An admin should be able to log in and change credentials.
- An admin should be able to create, edit, and delete essays.
- An admin should be able to publish essays.
You can see how the second list fills in some of the details assumed, but left undescribed, in the first list. In fact, the first list now seems a bit oversimplified compared to the second list. But this second list isn’t accurate or comprehensive either. This is the trap of The Features Are Everything Myth: A successful application is simply a combination of features. No matter how detailed your stories or feature lists are written, your custom application is inherently more complicated.
The trap of the features list is that they always seem accurate and comprehensive but always turn out later to be vague and oversimplified.
Before you launch any serious investment, be sure to document the initial goals you were seeking before you began. Those are your success factors and should be compared with the delivered features at regular intervals. If you do this, you’ll have a steady target and will be more likely to achieve measurable success.
