Why Software Development Projects Are Difficult For Publishers

by Jeff Wood

Jun 2003

Software development projects, by their very nature, are often difficult for publishers and publishing companies to get their heads around. Editorial staff members involved in such projects often feel that they are being asked to work and think in ways that are completely unnatural to them. Unlike the relatively fluid editorial process, all of the requirements need to be specified well in advance, and changing those requirements down the road is often times impossible or is met with great resistance. Development project teams aim for incremental milestones, rather than a single publication date. There also seems to be this secret "methodology" in place that makes perfect sense to everyone in IT, but leaves editorial staff with more questions than answers.

If you are a non-technical manager or executive and find yourself involved in a software development project, whether it's for internal system or electronic product development, here is some advice that can help to ease the pain.

Know your stuff

Knowing your business and market is one of the most critical pieces to the puzzle. Let's say that you envision a specific electronic product for one of your markets, and you want IT to build that product. You must first know what the market requires, as well as have a thorough understanding of what the competition is offering in this space. For example, if it's a PDA product, this means loading the competition's software onto your handheld and getting into the trenches with users to see how the product fits into their daily lives. Do whatever is necessary to really understand what the market needs. We have seen many projects fail because market opinion contradicted editorial vision, because the vision was driven by interesting new technical capabilities rather by market demand, or because the product owner was unable to articulate exactly what he or she meant. Before a project team is ever assembled, market surveys should be conducted and subject matter experts should be consulted. The extracted results of these queries should be dissected, merged, and documented thoroughly, and should form the foundation for the creation of business case.

Of course, all of this might require much more effort than is necessary for more traditional print products, and it feels like unknown territory to many editors. The natural human inclination is often to avoid the hard work by handing off an incomplete vision to IT, and hope that they will somehow build the right product. It rarely works out that way. While IT can be helpful in brainstorming about new electronic product capabilities, ultimately it is not their responsibility. As the product visionary, you need to own the concept.

The software development process is not very different than the standard print editorial process. It is not uncommon on larger projects for the requirements gathering phase to extend many months, much like the creation and editorial process for print products. Assigning and completing milestones and following a strict project plan is critical to the success of these projects. And the ever-present scope creep needs to be managed firmly and consistently (as many authors do!) in order to continually make progress on the project.

However, there are some differences. For instance, print products must be perfect from day one. Revisions mean reprints, or update packets that must be inconveniently carried around with the book. Electronic products and internal systems don't have to be perfect initially. There is opportunity to improve them over time, and in the case of electronic products, that can actually be an advantage (it gives you an excuse to remind your market about your product and allows you to make choices/investment incrementally). This concept seems difficult for editorial and production staff, who therefore have trouble prioritizing requirements—everything becomes of primary importance.

Do your part

Gathering and thoroughly documenting business and functional requirements is a critical phase prior to the development of the product. Think of these as an architect's blueprint: once building begins, only very minor modifications can be made. As the project moves forward, the business requirements need to be translated into functional requirements. Without proper management, this transition can easily become clouded with overly-technical and, to the non-technical lay person, incomprehensible jargon. Functional requirements should not be driven by IT or development vendors; they should reflect how users should interact with the application you are envisioning.

You need to make every attempt to understand the software development process as a whole, and uncover those areas where you can make the most impact. In our experience, editorial staff asked to review requirements often spend very little time doing so, or won't take the time to really understand what was written if they were confused by it.

If you are the primary stakeholder or project sponsor and will ultimately be responsible for a new product in the marketplace or the success of a new system in meeting business objectives, you will be required to skillfully champion the software system from concept through launch. Take ownership of the project early in the requirements phase—only you can ensure that the end result meets your (and your markets') expectations.

Demand a process that works for you

It is important to develop a manageable and logical requirements priority system. Always be thinking about (and trying to extract from team members) the requirements that are real market differentiators versus those that are necessary simply to compete. You need to make a compelling business case for this product or system. Make every possible attempt to segment and prioritize your requirements, especially on larger projects or those with many stakeholders. Identifying requirements as "Required-Core," "Required-Differentiating," "Desirable" is a good baseline. Agreeing to and assigning priorities early on will help to facilitate these final categorizations. Be aware that there may also be very different groupings of product requirements for different markets.

Fight the temptation to turn over a requirements document to the development team and wait to see what the final product comes out looking like (and the temptation to blame them if it doesn't come out right). Work with the development team to understand their process and scheduled milestones, and continue to meet with them all through their specification creation and development phases. Most importantly, negotiate with IT to use a process that works for you. They find your ways of thinking as alien as you do theirs, and might not anticipate how they can best help you.

This could mean asking for specific methods of documenting functional specifications and development by utilizing use cases and prototyping phases. Use cases describe how users interact with systems and have become an important way to capture the functional requirements of an electronic product. They are written in a language that is easy to understand by non-technical team members, and at the same time, provide developers with a descriptive interaction of users and systems that form the foundation of the application. Prototypes are an excellent checkpoint of the requirements and can be based on the use cases. In many instances, it is recommended that the prototypes be reviewed by a target market segment and subject matter experts.

Learn your lessons

Learn about the ways in which software development projects fail. Talk to project managers or pick up a book or two on the subject. Knowing generally how and when software development projects fail can help you to avoid these pitfalls. Getting this kind of information within your own organization can help you lead the project team around potential hazards.

Software development does not need to be a mysterious, black box process. Taking the time to understand this process will provide greater synchronicity between the project team and the development staff in jointly understanding the vision.