Andrea Hayes-Martinelli and Dragan Z. Milosevic
"Wait a minute" said Bali Balebi, the Silverbow program manager, while passionately waving his hands. "Do I understand you correctly that senior management is saying that my program must hit the release date, and if that requires dropping the two automation features, it is okay?"
"Yes," responded Christine Smiley, the PMO director, "you understood me. But please calm down, we need cool heads now."
Balebi continued, "So, first we add the automation features despite the program team telling us that the planned program duration of 21 months would only allow for the 8 original features. Now, we are in the integrate phase three months before we get to deployment, and I'm being asked to drop the automation features because we're a month behind schedule? I'm sorry if I'm having a tough time keeping a cool head, but we can't do that."
"They are not asking you, they are directing you to remove the features in order to get back on schedule; the delivery date is crucial," replied Smiley. "Again, please calm down and tell me why we can't drop the automation features. Give me a logical argument that I can take back to senior management. I can't just go back to them and say we can't remove the features because the program manager is passionately against it."
"Okay," said Balebi. "Two reasons, first I have already made an announcement to our lead customers that the automation features will be included in the next release. Second, the features have already been integrated with the other features in the release. It may take longer to back them out and redo the integration than to just continue with the integration as is."
"Oh, now I understand the problem," responded Smiley. "Let me talk to Matt Short (vice president of enterprise software), and you sit down with your team and review all possible options to make the original delivery date, both with and without the automation features. Also call the lead customers who we know plan to purchase the new release. Tell them about the possible delay of the two automation features until the next release and see how they react."
Before we see what program actions were taken on the Silverbow program, we need to evaluate ConSoul Software. Program decisions need to be put into perspective of the corporate context in which they exist, as the company environment heavily influences program decisions and strategy.
ConSoul Software was a late entry in the facilities and construction software industry, which was dominated by two primary competitors. Matt Short, vice president of enterprise software at ConSoul, recognized that, although the competition had a foothold in the industry, their products were not user-friendly. Short described the competitive environment. "The competition had tremendous advantages," he said. "Their products were just packed with features. The problem was, their products were extremely cumbersome to use and required large amounts of user training." ConSoul's strategy to enter the industry and to continually gain market share was to provide customized solutions that focused on ease of use and required little or no user training. "It had to be that easy, or no one would buy our products," Short said.
ConSoul is now an award-winning software product development enterprise, which produces integrated-software solutions for accounting, payroll, fixed asset management, human resources, customer relations, and e-commerce applications. The company specializes in developing integrated- and customized-software solutions for more than 20,000 customers in the facilities development and construction industry. This case describes how ConSoul struggled with the management of a program—Silverbow—in its attempt to release an upgrade and grab more market share in a dominated market and the challenges it faced.
ConSoul Software was founded in 1978 as a start-up company. Its mission is to empower its customers to succeed by providing them with extraordinary software and services. It does so by focusing on four primary business postulates:
Providing best-in-class products: By developing customized software solutions packaged as office suites, ConSoul gains both repeat business and a continually increasing customer base.
Implementing a rapid software release cycle: ConSoul delivers software products with new features and functions every six months for most product lines.
Developing ease of use and integrated solutions: Compared to its competitor's products, ConSoul's software solutions focus on ease of use, which results in little or no user training and tight integration with customers' existing business systems.
Providing competitive pricing: A unique bundling strategy and integrated-feature set allows ConSoul to provide its customers with a total solution at a fair and competitive price.
The strategy that ConSoul employed is best described by what Snow and Hambrick call a customer-intimacy strategy.[173] A customer-intimacy strategy has proven to be an effective way for companies to enter markets that are already dominated by a few competitors. Competitive advantage can be gained by delivering what a specific customer wants, not what the market as a whole may want. This type of organization demonstrates superior aptitude in advisory services and relationship management.[174] Its business structure delegates decision making to employees who are close to the customers and its management systems are geared toward creating results for carefully selected and nurtured clients. The corporate and program culture embraces specific, rather than general, solutions and thrives on deep and lasting client relationships.
ConSoul Software has three principle strategic objectives, listed in priority order:
Maximize customer satisfaction
Provide high product and service quality
Maintain competitive time-to-market delivery
These strategic objectives guide the work of the company and its program teams, as demonstrated in the following sections.
As stated earlier, a program manager within a business unit is charged with delivering an entire software solution through multiple software releases to ConSoul's customers. Program release planning is accomplished and communicated through the use of a program road map tool. An example of a program road map for the enterprise solutions business unit is shown in Figure B.1.
The road map represents the software releases planned for each program over a two-year time frame within each of the four product lines. Over the two-year time frame, each program consists of multiple release projects. It should be noted that even though the releases are shown as sequential events on the program road map, work is performed in a concurrent manner with overlapping activities and resources.
ConSoul Software is composed of two business units—enterprise software solutions and office software solutions—each led by a corporate vice president. The business units are supported by centralized finance, marketing, and manufacturing organizations, as illustrated in Figure B.2.
Each product development business unit is organized as a matrix structure and is led by three functional directors: director of program management, director of engineering, and director of technical communications. Each business unit is further segmented by product lines. For example, as shown in Figure B.2, the enterprise solution business unit is segmented into financial, operations, estimating, and corporate solutions product lines. A program manager is assigned to each product line and is charged with delivering the entire product solution through multiple software releases. Each release is organized as a separate project and is managed by a technical project manager.
The software development and software test/quality assurance (QA) resources report directly to the engineering functional organization and are loaned to the product line program managers and release project managers as needed. Representatives from other centralized support organizations are also assigned to the product line programs to represent their respective functions.
After Balebi's conversation with Smiley, he called an urgent meeting with the Silverbow core team. The agenda was short—plan for options to finish the program. Balebi briefly explained, "You know that the program plan shows we'll be a month late if we include all the ten features. Senior management has sent us a message that we must hit the release date, and if that requires dropping the two automation features, it is Okay." He continued, "Remember that senior management requested that we add the automation features, despite us telling them that our schedule wouldn't support it. Now, they have reversed their position. The trouble is we have already made an announcement to our lead customers that we have ten features in the next release, including the two automation features. Dropping them may significantly lower our sales.
Christine instructed us to put our heads together and review all possible options to meet the original delivery date, with and without the automation features. We will call the lead customers who we know plan to buy the new release as well, and see what kind of damage the removal of the automation features may cause.
Now, let's review our program from top to bottom, which may help us consider all the possible options. If you have any questions about senior management's request, you can ask them as we go through the review."
Silverbow is a code name for a program that was funded and executed in the office solutions business unit of ConSoul Software. The Silverbow program supports ConSoul's operations segment and provides a comprehensive set of document control capabilities. The program consists of six projects, each structured as a software release package delivered to customers in consecutive release cycles. Total duration of the program was 22 months. It was estimated that company revenue would increase 53 percent in the first year and 46 percent in the second year due to software licensing agreements associated with the Silverbow program. Table B.1 summarizes the characteristics of the Silverbow program.
Table B.1. Silverbow program characteristics
Silverbow Program Characteristics | |
|---|---|
Industry | Facilities and construction software |
Product description | Software upgrade (project management software) |
Program description | Provide solutions for common document control processes (handling of meeting minutes, daily reports), submittal packages, notices, issues) |
Product novelty | Derivative |
Technological Uncertainty | Low technology |
System scope | Full system |
Pace | Fast and competitive |
Business unit | Operations |
Customer | External |
Strategic goal | Extension of current product line for increased life cycle revenue |
Program size/duration | 20 people/22 months |
The Silverbow program utilized a PCT structure, which is common for all ConSoul product-development programs. The PCT structure was highly matrixed, with many interfaces between the engineering, test and quality assurance, technical communications, and marketing functional organizations. The PCT was led by the program manager and consists of the current release project manager, the subsequent release project manager, the engineering manager, and the software test/QA manager. Project managers report directly to the director of engineering and indirectly to the program manager for the duration of their involvement in the program. The program manager, in turn, reports directly to the director of program management.
Each project was segmented into multiple subteams that corresponded to primary product features such as drawing logs, meeting minutes and reports, as shown in Figure B.3. Each feature had an engineering lead, a test and QA lead, and a technical communications lead, as well as a marketing product manager who managed the technical design and development work for his or her respective function on the project.
The PCT is responsible for the product and business results derived from the delivery of the family of releases that constitute the program. The project teams are responsible for designing, coding, and QA testing of the various features that comprise the software release.
Silverbow was one of the first programs to use the new product development process adopted by ConSoul. The process is broken into the following elements: program phases, kitting, schedule management, cost management, risk management, resource management, and communications.
- Program phases:
As illustrated in Figure B.4, the PLC consisted of seven phases: predefine, define, plan, design, integrate, deploy, and evaluate.
Generally, a program is started by creating what ConSoul calls the story, which describes the end product in terms of the usage model. The usage model is a description of the interaction between the user and the program product that identifies the product's benefit to the user.[174] From there, use cases (sequence of interactions between the user and the product), primary features for each use case, high-level resources, and timeline estimates, and a release plan are developed. A feasibility analysis is then performed.
Once feasibility has been proven, each project—and the program as a whole—is scoped, functional specifications are developed, and development and resource allocation plans are created and presented to executive management for approval. If approved, the program moves into the design phase and execution of the project plans begins.
Throughout the design phase, customer change requests are evaluated and approved changes are added to the program and project plans. During the final integration phase, the software code is integrated, software test and QA is performed, release documentation is generated, and the current release product is evaluated for deployment. Once a product reaches deployment, focus shifts to manufacturing, order fulfillment, and customer support.
Table B.2. PLC phases and activities
Phases
Major Actions
Predefine
Perform feasibility analysis with marketing, product development, technology: perform financial analysis; get high level estimates
Define
Identify product definition team; create research plan; perform customer task and needs analysis; risk management; develop product definition; create initial estimate
Plan
Develop the functional specifications; resource allocation; develop plans to support all the business needs; present plan to marketing and make sure that this is what they wanted before going into design phase; negotiate with marketing; go/no-go decision
Design
Execute projects; do change requests from customers for better design solutions: integrate code; system test
Integrate
Generate release documents; finalize products; assess project
Deploy
Duplicate software disks; update internal systems; new order fulfillment; release fulfillment
Evaluate
Program retrospective; customer evaluation; overall evaluation of phase assessments
The predefine, define, and plan phases are executed only once for a given program. The design, integrate, and deploy phases are executed once for each project and, therefore, multiple times throughout the life cycle of the program.
Once the final project is deployed, the program enters the evaluation phase, in which a program retrospective is performed and customer feedback information is evaluated. Table B.2 summarizes the primary activities associated with each phase of the ConSoul PLC.
- Kitting:
Project scope was managed by a process referred to as kitting. The idea was to segment software deliverables into five-day work packages. At the end of five days, or one cycle, each subteam within a project released a deliverable for each of the primary features. Each deliverable consisted of one element of the product that was functional and fully tested. This process of iterative software development is known as Agile development.[175]
The kitting process was used for the first time on the Silverbow program and proved to be a challenge for the project managers because it did not lend itself to the linear process of historical project management methods. Tracy Brooks, the release project manager, described the problem to Balebi. "Kitting doesn't address anything about logical units of work of a software project," he said. "Software development is not manufacturing, as the kitting idea is. A software process doesn't chunk up the same way a manufacturing process does."
The source of the problem was having two planning systems in place, which were incompatible. Per the first one, the program and each of the projects were planned by major milestones corresponding to large deliverables and phase completion. Per the second one, small deliverables of five-day increments (kits) were scoped. As a result, kitting performance and milestone performance were not aligned, leaving the performance-to-schedule metric ambiguous. As changes to the program scope were approved, the feature changes were either incorporated into existing kitting plans or new software kits were developed. Balebi was able to determine that the dichotomy and lack of knowledge of how to coordinate the two planning systems were a major reason for the program delay of one month.
- Schedule management:
The schedule was developed based on time estimates from the engineering and software test/QA functions, not as a program team. High-level time estimates were first developed in the predefine and define phases, then detailed estimates were developed during the kit planning process in the plan phase.
Milestones were based on major project deliverables and standard program decision checkpoints and monitored every two weeks by the PCT. Example milestones included software detailed design complete, user-interface complete, code complete, code freeze, and product ship release.
- Cost management:
Cost of the program was expressed in terms of the number of people on the team and the number of hours to complete their tasks, not on a budgeted dollar amount. ConSoul sets budgets based on business solutions, rather than individual programs. The program manager, therefore, does not know the cost of the program in dollar value. Cost is managed through the program resource management process.
Balebi believes this is an area of potential improvement. "I think the current program cost-management process can get us in trouble," he said. "Nobody realizes how much money it actually takes to develop a product."
- Risk management:
Risk management was a shared process on the Silverbow program, both by phase and by team. During the program predefine phase, the marketing function was responsible for identifying potential risk events, evaluating the risk level, and developing necessary risk management plans. During the other phases of the PLC, the PCT drove the risk management process.
Risks contained to a single project were managed by the project manager and his or her project team, while risks that had potential affects on other projects, or program success as a whole, were managed by the PCT.
Each risk event was quantified according to the following two variables: probability of occurrence and severity of impact. Priority-one risks were the highest risk events, while priorities two and three were relatively lower. All priority-one risk events had to be communicated to all internal stakeholders, and a mitigation or avoidance plan had to be created. Priority-two and three risk events were monitored only on a recurring basis.
- Resource management:
Resource management was one of the primary responsibilities of Silverbow's program manager; the program manager also focused on ensuring that the project teams, as well as the PCT, were fully staffed with capable people to complete the work. Once a program plan is approved at ConSoul, resources are committed to the program by the various functional managers. The Silverbow program was fully resourced according to the program plan as it entered the design phase of the PLC.
However, resources were a primary constraint on the program. Because the program manager did not have a monetary budget to use for managing program constraints, the majority of scope, schedule, and quality issues were addressed by changes in program resources. For example, the program manager had to continually adjust resources to accommodate the additional features requested by customers or other stakeholders and address any quality issues associated with the current release or previous releases already operational in the field.
- Communications:
The PCT met once a week, generally on Monday mornings, to review program and project status, current issues, potential risk events, and planned activities for the coming week. Project status was focused on the kitting progress for each of the feature teams on the project. A review of each of the feature team's five-day kitting progress and deliverables was conducted. Program status focused primarily on progress toward major program milestones, resolution of current problems, and review of risk mitigation or avoidance plans for each of the priority-one risks.
Each project team conducted their own team meetings once per week at the beginning of the program, then two to three times per week during the later stages of the design and integration phases. The focus of the project team meetings was on the technical details associated with each feature team.
Communication of program status to internal stakeholders was accomplished by the program manager in the form of a formal status report once every two weeks. The report was sent directly to the senior management team and posted on the program website for all other interested parties.
The Silverbow Program employed standard metrics and tools for all ConSoul programs and focused on measurement of the following processes: scope management, schedule management, risk management, and quality management. As mentioned in the previous section, program cost is not measured.
- Scope management:
Program and project scope was measured by the number of kits associated with each feature in a project. Performance was measured by the number of kits completed versus kits planned and required a mitigation plan for variance recovery. Wall charts were used to manage scope and performance by tracking the number of kits completed by marking the kits off as they were finished, then monitoring the kitting progress against the original plan.
- Schedule management:
Performance to schedule was focused on progress toward completion of the key program milestone dates. As mentioned earlier, there was no correlation between completion of program milestones and completion of the five-day kitting activities. A standard Gantt chart was utilized to manage the program schedule.
- Risk management:
Risk management metrics included the total number of risk events for each priority level (high, medium, or low) and progress toward mitigation or avoidance of each high-priority risk. Timely development of a risk mitigation or avoidance plan for each priority-one risk and the completion date were closely monitored. A risk-management spreadsheet was used to track progress. Key fields in the spreadsheet included risk entry date, risk description, root cause, severity of impact, probability of occurrence, priority level, mitigation/avoidance plan, targeted completion date, and status.
- Quality management:
Software quality was measured by the number of defects recorded, resolved, and outstanding for each release. Software quality is the primary indicator used for the ship release decision. ConSoul utilizes an in-house developed tracking database to manage software defects on all of its development programs. The tool categorizes defects by severity level and resolution owner.
Table B.3 summarizes the program metrics and tools used for the Silverbow program.
Table B.3. Program metrics and tools
Program Processes | Metrics | Tools |
|---|---|---|
Scope and Performance Management | Number of kits completed versus planned | Kitting and wall chart |
Schedule Management | Performance toward meeting key program milestones | Microsoft Project |
Risk Management | Total number of risks per priority level (high, medium, low) | Risk management spreadsheet |
Time to develop risk mitigation plan for high priority risks | ||
Quality Management | Number of defects recorded | In-house tracking database |
Number of defects resolved | ||
Number of defects outstanding |
As stated earlier, ConSoul Software uses a customer-intimacy strategy to compete and gain competitive advantage in the facilities and construction software industry. Each business unit focuses on delivering particular features with specific, rather than general, solutions and does so with a lot of attention paid to maintaining the highest quality, customer involvement, and satisfaction possible.
All elements of the program management discipline explained previously are aligned with the three principle strategic objectives: maximizing customer satisfaction, providing high-quality products and services, and maintaining competitive time-to-market delivery schedules. Each element of program execution and its alignment to strategy is shown in summary form in Table B.4 and described in detail thereafter.
Table B.4. Program elements aligned to strategy
Program Management Elements | Alignment |
|---|---|
Program Organization | Matrix structure with many interfaces between engineers, software testers, technical communications, and product managers |
Program Process | Milestones are deliverable driven. Change requests often come from marketing and customers. Risk is based upon uncertainty toward meeting strategic goals |
Program Metrics | Measure program details toward achievement of strategic goals. Focus on meeting major program milestones, quality of the product, management of customer requested changes and management of risk |
Program Tools | Scope, performance tracking, and risk tools are important. Schedule tools are standard and flexible, whereas there is no specific tool for cost |
Program Culture | Customer driven, collaborative, wide-open communication, high degree of respect, pride, and teamwork |
- Program organization:
The Silverbow program organization is aligned to the business strategy by the utilization of a matrix structure that enables a high degree of cross-discipline interaction and collaboration. Interdependencies between engineering, software test/QA, technical communications, and product managers are focused on maintaining customer satisfaction and delivering quality products. The team was made as small as possible to facilitate open communication.
Product managers were the representatives and voices of customers, and their responsibility was to make sure that the product matched the customers' needs. The software test/QA team was responsible for assuring the highest-quality software possible. Mike Billard, the engineering lead for the Minutes Meeting feature, told Balebi, "We do set dates, but we are not hard set on achieving the dates because customer satisfaction and quality factors take precedence. We would drop everything if a customer had a problem with one of our products in order to fix it for them."
- Program process:
The program process adopted by ConSoul is highly focused on satisfying their customers. Customers are encouraged to be involved in the process by defining their needs and wants in the predefine phase—evaluating preproduction releases during the design phase, participating in the integration process, evaluating the product under operational conditions, and providing feedback to the program teams.
Designing the software is accomplished through a process of iteration, allowing for continual improvement, maturity of the product over time, and an opportunity for customer change requests to be evaluated and incorporated.
- Program metrics and tools:
The program metrics and tools utilized were highly aligned with the three primary strategic elements by focusing on the measurement and tracking of software quality, management of program and project risks to success, feature content, and performance to committed schedule.
- Program culture:
The program culture was highly influenced by the business strategy of the company. Therefore, there is excellent alignment between business strategy and program execution. Strategic objectives are clear, concise, and measurable, and the program strategy, organization, processes, metrics, and tools all support attainment of the business objectives. The cross-discipline program structure provides clear lines of responsibility and authority, and the PLC process has well-defined phases and phase-exit criteria. Some of the culture's other elements include the following:
Cross-discipline collaboration and open communication. There are no walls between engineering, software test/QA, program and project managers, or high-level executives.
The organization is driven by the customers.
The status of employees' work is tied to how well they know the product.
The environment encourages a high degree of respect, pride, and teamwork.
Team Silverbow spent nine hours in two days planning for review of the options. They rechecked the status, reviewed their strategy, organization, process, metrics and tools, how they were applied, and how the relevant decisions were made. Multiple iterations of what-if analyses were performed, resource reallocation was evaluated, pro and con analyses of each option were carried out, and rough comparisons established. Eventually, three final options emerged. Balebi will present the following options to senior managers:
Option 1
- Strategy:
Stay on the current course. Keep the scope, all features intact; shoot for the same deadline, using the same plan; and pursue quality as goal 1.
- Pros:
We know the game.
The team feels comfortable playing the way it knows.
The goals are reachable.
- Cons:
We will most likely be late by one month.
We will lose sales.
Team members may start finding new jobs as the program is nearing the end.
Option 2:
Keep all features intact and hit the announced release date.
- Strategy:
Crash schedule, fast-track, and outsource. First, in some parts of the program, we will crash the schedule by adding more resources, retaining activity dependencies and shortening critical path activities. Second, we will fast-track some parts of the program by breaking activity dependencies and creating new ones to overlap and speed up the schedule. Third, we will outsource the software testing to an external, top-notch company to accelerate the schedule.
- Pros:
It will be a feat.
Releasing product as announced.
Making customers happy.
- Cons:
We may not be able to deliver on time with the quality desired.
Outsourcing was never tried before.
Fast-tracking is a new approach for us.
Option 3:
Drop the two features and finish on time.
- Strategy:
Drop the two features. That enables the elimination of time to integrate the two new features, making it much easier to deliver on time. Also, to pay attention to the quality of the remaining features.
- Pros:
Will deliver on time with good quality.
Will release as announced.
It is still the best product in the market.
- Cons:
We may lose about 20 percent of the product sales (phone survey of lead customers).
Because we failed on our product feature promises, we may lose some customers permanently.
We may have a tarnished reputation.
After getting word from Smiley that the Silverbow program manager was ready to present a set of options, senior managers agreed to see Balebi for a brief review. The senior managers were organized as a Product Approval Committee (PAC) who have the authority to approve all product programs, perform gate reviews, and make major strategic program decisions. The PAC included vice presidents of marketing, enterprise software, office software, finance, manufacturing, and the director of program management. The PAC was headed by the vice president of marketing, John Biffin. When Balebi entered the conference room, the PAC members signaled that they were ready to start the meeting.
"Bali, Christine told us that you have some new options to offer," stated John Biffin.
"Yes, I have three options—some old, some new. Bear with the details, although I will be brief," replied Balebi. Balebi took seven minutes to present his three options, not forgetting to mention the source of his data, whenever he could. Finally, he wrapped up, with what he believed was his punch line. "After you decide which option to pursue, the program team will make it happen."
Biffin's response took Balebi by surprise. "Actually, Balebi, we won't choose the option, you will. We saw you today for one reason only. We wanted to make sure that you have a reasonable plan, and you do, and tell you that we will give you whatever resources you need. Choose your option and go for it. But you should know, we will hold you accountable."
Stunned, Balebi tried to think about how to respond. But it was too late to say anything because the PAC members had already adjourned the meeting. Balebi hurried out and was ready to reconvene his team members to decide which option to pursue.
The Consoul software example demonstrates some very good practices of the program management discipline, as well as a couple of opportunities for improvement. This example shows how business strategy drives the program management practices, structure, methods, metrics and tools. In particular, how business strategy influences trade-off decisions on a program.
This example also shows the impact of not utilizing consistent scheduling and budgeting processes to manage both projects and programs.
[173] Snow, C. C. and D. C. Hambirck, "Measuring organizational strategies: some theoretical and methodological problems", Academy of Management Review, Vol. 5, No. 4 (1980).
[174] Treacy, Michael and Fred Wiersema, The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market. Reading, MA: Addison Wesley, 1995.
[175] Schwaber, Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004.