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. 

The meddler

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

Changing direction

Acme Corporation, a manufacturer, was building a new data warehouse with multi-dimensional analysis and reporting capabilities. There were two main teams, one building the technical infrastructure and one developing the multi-dimensional cubes and reports.

The project was already underway when the project manager left and a new project manager was hired. At the first technical team meeting after the new project manager joined, the technical team lead discovered that his team was trying a new approach instead of what had been agreed as the path to developing the technical architecture. The team members explained that the project manager had decided that they should try a different approach. The technical lead spoke with the project manager to find out why he had been left out of the discussion. The project manager was surprised. She had certainly not intended to leave out the team lead. She had dropped by to discuss a different matter, when an informal discussion on the technical progress had come up and the change in direction had been agreed. The technical lead pointed out to the project manager that once the discussion turned to alternative approaches, he should have been involved in the discussion. At the very least, he should have been informed of the outcome, as it affected his team’s scheduled tasks and his resources. The project manager hadn’t meant to leave out the team lead, the new approach was a good one, and so she didn’t see the harm.

A few days later, the technical lead discovered a member of his team was working on a different assignment. The project manager had approved the reassignment. The team lead discussed this change with the project manager, who explained that she had just bumped into the other project manager in the elevator. This had not been a formal meeting. The other project manager happened to have been short-handed, so she had agreed that the team member could help out. Again, the technical lead protested that he had been left out of the decision and not been informed. The project manager didn’t think this was a problem. After all, the technical lead had not been left out deliberately, it was just informal, and the decision was a good one, so she didn’t understand his concern.

This pattern of events continued. It didn’t take long for team members to bypass the technical lead and start going straight to the project manager to resolve any requests or issues. The technical lead became extremely frustrated. Repeated meetings with the project manager did not correct the situation. So instead, the technical lead just tried to keep up to date on what was going on with his team and understand the progress they were making. The technical lead disliked working this way, but his repeated discussions with the project manager had not corrected the problem.

The technical lead regains control

The cube and report team started to have significant problems. The users had rejected the prototype cubes and reports. Significant re-design and re-work was required. End users and developers were blaming each other for the rejected work. In addition, the cube and report team had a lot of difficulty in doing the re-work. This team now required a lot of time from the project manager.

As a result of the upheaval in the cube and report team, the project manager was too busy to address informal questions about the technical team’s work. The technical lead regained control of his resources and scheduled tasks, and kept the project manager informed about progress through the weekly status reports and meetings. The work proceeded according to schedule.

As the cube and report problems were resolved and the project neared completion, the project manager congratulated the technical lead on a job well done. The technical lead pointed out that he had delivered the work with the appropriate quality on time, even though the project manager had been unavailable to interfere. The two laughed about the situation together.

Moving on

On their next project together, the technical lead met with the project manager at the beginning of the project. The project manager agreed to try very hard to avoid interfering. They met weekly to discuss progress, issues and explore alternative approaches.

Sometimes, the project manager slipped back into her old ways, but the team lead would remind her to stop meddling. They would laugh together about it, and the project manager would back off.

Conclusions

There were a couple of reasons for the project manager’s behaviour. First, she was new to the organization and felt a need to prove herself in the new environment. As a result, she was spending extra time getting involved in details to reassure herself that the project was going to succeed. In addition, the project manager was a very easygoing, approachable person, so team members and other project managers felt comfortable chatting about their project issues and getting her involved.

The project manager was usurping the authority of her own technical lead who was competent and did not require close oversight. By doing so, she was working very long hours doing more work than she really needed to. She could have been focusing the whole time on output and issues, and instead got involved unnecessarily in the details of the technical team.

It is fortunate that the project manager and the technical lead had a friendly relationship and were able to laugh about this problem and solve it. Overriding the technical lead’s authority was really no laughing matter.

Copyright 2015 Debbie Gallagher

It's a technically elegant solution

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

The schedule

Acme Corporation, a European manufacturer, was implementing a new billing and accounts receivable system. Acme engaged their implementation partner, Standard Consulting, to develop the data conversion programs.

Acme’s legacy billing and accounts receivable system was more than twenty years old. It was running on hardware and an operating system that were no longer sold. In addition, it was custom software, developed by a person who was no longer available to support it or explain how it worked.

The client team made high-level decisions about what data they needed converted to their new system to support internal and external reporting, as well as long-term billing needs. They wrote these requirements in a strategy document, which they gave to the Standard Consulting project manager.

Standard’s project manager assigned a technical team lead to review the strategy document, and prepare a schedule and cost estimate. Standard’s project manager was satisfied with the schedule and cost, and so was Acme. The data conversion programs were to be ready for testing by the client team in five weeks.

Falling behind schedule

After three weeks, the data conversion budget was half used. This was about as expected. However, the technical team leader had not submitted her status reports, and when pressed, provided only vague verbal reassurances that everything was under control. She seemed unclear on how she would know that her development team was finished.

Although there were several components required to convert the billing and receivables data, there were no components ready to test by the five-week deadline. Again, the technical lead was vague and assured the project manager that the programs were progressing.

After about seven weeks, programs were ready for testing, and the client lead was asked to review the sample data in the new system. The client lead was shocked. This data wasn’t even close to what was required. There were significant differences between what was stated in the high-level requirements document and what had been developed. In addition, there were several components that had not been built at all.

The technical team lead was disappointed, as she had developed a perfectly elegant solution to the technical challenge of extracting data from the legacy system, and the client was not appropriately appreciative of the effort or outcome.

Getting the programs corrected for go-live

The Standard Consulting project manager added a business analyst to the technical team. He was to review the design of the conversion programs compared to the requirements, and determine what re-work and new development was required. However, there were no detailed design documents to review, only the original high-level strategy document. The business analyst assessed each component by developing the detailed design, working with the technical lead and billing lead to solve discrepancies between what was needed and what had been built. Standard Consulting was committed to delivering what had been committed to Acme. Significant parts of the data conversion programs were re-written, and the missing components were developed.

Testing was very time consuming. The programs had not been built for the volume of data and complexity that was really required. As a result, whenever one bug was fixed, others would appear. More than a dozen rounds of testing and re-work were required for some components. The client couldn’t keep up with the testing, so Standard had to provide additional testers. The data conversion costs went three hundred per cent over budget. The client and the technical team worked nights and weekends to complete testing and program revisions.

The go-live date was not delayed. However, only the basic functionality could be used right away, because not all of the conversion components were ready. The technical team continued to work for another month to complete the remaining components.

Conclusions

The project schedule prepared by the technical team leader should have been the first sign to the project manager that something was amiss. The technical lead had been focused on the technical complexities of extracting data from the legacy system, and had planned only technical deliverables. She had included a task for preparation and a milestone for sign off of technical design, but no preparation and sign off of detailed requirements.

The next sign of a problem was the lack of status reporting from the technical lead. When she tried to give just vague reassurances, the project manager was rightly concerned, but should have pushed harder and earlier for proper status reporting, with progress described for each component. This would have allowed the project manager to identify earlier that components outlined in the strategy document were missing.

In the end, the client go-live deadline was achieved, and all of the components were finished. The data conversion programs ran successfully and loaded correct data into the new system. However, the client was not happy. Acme was not interested in the technical elegance of the delivered programs. What they wanted, and didn’t get, was programs that met their requirements and were delivered according to the originally agreed schedule.

Copyright 2015 Debbie Gallagher

I won't trouble the client with it

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

Choosing the product

Acme Corporation, a large Asian retail company, was expanding into the U.S. and engaged Standard Consulting to select, negotiate the software purchase, and implement a financial system to be used for their new U.S. subsidiary.

Acme wanted to move along quickly. Based on an existing professional relationship, Acme trusted Standard’s capabilities and expertise. Because Acme was setting up a new subsidiary, there were very few employees so far. Employees who had been hired had joined Acme recently, so had no experience yet in Acme processes and procedures. As a result of all of these factors, Acme decided to rely heavily on the expertise of Standard’s project manager in assessing the strengths and weaknesses of the various products, and recommending a product for Acme.

The project manager selected a system that was new to the North American market, but was widely used in Asia’s manufacturing industry. The vendor was planning to build additional functionality into the product to accommodate retail businesses.

The project manager was satisfied with the vendor’s plan to accommodate the U.S. market and the retail business requirements. She wanted to help the client feel comfortable with the selected product and vendor, and didn’t want to worry the client. So, she decided to skip the project risk assessment; it was only a list of potential problems that might cause unnecessary concerns for the client.

Problems surface

As the project got under way, the team started finding bugs right away. Many bugs were serious and affected basic financial processes. As the implementation continued, it also became apparent that the vendor’s new functionality for retailers was not going to be delivered, and was not even under development. As time went on, more and more bugs were found and, like the earlier bugs, several were serious, with the potential to prevent operation of the software by Acme.

The project team was heavily reliant on Standard Consulting, as there were very few Acme employees hired yet. Those who were on staff were all new hires and did not know yet what their business required. As a result, the project team had to guess at what some of the system configuration should be.

The project manager was pleased with the vendor’s intention to fix up all the bugs, and decided not to bother the client with any worries about the continuing and increasing incidence of serious bugs. The project team managed to develop a number of complicated workarounds to enable operation of the system, despite the lack of retail functionality, and to eliminate reliance on the worst of the buggy programs. The project manager continued to assure the client that everything would work out well.

More problems after go-live

The system did go live, but was very complicated to use and unstable. The project costs went over budget and because Acme hadn’t been made aware of the extent of the problems created by the vendor, Standard was left to cover most of the shortfall in fees.

Acme had no internal IT support in the U.S. yet, and hired Standard Consulting to provide support services. In the support services contract, Standard did not distance itself from the vendor’s problems, so Standard was often responsible for resolving serious errors caused by the vendor.

When Acme hired a CFO for its U.S. operation, and he discovered the complexity of using and managing the new system, with its instability and complicated workarounds, he complained to Standard Consulting. However, given the buggy software and existing system functionality, not much could be done in the short term to make the software easier to use or more stable. After go-live, the vendor did develop some of the retail functionality and did fix many of the more serious bugs. However, Acme and its CFO were stuck with several clumsy workarounds.

Conclusions

Skipping the risk assessment was an error in judgement by the project manager. She wasn’t lazy, but was overly concerned about keeping the client protected from the reality of the project risks.

The project manager significantly underestimated the risks of implementing software that was being installed for the first time in a new country and a new industry. She also did not warn the client of the risk of buying undeveloped features or modules (also known as vapourware). Because she was too optimistic, the project manager didn’t ensure that the vendor’s promises about the new retail functionality were written into the contract. There was also no provision in the contract for recourse when the serious nature of the numerous bugs was discovered.

Another sizeable risk in this project was the lack of availability of experienced client staff to participate in the product selection and the implementation. An experienced user has the best insight into what the company’s needs are and what configuration and processes are suitable. Acme didn’t have anyone available to fill this role, thus creating significant risk of selecting a product that was a poor fit, or of implementing the product poorly.

Later, when developing the support agreement, the project manager did not separate the responsibilities of Standard Consulting from the responsibilities of the vendor, thereby creating unnecessary risk for Standard. This error also reduced risk for the vendor, and may have decreased the vendor’s incentive to fix problems.

Due to the project manager’s concern about making sure the client always felt comfortable, the client was never fully aware of the level of risk being assumed in the implementation of this product.

Optimism is not necessarily a good quality in a project manager. Setting the expectations of the client is a major responsibility of the project manager and is best achieved with a healthy dose of realism.

Copyright 2015 Debbie Gallagher

Crossing our fingers; that's our schedule

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

Two projects

Acme was starting a project to implement a new logistics application, and engaged Standard Consulting as their implementation partner. When the logistics project started, a new manufacturing system was already in progress, and was also expected to complete before the logistics project.

There were a lot of custom reports required for both manufacturing and logistics. Acme had identified a few hundred necessary reports, including fifty reports for logistics that were critical to go-live. The report development for the manufacturing module had not gone well: many reports were incomplete and some reports that were done were buggy. Acme decided to take more control of the reports development process by assigning an Acme employee as the reporting team lead.

The schedule for reporting

The Standard Consulting project manager asked the new reporting team lead for his schedule, but the reporting team lead had no intention of developing one, as it seemed a waste of time. The project manager asked, “How do you know you’ll be done the critical reports in time for go-live?” The report team lead replied, “We’ll cross our fingers and hope for the best. After all, we always come through in the end.”

The project manager continued to insist on a schedule. Finally, the project manager prevailed. She had the two most experienced report developers stop work on reports. These two developers were assigned to define the development tool to use for each report, as well as the estimated effort for coding, testing, and promotion to production environment. The project manager used this information to build a schedule.

The reporting lead started to realize there was a lot more to report development than just the coding. In addition, the schedule made it clear that the fifty critical reports for go-live could not possibly be completed in time.

However, the reporting lead was worried about looking bad, and didn’t want anyone to know about the possibility that the reports might not get finished. He asked the project manager to avoid discussing the report schedule issue at the status meeting. Despite the schedule, he hoped the reports would get done on time.

The project manager insisted that since the problem had been identified, it had to be raised as a project issue. The reporting lead finally agreed.

Getting some help

The project manager and the reporting lead met with the logistics team and explained the problem. The logistics team was upset about the reports at first, but then agreed to help solve the problem.

The logistics team agreed to prioritize their reports and, with discussion, it became clear that only two reports actually had to be run on the day of go-live. Several others were not needed until the end of the first week, others at the two-week mark, and most at month end. There were even some reports that were not needed until year-end, which was six months after go-live.

When the reports issue was raised at the project status meeting, the manufacturing team offered to prioritize their remaining reports to free up resources to work on the distribution reports. In addition, the Acme project director offered to provide some extra report writing staff.

The manufacturing and distribution modules both were live on time. In addition, the critical reports for both modules were available by the newly prioritized dates.

Conclusions

The reporting lead’s approach of crossing his fingers and hoping for the best was not realistic. Once he understood and made the other team members aware of the reporting delivery problems, everyone pitched in to help solve the problem. The logistics team prioritized their reports realistically, the manufacturing team delayed some of their reports to free up resources, and the project director provided additional help. None of this could have happened if the team lead kept his problem secret.

Even though the client was responsible for its own report development, the consulting firm project manager was right to insist on a proper schedule for the reports. The reports were needed for the implementation, for which the project manager was responsible. Without the schedule, no one had any idea of the extent of work involved, and it was impossible to predict success or failure.

Copyright 2015 Debbie Gallagher

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

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