Strategies for Successful Development

Process and technology for small teams building real software

The No-Spec Spec: Identity

Posted by S4SD (Seth Morris) on 2008/09/24

This piece of the No-Spec Spec defines the what to the Fit document’s why. It is generally owned by the product or program manager and should answer the question "Does this feature/process/change belong in this project?"

It is amazing to me how often the answer to that question is "no" and the company doesn’t discover it until after the feature, process, or change has been implemented.

Again, this should be short. It can be as short as one sentence (such as McConnell’s Vision Statement: "A description of the highest-level objectives of the project") or it could stretch to a page or two, with one section (the "is not" list) potentially growing continuously.

These are the parts you may want to include.

Vision Statement – the key objectives

This is straight from McConnell and the SPSG: What are the objectives of the product and the project? This can include all of the company’s business goals, engineering’s technical goals, the user’s business needs, etc. Keep this to simple statements, bullet lists, etc., and avoid "fluffy" words.

There is all sorts of good advice out there on goal definition. SMART—Specific, Measurable, Attainable, Realistic, and Time-bound—for example, is popular, simple, and useful. I’ll just add/highlight a couple that are often missed.

  • Initiated and maintained by the company or team

    The hope that "our major competitor loses market share each quarter through the new year" is a great wish, but not a practicable goal.

    Initiated by the team means that the ability to make a change (release software, fix bugs, upgrade technology, …) exists within the organization. Outside resources may be necessary; if so, the organization should have the ability to go get those resources.

    Maintained by the team means that the goal has to stay within the organization’s power. This may mean coming into conflict with the company’s history and maturity around follow-through. If only internal causes threaten maintaining the goal then it still meets this criteria (although the chance of success may drop).

  • Has an explicit test for achievement

    If you want to "Improve performance of the system," you need to include a way to test that kind of performance. You don’t have to state how much the project wants to improve performance, unless that is a known goal, but you do need to indicate what kind of measurable performance. Even semi-subjective measurements can be acceptable ("most users in the survey group agree that it feels faster" is a fine goal), but goals that don’t have a way to test are open to misinterpretation.

    I worked on one project to update the base drive image copied onto all new units a customer shipped. We spent weeks tuning the OS install, tweaking the application setup, and researching the data most likely to be useful pre-loaded. Then, being engineers, we went about making the process repeatable: writing scripts to recreate the base image, writing queries to isolate the necessary data, and so forth. The product manager came to me and expressed concern over the time it was taking, especially since he had seen it basically running in the dev pit. I explained and showed him the project plan (which he had seen, but had not discussed in detail) and he asked me a great question: What was our deliverable? I responded that we were giving him a process that produced his drive image reliably and that could accommodate changes to the drive image in days instead of weeks.

    He replied that the image was updated once every 3-4 years and all he needed was a hard drive to stick in a duplicator. The last couple of weeks of the project were useless to him and the repeatability we were building was probably going to be outdated by the next time they tried to do this. Throughout the project, we described the project as "Recreate the source image." Stated as a testable goal from the product manager’s point of view, it should have been "Have a hard drive to duplicate on new boxes." We would have been done weeks earlier.

The Is/Is-Not List – project scope and boundaries

Invariably, someone wants to add something to a project. It’s a normal and often useful instinct: this train is rolling, let’s throw another bag on instead of having to start a whole second train. Some of these will be great ideas; some will be feature creep or attempts to change the product direction.

The Is/Is-Not list works to counter this by listing what is explicitly included in the product and project, by explicitly listing exclusions, and by keeping a hard and clear line between the two.

At the start of the project, you probably know what the project is to some reasonable degree:
– …is the follow-on to version 3.2
– …is minor UI enhancements to almost every screen
– …is the new data layer (formerly code-named "Skippy")
– …is data integration with SQL Server 2008
– …is new charting modules for for the Analytics module

Note that the Is/Is-Not doesn’t have to be as well-structured as the Vision should be. Is/Is-Not should contain the colloquial shorthand your teams use. Feel free to use code names if people like them, or those "cute" names that pop up at every company now and then. If everyone knows what "finally implement Special Sauce" is, giving it another, more detailed name doesn’t do anyone any good at this stage. This isn’t a spec: it’s a list of the areas that are being opened up for change and the kinds of change that are in scope.

At the start, the Is-Not list may be very short, but in practice it is often as long as the Is list.
– …is not implementing the UI redesign hanging in Marketing’s conference room
– …is not a rewrite of the Analytics module flow
– …is not refactoring the GUI engine
– …is not the "Auto-Advise" feature

List the projects, proposals, and pipe dreams that float around often enough and have active champions that you know they might try to shoe-horn into this project1.

As the project proceeds, every time a large change is rejected, add it to the Is-Not list. You don’t want to add every little change or bug, but do list things people feel passionate about—those are the ones that will keep coming back if you don’t do something with them.

In addition to cutting off discussion on revisiting changes, the Is-Not list helps engineers keep their creep and gold-plating closer to scope. But the major value is in giving feature advocates a place to "park" their ideas2. The Is-Not list is more visible and less cluttered than a product backlog, a feature database, or whatever you’re using to plan future work. It ties the proposal to a project and gives the project postmortem/lessons learned a place to see what was excluded and make recommendations to include specific things in the next project.

As features are cut, especially partially- or completely-finished features, definitely add them to the Is-Not list.

Using the Identity document

This doc should be short enough to post on a wall somewhere, but even if it isn’t you should put the project vision everywhere you can: add it to the footer in templates for project docs, put it on the wall, whatever. The Is list shouldn’t be nearly as detailed as a functional spec, and not as detailed as most MRDs, but it is a good start for project planning; development and QA can often start to rough out some plans from it (a good place to start Sliding Window Scheduling).

When the project is closing down, the Is/Is-Not list comes back into the forefront as a check that the project did what it intended to and no more. The Is-Not list also serves to suggest changes that might be important enough to implement soon.

1) If you do decide to make a change and include them, just edit the doc and tell every one. One of the wonderful things about docs is how easy they are to change. Keep a history if you like (highly recommended, actually), but nothing is carved in stone unless you have a very, very specialized plotter.

2) This is similar to the "parking lot" often used in classrooms and at meeting. It has a great effect on people who have a visible indication that their request has been heard and caused action, even if it isn’t being enacted immediately.

Listening to: Steely Dan – A Decade of Steely Dan – Deacon Blues



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: