Late Requirements

Keeping software development projects on schedule is difficult enough when you are in control of the activities and tasks scheduled; it becomes infinitely more difficult when you have to rely on your customer meeting deadlines. Project managers are confronted by two issues when gathering requirements to a schedule: dealing with the customer or client and the compulsion to ensure a thorough job is done collecting them. The first issue is immutable: the customer is always the customer and you have fewer options in dealing with them than you have with team members. The second issue can be managed.

Planning the right tasks and activities to thoroughly examine the businesses needs for the software and identifying the right representatives to engage is the best safeguard against incomplete or incorrect requirements, but even this will not guarantee your schedule will be met. Typically when we gather requirements we depend on customer representatives who have jobs to perform and whose daily activities can’t be dropped to accommodate requirements gathering activities. The best we can do is to plot their schedules as accurately as possible and then work around those schedules. The problem here is that those schedules aren’t cast in stone and are subject to day to day changes. These problems become compounded when the planned requirement gathering activities are group oriented. All of these challenges can lead to our requirements gathering activities falling behind schedule.

Now that we know the circumstances that brought us to this uncomfortable place, let’s look at how to extricate ourselves. Perhaps the most obvious option is to re-examine your schedule. If requirements gathering activities have been delayed by 1 month, pushing the completion date out by 1 month would address the problem. This solution may be the right one providing there is no rush for your software system. Typically this is not the case though. The new system or application is a response to a market demand or a business case and delaying delivery will cause lost revenue or increased costs. Choosing this option will seldom appeal to your customer.

It may be possible to make up the lost time by increasing development and testing resources to shrink the development and testing windows. The feasibility of this option will depend on the size and nature of your project so careful analysis will have to be done before choosing it. Now it would seem intuitive that if development and testing of the software was initially planned for a team of 20 over 12 months, that you could shrink the schedule by 6 months by doubling the team. Everything else being equal, this will still allow you to complete the work on budget. The law of "diminishing returns” contradicts this. Putting 2 programmers on a 2 month task will rarely be effective in delivering the task in 1 month. It may be possible to make up the lost time by increasing resources in which case it is very likely that the increase required will increase the project budget. The increase may be acceptable to the customer providing the business case is not significantly altered. If it is, you will find that your customer has little appetite for absorbing the additional costs. If this is the only option available, don’t be surprised if the customer decides to cancel the project.

There is another option however, that may allow the project to meet the original schedule and budget. This option involves what some project managers refer to as "crashing the schedule”. Crashing the schedule in this case means planning for some activities that were originally planned to occur sequentially, to be done in parallel. There are some requirements in every software development project which are not integral to the system which could be developed after building activities have begun. The trick is to identify the requirements that are integral, or "core” and those that are not. Core requirements are those that must be defined, refined, and approved before design can begin. Segregating requirements into core and non-core categories will enable design work to begin on the core requirements while the rest of the requirements are being debated.

There are some Software Development Lifecycle methodologieswhich support this approach to building a software system incrementally. One example is Scrum, which takes an iterative approach to development and prioritizes requirements with top priority requirements being addressed in the first iterations or "sprints”. If you have chosen this method to develop your software you should have your requirements prioritized and the top priorities already defined and approved. You also won’t be managing the project as this methodology does not require a project manager. Other methodologies rely on gathering requirements before beginning building activities. Even RUP requires that the requirements for a given iteration be defined before design begins.

The distinction between core and non-core requirements is a significant one. Failing to make this distinction can add significant effort and time to your project as your development team has to revisit code because a new requirement cannot be delivered without a change to code already developed. Your software architect (aka Chief Architect, Head Architect) can be a significant help by distinguishing core requirements from non-core ones. It is the architect’s job to determine how the new system will hang together (or how the new application will fit into the existing system). This determination will influence the sequence in which the application must be built. For example, functions such as messaging, error handling, and how users and their privileges will be handled, should be part of your core requirements because these functions will support the entire system. Another way to look at it is that all the features and functions of your new system will interact with one another and the design and implementation of one function will impose restrictions on another. It doesn’t make sense to have an infrequently used function constrain the design of one that is frequently used. Put another way, core functions are those that are used all the time and therefore influence system performance. These will be designed to yield performance and functionality that will best suit performance requirements as well as functional requirements and will constrain how less frequently used functions are designed.

This division of requirements into core and non-core must begin with the Business Requirements Document and could begin with the Statement of Work (SOW), or Scope Statement, although you could not be expected to spot the need for this action at that early stage. Requirements for core functionality should have a higher priority than requirements for non-core functionality. This prioritization may not always be borne out by the prioritization in the BRD because that prioritization will be a business one rather than a functional one. Nevertheless, any requirement identified as a low priority in the BRD and as a core requirement should be reviewed to ensure you haven’t miss-interpreted it.

There will not be a direct one-to-one relationship between requirements and functions. Some requirements will be delivered by a set of functions and some functions will support a number of requirements. This tends to be particularly true of the functions that are identified as core. Since the new application is constructed of software functions, you must rationalize functions with requirements. This will take a careful reading of the BRD, or the system description you are using to determine what implications each requirement has on a given function. The goal here is to design the function in such a way as to provide maximum compatibility with the requirements it touches and still meet performance goals. Your architect should be able to provide this analysis for you, should you have one on your team. If not, choose a seasoned systems analyst to do the analysis.

Once you have your requirements divided into the core and non-core categories you can determine which of the core requirements have not been defined to date. The goal here is to get design work started on time; the deadline for finalizing these requirements will precede the start date for that work. Be clear with your customer that any slippage of that date will push final delivery out. Since this constitutes a change in project approach, yourProject Charter will change and this must be agreed upon by your project sponsor and/or steering committee. If this change occurs during the planning phase of the project, no change request is needed. If not, the change must be supported by an approved request.

Dividing requirements into core and non-core categories means that your project now has at least 2 iterations. For projects using the Waterfall SDLC this will mean a fundamental change in approach and schedule. Examine the requirements relegated to the non-core category to determine if they can all be delivered at the same time or whether they will be delivered in stages. This determination will decide the number of iterations your project will have; you can’t begin design of requirements that are not signed off. Your iterations will determine when requirements must be finalized. Choose a schedule that your customer can commit to and then make it clear that any deviation from this schedule must lead to the implementation of one of the other remedies already discussed.

The success of dividing the requirements into core and non-core categories to make up for lost time depends on how well core requirements are identified, how well functions are related to requirements and how well the software is architected. Paying close attention to these areas and having the right subject matter experts (SMEs) analyze them will make this fix successful. Failure to do so will result in a project which falls further behind schedule and may result in a badly architected system.