Software project management is an art and science of planning and leading software projects.^[1] It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

• 4Issue
• 7External links

History[edit]

In the 1970s and 1980s, the software industry grew very quickly, as computer companies quickly recognized the relatively low cost of software production compared to hardware production and circuitry. To manage new development efforts, companies applied the established project management methods, but project schedulesslipped during test runs, especially when confusion occurred in the gray zone between the user specifications and the delivered software. To be able to avoid these problems, software project management methods focused on matching user requirements to delivered products, in a method known now as the waterfall model.

As the industry has matured, analysis of software project management failures has shown that the following are the most common causes:^[2][3][4]

1. Insufficient end-user involvement
2. Poor communication among customers, developers, users and project managers
3. Unrealistic or unarticulated project goals
4. Inaccurate estimates of needed resources
5. Badly defined or incomplete system requirements and specifications
6. Poor reporting of the project's status
7. Poorly managed risks
8. Use of immature technology
9. Inability to handle the project's complexity
10. Sloppy development practices
11. Stakeholder politics (e.g. absence of executive support, or politics between the customer and end-users)
12. Commercial pressures

The first five items in the list above show the difficulties articulating the needs of the client in such a way that proper resources can deliver the proper project goals. Specific software project management tools are useful and often necessary, but the true art in software project management is applying the correct method and then using tools to support the method. Without a method, tools are worthless. Since the 1960s, several proprietary software project management methods have been developed by software manufacturers for their own use, while computer consulting firms have also developed similar methods for their clients. Today software project management methods are still evolving, but the current trend leads away from the waterfall model to a more cyclic project delivery model that imitates a software development process.

Software development process[edit]

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:

• Interpersonal communication and conflict management and resolution. Active, frequent and honest communication is the most important factor in increasing the likelihood of project success and mitigating problematic projects. The development team should seek end-user involvement and encourage user input in the development process. Not having users involved can lead to misinterpretation of requirements, insensitivity to changing customer needs, and unrealistic expectations on the part of the client. Software developers, users, project managers, customers and project sponsors need to communicate regularly and frequently. The information gained from these discussions allows the project team to analyze the strengths, weaknesses, opportunities and threats (SWOT) and to act on that information to benefit from opportunities and to minimize threats. Even bad news may be good if it is communicated relatively early, because problems can be mitigated if they are not discovered too late. For example, casual conversation with users, team members, and other stakeholders may often surface potential problems sooner than formal meetings. All communications need to be intellectually honest and authentic, and regular, frequent, high quality criticism of development work is necessary, as long as it is provided in a calm, respectful, constructive, non-accusatory, non-angry fashion. Frequent casual communications between developers and end-users, and between project managers and clients, are necessary to keep the project relevant, useful and effective for the end-users, and within the bounds of what can be completed. Effective interpersonal communication and conflict management and resolution are the key to software project management. No methodology or process improvement strategy can overcome serious problems in communication or mismanagement of interpersonal conflict. Moreover, outcomes associated with such methodologies and process improvement strategies are enhanced with better communication. The communication must focus on whether the team understands the project charter and whether the team is making progress towards that goal. End-users, software developers and project managers must frequently ask the elementary, simple questions that help identify problems before they fester into near-disasters. While end-user participation, effective communication and teamwork are not sufficient, they are necessary to ensure a good outcome, and their absence will almost surely lead to a bad outcome.^[3][4][5]
• Risk management is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost-benefit analysis as well as a list of fallback options for project failure, called a contingency plan.
  • A subset of risk management is Opportunity Management, which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact. Though theoretically handled in the same way, using the term 'opportunity' rather than the somewhat negative term 'risk' helps to keep a team focused on possible positive outcomes of any given risk register in their projects, such as spin-off projects, windfalls, and free extra resources.
• Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system^[1] Requirements management, which includes Requirements analysis, is an important part of the software engineering process; whereby business analysts or software developers identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.
• Change management is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to scope (project management) and then controlling changes and communicating to relevant stakeholders. Change impact analysis of new or altered scope, which includes Requirements analysis at the change level, is an important part of the software engineering process; whereby business analysts or software developers identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include risk-benefit analysis before approval.
• Software configuration management is the process of identifying, and documenting the scope itself, which is the software product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include version control, naming convention (programming), and software archival agreements.
• Release management is the process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before releasing to users, there will often be more environments for testing, called unit testing, system testing, or integration testing, before release to User acceptance testing (UAT).
  • A subset of release management that is gaining attention is Data Management, as obviously the users can only test based on data that they know, and 'real' data is only in the software environment called 'production'. In order to test their work, programmers must therefore also often create 'dummy data' or 'data stubs'. Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule.

Project planning, execution, monitoring and control[edit]

The purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion. The project execution is the process of completing the tasks defined in the project plan.

The purpose of project monitoring and control is to keep the team and management up to date on the project's progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, change control is used to keep the products up to date.

Issue[edit]

In computing, the term 'issue' is a unit of work to accomplish an improvement in a system.^{[citation needed]} An issue could be a bug, a requested feature, task, missing documentation, and so forth.

For example, OpenOffice.org used to call their modified version of Bugzilla IssueZilla. As of September 2010, they call their system Issue Tracker.^{[needs update]}

Severity levels[edit]

Issues are often categorized in terms of severity levels. Different companies have different definitions of severities, but some of the most common ones are:

High

The bug or issue affects a crucial part of a system, and must be fixed in order for it to resume normal operation.

Medium

The bug or issue affects a minor part of a system, but has some impact on its operation. This severity level is assigned when a non-central requirement of a system is affected.

Low / Fixed

The bug or issue affects a minor part of a system, and has very little impact on its operation. This severity level is assigned when a non-central requirement of a system (and with lower importance) is affected.

Trivial (cosmetic, aesthetic)

The system works correctly, but the appearance does not match the expected one. For example: wrong colors, too much or too little spacing between contents, incorrect font sizes, typos, etc. This is the lowest severity issue.

In many software companies,^[which?] issues are often investigated by quality assurance analysts when they verify a system for correctness, and then assigned to the developer(s) that are responsible for resolving them. They can also be assigned by system users during the User Acceptance Testing (UAT) phase.

Issues are communicated using Issue or Defect Tracking Systems. In some other cases,^{[example needed]} emails or instant messengers are used.

Philosophy[edit]

As a subdiscipline of project management, some regard the management of software development akin to the management of manufacturing, which can be performed by someone with management skills, but no programming skills. John C. Reynolds rebuts this view, and argues that software development is entirely design work, and compares a manager who cannot program to the managing editor of a newspaper who cannot write.^[6]

References[edit]

1. ^ ^abStellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN978-0-596-00948-9. Archived from the original on 2015-02-09.
2. ^'Why Software Fails', in IEEE Spectrum
3. ^ ^abProducing Open Source Software: How to Run a Successful Free Software Project (e-book, freely downloadable), by Karl Fogel
4. ^ ^abRobert Frese and Vicki Sauter, 'Improving your odds for software project success,' IEEE Engineering Management Review, Vol. 42, No. 4, Fourth Quarter, Dec 2014
5. ^Philip Greenspun, in Jessica Livingston's Founders at Work (2007), ISBN1-59059-714-1
6. ^John C. Reynolds, Some thoughts on teaching programming and programming languages, SIGPLAN Notices, Volume 43, Issue 11, November 2008, p.108: 'Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing editor who cannot write.'

General

• 1058-1998 - IEEE Standard for Software Project Management Plans. 1998. doi:10.1109/IEEESTD.1998.88822. ISBN978-0-7381-1448-4.
• Jalote, Pankaj (2002). Software project management in practice. Addison-Wesley. ISBN0-201-73721-3.
• Murali Chemuturi, Thomas M. Cagley Jr. & (2010). Software Project Management: Best Practices, Tools and Techniques. J.Ross Publishing. ISBN978-1-60427-034-1.

External links[edit]

• Resources on Software Project Management from Dan Galorath

Project failure[edit]

• Robert Frese (2003-12-16). 'PROJECT SUCCESS AND FAILURE: WHAT IS SUCCESS, WHAT IS FAILURE, AND HOW CAN YOU IMPROVE YOUR ODDS FOR SUCCESS?'. University of Missouri-St. Louis. Retrieved 2015-05-13.
• Joseph Gulla (February 2012). 'Seven Reasons IT Projects Fail'. IBM Systems Magazine. Retrieved 2015-05-13.

