Figure 1-1 The Johari Window.

Figure 1-1 The Johari Window.

The risk factor here is that there may be variables that a competitor or customer knows about the organization that the project manager may not know. For instance, a current supplier to the project may have failed in the delivery of a similar component to a competitor, but the project manager is unaware of the situation.

The hidden quadrant. The "hidden" quadrant represents things that I know about myself but that you do not know. For example, I have not told you, nor mentioned anywhere on my website, what one of my favorite ice cream flavors is. This information is in my "hidden" quadrant.

The risk here is that a project team member may not be entirely open in divulging important information about their expertise and experience.

The unknown quadrant. The "unknown" quadrant represents things that I don't know about myself, and that you don't know about me. This is the universe of new product development. In effect, this unknown quadrant represents the undiscovered market for new products, a realm of innovation and imagination that is created in the mind of a company associate. It is this kind of new ground we want people to discover every day in the innovative, new product organization. Customers have hidden needs and expectations that are not expressed in the marketplace; new product developers do not know what these needs are, but can discover them through good market research.

The risk here is that there are factors at work that are unanticipated both by the project manager and the customer. The point is that the early generation of new ideas and concepts that might lead to successful new products and services comes from the unknown quadrant, the result of inquiry, investigation, and imagination. It starts with an individual who envisions a new market opportunity that is beyond the current reality; the thought process creates a new scenario in the marketplace that is unknown, a subjective reality. This is the beginning of seeing new products and services that might meet a currently unknown demand.

Personal, Project, and Organizational Risks

There is something very personal about the issue of risk and new products. In many companies, taking risks in new product concepts is rewarded in principle, but failure to take risks has its implications despite the company rhetoric. What the company is really saying is, "Go ahead and take risks with new product ideas, but take them only if you think you can succeed and produce value for the customer and the company. We will support you with data and information. Don't take risks frivolously."

For the business and project professional, risk is a personal issue because project risk is directly associated with personal risk. If a project manager fails to see and control risk, that project manager faces the prospect of being associated with a failed project. So the way a project team faces risk has implications for each team member personally—and for the team dynamics involved in a given project.

The way the company protects its employees and officers from risk is key as well. If the company is positioned to absorb the cost of failure, the program or project manager is more likely to take the risk. Thus the propensity to accept risk and manage it successfully is partly a function of organizational support; if my company supports me, I will address risk and make the best decisions I can, but I will want to let my top management know the risks as I see them so that if the risk is not successfully controlled, it will have been a company-wide decision, not a personal one.

In sum, the organization must position itself for risk, and must empower and enable its business and project people to address and take risks; however, there must be an open, organization-wide process for addressing and absorbing risk. If these conditions don't exist, the project manager is not "incentivized" to address risk and will avoid it—often at the expense of opportunity.

The New Product Risk Framework

It is important to see new product development and risk as a business-wide challenge. After all, business enterprise itself is a risk, and that is what makes success and payoff satisfying to the business entrepreneur. Project risk is simply a microcosm of the overall business challenge, and the fate of every project lies first in the capacity of the parent company to create conditions for success. As we have said, project risk starts with the business itself, its market position and business viability, its partnerships and vendor relationships, and the economic risks the business itself faces, as well as customer and client risks.

The author learned a valuable lesson in project risk management working with a leading avionics product company, a product development, engineering, and manufacturing company that used project management systems at the division level, but had no project management systems in the corporate "head-shed."

As part of the support project management office, the author's role was to ensure that there was support to the project managers, and that there was a clear project management policy and process in place. I also ensured that standards were enforced, and served as an assistance project manager in several functional areas such as procurement and cost capture. The work was in a regional facility in the east, while corporate was in the west run by a single owner and a small corporate staff largely without corporate program management competence.

This major producer of avionics equipment had several new product development projects going on in the engineering plant involving mechanical, software, and electrical engineers, supported by procurement, acquisition, and accounting staff, and a human resources office. The product involved embedded software and regulatory requirements for avionics equipment, and much of the process was testing and retesting prototypes against standards. In addition to the work underway, the regional facility had been awarded

