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
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.