Most Read Articles

Supply chain network planners don't have it easy. Their job is to evaluate complex tradeoffs among supply chain components, maximizing profits and minimizing costs within the limits of relevant constraints and intangible considerations.

Because that is such a complex task, many planners use network-modeling software. But having good software is just a first step, not a complete solution. For one thing, modeling results and recommendations are only as good as the user's problem formulation, assumptions, and data. Furthermore, if key decision makers cannot see or understand what was done during the modeling may not accept the results and recommendations.

Network planners can avoid such problems by following a standardized, step-by-step planning process that is explicit, well documented, and visual. One approach we strongly recommend is Systematic Network Planning (SNP), a standardized methodology for conducting network-planning projects. SNP uses the High Performance Planning model developed by consultant Richard Muther. This model has been used in Muther's well-known methods for systematic planning of supply chain facilities and material handling systems since the 1960s.

SNP is based on the three fundamental components of every network plan:

1. Variables—aspects of the network plan that can be changed in a model (for example, facility location, product type, and demand);

2. Sensitivities—the degrees to which modeled costs and performance vary in response to changes in variables; and

3. Scenarios—sets of possible changes to the network that is being planned.

The simplified, or short form, of SNP is presented in this article. The simplified procedure improves planners' effectiveness on projects that use an already existing model to address problems of modest scope, such as:

• the best existing location at which to add capacity
• the impact of a change in inventory policy
• the effect of adding or closing a warehouse
• inventory and resource planning for seasonal or peak periods
• contingency planning for supply interruptions or loss of capacity

For larger-scale network-planning projects, a fuller version of SNP adds phases and additional steps but still rests on the same fundamentals of variables, sensitivities, and scenarios.

For those who already have modeling software and know how to use it, the six steps of Simplified SNP can be mastered in less than a day; the steps simply standardize sound modeling and project-management practices. (It is important to note here that while appropriate optimization software must be used, Simplified SNP is not dependent on any specific algorithm or software product.)

For companies that are just developing modeling capabilities, SNP's standardization assures consistent service and results. Moreover, because SNP makes the modeling process more visible and its steps more explicit, even experienced modelers can benefit from the improved communication and explanation of results that it offers. For users at all levels of expertise, SNP can help avoid the pitfalls, oversights, and rework that are all too common in the day-to-day use of network-modeling tools.

The six steps
The article presents and explains a key document for each of the six steps of Simplified SNP.¹ These steps include:

1. Orient the project. The objective of this step is to understand the scope of the project and schedule important deadlines and milestones. The related document is the Orientation & Issues Worksheet.

2. Define the variables. The purpose of this step is to create a modeling framework for the variables and trade-offs. These are recorded on the Variables Summary Sheet.

3. Analyze the sensitivities. The output of this step is a validated baseline model that replicates the company's current performance. This is recorded on the Baseline Validation Worksheet.

4. Create scenarios. In this step, the company models the results for alternative network plans relative to the baseline. These results are summarized on the Scenario Summary Worksheet.

5. Evaluate the alternatives. During this phase, the project team will select a network plan from among the alternatives. All of the analysis for this step is summarized on the Alternatives Analysis Worksheet.

6. Detail and do. In this last step, the team creates a detailed protocol for implementing the selected network plan, which is represented on the Detail and Do Worksheet.

In the following pages, we illustrate the use of Simplified SNP by the fictitious company Mountain Trail Tonic Inc. (MTT), a growing manufacturer and distributor of organic juices. In our example, MTT is using Simplified SNP to determine where to add manufacturing capacity and justify the cost of the additional manufacturing line.

Step 1: Orient the project
Step 1 organizes the project and ensures that it is well defined, clearly understood, and realistically scheduled. The project team members begin by identifying the project's objectives and scope. They then try to understand all of the issues connected with the problem to be solved and identify the elements to be modeled. Finally, they document and rate the significance of the planning issues, and then create a schedule for the network analysis, complete with deadlines.

