Work Breakdown Structures for IT and Software Work

Work breakdown structures or WBS are used to break down tasks so that budget and time allocations can be made. A work breakdown structure should separate recurring costs like typical labor costs from non-recurring costs such as hardware purchases or consultants hired for a specific project. A work break down structure may need to fit a customer's management structure or outsourced contractors.

Software work breakdown structures can take two forms, the product hierarchy and the activity hierarchy. In the product hierarchy, the software components are the basis of the work structure breakdown, such as software modules and subsystems. The activity hierarchy breaks down work based on activities like requirements definition, code creation and software testing.

Work breakdown structures or WBS require elements to be broken out based on the percentage of the total effort or amount of time dedicated to the task. As projects become larger, the size of WBS elements tend to become smaller relative to the size of the project. For example, for small projects, a WBS element should be at least 7% of the budget.

WBS elements can also be measured by the amount of time required to perform the task; WBS elements for small projects should not be smaller than half of a man-month, 40 hours a week multiplied by two weeks for a total of 80 hours. WBS elements must be kept to a minimum size to provide granularity when planning while large enough that tracking them does not waste management time. For medium projects, each WBS element should consume at least 1% of the total budget or require at least three total man-months, though the work may be performed by several people.

Increasing the number of WBS elements will increase the management time required to maintain the schedule and update plans. Choose a WBS that has fewer elements when management is already busy or does not want to micromanage according to a granular WBS.

In short, breaking down the work structure into too many pieces leads to too much time spent working on tracking expenses and schedules than resolving problems that move the project forward.

IT WBS can take the form of breaking down the WBS hierarchy by software activity. Software activity WBS closely follows the waterfall software development model.

The eight most common major software project activities are requirements analysis, product design, programming/coding, planning of software testing, verification and validation or V&V of software, project office / management functions, configuration management and software documentation.

Requirements analysis is the process of determining the requirements the software must meet. What does the software need to do? What does the customer want it to do? The initial collection of software requirements occurs at this step along with a prioritization of requirements.

Product design is when the software development plan and budgets are created along with the product control plan. What is the quality assurance plan? What IT standards must the final software product meet? What are the final software requirements that coders must meet? If there is not sufficient budget or schedule for all software requirements, the priorities of each requirement will reviewed and some of them dropped before product design starts.
Product design activity focuses on the logical data structure, the program component hierarchy and review of the software interfaces to be used. All aspects of the product design are reviewed to ensure that the formal requirements are met.

Programming is when the code is written. Unit testing for individual components like daughter cards and memory cards plugged into a computer or sensors connected to a computer occur at this step. Databases may be created. Component level documentation is written at this time; this documentation will include the purpose of each code module and an explanation of its logic. This documentation will help testers understand what the code is supposed to do even if it fails to perform as expected.

Planning of software testing activities include the creation of software test plans, the purchase of software testing tools if necessary, the creation of software test plans and selection of software testers. Software testing processes may be selected at this time, such as whether users will be brought in for user acceptance testing, if iterative software testing and development will occur or if beta versions will be released to select users before a final software version is released.

Verification and validation is when the software testing is performed. All software modules are combined into a single software product and tested. All software interfaces such as file up-loads, data exports for reports or database connections are tested. Software requirements are also tested, verifying that the final product meets the formal software requirements.
Project office functions are those activities on the project level. Creation of the work breakdown structure, budgeting, issuing purchase orders, assigning personnel according to plan, handling payroll and managing subcontracts fall under this activity.

Configuration management is the process of tracking software code modules and software executables. All code is regularly checked in to ensure that it is saved while configuration managers ensure that software testers are running tests on the latest version of the software. Software quality assurance may be its own software activity or be combined with configuration management.

Software documentation activities include creating user training documentation, user reference manuals, help desk troubleshooting documentation and system administrator documentation.

An IT work breakdown structure can be broken into separate software product hierarchies. Software product hierarchies must include all code modules, subsystems, software systems and software interfaces. The software product hierarchies can be further broken down into software routines if they are large enough to classify as their own as WBS elements. For example, a product verification code module need a thousand hours to define and code, while the rest of the data interfaces combined require this much time. In this case, the product verification routine becomes a separate element.

Activities such as coding and test occur when the software product hierarchy is used. However, several of the software development life-cycle steps such as coding and testing are performed and charged to the software product element instead of being lumped together with the effort and costs associated with the same activities are performed on other software products. During the requirements analysis phase, the requirements are generated for the entire software product.

Product design will break down the project into separate software products that will become WBS elements. For example, a financial software application may be broken down into a check register module, a tax software module, an accounts payable/receivable module and a software interface that will download information from the customer's bank website.

Software requirements flow down from the requirements analysis into a set of final requirements for each software module. Then the coding, software test planning, unit testing and module level documentation are performed independently for each software module. Project office / management functions may be broken down and tracked for each software product or run as a single oversight unit for all software products.

For example, the coders for the tax software module will charge their time to the tax software product’s charge number. Coders for the bank interface will fall under the bank interface product, whereas they would log their time and budget to the software coding element if a software activity WBS were used.

During the verification and validation software life-cycle step, all of the software products are combined and tested together. Debugging and software quality assurance like maintaining the code library may continue to be charged to each software product. Software documentation and software quality assurance to meet IT standards like ISO IT security standards are typically done for the final software product.

IT WBS can be integrated into activity based costing. Work breakdown structures can treat each software module as a cost center, similar to activity based costing tracks all costs from materials to engineering time to a particular product line.

Work breakdown structures may also treat the entire program or software project as a single product. In this case, activity based costing treats the entire software development as part of the same cost center, though coders and testers may have separate charge numbers for their time.