What Are Dependencies

Dependencies are one form of constraint for any project. Remember the triple constraint shown in "What Is a Project" Figure ? It says that scope, schedule, and cost are the triple constraints of any project, with quality measurement permeating all three parts. Hard deadlines and specific minimum functionality levels are to be considered constraints to your planning.

Dependencies are any relationship connections between activities in a project that may impact their scheduling. And there are generally many, many dependencies in a software development project. If the work were completely linear, every activity would depend on one other activity (except for "get started"), and the project would take forever to complete (the sum of all the activity durations estimated in "Software Size and Reuse Estimating" and "Estimating Duration and Cost"). If there were no dependencies, everything could be started at the same time and the project would take as long as the longest single activity. Neither of these happens, of course. But they show the extremes within which you want to build a realistic schedule.

After the product-oriented work breakdown structure has been defined, we often assume that certain dependencies between branches are implied. However, the WBS is not a structure well suited to showing dependencies. It does show relationships hierarchically, but it does not show cross-branch dependencies. A better representation for dependencies is the network diagram. How to build a network diagram will be discussed in "Scheduling the Work", but for now, just consider that there is a dependency relationship between two activities represented as a straight line with an arrowhead pointing in the direction of the dependent activity. It means the second (dependent) activity depends on the first activity. A simple two-activity dependency is shown in Figure 1, as Gantt chart activity bars.

You and your project team must find as many of these dependencies amongst the activities in your project WBS as you can. Any you fail to find will likely cause their activities to form a default relationship. Most project management scheduling tools assume no relationship between activities when first entered into the tool. However, as soon as they are linked, a completely linear relationship is assumed (just like those in Figure 1). Reality is generally somewhere in between.

Types of Software Development Dependencies

As stated before, dependencies can be categorized a number of ways. One way is to consider internal versus external dependencies. Another way is to see them as activity-limited or resource-limited. Yet another way is to look at the strength of the dependency. All of these dependencies may not be as clean as you would hope for, and may have some special consequences in the schedule. Nonetheless, all must be identified and understood to build a realistic project schedule.

External versus Internal Dependencies

External dependencies for the development project would include any connections to the work products of other projects. These may be higher-level projects (see Step 2, "Find Any Higher System WBS", in the "Building a WBS for Software" section of "Creating the Work Breakdown Structure") with dependencies on your project's work products or deliverables. Your project may be dependent on other development activities parallel to the software development. An example of this is when there is a higher-level WBS describing a total turnkey system solution under development that includes hardware (customized, or just assembled), software (what you are responsible for), and installation and training (you may or may not be responsible for all or part of this).

Another source for external dependencies is stakeholders. Stakeholders are anyone who has an interest in the project and who might influence it in a positive or negative way. An early project planning activity is to identify stakeholders and plan to manage relationships with them during the course of the project. This minimizes the chances that someone will "come out of nowhere" and destroy the project, since managing expectations and monitoring requirements changes is a big part of managing a software development project.

Stakeholders include, at a minimum: the project team, the sponsor, the functional manager(s), the customer(s), and the user(s). Sometimes the customers' customer or the user's users are included as well. Stakeholder management happens early and throughout the project, and includes communication and soliciting of stakeholder input for planning and scheduling, not just in requirements analysis, but throughout the planning process. Often, it is recommended to assign responsibility to the members of the project team to manage stakeholders on a one-to-one basis. This need not be a time-consuming activity, but the chances for surprise diminish if people on the project take explicit actions (such as occasional emails and short update visits or phone calls) to keep the stakeholders connected to the project and its goal. This is relationship management and is just as important to the success of the project as the technical parts, because projects in business are not just about transactions, but are about relationships, too. The objective of stakeholder management is to obtain and retain stakeholder buy-in to the project's objectives and plans. Individual stakeholder contacts can be selected using a variety of criteria, such as:

● Existing social relationship with a stakeholder - was there already an acquaintance in another context; ● Shared domain - both are database gurus or GUI experts who have attended similar conferences; ● Expect to work together later - maybe as a tester, installer, or beta user of the developed product; ● Common location or language - share the same workplace, campus, city, country, or time zone.

Examples of stakeholder dependencies that are important to many software development projects are major business events important to the customer, or to their customers. If you are developing a software system for a client to resell in the client's specialized marketplace, the customer's marketing team may have events such as trade shows at which they would want to show early versions of the software (often beta versions). This is an important dependency to know about for your project schedule, as it implies some kind of working version to be ready by some (immovable) date. This can really put a lot of pressure on a project team trying to develop a working product for a real deliverable later. It should be treated as a hard project constraint (on the schedule side of the triple constraint triangle). Experience suggests that this kind of event can be overlooked in the planning steps of the project life cycle because they may be on the periphery of knowledge of the direct customer from whom you get most of your requirements information.

Another major source of external dependencies are suppliers. They are also stakeholders, but are usually much closer to the project than most external stakeholders. Often, there are specific contractual relationships that can dictate firm constraints for the project. An example of a supplier dependency might be an interface to a third-party system that your software must communicate with. You may be dependent on another project's schedule in another department, company, or location over which you have little or no control. These become constraints for your project and cause a high need for contingency planning.

Internal dependencies abound in a software development project because the modules, components, and processes are so interrelated. Many of them are a direct result of relationships between components in the product-oriented WBS. For instance, the complete system build is dependent on all of the code for the components being compiled and ready. There are also many integral process dependencies in a software development project. These would include configuration management, project management, and software quality assurance. These tend to be very project specific, but some examples of common dependencies are:

It is recommended that these dependencies are represented as milestones in the software development project plan. Often, there is more than one activity that must be finished to recognize them anyway. Showing external dependencies as explicit milestones shows that your project is dependent on inputs out of your control. These must be kept visible and monitored frequently, as slips in them can cascade throughout the rest of your project plans. Describing project milestones was described in "Creating the Work Breakdown Structure".

Resource versus Activity Dependencies

Another way to view dependency types is based on whether they are resource-driven or activity-driven. Most schedules are derived using the critical path method (CPM, described in "Scheduling the Work") and are presented as Gantt charts. Gantt charts show only the dependencies between the activities in the project and so are activity-driven. They don't show the resource constraints underlying them. This is why executing a resource-leveling algorithm against them in a project management scheduling tool such as Microsoft Project seems to scramble all the activity dates and make the project end-date extend further.

Once you map the availability of resources into the schedule, you get a resource-constrained schedule. A resource-constrained schedule says that some activities cannot start when the predecessor activities have been completed because the resources to do them are not available yet. For example, even though integration and regression testing are scheduled to begin immediately after unit coding and testing have been completed, the testers are not available then, so those activities must slip out until the tester resources become free. This kind of dependency on resource availability becomes very constraining with some types of equipment resources, such as special test harnesses or new devices under development. Resource constraint dependencies can also occur because of calendar windows of availability, such as scheduled test time on a production network, or even the vacation schedules of key members of your project team. Another resource-driven dependency cause can be cost oriented, such as the need to wait until a more favorable time frame for access costs to diminish. An example of this kind of cost-oriented resource constraint could be using teleconferencing facilities at non-peak hours. In "Scheduling the Work" we'll see how to adjust an activity-driven schedule to comprehend resource availability.

Now let's look at a few technical relationships between activities to help us understand how the different software development activities we saw in "Identifying the Tasks and Activities" might relate.

Possible Dependency Relationships

Dependencies can be classified a number ways. One of the most common ways is by the type of their start-finish relationships. Others include classification by their category, and by their source. First, let's look at their start-finish relationships.

Finish-to-Start (FS)

In the finish-to-start (FS) relationship, one activity starts only when the preceding activity finishes. This is the most common type of activity dependency and is the default relationship for linked activities in most project management scheduling tools. The finish-to-start relationship is shown in Figure 2.

An example of a finish-to-start dependency could be that the activity "find cause" must finish before the activity "fix problem" begins, because you can't fix it until you know what to fix. Other illustrations are that "build tests" must finish before "execute tests" starts, and "install software" must finish before "execute software" starts.

Start-to-Start (SS)

The start-to-start (SS) dependency means that one activity can start if and only if the other activity starts. Also a common type of relationship in software development projects, it is very useful for kicking-off a set of simultaneous activities based on a trigger event. An example would be starting the activities "perform project planning", "perform risk assessment" and "perform configuration management" at the same time that "start project" begins. The start-to-start activity relationship is shown in Figure 3.

Finish-to-Finish (FF)

The finish-to-finish (FF) relationship is similar to the start-to-start relationship, in that one activity must tie in with another, but it must finish at the same time. That is, one activity cannot end until the other one does. An example of this relationship could be that the "manage the project" activity cannot end until the "obtain project completion approval" activity is done. This dependency is shown in Figure 4.

Start-to-Finish (SF)

Rarest of all these relationships is the start-to-finish (SF). It means that the first activity cannot finish until the next activity starts. This is similar to the common finish-to-start relationship, except that the dependencies are reversed. It is useful to tie a working activity to a milestone (an event activity with zero duration often linked to several different activity accomplishments), such that the activity cannot end until the milestone is achieved (all the other activities have finished). An example of this might be that the "support customer" activity cannot finish until the "contract ends" milestone occurs. The start-to-finish relationship is shown in Figure 5.

Special Types of Relationships

Lag and lead relationships, hard versus soft dependencies, and the uncertainty principle all can be present to impact the straightforward start and finish relationships.

Lag and Lead Relationships

Useful dependency modifiers are the lag and lead types that can occur with any of the other dependencies discussed so far. Basically, the start or finish of one of the other dependency types is slipped-out (lagged) or pulled-up (led) by a certain time period. A lag is usually indicated with a positive number and a lead uses a negative number added to the start of finish times of their connected activities. This is a useful relationship for activities with a fixed duration connection to some other activity. For instance, you may want to always lag "apply second coat of paint" by two days after "apply first coat of paint" finishes to allow for drying time. The example in Figure 6 shows activity C lagging the finish of activity A by 10 days, even though activity B can start right away.

Hard vs. Soft Dependencies

Yet another way to look at dependencies is to rate their strength of connection. Some connections are physical, that is, it is physically impossible for activity B to start until activity A finishes. For example, it is impossible for the "allow paint to dry" activity to occur before the "apply paint" activity begins. And gravity prevents us from doing the "install roof" activity until the "erect walls" activity finishes. Likewise, we cannot achieve the "code compiled" milestone until the "write code" activity finishes, and we cannot start the "review design specification" activity until the "draft design specification" at least begins. These connections are said to be "hard logic" or "mandatory dependencies". They cannot be broken, and so the activities involved must be sequential, lengthening the total project duration.

However, some dependencies are discretionary, and may allow activities to overlap. An example would be that "paint living room" and "paint bedroom" could occur simultaneously. Often, it is not obvious that the dependency is discretionary. For example, to non-builders it first appears that "build slab foundation", "build walls" and "build chimney" are sequential hard-logic activities. However, most construction managers have learned that framing the walls can begin at the same time as foundation construction by building them laying down on the ground next to the slab. Then when the slab's concrete cures enough to walk on, they can erect the pre-built walls onto the slab and nail the corners together. Software projects are full of these discretionary dependencies. For instance, "draft design specification" need not wait to start until after "complete requirements document" has finished. It may start at the same time, or lag slightly behind, thus allowing the schedule to be compressed a bit. These so-called "soft-logic" dependencies are the project manager's key to constructing an aggressive, but realistic, schedule.

Hard and soft dependencies are summarized in Box 1.

The Uncertainty Principle

So far we have talked about dependencies as if we knew all the relationships. Unfortunately, there is always guesswork in planning because no one can predict the future very well. A project schedule is just an educated guess about how things might go if all the relationships and assumptions hold up. It is no better than the people making the guess, but usually, there are no others with more knowledge about the particular problem or product that the project was chartered to solve or build. Sometimes you plan a schedule with assumptions about dependencies and then find out later that your assumptions were wrong. All you can do is make the best guesses possible with the facts available, and plan to re-plan later.

You can also explicitly allow for the unknowns of the future through the use of contingency buffers, or management reserve. This is generally shown in a Gantt chart schedule as a separate activity bar, prior to a milestone. But it doesn't appear in a WBS since it is not an activity that you can assign people to. It is just there to absorb the uncertainty of the future. Of course, if you do no planning whatsoever, then your whole project is just one long activity bar - a big guess.

In "Scheduling the Work" and in "Determining Project Risks" we will learn how to handle the inherent uncertainty in any software development project.

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.