SNP uses a standard, one-page form called the Orientation & Issues Worksheet to capture all of this information. This form typically is completed during a meeting with the sponsoring executive, appropriate subject-matter experts, and representatives from finance and from each of the operating units that may be affected by the project. To help planners remain focused on the critical network-planning issues and assure that the project resolves the most important ones, the worksheet also lists and rates the issues' significance or importance as follows:

A – Abnormally high
E – Especially high
I – Important
O – Ordinary
U – Unimportant

Issues or factors that are beyond the planners' control or are outside the project's scope are flagged with an 'X.'

Figure 1 shows this worksheet for MTT. The worksheet includes a sample of the company's key planning issues, actions required for addressing those issues, and a project schedule.

In our MTT example, only one facility produces 32ounce plastic bottles. Because of increasing sales volumes and product proliferation, this facility will not be able to meet expected demand. MTT's network planners have therefore been asked to cost-justify upgrading an existing line to add a second 'big bottle' manufacturing line. The planners must also determine which of six existing plants will be the best location for the upgrade. The planners will use an existing sourcing model and software to find the location with the lowest total cost. In addition, the decision must also consider other, less tangible factors such as capacity relief, ease of implementation, and risk of line shutdown. For MTT, these factors are as important as cost, and they vary by plant location.

Step 2: Define the variables
Once the project has been defined and outlined, the planners diagram the network to be modeled and gather the information required for constructing the model, which will weigh different trade-offs among the variables. In applications of Simplified SNP, the planners typically are adapting an existing model rather than developing an entirely new one. In our MTT example, the company has already developed a sourcing model using a popular demandplanning software package and will adapt it for the 'big bottle' analysis by substituting relevant data.

Step 2 also involves defining relevant constraints, documenting assumptions, and writing any formulas or algebraic expressions that will be used to model the network. Constraints are physical limitations or policies that restrict the capacities and capabilities of locations and lanes and their resources. Assumptions are descriptions of typical or anticipated conditions that are used to clarify the model's scope, simplify the model, and/or describe the manner in which some variables will be treated. For example, MTT's model is simplified by assuming that transportation and raw materials are always available. Formulas used to express costs or resource performance also are listed.

All of this work is summarized on the Variables Summary Sheet, as seen in Figure 2. This summary assures that planners and the ultimate decision makers agree on all aspects of the modeling exercise before it begins.

The upper left corner of the Variables Summary Sheet defines the scope of the network model in terms of the following design characteristics:

• Locations and lanes included
• Products included and product hierarchy
• Resources included
• Demand data type and duration
• Time buckets
• Unit of measure

For MTT, the locations include all of its manufacturing plants, outside bottlers, and distribution centers (DCs). These consist of one raw material supplier, six other (contract) bottlers, six MTT manufacturing plants, and 42 branch distribution centers. These are represented in the diagram that appears under the heading 'Visualization.' This diagram uses an adaptation of industry-standard, operation-process charting symbols. (Note that in our example, the manufacturing plants are located in fictitious towns in a six-state area of the eastern United States, and DCs are identified by number rather than by location name.) Lanes include all transportation routes between those locations. All of them are potentially active. Products are manufactured in certain plants and are crossdocked through other plants. In this way, a branch DC can receive product from any of the plants.

The resources to be modeled are manufacturing lines, transportation, and storage for all juice products, whether purchased or manufactured. The model's results will be based on 12 months of historical demand data in weekly time buckets, measured in cases. The 12-month historical horizon makes sense, as management wants to know what MTT's reported financial results would have been with an additional big bottle line. Weekly buckets will detect seasonal and other demand variations, and cases are the company's common measure of output.

The data source summary in the upper right-hand corner of the Variables Summary Sheet lists the data needed for the model and where it will come from. This will include demand- and resource-related data as well as cost-related data. For MTT, data about products will come from the company's demand-planning information system (abbreviated as CIMMS in Figure 2). Data about resources will be manually entered. Manufacturing cost data will come from transaction records in the company's enterprise resource planning (ERP) system. Other cost data will come from a variety of sources.

The 'model constraints' section of the sheet specifies the constraints or limitations on the resources that are being modeled. In some cases, these constraints are physical; for example, MTT's manufacturing lines must run at least 80 hours but no more than 140 hours in a week. Others are a matter of cost, such as the need to produce minimum lots.

The Variables Summary Sheet also lists formulas for expressing costs or resource performance. In our example, MTT, defines its transportation cost as:

Transportation cost = X1* (two-way private fleet cost, for example US $900 per round trip)
+ X₂*(one-way incentive for common carrier use, for example US $600 per one-way trip)
+ X₃*(backhaul incentive factor, for example US $200 per backhaul)
+ X₄*(reverse-logistics factor, i.e. container and damaged- goods return)
Note: X₁, X₂, X₃, and X₄ are trip frequencies for each lane, and * represents 'multiplied by.'

This formula shows that the planners are using a weighted-average approach to estimate a single transportation cost for each lane, rather than modeling each kind of transportation as a separate resource on each lane. The latter approach would greatly increase the complexity of the model without significantly improving the precision of the results.

Key parameters for each manufacturing plant are summarized in a table at the bottom of the worksheet in Figure 2. In MTT's case, the parameters include number of lines, maximum and minimum capacities expressed as hours of operation, and storage capacity expressed as number of pallets. Manufacturing line speeds are expressed simply as 'demonstrated speed'; that is, the modeler will use the line speeds in cases per hour that are normally used by the production planners when scheduling each line.

Step 3: Analyze the sensitivities
Now that the model has been constructed, it needs to be validated. In Step 3, the planners run the model using optimization software and identify any violations of constraints or infeasible (that is, unreasonable) results. The planners then troubleshoot the model to eliminate infeasibilities.

Troubleshooting the model is an iterative process. The planners systematically relax the violated 'hard' constraints to make them 'soft' policy constraints with high penalty costs for violation. The model is run again to identify the location or lane with the highest cumulative penalty cost. The planners then examine all variables, constraints, and assumptions that might be contributing to the penalty cost. Once they have been identified, the planners tweak the parametric value of the appropriate resources; add missing lanes, locations, or products; or adjust constraints and assumptions as appropriate. The model is run again and the process repeated until all constraints have been honored. Following Simplified SNP Steps 1 and 2 will significantly reduce the number of iterations required. Next, the planners run the model again and finetune it to establish a baseline that replicates current network performance. Fine-tuning typically involves adding additional resources and slightly changing the value of the parameters until the model's results match—either exactly or with acceptable variances— the actual network performance for the chosen baseline period. The fine-tuned results for demand variables and cost variables, as well as the constraints met, are summarized on the Baseline Validation Worksheet in Figure 3.

The ultimate purpose of Step 3 is to validate the model. Validation compares the model's results to the actual performance of the current network for the modeled period. This exercise builds credibility: The smaller the variance, the more accurate the model— and the greater the acceptance of the model's results. Notes and explanations on the worksheet explain any changes that were made to the model and the reasons for the variances between its results and the network's actual performance.

In practice, validation is difficult and may take several days, even when the model has been systematically defined and documented. Validation can take much longer if the planners' approach is less systematic and the model constraints are poorly documented.

Step 4: Create scenarios
In Step 4, the planners develop scenarios that represent alternative network plans. Each scenario makes one or more of the following changes to the baseline model:

• adding or deleting products or locations
• adding or deleting resources
• adding or deleting transportation lanes
• changing which locations serve which customer demand
• changing network flows and sources of supply
• adding or relaxing constraints

The planners then collect summary statistics for each alternative plan and document the results on a series of Scenario Summary Sheets. The Scenario Summary Sheet records changes from the baseline and summarizes model results in terms of demand, resource utilization, lanes, and flow. A diagram shows what the network would look like for that particular scenario. Download fifa 12 full version.

In our MTT example, several scenarios place the 32-ounce upgrade at different plants. Figure 4 shows the Scenario Summary Sheet for scenario 1, which places the upgrade at the Jonesville plant. As the 'Setup Summary' shows, transportation lanes to branch distribution centers are set up to receive products from Jonesville or Sommersville, with an added constraint that each DC order must be for a full truckload. When the model was run, the optimizer software moved 300,000 cases of 32-ounce production from Sommersville to Jonesville. Of these cases, 200,000 formerly were cross-docked through Jonesville to its branch DCs. In terms of resources, Sommersville was relieved of 450 hours per year of production, while 300 hours were added to Jonesville. The difference is due to the greater efficiency of the newly upgraded line in Jonesville. These results are reported in the sheet's 'Results Summary' section.

This scenario also showed that the distribution network would have to be reworked. Network lane assignments were changed for three distribution centers. DC 23 could not satisfy Jonesville's full truckload constraint, so the modeling software reassigned it to the Sommersville plant. Meanwhile, DCs 11 and 12, along with all of the DCs in Virginia and West Virginia, now receive all of their 32-ounce products from Jonesville. In the baseline scenario, these DCs had been served by the Sommersville plant.

Some cost categories that are a concern at the outset of modeling often prove to be insignificant once results are in hand. In Figure 4, for example, cross-docking costs and reduced overtime are insignificant and will not influence the choice of network plan. But key decision makers frequently focus their attention on the 'Cost Summary' section of the Scenario Summary Sheet, and the planners therefore have chosen to include those essentially irrelevant costs in order to remove any concerns or doubts.

Those who manage the network may also be skeptical of scenario runs that predict significant cost savings compared to current conditions. They may challenge assumptions, parameters, or constraints and ask the planners to make adjustments until the scenario run yields a more modest improvement—one that they are willing to be accountable for obtaining. The wise planner anticipates this give-and-take and budgets time to run optimistic, pessimistic, and 'most likely' cases and present them to management. These savings scenarios are recorded in the 'Scenario Cases' columns in the Cost Summary section.

Step 5: Evaluate the alternatives
In Step 5 the planners evaluate the alternative network plans that were developed in Step 4, and those involved in decision making compare and select the most preferred plan. Evaluation, using the Alternatives Analysis Worksheet, typically takes two forms:

• Cost analysis—comparing relevant costs among the scenarios and their network plans.
• Intangible analysis—considering factors that cannot be easily modeled or measured in economic terms.

Cost analysis generally is straightforward. Modeling software typically computes each alternative's difference from the baseline for each element of the total cost. When comparing alternatives, planners must decide whether to show all costs or only those that are affected by the proposed alternatives. When the impact of proposed changes on total cost is small, it may be preferable to present and compare only the costs that are actually affected. This will magnify the cost differences among the alternatives.

In Figure 5, the four alternative plans compare what MTT's annual costs would have been if 32-ounce capacity had been added at one of four existing plants: Jonesville, Briansville, Vicksburg, and Madison. Jonesville's costs (Alternative I) are the lowest and would have saved about US $700,000 per year over the current, or baseline, network. The remaining locations would have saved between US $391,000 and US $581,000. These savings easily justify the upgrade of a production line.

Naturally MTT would like to implement the network plan with the lowest total cost. But intangible factors must also be considered when choosing the most advantageous plan. In this example, annual costs differ by only 1 percent among the four alternatives. With such a small difference, cost alone should not determine which plan is best. When two or more plans yield similar costs, comparing intangibles can identify which is best. Examples of relevant intangibles include exposure to various types of risk, ease of implementation, ability to respond to demand changes, fit with the organization's structure, and labor- or facilities-related considerations.

To measure the importance of intangibles, SNP uses the weighted-factor approach shown in the lower portion of Figure 5. The planners list relevant factors, and managers assign weights reflecting each factor's relative importance in the evaluation.

Next, those who will implement and operate the new network evaluate and rate the likely effectiveness of each alternative in addressing each intangible factor. SNP uses the vowel code convention of A, E, I, O, U, and X in descending order of effectiveness, where A = 4, E = 3, I = 2, O = 1, and U = 0. By convention, SNP assigns a weight of 10 to the most important factor. A rating of 'X' disqualifies a plan unless the objectionable feature can be fixed. (The meanings of these codes, shown in the bottom lefthand corner of Figure 5, are different from those discussed in Step 1.)

After the planners have rated all of the plans under consideration relative to all of the intangible factors, they multiply the ratings' numerical values by the factor weights and add them together to arrive at total scores for each plan. The highest score indicates the best network plan from an intangibles perspective. Ideally, the highest-scoring plan will also have the lowest total cost. But if not, this procedure will still reveal the intangible benefits of the more costly network plans. Moreover, when a cost comparison does not indicate a clear winner, the weighted-factor calculation will help to identify which plan is best and why.

