The expert sub-contractor

This is a true story. The company names have been changed.

Engaging the sub-contractor

When Acme Consulting was preparing to implement a work order management and call centre processing application at Standard Limited, Acme had several staff resources with expertise in the work order application. However, their only employee with call centre experience had never implemented this particular package. Acme had asked a sub-contractor to participate in the sales process and, now that they had won the contract, to work on the implementation.

Acme’s project manager had used the sub-contractor once before. On that previous assignment, the client staff had made some vague complaints about the sub-contractor, indicating her documentation and follow ups were inadequate. However, the client wasn’t very specific, and didn’t complain very much. The project manager knew that many other companies had used the sub-contractor and that she was generally recognized as having a lot of experience with that particular call centre system.

Standard’s project

As soon as the project started, the sub-contractor was dissatisfied.

·         As planned, Acme did hire the sub-contractor to do some of the call centre module work, but because this was a larger engagement, Acme also assigned their own resource to work on the team. The other resource had industry experience, but he did not have experience with this particular package, so was assigned a more junior role on the team. The sub-contractor complained to the project manager that she was not assigned enough hours on the project, as she expected to be assigned all of the call centre tasks.

·         The sub-contractor worried that her performance would be monitored by the more junior Acme resource.

·         The sub-contractor did not want to use Acme’s implementation methodology, but the project manager, the Acme resource and the client insisted on following it.

·         Differences in approach and work habits, such as attention to detail and quality of documentation, caused additional friction between the sub-contractor and the junior resource.

The project manager met with the Acme resource and the sub-contractor together to clarify roles and responsibilities. The sub-contractor agreed to follow the Acme Consulting methodology and both agreed to work together on ensuring the implementation was delivered according to the client’s requirements.

The problems continue

However, the client liked the more junior person’s work habits and approach, and over time, the junior resource informally led the team. In addition, although the sub-contractor appeared to be knowledgeable about the call centre software, the client and the junior resource did a lot of detailed analysis and didn’t always need the sub-contractor’s expertise.

There were occasions when the client felt the sub-contractor had given incorrect information about how the product worked, so the junior resource corrected the problems and did not charge the client for the time spent in re-work. Although the client was not overcharged, she felt that the sub-contractor should have been more knowledgeable so the work would not have to be re-done.

During the project, Standard Limited required some custom programming work to be done, and Acme Consulting had no resources of the right type available to do the work. So, when the sub-contractor proposed using her own staff to do the custom programming, Acme’s project manager did not object.

As the project continued, it became evident that the sub-contractor had continued to provide additional staff for more custom programming projects at Standard Limited. The sub-contractor team’s custom work became a source of confusion on the project. Who was responsible for delivery? Did Acme Consulting guarantee the work of the sub-contractor’s staff?

At the end of the project, Standard was generally pleased with the work done by Acme Consulting resources. However, they were very unhappy with the work done by the sub-contractor. In addition, when there were problems with the custom work, Standard called the Acme Consulting project manager, who had to refer them back to the sub-contractor.

Conclusions

Although the project manager had a queasy feeling about the complaints regarding the sub-contractor at the previous client, he ignored them because she was generally known as an expert. That queasy feeling was an intuitive recognition of risk and should not have been ignored. The project manager could have inquired further about the vague complaints at the previous client, and made a more informed decision about whether or not to use the sub-contractor at Standard Limited.

The sub-contractor assumed that Acme would use her for all of the implementation work because had no specific agreement had been made. Acme Consulting could have used the sub-contractor during the sales process and paid her for her time instead of agreeing to put her on the implementation project. Alternatively, a different resource could have been used, perhaps a different sub-contractor, or an Acme Consulting resource from another city or country.

Once Acme Consulting did decide to use the sub-contractor, she should have been managed more rigorously from the start. For example, a written agreement should have been drafted, covering the amount of work that was awarded to her, the methodology to be used, the quality of work expected, and how it would be measured. The agreement should have also specified how to terminate the sub-contractor in the event that the work delivered did not meet the standard required by the client.

The sub-contractor should have been specifically prohibited from presenting her own staff to work on other projects at the same client. The confusion caused by this practice led to a lack of satisfaction with Acme Consulting that was not directly attributable to Acme’s own work. 

In retrospect, the project manager says he made too many allowances for the sub-contractor, and should not have “fluffed off” his vague feelings of discontent with the sub-contractor’s work at the previous client.

Copyright 2015 Debbie Gallagher

To plan or not to plan

This is a true story. The name of the company has been changed.

Two projects, one plan

Acme Corporation, a U.S.-based retailer, created two projects, one to replace their financial system and the other to replace their credit card processing system.

Both projects were to go live on the same date. The credit card system was to take eight months, so it started first. When it was at the two-month mark, the six-month financial system project started.

The credit card system project was to include development of an interface between the new credit card system and the new financial system.

The credit card project was kicked off with the project manager’s declaration that “It’ll be tough, but we’ll make it”. There was no project plan, and therefore no scope definition, resourcing, or timelines.

Prior to starting the financial project, a comprehensive plan was developed. It included detailed definitions of items in and out of scope, team member roles and responsibilities, timelines, and a communications plan.

Progress on the projects

The financial system project had a steering committee, which met monthly. Due to the dependency on the credit card project, that project manager was required to attend and provide updates.

At the first steering committee meeting, both the financial system and credit card system project managers reported that their projects were on schedule.

At the second meeting, the credit card project manager stated that work was falling a bit behind, but they would be caught up soon and would be back on schedule.

Unfortunately, at the third meeting, the credit card project manager confessed that the project had continued to slip, and they could not catch up because the team was busy with extra work. They had decided to expand the credit card capabilities to allow an additional brand, which required dealing with a new financial institution and file format.

There’s no plan

The financial systems project manager asked for details of the credit card project, but the credit card project manager had no plan and no other documents to support resourcing, scope, and timelines.

The steering committee insisted that the credit card project manager prepare the information requested and present it as soon as possible. Preparation of project plans for the credit card project took nearly three weeks. The credit card project manager concluded that his project could not be completed on time.

The steering committee did not accept the credit card project manager’s recommendation to defer his project’s go-live. The go-live date of the two systems had been carefully chosen, the company staff had been informed, the financial data conversion would require re-work if the go-live date moved, and the new process designs were dependent on the two systems both being live at the same time.

The financial system project manager realized the critical importance of the credit card project to her own project’s success and offered to help the credit card project manager develop a catch-up plan.

The catch-up plan

The new plan defined the scope of work that would be done by the go-live date and the work that would wait until after go-live. Resources and timelines were identified in detail. The team on the credit card project would have to work 50-hour workweeks, reports would be delayed, additional specialists were hired on contract to assist, and some testing was eliminated, necessitating risk mitigation strategies for go-live.

The financial systems achieved the expected go-live date within budget, and the stripped-down credit card system also was live. However, the interface between the two systems did not work properly.

Acme management decided to live without the interface for over a month, which required a huge effort in creating manual entries to replace the data that was to be supplied by the interface.

Conclusions

The financial systems project manager did a good job of developing the plan and managing her own project. However, despite knowing about her project’s dependency on the credit card project, she took a hands-off approach to it until it was in trouble.

It was a good idea to include the project manager from the credit card project in the steering committee meetings.  However, the financial systems project plan should have included key elements of the plan for the credit card project, including critical milestones, scope, and resourcing.

This story illustrates how critical the project plan is. It allows the company to define expectations, measure progress, assess priorities, assign the right resources at the right time, and communicate as needed with the company.

Prior to starting the financial system project, the project manager and five others spent a full month developing the detailed plan. It seems like a big investment, but as a result of the detailed planning, her six-month project with thirty resources finished on time and on budget.

A project plan should include a detailed list of what is and is not in scope for the project. This definition would have prevented the credit card team from going off on a tangent, developing capability for a new credit card brand, when they should have been focused on the development of the credit card functionality and interface that were required by the go-live date.  At a minimum, clearly defined scope would have allowed Steering Committee to discuss the branding need, the impact of that effort and the implications for the other project.

Copyright 2015 Debbie Gallagher 

Musical chairs

This is a true story. The company names have been changed.

The project

Acme Corporation, a software vendor, was implementing their Sales Order and Payment Processing application at Standard Limited. The product was very flexible, but was also being customized to Standard’s needs.

The contract between Acme and Standard was structured so that there were no progress payments. Payment from Standard could only be requested after a successful User Acceptance Testing (UAT) phase.

The Standard project was estimated to take six months to complete, but at the five-month mark, development was still under way and the testing phase had not started yet.

A few resource changes

Acme had several staff on site doing the implementation and custom development work at Standard. During the fifth month, the project manager and architect were removed from Standard’s project to work for another Acme client. A new project manager was assigned to the Standard project, but the architect was not replaced.

Acme started to worry about Standard’s ability to pay them, as Standard’s business was struggling in the marketplace. Acme wanted to deliver the software and get paid before Standard ran out of money. In addition, Acme was concerned that Standard might sue Acme for non-delivery of the software if they didn’t finish soon. The new project manager was charged with ensuring the project was completed as soon as possible, in order to avoid the potential lawsuit, and to reduce the risk of non-payment.

The project manager assessed her team and discovered they were poorly trained and had learned very little on the project so far. The architect had been providing specific answers to questions from the developers, without explaining the business and software design background that would help them understand the product and their own work better.

The project manager also learned that the development team was sometimes building additional functionality than what had been agreed in the contract.

Getting the work moving

The new project manager immediately re-focussed the development team on the contract as the definitive guide to what was to be built, and directed that no additional work was to be done.

In addition, the project manager realized that a new architect, although not available to the project, was critical to getting the job done. She evaluated the developers on the team and found that one was a resourceful, determined person with good analytical capabilities. This developer was re-assigned to the architect role.

The new architect did whatever analysis was needed to resolve issues and was also able to teach what he learned to the other developers. Progress was being made.

More resource changes

As the developers became more competent, Acme management caused more staffing issues by reassigning them to other Acme projects where there was a greater likelihood of being paid for the work. The project manager had trouble maintaining any stability in the development staff on the project.

During the sixth month, Acme announced job cuts and laid off three of the project’s seven developers, without any notice to the project manager.

At about the same time as Acme’s job cuts, Standard announced that they were dissatisfied with the early results of UAT and would do no further testing until the existing defects were fixed.

Although the client was not contractually entitled to stop the testing phase, the project manager agreed because she didn’t have enough developers to complete the fixes. Having the testing stop allowed the corrections to be completed without new bugs being added to the work list.

The project manager needed to get the bugs fixed but was critically short of resources. Because the project was at the bug-fix stage, the project manager decided that short-term resources were adequate for completing the work. She approached other project managers at Acme and asked to borrow resources for short periods of time. For example, if a developer was not assigned for a few weeks prior to taking vacation in one or two weeks, the project manager used that developer on the Standard project.

When the existing defects were fixed, UAT resumed. The project manager continued to borrow developers for very short periods to correct deficiencies.

Time to pay

When the UAT was completed, Acme requested payment from Standard, but. Standard said there was no money to pay Acme for the software implementation and development fees.

Acme issued a legal notice to Standard that due to non-payment, Standard was not entitled to use the software.

Conclusions

The developer assigned to be the new architect had been reluctant to take on the role, as he felt under qualified. However, he was a good choice because he had the skills to figure out the solution to issues, and as he learned, he shared his knowledge with the developers.

Developers who temporarily could not be used on longer-term projects were a good solution to the problem of staffing the Standard job. These resources were not earning fees on other projects; so there was no additional cost to having them work on the Standard project.

The project manager had no support from her own organization to provide adequate resources to the project. However, her novel staffing approaches allowed her to complete the work so that a non-delivery lawsuit was averted.

The project manager was wise to ensure that the team delivered only what had been specifically contracted. Additional scope takes time, and time was critical to avoiding a lawsuit.

It was common for Acme’s projects to require significant customization and then run late and over budget. Acme management frequently made things worse by removing resources before the work could be completed.

Copyright 2015 Debbie Gallagher

Lessons for the project sponsor

This is a true story. The company name has been changed.

CRM project

Acme Corporation, a company specializing in implementation of business applications for small businesses, decided to expand into implementing Customer Relationship Management (CRM) systems.  

Acme executives decided to implement the CRM package for their own use before selling it to their clients. The implementation of CRM at Acme would be followed by the development of a marketing strategy for the CRM product.

The Acme employee setting up their new CRM system took the vendor training, then spent three days getting the system set up for Acme. The implementation included installation of the software, migration of data from the old contact management system, and four hours of training on system navigation to the first four users.

Review of the CRM system

Acme’s president engaged a marketing consultant to develop Acme’s marketing strategy for the CRM product.

The consultant began by reviewing what Acme had done on its own implementation of CRM. Her assessment was that the technical implementation of the system was very good, including software installation, database optimization and system performance. These had been achieved despite some technical difficulties with the hardware.

However, the consultant also pointed out that there had been no changes in business process to ensure the successful use of the new system. In addition, the implementation had been done with no clear understanding of the goals of the new system, the benefits that were expected or any vision of what could be achieved by implementing CRM at Acme.

Acme’s president was very interested in the consultant’s comments. He recognized immediately that she was right – Acme had not thought about what they hoped to achieve by implementing the CRM system, and had not considered business processes in their implementation.

In addition, the consultant talked to the president about his role should have been as the project sponsor, and pointed out how critical the sponsor was to the success of the project.                                                                

Implementing CRM again

Acme’s president asked the marketing consultant to re-implement the CRM product at Acme before developing the marketing strategy.

The president rolled back the CRM implementation, and Acme resumed use of the old contact management system for several more weeks. The president enlisted the support of another key executive in pushing forward with the re-implementation rather than using the system the way it had been implemented already.

The re-implementation started with a series of design workshops. The president attended every workshop, in order to highlight to Acme staff the importance of this project. By the time the fourth design workshop was over, the other staff members understood and agreed with the need for re-implementation of the CRM system.

The re-implementation took five weeks, considerably longer than the original three-day implementation. This time, the work included definition of the expected benefits of the system, as well as the new business processes needed to provide good quality data, and to ensure usage of the system to benefit Acme.

The consultant stayed an additional two weeks to complete the marketing strategy.

The sponsor’s lessons

The president of Acme, as the project sponsor, learned a number of lessons from this project. The first lesson was the importance of defining the system’s goals and benefits to the organization. Without these, the system has no purpose.

The sponsor also learned about the critical importance of business process change when implementing a system. Without processes to ensure the success of the system, it will never deliver the expected benefits. For example, in the new CRM implementation, processes were developed for gathering, validating, and using the data in the new system.

The consultant also taught the president about the very important role of the project sponsor. The sponsor’s support of the project in the organization was critical to its success. When the president attended design sessions, enlisted the support of another executive and, after go-live, used the reports produced by the system, he showed how important he believed the system was to the company. These actions carried more weight than his verbal statements to the staff.

The final lesson for the sponsor was the value of having the right person for the job. The employee hired to do the first implementation was a skilled technician, but with skills different from those required to implement this particular system at this particular company. The president recognized the importance of the marketing consultant’s ability to guide the setting of system goals and benefits and lead the development of new business processes.

Copyright 2015 Debbie Gallagher

That user is a loser!

This is a true story. The company name has been changed.

Setting up telecommuting

The manager of the research department at Acme Corporation approached management with a request to provide telecommuting capability for research employees. The research staff would need remote access to email, external journal articles, and internal document systems.

Acme executives thought the telecommuting capability would allow improved staff retention and flexibility, while also reducing office rent costs. A pilot project was approved, and an employee chosen to be involved in the pilot.

Set up and immediate failure

Acme set up a home office with company equipment for the employee. Because the employee lived in a rural area where there was no high-speed Internet access, a dial-up service was arranged.

Right away, the employee complained of intermittent service problems; email was failing, and the screen was freezing while he was trying to use internal documents or external journal articles.

The IT help desk suggested that the employee call the Internet service provider about the service problem. The Internet service provider said they had not been experiencing problems in the employee’s area and that the problem must be with the employee’s system or phone line.

The employee continued to call the help desk whenever the problem occurred, which became more frequent, usually more than once a day. Over the next three months, the problem continued and the IT department tried several different ways to identify the problem.

·         A technician was sent to the employee’s home to replace the modem and verify the configuration settings on the employee’s system. The problem was not resolved.

·         The Acme email and document systems were monitored for problems, but none were found that would cause the employee’s problems.

·         The telephone company tested the employee’s phone line, and verified that the line was fine.

·         A technician was sent to the employee’s home to replace the computer.

Escalation

The research manager complained to management that this pilot was a disaster and that IT wasn’t able to figure out the problem. Several VPs noted that it seemed impossible for the project to have gone so badly.

The IT manager was instructed to make the remote employee’s problem a priority and get it resolved. After reviewing the support desk records, the manager met with one of the support technicians. It was a mystery. The technician was instructed to report to the employee’s home to observe, and to spend every hour of every workday at the employee’s home until the trouble was definitively identified.

Duh user

The technician returned to the office after only a few hours, and could hardly wait to share her findings with the IT manager. The technician and IT manager laughed all the way to the management meeting to explain the problem – the employee had been using the telephone to place outgoing phone calls while the phone line was already engaged for Internet service. Because his phone was often in use for Internet service, his friends, family, and co-workers found the employee hard to reach. As a result, the employee started to make more frequent outgoing calls. He had not realized that the reason he had to click the phone button to get a dial tone was because his computer had the phone line in use for Internet access to email or the remote database.

A second phone line was quickly installed for the employee, the problem did not recur, and the rollout of telecommuting was expanded successfully to other employees.

Conclusion

The IT manager and technician thought the user was extremely stupid and found the whole situation hysterically funny. Unfortunately, the IT manager did not realize he had a serious customer service problem.

Some things were missed in setting up the pilot project for the telecommuting employee. First, although the IT department asked the office services department to make arrangements for the employee to have a second phone line, they didn’t follow up to make sure the line had been installed. This was a critical component of the plan.

Second, when setting up the employee’s home office, assumptions were made about the employee’s technical savvy. No assessment was made of the employee’s capabilities, and no training was provided.

When the employee’s problems started to occur, it took much too long for the IT department to really get serious about solving the employee’s problem. He had service problems more frequently than daily, and yet it took three months and the attention of several VPs to motivate the IT department to go on site and determine the employee’s problem first hand.

An observation – sometimes the only way to assess a problem is to be on site and watch. The issue can occasionally be beyond imagination.

Copyright 2015 Debbie Gallagher

We're not concerned about the budget

This is a true story. The company names have been changed.

Estimates are wrong

Acme Corporation’s salesman assured Standard Inc. that the billing and accounts receivable software, hardware, and customizations could be bought and implemented for $500 thousand dollars.

After Standard signed the contract, Acme’s project manager and team were assigned. They met with Standard to work out more details of their requirements and quickly realized that the salesman had under-estimated the costs. In order to support their business, Acme would need additional modules for inventory management, work order management, and additional details to support regulatory reporting. The price should have been $8 million!

Acme management was horrified and decided they would not show this new estimate to Standard. They decided to cut the figure to $6 million. The Marketing VP was interested in these new modules and agreed to pay thirty-five percent, bringing the number down to $4 million. When Acme presented this new budget, Standard thought the estimate was completely unreasonable, but could not agree to eliminate any customizations.

Standard and Acme worked together to create break down the work into two phases. Phase one would have half the work and a budget of $2 million, the remaining work and budget would be phase two. The contract was revised for the new scope of work and price, with additional provisions for a fixed price and for phase one to be completed within twelve months.  

Behind schedule, over budget

Phase one wasn’t even half over when it became very obvious that the project was running behind schedule and over budget. The project manager alerted the Standard sponsor and Acme’s management. The Standard sponsor told the project manager not to worry about the budget for now, but just to keep developing the customizations to make sure the project delivered on time.

For the next four months, the project manager continued to warn Acme management and the Standard sponsor that that project was continuing to run over budget and could not be completed for the expected amount. Both Acme management and the Standard sponsor assured the project manager that she should continue to do the work and bill Standard.

Standard continued to pay the monthly invoices until the end of the ninth month, which brought the billings up to the budgeted $2 million for phase one. More than three months remained in the schedule, and more than three months work remained to be done.

The invoice for the tenth month was being processed at Standard just as Standard was taken over by a new owner. The new owner refused to authorize payment for the tenth month.

Payments stop

The Standard sponsor asked Acme to continue the work, and the sponsor would convince the new owner of the value of the project and obtain approval for payment.

At Acme, it became known that Standard was not paying, and other projects began using resources from Standard’s project to do paid work. The project manager alerted Acme management and Standard that the project would run later as resources were dwindling. They encouraged the project manager to continue the project at whatever pace she could. By the end of the twelfth month, the original deadline, the estimate to complete was another five months.

Work and billings continued to the end of the fourteenth month, when the project fizzled out. Acme never got paid after month nine. Standard never installed the new product. The work completed was rolled into the existing product and sold to other customers.

Acme fired the project manager for allowing the project to run late and over budget.

Conclusion

Management at Acme did not accept responsibility for the problems that they created on this job. The project manager had made it clear to them that the project was behind schedule and over budget. They also knew they weren’t being paid. However, when the project ended disastrously, the project manager was fired.

The early estimates by the project manager and team came to $8 million, twenty-five per cent more than the figure used as the project budget. It was trimmed because Acme management thought the figure was too high to present to the customer. Unfortunately, unless the work is eliminated, reducing estimates of effort don’t make the effort go away. This cut in the estimates was not based on reduced work, and could not be achieved. The project running over budget was predictable.

It’s curious that Acme management did not arrange to meet with the new owner. A meeting with the person refusing to authorize payment would have allowed Acme to discuss the benefits of the project with the new owner. Alternatively, the meeting may have made it clear earlier on that there was no hope of the project being completed and paid. Instead, Acme accepted assurances from the Standard sponsor, who no longer had authority to pay.

Copyright 2015 Debbie Gallagher

Friendly fire

This is a true story. The company names have been changed.

Background

Acme Services was selling version four of its sales and distribution system to Standard Inc., a new customer.  Version four had many features that Standard wanted, including pre-built integration with several other industry-standard systems used by Standard.

Timing would be critical, as Standard’s existing system could not support upcoming regulatory requirements, and price discounting calculations that the marketing department believed were holding them back from significant sales.

What version to implement?

In May, Standard’s VP IT told the Acme sales rep that the regulatory changes were going to be government-approved sooner than anticipated. The system implementation would have to be completed by mid-July.

This date was not possible, as version four would be released in September, and then would need to be configured and tested before go-live.

Standard and Acme discussed other options. For example, could version three be implemented immediately, followed by an upgrade to version four later? That approach wasn’t feasible, as version three didn’t meet Standard’s integration and reporting requirements. Just as important, version three took several weeks to implement, so could not be completed by mid-July.

The Acme sales rep suggested to the Acme project manager that he should push the version four delivery date earlier and give Standard a September go-live date. The Acme project manager refused to guarantee an earlier completion and delivery date because he knew that version four couldn’t possibly be ready and implemented by then. The Standard VP IT was irritated that the mid-July date was not being taken seriously.

Back to requirements

The project manager asked Standard detailed questions about immediate requirements. Although Standard wanted everything that version four had to offer, what elements could wait and what elements really had to be in place in July?

Standard’s VP said they could live without the flexible configuration, management reporting, and integration for a short time, but absolutely had to be able to meet regulatory requirements for distribution of their new product by July 15. Some of the discounting features were also crucial to their marketing strategy.

The project manager suggested that what Standard needed by July 15 was version one, with some customizations. Doing the custom programming for version one would delay the release of version four, as the same programmers would be used. When version four became available, then Standard could implement it and get all of the features they wanted.

Standard’s VP thought version one was an acceptable interim solution. However, the Acme sales rep said there were some technical issues that would be problematic. She and the project manager retreated to another room to make phone calls to the Acme technical staff.

Friendly fire

As soon as they closed the door to the other room, the Acme sales rep let the project manager know that she was very angry. This was a terrible solution, as the sale for version four would not fall in the current year’s revenue, nor would her commission. There was no license fee for version one, so the only revenue would be for the custom programming and implementation fees. The phone calls made were not to technical staff but to the Sales VP and Executive VP at Acme.

The project manager was on the receiving end of a tirade from the sales rep, the Sales VP, and the Executive VP. They really wanted the version four revenue booked this year. They felt that if they pushed hard enough, they could convince Standard to accept the September delivery date for version four, allowing the version four sale to occur in the current year. Then, when the software was not ready, Standard would have no choice but to accept the delays.

Implementation

Acme did customize version one and install it at Standard by July 15. Although version one did not have much functionality and was inflexible, it was able to do the basics that Standard needed.

Standard was very pleased with Acme for coming up with a solution to the timing problem. They operated version one until March, when Acme implemented version four of the software at Standard.

Conclusion

Sometimes the project manager has to stand up to members of his own team to deliver what the customer really needs. The project manager’s recommendation was based on the customer’s best interests, but his own organization was displeased about the delayed revenue.

The version one approach allowed Standard to meet its regulatory obligations and use the price discounting features to expand the market for its product, so the effort was appreciated. Standard became a high-profile, very satisfied customer reference for Acme.

In order to figure out how to solve the customer’s timing problem, the project manager had to re-visit the customer’s requirements. This additional analysis was the key to determining how to solve the customer’s problem.

Copyright 2015 Debbie Gallagher