Manager’s Tool Kit
Success through Managing the Technology
-by Bruce Elbert
Introducing a new service or application, or upgrading an existing one, is a process of planning and action directed around the critical technologies that deliver market or operating advantage. Major systems like DIRECTV, as well as small successes like adding a data feed to an existing video distribution network, require a clear process that is well managed. Otherwise, the project runs off course and wastes money needlessly. Successful projects combine process with technology and leadership.
Technology is the essential ingredient in satellite communications for achieving an advantage in these highly-competitive times, where deals and opportunities are won or lost on a thread. Successful technology management allows an organization to perform in complex industries like ours by following a process of project management and systems engineering. Leadership is what ties process and technology together. Any project or service development activity needs a committed, experienced and competent leader to provide vision, direction and coaching to team members at the time and place where it is needed most.
Managing the technology takes people and time to do the work, as well as financial support. Some will view this as expensive overhead that will delay action. In my experience, a lack of homework ahead of committing to an application system or service will probably result in costly delays at the back end or even total failure in the business. While applying them does not guarantee success in the market, they are how major programs in aerospace and telecommunications systems are implemented on time and within budget. Corporations that apply this to private intranet upgrades and enterprise software introductions likewise find them beneficial; and numerous satellite communications enterprises in space and on the ground use them routinely to improve their technical and service performance.
The following guidelines have evolved over a 30-year period of experience in satellite communications. The approach focuses on the “how” of implementing a new system or service. The issue as to “what” service to implement is left to what I call the entrepreneurial function. Obviously, an organization must go through a business planning and market research activity to select the particular satellite communications service. It is my belief that technology management must be blended with business planning in its early phases to make sure that when light bulbs burn bright in the entrepreneur’s mind, the reality of the application system is properly infused.
State and Resolve the Requirements
There is probably no standard form for specifying requirements. It may be as simple as a one-page table of performance parameters (number of channels, dish size, throughput data rate, locations and interface definition) or it could be a volume of a 1,000 pages that describes every conceivable normal feature and failsafe measure to deal with contingencies. There must be an ongoing process of documenting and coordinating requirements among various internal departments and external groups. You may get lots of resistance from those inside your organization as you go about this in a thorough and thoughtful manner. Some may suggest that it will take too much time, and anyway, it would be impossible to know the requirements in sufficient detail. In contrast, those aerospace and telecommunications corporations I mentioned have less difficulty in this area because they have strict processes for capturing and codifying the requirements for every program. Many organizations in the public and private sector are less experienced in this area and many managers, including executives, are neither familiar with nor confident in its value. Taking the time to explain the rationale and past successes in using this approach will usually deal with any thoughtful objection.
To tackle requirements gathering, create a list of needs (must-haves) and wants (like-to-haves) at the most detailed level you can imagine. Then build a file containing individual records for each requirement, grouped according to a key aspect of the overall program. Some of the requirements will come from an existing system that is already in service, providing a foundation for the effort. Others will need to be doped out from experienced guesstimates. A good practice is to gather quantitative data about existing services and even perform tests on operating networks or equipment to identify areas of improvement or potential difficulty. This is done in the software industry where the existing servers and network are stress tested to find bottlenecks.
Despite advance effort, requirements can and will change at the beginning and throughout the development program. The best strategy is to keep an open mind and to listen when new requirements are exposed. Some will be driven by the physical world – that is, by technical problems in application system development. Other changes will result from any new perspective on the business or application. If this is a market factor, then it needs to be given serious attention.
Survey Available Technology and Experienced Resources Thoroughly
During the mid-1970s, Hughes Aircraft Company was engaged by the Indonesia telephone company, Perumtel, in a massive endeavor to design and construct that nation’s first domestic long distance telephone and television distribution networks. The end date in August of 1976 (just 18 months from go-ahead) was set by the president as a way to demonstrate how Indonesia could be united in purpose. Two satellites as well as 40 earth stations were to be constructed and integrated with state of the art telephone exchanges throughout the archipelago; no other technology could deliver these results within the time and money allocated by the Indonesian government. The program manager, Lloyd Harrison, understood the importance of doing a throughout job of evaluating technology and defining the right resources (inside Hughes and from other capable suppliers). After all, you can’t design a system unless you know what ingredients are available.
In the first months, nothing was spared in the way of time and travel budget to gather the necessary data and validate all of the relevant hypotheses. Other tasks involved designing the satellite system so that it would take account of the tropical environment and need to extend operations from Southern California almost halfway around the world. The program was so well managed that the job was finished one month early and within the budget set at the start. Mr. Harrison always insisted that each employee involved in program planning and systems engineering challenge one another about our assumptions and design concepts. This was at times brutal as many of us pushed hard to have our ideas adopted; however, the program manager, as much coach as taskmaster, knew how and when to step in and make the most appropriate call.
One of the difficulties of working with experienced technical people is that they often have a preset notion of how to approach a particular design problem. This is good when time is short and any solution can satisfy the need. However, in a major system, design decisions can be addressed through a process that explores alternatives. Program team members will evaluate sources of supply and then procure the elements in a way to allow competition to produce the greatest good for the least cost. A classical approach to this is the Request for Information (RFI), followed by the formal Request for Proposal (RFP), concluding with negotiation of a delivery contract with the selected supplier. As with requirements gathering, this commitment to a process will pay dividends when the program becomes a reality.
Do Systems Engineering Tradeoffs to Optimize
In systems engineering, the requirements represent the starting point for weaving technologies together into the most effective application system. The systems engineer works like an architect using a block diagram that shows each major element, its performance requirements and how the elements tie together into the system. This initial baseline configuration is evaluated in terms of its performance against the requirements, likely cost and schedule completion time, and risk. Then, other approaches to the same result are developed to compare with the baseline. This can be on an element or subsystem basis (a subsystem is a major functional part of the system which typically is provided by one activity or supplier and can be defined in terms of some deliverable qualities). The systems engineer performs tradeoff studies, which put numbers to each configuration’s ability to meet requirements. The alternatives and baseline are then presented in a trade table to allow selection of the optimum solution according to agreed criteria.
An example of such a tradeoff is the determination of the optimum dish size for a prospective broadcast satellite network. The two major subsystems are the space segment (satellites in orbit) and the ground segment (the multitude of receive-only terminals). Dish size is directly determined by the power that would be radiated by the satellite. We can optimize the system by calculating the total space and ground cost versus dish size. As the dish gets smaller (reducing the cost of the ground segment), the satellite power must correspondingly increase (increasing space segment cost). There is a natural cross over point where the total cost is a minimum – at a point where the cost of each segment happens to be equal.
There are many other factors to consider, such as the capital investment (CAPEX) associated with building and launching satellites; and the operating expense (OPEX) for running the broadcast uplink center and staffing the business operations. The basic point is still valid here – develop a baseline and alternatives for evaluation. Consider as many factors as make sense for the particular program. In some cases, the issue of risk is paramount – such as when the program must be ready for service on a near-term date or the system capability is needed for the survival of an organization. One caveat – tradeoff studies, while valuable, are not the be-all and the end-all for decision making. Another role of the systems engineer is to oversee that the system will fulfill its mission at every stage of the program.
Manage the Design and Implementation Team
Use inside staff as well as qualified outside resources, and include the operations team that has to live with the system after it’s installed. While most organizations may have qualified staff, there can still be great difficulties having all efforts move together toward the necessary outcome. The best program managers are familiar with systems engineering and can understand the requirements and how the pieces come together to meet them. As a leader, the program manager needs to understand the content as well as the process, and have the fortitude or charisma to make the point that everyone is working toward the objective of delivering an application system that serves the organization’s needs. Without that leadership, each individual manager and group will pursue its own course in the manner most convenient, resulting in elements and subsystems that are individually optimized into a suboptimum product or service.
One formula for failure is to focus on technical performance at the expense of operating excellence. The right way to avoid this is to involve your operations group in the requirements and development of the application. This may be complicated by two issues: (1) operation design isn’t usually addressed until the system is almost ready for delivery, and (2) operations people are more expert at handling the controls and may not be proficient at defining requirements and designing systems. As a consequence, the systems engineers should represent operations’ interest to the extent feasible.
Anticipate Murphy
Run the operation as a business, and take care of problems before they take care of you. In other words, anticipate Murphy. This was the daily guidance of the late Col. John Sedano, Vice President of Operations at Hughes Communications (now PanAmSat), who placed a high value on keeping satellite systems working as close to 100 percent as humanly possible. He conducted daily morning meetings where both the usual and unusual from the past 24 hours were considered and debated. Anything that appeared abnormal was treated seriously and acted upon (lest the customer see it first).
In satellite communications, the areas that Murphy has a particular liking for are:
Through all of this, the activities of the program and the eventual operation must continue unabated. In the end, we are talking about a business, and, as such, it must still address budgets, return on investment, staffing and training, and a general commitment to continuous improvement. The three elements of technology management – systems engineering, program management process and leadership – are your insurance policy for success.
Bruce Elbert is a 37-year veteran of the satellite industry, having spent 25 years with the manufacturing and services divisions of Hughes Electronics. His consulting firm, Application Technology Strategy, Inc., assists developers and users of satellite communications systems and networks in the private and public sectors. He is the author of numerous books, and an educator, presenting courses in satellite communications and IT application systems at UCLA and the University of Wisconsin – Madison. Contact: bruce@applicationstrategy.com or visit the website at www.applicationstrategy.com.