In our example, the lowest-cost alternative, Jonesville, is ruled out because it rates 'X' on the risk of line shutdown. Of the remaining alternatives, Briansville scores highest at 84. It offers more capacity relief and easier implementation, and its savings are somewhat greater than Vicksburg (Alternative III) or Madison (Alternative IV). For these reasons, MTT selected Briansville for the 32-ounce bottling line upgrade.

Step 6: Detail and do
In the final step, representatives of the affected organizations complete a Detail and Do Worksheet. This worksheet outlines the actions that will be required to implement the network plan selected in Step 5 and schedules the implementation. (If the purpose of the network-planning project is simply to conduct an analysis and make a presentation, no actual changes will be made during this step.)

If the company does want to make changes, the planners first prepare a Gantt chart with the implementation schedule. A Gantt chart serves as a communication tool, outlining the tasks and actions needed to change the network, the individual(s) responsible for each one, and the scheduled time period for conducting each task or action. The top half of Figure 6 shows MTT's Gantt chart.

The network plan must, of course, be implemented by professionals in the field. But the network planners should be involved: first, so they can better understand what is required to implement change, and second, so they can confirm the effectiveness of their recommendations. During implementation, it is a good idea to periodically measure performance against the schedule and take action, if needed, to keep the project moving.

A post-implementation audit captures actual results and measures variances between projected and actual savings and costs. Such audits typically are performed between 90 days and one year after an implementation has been completed. During the audit, planners should seek explanations for any significant variances.

This practice provides useful lessons for future modeling and improves the overall effectiveness of network planning. The lower half of Figure 6 proves that point: Because fuel-price increases eliminated half of MTT's projected transportation savings, the planners will probably include fuel-price projections in future models of this type.

SNP: The difference between good and great
Do you need SNP, or is your current practice good enough? The 10-point Network Planning Spot Audit in Figure 7 may help you decide. Once you have effective modeling software in place and know how to use it, these 10 considerations will make the difference between excellent results and those that are simply good or perhaps even poor.

In the authors' experience, SNP's step-by-step structure and documentation make it easy to involve operations personnel in the planning process and help to consistently achieve excellence in all 10 of the audit areas:

• Step 1 and its Orientation & Issues Worksheet assure quick start-up.
• Step 2 and the Variables Summary Sheet improve visualization and model setup.
• Step 3 and the Baseline Validation Worksheet speed up this time-consuming task, assuring accuracy and ready acceptance of results.
• Step 4 and the Scenario Summary Sheet make sure that the right alternatives are considered and that management is offered valid choices.
• Step 5 evaluates all relevant factors in addition to supply chain costs.
• Step 6 and its Gantt chart enable timely implementation and learning from actual results.

Systematic Network Planning is designed to avoid the pitfalls, oversights, and rework that are all too common in the day-to-day use of network-modeling tools. Whether network planners are highly experienced or new to this important function, SNP assures that modeling projects will be both effective and accurate.

Endnote:

1. Copies of these and other worksheets, all of which are proprietary and copyrighted, are available at no charge to readers of CSCMP's Supply Chain Quarterly at www.RichardMuther.com. A booklet on Systematic Network Planning written by the authors will be published later this year by Management & Industrial Research Publications. For more information, telephone 770-798-7792 (Marietta, Georgia, U.S.A.)

Join the Discussion

After you comment, click Post. If you're not already logged in, you will be asked to log in or register.

We Want to Hear From You! We invite you to share your thoughts and opinions about this article by sending an e-mail to ?Subject=Letter to the Editor: Quarter 2008: Six steps to effective network planning'>. We will publish selected readers' comments in future issues of CSCMP's Supply Chain Quarterly. Correspondence may be edited for clarity or for length.

• Why additive manufacturing needs blockchain (Quarter 1 2019)
• Automotive supply chain braces for change (Quarter 0)
• Delivering on 'direct to consumer' in the CPG industry (Quarter 4 2018)
• Talent shortage to hit manufacturing hard (Quarter 4 2018)