(by the owner's decision) a system program from another region that had not been successful with a system upgrade. New staff was hired to handle the project. At the same time it was authorizing this hiring process at our facility, corporate was experiencing downturns in sales and marketing efforts, and consolidating facilities to reduce costs. But the owner made the decision and we implemented it.

Later the same year the company had to conduct a major downsizing, cutting many of those same staff members hired to run the new program, plus other valuable and high-performing engineers. The reason it had to downsize was that the corporate investment source was unwilling to forward additional funding until the company cut costs.

We learned that project risk cannot be separated from business risk in general, and that the effectiveness with which a company identifies broad threats and risks in its business planning will establish the conditions for successful management of project risks.

Project risk is inherently business risk, and cannot be disassociated from the overall risks and threats faced by the business as a whole. Thus project risk management must start at the perimeter of the business and its relationship to its market environment. As the business identifies its threats, competitors, and risks, it provides the basic wherewithal to identify project risks. There is an inextricable linkage between the threats a company faces in technology, labor availability, or product development, and the threats a project team faces in producing a deliverable designed to implement the business plan and strategy.

The lessons are these: Risk is a vertical process, not just horizontal; that is, risk happens up and down the organization at the same time it happens in project planning management processes over time. Risk is a multidimensional and multiscaled syndrome that can affect you without warning if you are not in the inside. And risk does not often come in recognizable clothes, but rather sneaks up on you through the side door. Very often the key determinant risk is out of your control as a program manager, or even as a general manager, because risk stems from central leadership more than from project processes. The "risk as part of the business framework" concept looks something similar to Figure 1-2.

Knowing the business you are in helps anticipate risks inherent in the business. For instance, if I am project manager of a software development project in a software firm, I know from past experience and good corporate strategic planning that one of my risks—as a business—is going to be the "integration and debug" process. This includes the time and effort to ensure that a new computer program or code works on the user's hardware platform. I can almost bet that this task will be one of my risks in any such project. I can differentiate that very distinct risk from a general uncertainty about whether there will be any demand for the product once it is ready. I can "work" the risk in my project; the uncertainty about market demand can also be worked, but I can't control it.

Business Ris





Figure 1-2 Business framework for risk.

/ Project Risk


Business Ris





/ Project Risk


Figure 1-2 Business framework for risk.

The risk in this software development process can be identified, defined, and ranked as part of a process called qualitative risk assessment. If I wanted to quantify the probability that a debug problem will actually happen and create a major schedule slippage and/or quality issue, I would do a quantitative assessment of probability. That process might result in my estimating that there is an 80 percent probability of a debug problem not getting fixed within my estimated and scheduled "most likely" task duration of three weeks. I might then identify two alternatives—a worst case and a best case, based on various assumptions, and plug them into my schedule using the "PERT" tool discussed in Chapter 3.

Thus the reason that project risk starts with the business itself is that any project or portfolio of projects coming from the business pipeline is typically aligned with the business competencies and capacity. The business leadership has chosen a project because it believes the payoff of a project is worth the investment in overcoming the risks inherent in doing the project. The product or service to be produced by the project is key to the success of the business in its industry niche.

Figure 1-3 illustrates the linkage of customers and business risk planning. Customer requirements generate business plans which look at the strengths, weaknesses, opportunities and threat (risks). New products are evaluated for risks and opportunities and selected. Programs and projects for new products are planned that make sense financially and from a risk standpoint. The individual WBS, schedules, and contingencies are flushed out.

"I got the customer's approval to do the Schneider program," Lakeisha told Bill.

Lakeisha and Bill were project managers at Project Associates, Inc., a software and information technology company. "I've got four months to deliver the program to Schneider, including a new hardware platform, software code and

Another Case in New Product Development: The Schneider Program

documents, and a training manual." "I think it's going to be a blast—the biggest issue to me is the software. The hardware is a no-brainer."

Lakeisha had delivered her last project, the Mires program, well ahead of schedule. Bill, on the other hand, had not done well in his last project and was late and over budget. Lakeisha was eager to show that her last performance was not a fluke and that she knew what she was doing. She always suffered a little lack of confidence under pressure, but always came through. There was a subtle competition going on between Lakeisha and Bill, but they worked well together.

"I wouldn't get too excited just yet," Bill told her. "You know I was going to do that program, but I got sidetracked and the boss gave it to you. I've seen the specifications for the program, and there are a lot of risks. I think you've got at least six or seven months of work with the current team to produce the deliverable as I see it. And that is if you don't have any problems with platforms, software, people, our 'old' testing equipment, and good old unreliable Software Systems, our contractor. Are you going to go with the same team you used last time? Planning any risk assessment and contingency—you know, those scenario things?"

"Yes and no. I am going to use the same team—I think—but I don't have time for the risk stuff. Been there, done that. I will use a schedule from our last project for Smothers, which was a good run and we kicked butt. I have looked at the risks and the big ones are in the software graphics package and online training package. I've got a plan to shrink the schedule to four months by crashing some stuff and outsourcing. I read an article on outsourcing last week and a story included a great company that does just what I want them to do—or almost. That is going to cut my schedule by two months. This project is going to have to be on the fast track from the word go. I am going to write a cost-plus contract with them because procurement says that is the template they like to work with."

"Well, I hope you know what you're doing," Bill said to Lakeisha as they crossed the corridor. "I have seen a lot of people get burned by contractors, and you know that the hardware for this deliverable is new and will require some long lead times on parts."

"Cool it, Bill. I've picked a reputable contractor," Lakeisha said. "I checked his references and I am sure he'll do a great job—and he is going to accept most of the risk. I told him I would make progress payments on the cost-plus contract only if he was on schedule, and he agreed. He said he would put more people on the job if it turned out to be more complicated than he thought it was. I will just keep an eye on him. I understand that this is risky business and some risks are inescapable. But what an opportunity to show what we can do—think of the plus side of this thing if it goes! When I have this much to do in such a short time, I'm not going to waste the team's time on risk games and risk matrices—I know what I want and I know what the risks are."

Bill thought she should be more careful, but liked her spirit. He and Lakeisha had been over this ground before. He had learned some lessons on risk in his previous project, which failed because he was hit by an unanticipated shortage of key technical people and a surprise glitch in getting parts for the hardware platform. He had been reading about a new theory of "constraints" that focused on resource and equipment availability risks, not just critical path issues. But he had learned not to argue with Lakeisha when she had already decided what she was going to do.

Lakeisha met with the contractor and gave him the specification before her procurement office could get the scope out and signed, but they didn't have a problem with that and she didn't have time to go through formal signatures anyway. It turned out that the contractor, Mag Company, was headquartered in New Delhi, India, but had a local office. Their procurement people had said the specification made sense and that they would get on it right away—they too felt that could go ahead without a signed contract. They needed the work.

Six weeks later, Lakeisha called the local Mag Company project manager, Abdur Manat, to check on progress. "Everything is going great," he said. "But we have been working on a high-priority project for another company that came in just last week with a heavy job due yesterday, of course. So I have not made as much progress as I had hoped." Lakeisha responded, "Maybe I ought to have a schedule from you, particularly on the tough pieces of the work you see as potential problems." Abdur replied, "But I still have three and a half months to do two months of work, so I don't see any problems. Did you send me those specs on the hardware? By the way, did you say that the customer wants online training—what's that?"

Lakeisha hesitated, but disguised her concern in a positive expression. "That sounds fine," she responded. "Let me know if you need anything. I'll be back in touch in another six weeks and then we can talk about integration."

For the next several weeks, Lakeisha spent most of her time trying to put together the specifications for an online training program for the contractor, a task she hadn't anticipated. She also inquired on the lead times for the new hardware, but the design people were busy on other work.

Six weeks later, Lakeisha called Abdur to check on progress. "The last project took me longer than I expected," Abdur said. "I've gotten into the graphics work and looked at your hardware requirements, and I've been working like crazy, but now that I have taken a closer look at it, I think there's at least a good three months of work on this job, particularly on that online training stuff you sent me—I will have to sub that out."

Lakeisha almost choked on that one. Her stomach told her she was in trouble and she murmured to herself. That would make the total development time for the Schneider project six months instead of four months. "Three months," she said, "you have to be kidding. I need the software code in two weeks to begin integration. You were supposed to be done by now! I am not paying your last invoice."

Abdur responded, "OK, but you already paid our last invoice—your accounting office has been very efficient. We just got the check, along with a nice holiday greeting." Lakeisha knew this was not her day.

"I'm truly sorry," Abdur said, "but this isn't my fault. There's more work here than we could have ever done, and more than you estimated in your schedule. We found that the software code doesn't work in your hardware, and we haven't been able to figure out why. And your team people aren't available to talk to us. I will finish it as fast as I can."

It turns out that Abdur delivered the software in three months, but the project took another month after that because of integration problems with the in-house team's code. In the end, the Schneider program took over seven months rather than the four month estimate. Lakeisha concluded that Bill and the company had sandbagged her by palming off a bad project that he was not able to handle and that had inherent big risks.

This story is about the fact that the new product innovation process is rarely a question of major breakthroughs and starting new concepts out of the clear, blue sky. Most innovations and new product developments are subtle product increments, improvements in design or development or processes, which generate major benefits in time to market. These incremental product developments require creative concepts and ideas that are no less important than brand new products. They evolve in organizations that encourage flexibility in process and procedures, allow redefinition of tasks during development, and encourage testing new materials and technologies in development.

As an example, in the development of an electronic instrument involving electronic, mechanical, and software engineering, new materials are often discovered in developing products that reduce production costs and improve the financial performance of the product in revenue use. An avionics firm recently found that when developing a radio control unit, a new low-voltage resistor package would produce major safety and performance benefits but would require a new mechanical housing design. The idea came from an experienced electronic engineer who thought through the role of the resistor in the instrument and searched for new designs by surfing the Internet. He found a new resistor design and, after simulating its performance, ordered the new resistor on his own and integrated it into the instrument. Results were startling in reduced cost and efficiency in the performance of the product.

The way configuration management is used is key when balancing the creative process with the control of product design. If new designs cannot be integrated into design because configuration management locks in a design too early, new ideas can be stopped prematurely. On the other hand, if new designs are not locked in until production is scheduled, information on alternative designs is lost and production can be delayed because the actual configuration of the product is not clear and not documented to support production.

People who participate in this product development process have to feel that the project allows flexibility while at the same time schedule milestones are taken seriously.

Another Story of New Product Development

A small (150 employees) avionics research facility reports to corporate headquarters in another state. The group is in charge of developing and producing new avionics products, electronic instruments used in aircraft for aircraft control, and subject to strict Federal Aviation Administration (FAA) regulations.

This particular story is about the development of a radio control unit with a new design and system requirements. The story demonstrates that creativity, innovation, and new product development decisions come at many points in the process, and not through a rational, controlled environment. These are not one-shot decisions or activities controlled by "gateway" decisions, but rather incremental and often personal—the tyranny of small decisions. The small decisions create the larger whole. To demonstrate, consider a typical development and manufacturing organization, and trace how new product development actually happens in many cases—at various levels of the organization.

The product is a new control unit that will manage the radio system in a business aircraft suite of avionics equipment. In the following example, it will be clear that the opportunities for new product and service ideas come up in very subtle ways and survive through very personal decisions affected directly by the tone of the organization.

Don Akers, a mechanical engineer in charge of the instrument housing, sees the new product as a challenge in housing the electronics in a new mechanical concept that he has been advocating. But his ideas have not been welcomed in the unit, which is dominated by electronic engineers. Akers feels he can make a mark through this new housing concept, but fears that if he goes too far, his ideas will be ridiculed and, worse, ignored. This new product offers a great opportunity to create a new mechanical concept, but there are organizational barriers to his idea and he has to be careful in promoting it.

Bill Verdon, an electrical engineer and functional head of the electronic engineering department, is the senior electrical engineer in charge. His focuses are his own expertise in this kind of avionics instrument and maintaining his role as the primary guru in the company. Verdon is skeptical of mechanical and software engineers, and does not welcome new ideas unless they come from him.

Buster Right, a software engineer in charge of embedded software design, is working on a new process of developing software code. This approach is a new and innovative software development concept that produces code in full increment stages, rather than in pieces and phases. He has advocated this approach with his software guru, Ben Branish, but his ideas are new to the company and not the way things are normally done. Branish is skeptical.

Ben Cartwright, the facility general manager in charge of the whole effort, is caught up in corporate and local management issues that have little to do with this new product. Cartwright, an electrical engineer, deals with a strong regional manager who started the whole business unit and who is known in the company as the corporate genius. However, management is not his strong point, and he often interferes with product development by intervening directly with engineers working on a given product with new assignments that divert their attention.

Bruce Hall, the test technician, is working with a new test system and new equipment, and is intent on showing that the new test process will speed up testing and reduce the cost of testing systems. However, the electrical engineers are skeptical of the process and generally look down on test technicians who do not have their level of education or experience. Technicians are technicians and should not be experimenting with test protocols, they would say.

Bart Strong, the project manager, is a physicist who backed into the new product process. Brilliant and gifted in many fields and a generalist, Strong is not accepted by the electronic engineer community because he does not have the training and education they have, and because he is loose in his management style. He actually enables staff to produce and expects them to take responsibility, while the electrical engineers often end up doing the work themselves. He is a manager in an organization that does not encourage management.

John Cherell, the head of the project management office, is trying to create order and consistency in the new product development process. But Cherell does not have an engineering degree and does not have the support of the general manager. Bruce Cartwell, the purchasing head, is not part of the new product team, reporting instead to the finance and procurement office. His interest is bulk buying to reduce costs in product components. He does not always purchase materials when the team needs them because he is driven by an incentive to wait until components and inventory can be procured in volume.

Sid Still is an electrical engineer in charge of putting the instrument together and testing it before it goes into test protocol. He has ideas about a new resistor for the product that will increase efficiency and reduce costs, but will take some time to procure. Still is faced with the issue of whether to push for the new resistor in the light of pressure to get the instrument into product, cheaper, better, and faster. Mildred Best, the configuration management director, is a strong personality who uses her specialized configuration management software to control product designs.

No product can go through new product development without dealing with configuration management. Best tries to capture designs early in the process to control them; engineers try to avoid locking in designs with configuration management (CM) because the CM change process is time consuming and difficult.

Joyce Cobb, the documentation manager, is assigned to the team and has taken the responsibility to document each step in the process. She is trying to organize the process so that documents are produced by engineers at each appropriate step, but is challenged by the propensity of engineers, especially software engineers, to avoid documentation until late in the process.

Bob Smith, the manufacturing manager, is interested only in scheduled production and making sure he makes the monthly quota of product units. Smith works closely with configuration management to ensure that products can be assembled and produced, pressing for early information on scheduling and inventory needs.

Each of these team members participates in new product and service development daily, as opportunities surface in their work. Some of these ideas will flourish as they are accepted, others will not.

What are the motivations and thought patterns of those who participate in new product development activity, and how does program management handle the unique dynamics of the new product environment?

Akers, the mechanical engineer, is motivated by the prospect of creating a new housing for the instrument that is innovative as seen by his peers, e.g., the new housing creates minimal tolerances with internal electronics and is designed to cost. "Design to cost" means that the design takes into consideration the costs of production. To Akers, this means that he will be recognized as really good at what he does if he minimizes the tolerances in his housing through robust design and at the same time reduces the production costs associated with the mechanical housing.

Verdon, the electrical engineer and functional head of electronics, has a different focus. He is motivated by the need to maintain his head guru status in the company by serving as a general consultant on the new design. He stays in his office and waits for engineers to come to him with questions. He has quiet empathy for his electronic engineers and less-quiet disdain for the mechanical and software engineers outside his functional department. He would like his people to receive the recognition they deserve for designing a truly new, state-of-the-art, low-voltage system for the new unit that will change the standard for the industry.

Buster Right, the software engineer, is a hardened software engineer who has bumped around the industry and knows coding and software development—but is relatively new to the embedded software challenges of this avionics instrument. Right is also an advocate of a new software development process that is at odds with the linear, sequential approach used by the company. He believes he is creating new product concepts through his innovative process engineering. His approach is called staged iteration, a process that designs and tests various iterations of the eventual software on the test platform rather than designing software and coding for one, final test on a platform. Right's approach requires the platform to be ready earlier than usual in the process. Right's functional software chief, Jim Barrangan, is skeptical of the new approach, but goes along with it. In holding back his personal and professional views until well into the project, Barrangan creates a major bottleneck by later holding up the new product development process because he decides the new approach is dysfunctional and puts Right back on the drawing board.

Cartwright, the general manager of the research and manufacturing staff and a well-respected senior electrical engineer, is caught up in satisfying the constantly changing whims of the local vice president, the corporate technical and sales guru in charge of several local operations. Between these distractions and more remote, corporate micromanagement, Cartwright fends off the outside, corporate world to protect his project staff. His interest in new product development is to try to leverage the corporate aircraft fleet office so that an appropriate test aircraft is available when his projects needs it, a typical bottleneck in the new product development process.

Bruce Hall is a local community college graduate with an electrical test technician degree who runs the test lab, which is always overscheduled and understaffed. Hall juggles many projects wanting testing services all at the same time. Engineers tend to treat Hall as a lower-level staff aid who does not understand the sophisticated world of electrical engineering.

Bart Strong is a physicist and project manager. He is in charge of the project team but has no authority to manage them. Strong is not an electrical engineer and has an open-ended and collaborative personality at odds with the head-down, structured approach of the other engineers and project managers. He is not accepted into the fraternal grouping of inside professionals.

John Cherell heads up the project management office that Cartwright created to accelerate the productivity of the group. He is a senior author in the field and teaches at the local business college. He finds that his attempts to standardize and control project management practice, his interpretation of his role, comes up against the need of the key staff to do their own thing. Cartwright eventually becomes disinterested in the function amidst his problems with corporate.

Cartwell, the purchasing head, supports the project team but is marching to different orders from the local vice president to buy in volume. Buying in volume means promising high volumes of orders of components to reduce prices. Also, Cartwell is not buying until demand builds up from several projects. The company continually fails to meet its volume predictions, which leads to unfulfilled orders and major vendor problems, all of which delay project activity.

Still is an electrical engineer who truly sought out innovative product enhancements, including a new resistor concept that he had generated himself. Generally focused on his profession, he actually creates brand new approaches that are later accepted as major state-of-the-art contributions. For his work, he is unceremoniously laid off along with several of his colleagues when company management recognized what everyone in the staff had known for months, that it had overstaffed the group given the project load.

Best is the configuration management specialist and managed her function with discipline and narrow perspective, often using the role to control designs and components before they were fully developed. Typical in the new product development environment, there is constant tension between the engineers who want to keep options and designs open, and configuration management staff who want to lock in designs to prepare for production.

Joyce Cobb, the documentation specialist, is organized and competent. Her approach to new product concepts is to generate a documentation process that quietly organizes the process by framing documentation needs early and getting documentation done during design and development.

Bob Smith is pressed to improve production in a facility characterized by changing assembly workforce and undocumented manufacturing processes. His interest in new product development is to meet expectations for defect-free production of prototypes and volume units.

The point of this story is to suggest that new product development teams are characterized by a wide variety of motivations as well as internal and external forces that shape the effort and its output. An effective new product development manager understands these dynamics and works with them to ensure that the team performs. There is a time and place for new product innovation, during design and early product planning. But when a product is in configuration management the issue is getting it produced and marketed quickly, not to second guess the product.

This page intentionally left blank

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment