Project risk case study: Scarce resource management

Technology projects are heavily dependent on expert resources from the IT team and the business. Managing people whose work is critical to the success of the project is essential and managing their time can be challenging.

This case study is a situation where a business expert was proving to be unable to deliver to the timeline.

Case study

The project was development of custom reports. When engaging resources for the work, the project manager did the usual things to ensure availability of the resource: for example, arranged for dedicated team members, and obtained commitments from their managers that they would be free to concentrate on the project. For those who were not vendors, the project manager arranged for the individuals’ jobs to be filled by other workers so the project team could concentrate on the project work.

The situation

The development work proceeded but there were challenges and issues along the way (perhaps a case study for another time).  Due to the development issues, there were quite a large number of problems found in the testing phase. 

However, just as problematic, it was taking a very long time for the business expert doing the testing to identify the issues on the reports, and to re-test as defects were corrected.  As time went on, it became clear that the tester was a significant bottleneck in the process.

The project manager discussed the pace with the tester, who confirmed that he was concentrating on the testing tasks, and had not been pulled away to work on other non-project work. The tester claimed that it was just a temporary delay due to learning curve on what needed to be done, and that he would have no problem catching up.

Unfortunately, the tester’s prediction of increasing speed did not come true. The testing continued to take much longer than planned.  In addition, the tester claimed, and his manager agreed, that no one but himself was qualified to examine the reports and determine whether they were right or wrong.

Evaluation of the problem

The project manager decided to see for herself what was causing the delay, so she arranged to sit in the tester’s office while he worked. She did some other work, but by sitting close by was able to observe the tester’s process.

What she observed was that there were many time-consuming steps to complete the tester’s work.  He printed the legacy report; then printed the new report. Then, he went through every line and checked every heading, description, and number for accuracy.  Then, when he found a difference between the legacy and new report, he had to determine whether the difference was acceptable. If it was not acceptable, he had to log the defect in the tracking software.

The project manager realized that much of the work could actually be done by others. The only part of the work that the business expert tester really had to do for himself was to evaluate whether a difference was acceptable or not.

New approach

The project manager arranged to add two junior staff to the project. They were assigned to print the legacy and new reports, compare every heading, description, and number, and mark differences with highlighters and tape flags for review. 

The business expert was now able to focus on the one thing that no one but himself could do. He focused on evaluation of the differences between the legacy and new reports, and decided whether the difference was acceptable or a defect.

The project manager also arranged for someone else to log the defects for the tester, so he could concentrate on just the evaluation.

Conclusion

The project manager’s observation was essential to resolving the work bottleneck. Each report was taking two to four hours to test, but the portion that only the business expert could do was really only fifteen to thirty minutes.

By re-allocating much of the work to other resources, the business expert was freed up to complete the evaluation for many more reports.

Although their participation is critical to a project’s success, business experts can become a bottleneck on a project. In order to ensure the proper participation of the expert while also eliminating the bottleneck, it was necessary for the project manager to evaluate the work and break it down into its component parts. Then many of the steps could be completed by others, freeing up the expert to focus on the task for which he had the expertise.

Introduction to IT Project Risk

While working on a variety of IT projects, I’ve seen several project charters and risk registers. Over time, I’ve noticed that not all project managers have a solid grasp of how to identify and mitigate project risk. So, here’s an introduction to the subject.

These aren’t project risks

Perhaps it seems an odd place to start, but the most common problem I see is that many risks identified aren’t really risks.  So, what is not a project risk?

An issue is not a project risk.  An issue is something that is already a problem for the project. E.g. a risk item that states: Vendor is late delivering components. Since the vendor is already late, or you already know the delivery is going to be late, this is an issue, not a risk. A risk is something that could happen, but hasn’t happened yet.

An outcome is not a project risk. E.g. a risk item that states: The project might not go live on time. This statement is an outcome of one or more events that could happen, for which the outcome is that there could be an impact on the project timeline. A risk is the thing that might cause the project to go late or cost more, etc.

Also, a vaguely-defined concern isn’t a risk. Risks aren’t really properly identified if they are not specific. E.g. a risk item that states: Testing is a risk. This statement is too vague, as it doesn’t say what specifically about testing is a risk and why it is being identified.

These aren’t mitigation plans

In addition to incorrectly identified risks, I often see vague mitigation plans. E.g. Manage dependencies and milestones. E.g. Leverage vendor’s experience. These mitigation plans are too vague to be actionable.

What are we worried about? What will we do about it?

Every book on project management has a risk definition along the lines of “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.” (PMBOK, Fifth Edition). Following that, there’s a definition of risk mitigation, such as: “Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk.” (PMBOK, Fifth Edition)

Although accurate, these definitions can be simplified to aid understanding. The easiest way to identify risks is to ask yourself and others: What exactly are we worried about and why are we worried about it?

Then, once the worry and rationale are very clearly defined, the mitigation plan is based on:  What very specific actions are we going to take regarding that worry?

An example

Do you have reason to believe the vendor might deliver late – before it happens? For example, maybe the vendor has recently made a lot more sales than usual and you’ve had late deliveries when you’ve bought from other fast-growing vendors. If so, you can record the risk very clearly: Vendor has gained significant market share in the last three months. Based on our experience with other vendors, this market gain can have an impact on manufacturing capacity, which may result in late delivery.

If you want to avoid this event, think about what options you have to avoid your project being derailed by late delivery. For example, if the contract isn’t signed yet, can you build in a penalty clause, or pay a premium for on-time? Can you spend extra effort on vetting your requirements to ensure your own project doesn’t cause any impact on the vendor? Do you have access to other equipment you could use temporarily if the delivery is late? Does that strategy lead you define an additional risk and mitigation plan? Ask others for ideas on how they’ve managed this kind of risk before and how successful the strategy was for them. Be specific in your mitigation plan: go beyond platitudes such as good project management.

Do you have other worries?

Anything that causes you a specific concern is a candidate to be included as a risk.  Risks are as varied as the projects on which they arise. Here are a few examples I’ve seen: (1) Servers are being moved from a company-run to an external data centre during the same time period that our project needs to test connectivity for several interfaces. Testing connections to the old data centre will need to be repeated for the new data centre, with potential for delay to our project’s timeline. (2) Although the on-site project manager assigned by a major vendor has great leadership skills, he’s not particularly rigorous about scheduling and tracking against the schedule. Since he is managing a large team and a tight delivery timeline, we are concerned that we won’t have adequate visibility to progress or lack thereof. (3) Previous upgrades to this application have failed due to lack of understanding of the integration points.

Notice that all of these risks are very specific, and they provide a rationale for why the risk has been identified.

Schedule and follow up

Assign a responsible person and due date for every mitigation action item. If you aren’t able to assign a person and due date, the mitigation step probably isn’t defined clearly enough. Track these mitigation steps to make sure that they actually get accomplished.

Conclusion

Understanding of IT project risks and mitigation plans can be improved by simplifying the definitions to: (a) What you are worried about exactly and why; and (b) what you will do about it.

It is important to be very specific and provide the rationale for the risks. The mitigation plan needs to be detailed enough that each task in it can be assigned to a person and on a specific date. 

Project risk: Vendor management case study

Working with vendors is a fact of life on technology projects. It makes sense to engage vendors to work on your projects. They have product experience with many clients and can bring best practices in addition to technical expertise.

However, vendors are not your employees and it is wise to remember that their goals and your company’s goals are not always completely aligned. As a result, in addition to the benefits, there are risks in bringing on vendors to deliver your projects.

Case study

Here’s an example of a project gone off the rails due to issues with selecting and managing the vendor.

The client had issued a Request for Proposal (RFP) and selected a vendor to implement a new application and its supporting technology platform.

The vendor started missing deadlines early in the project. The client’s requirements for performance were not met. To resolve the performance issues, the vendor proposed hardware changes. The resulting procurement and installation time caused more delay.

Unfortunately, installation of the new hardware did not resolve the performance problems, so the vendor embarked on a series of changes to try and improve performance.  Time after time, the vendor said the performance changes would be done by the following week, but every time they were unable to deliver the improvements.  It was clear that the vendor’s team was working hard, including evenings and weekends, but still the system could not operate within the necessary timeframe.

After months of promises followed by non-delivery, the vendor asked for a three-month period to achieve the necessary performance. The client agreed to the three-month timeline, but once again, the performance metrics were not achieved.

At this point, the vendor asked if the client would make changes to other applications in the same business process. As long as all of the applications fit into the overnight process, the vendor’s own application performance would be of less concern. The client agreed to modify other applications, which caused further delays while requirements, development, and testing took place.

Unfortunately, the changes to the other applications were not sufficient. When done, it was clear that the vendor would still have to significantly improve the performance of its own product.  

The vendor continued to work at application changes and database tuning to try and correct the performance issues. When that failed to achieve the desired results, the client agreed to examine the business process to see if they could change it to accommodate the product’s performance issues. The process re-design did not create enough efficiency to solve the problem.

If you’ve ever been in this position, either as vendor or client, you know it’s a very unpleasant situation. The client and vendor blame each other for the problems. Millions of dollars are spent. The business does not have their new application. The vendor is losing money on the project. Discussions about legal action take place.

Causes

There were several problems with this situation.

In the RFP, the client did not specify performance requirements. This lack of guidance allowed the vendor to avoid considering performance when creating the proposal.

The vendor was a solid, well-established company, with an excellent reputation for delivery and support. However, the product was new, with no installations in the client’s industry or any other industry. When evaluating the vendor proposals, the client did not recognize the importance of the fact that the references provided by the vendor (for other products) were irrelevant to the project they were proposing.

The vendor’s size, stability, and reputation were a good thing, of course, in that the vendor was motivated to deliver to the client’s satisfaction, and had the financial resources to invest in efforts to correct the problems.  A smaller, less reputable vendor may have simply walked away early on.

As delays continued over many months and millions were spent, the client never had any discussion regarding whether the project should be cancelled and alternative products evaluated.  This inability to face the failure of a product and project is common. Many clients, once they’ve invested a lot of money, time, and resources, do not admit defeat and start over.

Conclusion

The interests of the client and vendor were never aligned right from the start. The client was looking for a product to install and add value to their business process right away.

The vendor was looking for a successful installation of its new product, so they could use it as a reference when selling to other clients.

If the client had realized up front the differences in their goals, they may have been able to negotiate an approach that worked for both. Instead, both the client and vendor have failed to achieve their objectives.

The middleman

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

The project manager gets in the middle

Acme Corporation, a large financial institution, decided to eliminate its personal credit card business to focus on commercial customers. As a result, Acme agreed to sell its database of customer information to a competitor.

Standard Consulting was engaged to extract the customer data and transform it into a format that the competitor could load into its own system. The competitor was creating a new marketing database system, and had hired a team of developers to build it for them.

Acme’s project manager estimated that it would take Standard about four months to complete the work.

Acme’s management was concerned about the possibility of disclosure to the competitor of any data in the database beyond the specific customer data that had been sold.  To alleviate management’s concern, the Acme project manager decided to act as the communication channel between Standard and the competitor. The consultants from Standard could not speak directly with the competitor or with the competitor’s development firm. Instead, they directed their questions by email to the project manager at Acme. Then the Acme project manager would obtain an answer from the competitor and direct it back to Standard.

The communication process was cumbersome and time-consuming. Because the questions and answers were all exchanged by email, there was no opportunity to ensure that the receiving party completely understood the question being asked and as a result, it would sometimes not be answered satisfactorily. Follow-up questions were needed, and the process was repeated.

Because the competitor’s marketing database was still being developed, some data requirements were still changing, resulting in changes to the extraction programs being built. Sometimes these changes were not communicated to Standard via Acme quickly enough and as a result, test migrations of data would fail.

The project manager had other responsibilities, so answers to questions, and follow-ups for changes or issues were slow. The project ran late, but still the process continued. Some issues required significant analysis and discussion between Standard and Acme’s competitor, but all of these took place via email through the Acme project manager. 

Well into overtime

The project had now run for twelve months instead of four, and still it was not finished. Acme’s management was concerned that it might be sued by the competitor for non-delivery of the customer data. The Acme project manager was replaced.

The new project manager met with the Acme and Standard teams to develop a comprehensive list of outstanding tasks and new dates by which the tasks needed to be done.

In addition, she had brief team meetings every day. At the daily meeting, the tasks due that day were determined to have been completed or to have slipped. If a task had slipped, remedial action was taken immediately. Representatives of the competitor attended part of the meeting by phone, so that questions, answers, and outstanding issues could be resolved immediately.

The project finished after sixteen months, a full twelve months later than the original estimate of four months. Acme’s competitor did successfully load the customer data into the new marketing database system, and Acme did not get sued.

Conclusion

The original time estimate for the work was much too low. The Acme project manager did not realize the impact on the timeline of having so many parties involved in the process. Project managers who have successfully delivered multi-party, multi-location projects are painfully aware of how time-consuming the coordination effort is. Anything that can be resolved in an hour with one company involved can easily take ten hours with three parties involved. There is significant effort in the scheduling, discussion, resolution, and follow up for every issue. This data migration project had four parties: Acme; Standard; the competitor; and the competitor’s development team. Dealing with multiple locations is also time-consuming, as the immediacy of face-to-face contact is lost. Sometimes, when the related team is not physically present, the local team forgets to keep the off-site team up to date. This project had two locations, one with Acme and Standard, and another with the competitor and its development team.

Although the estimate of four months was too low, the project should not have taken sixteen months. The communication process designed by the original project manager was rigid. However, it might have been made workable by assigning that liaison role to someone else. Because the project manager had other responsibilities, the management of the communication process often fell to a lower priority and caused project delays. 

The project manager should have placed a resource in that analyst/communication role full time.  That analyst should have been given the authority to speak with both parties by phone and in person, in addition to using email correspondence. This would have improved the response time to questions and issues considerably. It also would have reduced the number of times that emails went back and forth between parties who were trying to understand the issue well enough to get it resolved. Key hiring criteria for that analyst role would be verbal and written communication skills, organization, documentation (to capture decisions and agreements), and ability to prioritize issues. The cost of that one additional person on the job would have been significantly less expensive than running the project so late.

When it was clear that the project tasks and issues were not being completed on time, the new project manager did the right thing by ensuring very frequent meetings to review completion status and follow up.

The new project manager also brought the competitor to the status meetings, a step that helped immeasurably in getting issues resolved quickly.

Copyright 2015 Debbie Gallagher

Head in the sand

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

The data conversion

Acme Corporation was a retailer based in Canada and in France. They were replacing the separate Canadian and French systems with one common system, including financial as well as sales and distribution modules.

Early in the project, a software developer in France was assigned to design and create data conversion programs to load data from the two old systems into the new system. The developer was familiar with the French legacy system but not familiar with the Canadian system or the new system. The developer’s experience with the French legacy system provided her with some knowledge of the business and its system requirements. However, she had always worked for a supervisor or project manager, and did not have any experience at managing work.

Several members of the project team expressed their concerns to the project manager. Surely the one developer would not have time to plan and develop all of the programs needed to convert data from both legacy systems. The project manager was not worried, as the developer had always got assigned tasks done in the past.

After several weeks, there was no visible action from the developer, and the project manager was still unconcerned, so a couple of team leads on the project decided to try and move things along. The Purchasing/Accounts Payable team lead called a meeting to discuss data conversion requirements for vendor master and purchase orders. The Sales/Accounts Receivable team lead called a meeting to discuss conversion requirements for sales orders, pricing, and customer master.

The developer took some notes at these meetings and said she was going to start coding extracts from the French legacy system. She did not provide any confirmation to the team members about what would be delivered. In addition, she spent no time working on extraction of data from the Canadian system.

The team leads continued to press the project manager for answers about how the data conversion was going to get done with only one resource. After a few more weeks, the project manager assigned a second developer to write the data conversion programs for the Canadian data. The two developers had no shared design to ensure that the separate work done for the two legacy systems would have similar results in the new system.

The team leads kept voicing their concerns to the project manager, that the data conversion was not well planned, that there might not be consistency in the data from the two countries and that the programs might not be done on time. The project manager saw no need for the developers to stop their work to do some planning.

At the project status meetings, it became clear that the team leads and the developers had different ideas about what was to be delivered. As a result, additional meetings were held and the programmers took notes on additional files to be converted.

When data was loaded into the new system for testing, the team members were shocked at how many fields were missing or incorrect. The team leads again approached the project manager with their concerns about the data conversion and whether it would be on time and of acceptable quality.

The project manager still thought it didn’t make sense to stop and coordinate efforts between the two countries or to create a schedule at this late date. He decided that the developers were too busy working to take time out for planning.

The project manager starts to worry

When the go-live date was less than a month away, the rest of the system implementation was going well, but the data conversion work was significantly behind, the project manager got worried. Conveniently for the project manager, he was directed by the steering committee to delay the project go-live date by three months. Acme was acquiring another company and the system implementation would be delayed for a few months to allow Acme to focus on store amalgamations and training the new employees on Acme’s way of selling products. The project manager was very relieved. He did not have to be the one to defer the go-live date due to a late and inadequate data conversion.

Conclusion

The project manager made an invalid assumption right from the start and kept to it even despite evidence that proved him wrong. He thought that since the French developer had always got the job done when given assigned tasks that she would also be able to deliver when she needed to define, plan, and manage the work as well. Project management was not a skill the developer had learned and so the assumption was unfair.

In addition, although the project manager monitored the progress of the rest of the project very carefully, he didn’t pay much attention to the scope, resourcing and delivery of the data conversion. He assumed that data conversion was a small and easy task compared to the rest of the project. If he had ensured that scope was defined and a schedule was developed at the start, he would have realized the extent of the work to be done. Even some preliminary discussions with other project managers would have given him better insight into the likely challenges of the data conversion work. Except for the company’s timely acquisition of a competitor, the project manager would have faced an embarrassing and costly project delay, due to his reluctance to define and plan the data conversion.

Unfortunately, both developers were uncomfortable about asking for help. They would have been wise to insist to the project manager that they needed help with the planning and coordination of the two countries’ requirements.

Copyright 2015 Debbie Gallagher

The penny pincher

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

Losing staff and saving money

Acme Corporation, a British manufacturer, was implementing a new billing system, including development of custom reports, modifications, and interfaces. Acme assigned twenty of its own staff either part-time or full-time to the project. In addition, Acme engaged Standard Consulting, who assigned twenty part-time and full-time consultants to the project.  The consulting fees were expected to be about two million Euros for the nine-month project.

The first phase of the project went well, with the smallest Acme division starting to use the new billing system after seven months, as scheduled. The remaining divisions, billing over ninety-five per cent of Acme’s customers, were to be live nine months after the start of implementation.

During the eighth month, one of Acme’s four technology staff quit with very little notice. Acme’s IT manager wanted to get a replacement hired quickly, but was also concerned about cost. When the Standard project manager suggested that a Standard consultant could be added to the team, the Acme IT manager declined due to the additional fees. Then the Standard project manager offered to assist in the recruiting process, but the Acme IT manager declined that option as well. Instead, the Acme IT manager brought on a resource from a foreign country, which would save five thousand Euros for the remaining time on the project.  

The foreign developer arrived within a week, and in less than two days it was obvious that the developer was not qualified and also spoke very poor English. By the time the developer was terminated, a person-month had been lost. Acme decided to add another Standard consultant to the project to replace the terminated developer. This arrangement started immediately.

Now a second Acme developer quit his job, also with short notice. While recruiting was under way for the empty positions, another Standard consultant was added to the project part-time.

Then, a third member of the Acme technology team left his job with short notice. This time, the Acme manager asked the Standard manager to assist with the process of hiring a contractor, to ensure the new person was qualified to work with the new software and development tools. The new contractor started right away to catch up on the lagging work.

Go-live

The Acme and Standard technology team members worked longer hours to try and catch up. However, enough time had already been lost that it could not be completely caught up, and the go-live date had to be delayed by a month.

During the project, the project team ran test billings successfully. So, in order to save money, Acme’s IT manager told the Standard project manager that no go-live support would be needed, and the Standard consultants could leave. Standard Consulting’s project manager thought it was wiser to keep a few of the consultants on site for a couple of weeks after go-live to support Acme. This would have cost Acme about twenty thousand Euros, which had already been included in the budget for consulting fees. However, Acme was insistent that they didn’t want to pay for it and that Standard should leave.

After go-live, Standard’s project manager was shocked to find out that Acme was extremely unhappy. Upon investigation, Standard’s manager found out that Acme had not properly run a step that was required prior to running the billings. Acme’s staff did not have the experience to solve the problem quickly and the billing had been delayed. Acme’s CIO had been concerned that she would lose her job if they could not produce invoices after spending millions on implementing the new software.

After all the work that had been done well, Standard’s project manager was very concerned that Acme could end up dissatisfied. In order to ease Acme’s concerns, he assigned a consultant to automate the pre-billing step and did not bill Acme for the work.

Conclusions

Acme’s decision to choose the unqualified foreign contractor to save five thousand Euros out of two million Euros in fees was short-sighted, as the go-live date ended up being postponed for an entire month.

The Standard Consulting project manager discovered that it is possible for a project to go well and then for lack of go-live support, the delivery team can lose credibility. He may have found it worthwhile to manage this risk by assigning one consultant to stay or be on-call for a week or two at go-live and not bill the client, or bill at a discounted rate. Providing a bit of free service is what he ended up doing, and perhaps they’d all have been happier if it had been done earlier.

It is tempting during a project, when budget revisions are needed, to consider reducing or eliminating the go-live support budget. In this case, where the client had continuous turnover, leaving only the consultants with knowledge, it was an unwise decision. It may have saved a few dollars but nearly prevented the company from running its business. 

Something I wonder:  When the billing couldn’t be made to work, and his boss, the CIO, was in danger of losing her job, why didn’t the manager phone the consultants to ask for help?

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

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

Something keeps coming up

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

The vision

Acme Corporation is a successful business selling medium and large-scale business applications. Some executives had an idea for a new application. After further development of the idea, and approval of the business case, a project was started to create the new product.

The steering committee comprised three executives, all of whom had been involved in developing the business case. Senior management was very excited about the prospects for the new product.

Before starting the definition of functional requirements, the project manager interviewed the three executives on the steering committee individually, to determine what their vision was for the new software. Two of the executives agreed on a vision, but the VP Product Development had different thoughts. The project manager met with all three as a group, to try and achieve consensus. There were still significant differences.

In order to try and achieve consensus, the project manager and steering committee agreed it would help to meet with industry experts who could provide additional insight on high-level requirements.

Meeting the experts

Just as the first industry-expert meeting was about to begin, the VP Product Development apologized and explained that an emergency had just come up on another project and he would be unable to attend the session. The other two executives and the project manager continued the meeting with the industry expert.

The next industry-expert meeting was scheduled at a time convenient to the VP Product Development, to ensure he would be able to attend. Unfortunately, a last-minute urgent matter again prevented the VP Product Development from attending. He urged the others to go ahead without him.

At a follow-up meeting to discuss high-level requirements based on the feedback from the industry experts, the VP Product Development didn’t like the proposed product, and thought it wouldn’t sell. He was unable to stay at the meeting long enough or to attend follow-up sessions where further requirements and direction were developed. However, he didn’t want to hold back the team, and suggested they should forge ahead without him. He would review the more detailed requirements and early product prototypes.

Product development

The high-level requirements were not defined, development had not begun, yet the project was behind schedule already. All three members of the steering committee urged the project manager to get the project back on schedule. She should go ahead and develop more detailed specifications, based on the high-level requirements already developed.

In addition, the steering committee was worried about the lack of progress reported on product development, and urged the project manager to get the work started, using the high-level design. As the more detailed requirements were established, the development team would re-work their design as needed.

Project resources were gradually shifting. The database designer was moved to another project and replaced. The technical architect transferred to another division and was not replaced. Her work was assigned to another member of the project team. Some development staff were given additional high-priority work for another project by the VP Product Development.

A key component that was to be purchased and integrated into the new product was not approved for purchase. Instead, the development team built similar functions into the product.

On the market

As a result of the shifting requirements, related re-work, changing and lost resources, the development of the product was behind schedule. Since competitors were moving forward with their own products, the scope of the development plan was revised, eliminating some features in order to have a product ready for sale earlier. They could incorporate the removed features in a future release.

The first product was launched. No one bought it, as competing products were already established and were much more robust. The product was later dropped.

Conclusion

The failure of the product can easily be traced to its root cause. The product didn’t sell because it launched late with insufficient features. This lacklustre product was due to delays in development, as a result of resource gaps and re-assignments. These resource issues were due to the lack of commitment of the VP Product Development.

The signs of lack of commitment were evident starting from the two industry-expert meetings, where “something just came up” and prevented the executive’s attendance.

The project manager got caught up in a get-it-done mentality, focused on the hard deliverables needed to keep the project on schedule. As a result, she did not recognize the signals that her project was doomed to fail, no matter what she did.

Copyright 2015 Debbie Gallagher 

Drowning in email

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

Background

The Acme Corporation and its two subsidiaries were outsourcing their order taking and fulfillment functions to Standard Inc.  Every month, Standard would send a file of orders taken and shipped so that Acme and its subsidiaries could record entries in their financial systems.

Standard would create one file each month and split it into three, so the file design and content had to be capable of loading into the three different financial systems used by Acme and its subsidiaries.

The three companies would need to define common requirements for the incoming file. A facilitator worked with financial, sales, fulfillment, tax, and systems representatives from Acme and its subsidiaries to define the common requirements.

The situation

With so many participants involved and multiple organizations and systems to serve, progress on the common design was very slow.

In addition, many issues surfaced during the design discussions. They were documented in minutes of the meeting and assigned to individuals for follow up. However, some issues were very time-consuming to resolve and held up progress on the design.

When the deadline was reached and the requirements were not completed, the Standard Inc. systems analyst started to attend the requirements sessions to learn what she could about the requirements.

Between requirements meetings, several participants were sending email and phone messages to the analyst at Standard, letting her know about the various issues and proposed resolutions.

The Standard systems analyst began to receive twenty, then thirty, and then forty messages per day about design concerns.

Then, as the technical specifications were being developed at Acme and the two subsidiaries, there were additional questions. At fifty messages per day, the systems analyst at Standard began to feel like she was drowning in email.

The blame game

The staff at Acme and its subsidiaries complained that the Standard analyst was unresponsive and not able to answer questions or address issues. They were beginning to question the ability of Standard to complete the necessary files. Standard, however, felt that Acme was not being fair, as the design was late being completed, and issues were continuing to be raised long after Standard had expected them to be settled.

The project manager reviewed several of the emails with the facilitator who had been working with the participants to create the functional design.

The content of each message required assessment of the impact on other aspects of the design. In addition, there were frequently other parties to consult before a resolution could be reached. For instance, if Acme head office wanted sales orders to be summarized differently, the two subsidiaries would have to be consulted to see if the change would be acceptable. On top of these considerations, the volume of messages to be dealt with was very high.

They concluded that Standard’s analyst could not possibly have time to answer the volume of issues and questions in addition to the work she already had to do. Unfortunately, Standard’s analyst did not have help, and getting someone at Standard assigned and then up-to-date on the project and issues would take a long time.

However, the facilitator had been involved in the requirements sessions already with all parties, so was knowledgeable about the project details.

The project manager assigned the facilitator to coordinate all issues and questions. Everyone wanting to question or raise an issue with Standard’s analyst had to send it to the facilitator. The facilitator would coordinate all the requests, prioritize, and summarize them for a once-daily phone meeting with the analyst at Standard. In addition, the facilitator would do all the coordination between Acme and its subsidiaries for requests for changes.

Epilogue

It took a few weeks for the backlog of issues and questions to be cleared up. However, the assignment of the facilitator to work as an assistant to Standard’s analyst worked well, and the backlog lessened. In addition, when the analyst had a question or issue for Acme, she could have the facilitator coordinate with Acme and the subsidiaries, and determine a common answer. With so many parties to consider, this coordination saved a lot of time for the analyst.

Conclusion

The project manager had heard complaints from both sides. Acme complained about how unhelpful and unresponsive Standard was, while Standard blamed Acme for causing the project to be so late.

However, the project manager realized that pointing fingers was not getting the job done. So, he focused on assessing and solving the problem.

The problem was that the analyst at Standard had too much work. The project manager’s solution was to assign an extra resource, a knowledgeable one, to help out the analyst.

Copyright 2015 Debbie Gallagher