The changing role of the technology team in ERP implementations (part 2)

In a previous article, I described several areas where the role of the technology team in ERP implementations has changed in the last ten to twenty years.  Here is part 2.

Importance of data

ERP and other application implementers have historically considered focus on People, Process, and Technology as the foundation for success. In the last several years, it has become apparent that Data is a fourth and equally important element.

Data, including its definition, conversion, integration, and governance have become critical to the success of the implementation and the ongoing usability of the ERP system. Although the data is owned by the business, they generally require support from the technology team in supporting data governance and enforcement of data standards.

Downstream systems

Due to changes in master data or the business meaning of data when you implement a new ERP, combined with the integrations, you may have many changes to data in applications you connect to/from.

One of the causes will be data re-numbering. For example, if you change significant master data such as customer number, vendor number, or part number, you will likely have a business requirement to update existing data in other systems besides the ERP.

In addition, when implementing ERP, the business may take the opportunity to change the meaning of the data. For example, the existing ERP may have Acme Toronto, Acme Vancouver, and Acme Calgary all set up as separate vendors. In the new ERP, the business may choose to eliminate these three vendors and instead create a vendor called Acme Canada with three sites in Toronto, Vancouver, and Calgary. You can see that this would have an impact on the way that integrations to/from other applications are designed; and the potential for changes to existing data in those systems.

Data cleansing

Data often requires cleansing in order to accommodate a new ERP. In addition to correction of issues with existing data, the business may want to develop data for the ERP that exists only in spreadsheets today. The technology team is often called upon to support data assessment and may also need to provide tools and processes to support data creation and standardization. 

Workflow

Workflow can enforce controls and retain documentation of approvals, and is built into modern ERPs. In a cloud environment, the notification emails will be crossing multiple corporate firewalls. Similarly, if you are using your ERP host or another external party to provide integrated services such as invoice scanning, there will be technology-enabled processes crossing internal and external environments. Your technology team will need to be involved in the security design and implementation.

Customizations

If your existing ERP system is customized, you know what a challenge it is to keep up with upgrades, as modifications need to be re-established with each upgrade. With cloud ERP, it is easier to push back on the business when they want to customize, as cloud lends itself to adherence to the vendor’s standard offerings. However, where there is a real business need, you may need to develop the customization outside of the ERP, leading to another system and interface to manage, and the necessity of supporting business questions on differences between the two systems.

System cutover

Along with the transition of business functions to the new application and processes, there will be a number of technical steps involved as well. Cutover tasks may include turning off/on interfaces and scheduled jobs, and providing updated charts of accounts and other master data (e.g. customer numbers) to other systems and business partners. It is also common to prevent data updates in legacy applications by modifying user roles when the new ERP goes live.

Stay tuned

There is more to cover on the changing role of the technology team in ERP implementation. Watch for part 3.

Is it really all about schedule and budget?

When I read job postings for IT project managers, there is a heavy focus on being able to deliver on schedule and on budget. In addition, I sometimes hear rather lively discussions about the role of the project manager: are they/should they be accountable for anything at all beyond schedule and budget? I’ve also observed from my own project management experience that the first questions from the sponsor and from the steering committee are invariably “how much will it cost” and “when will it be done”? Again, the focus is on schedule and budget.

Why are schedule and budget the big focus of project managers and the executives for whom they deliver projects? Is that where all the big risks are?

The big risks

In my opinion, schedule and budget overruns are not the big risks themselves. They are the outcome of other risks that have materialized into issues. So, what are the biggest project risks that drive schedule and budget problems?

In a previous article Identifying and Managing Project Risk by Tom Kendrick (book summary), I summarized Tom Kendrick’s book, in which he outlines his findings from examining hundreds of technical projects. In the book, all the risks that occurred were translated to a timeline impact so they could be compared. I think it’s a fair assumption that when the timeline is extended, the cost also grows. So, what are the risks that have the greatest impact? From Kendrick’s book, two risk areas with the greatest impact are: (a) non-mandatory scope changes; and (b) legitimate, but not anticipated, requirements gaps.

In other words, the big risks are related to scope and requirements. There are plenty of other risks, but let’s start with these two. When these risk events occur, there is an impact on the schedule and budget.

Managing scope and requirements

There are several ways to focus on scope and requirements.

First, these need to be defined as clearly as possible at the outset.  Too often there is a rush to get the project started, and it begins with inadequate descriptions of scope and requirements. This rush to delivery and related skimping on scope and requirements can lead to disastrously large impacts on schedule and budget.

Sometimes there is a good reason to have uncertainty at the start of the project.  In that case, identify the lack of clarity as a project risk. Then, make sure that everyone on the project and on the steering committee knows about that risk. Also be sure to include a re-assessment point in the schedule and funds in the budget to address the cost of potential changes.

Next, focus on requirements and scope during the project.  At the outset, meet with the project team(s) to review these in detail and address any questions. It is crucial that the team knows what is to be delivered.

Make sure there is a change control process and that it is followed.

Review and follow up on the project issues frequently. Issues are often the result of disagreement regarding what is in scope or what is needed. Too often, issues are logged in a database and neglected.

During the project there should be checkpoints to verify that the project team is on track. Hold walkthrough meetings with team members, and also with stakeholders outside the team. While often seen as time consuming, these walkthroughs are critical tools to ensuring the delivered product supports the requirements and scope of work.

An effective way to determine during the project if there are issues with scope and requirements is to ask team members informal questions about what they are working on, whether they are clear enough on what they need to do, and what problems they are having.  The project manager needs to make herself available when there are questions from the team regarding scope and requirements, and not put them off while heads-down adding up budget hours or updating Gantt charts.

Testing is another method of ensuring that the delivered product meets requirements and scope. Evaluate test plans to determine if they engage the right people and cover the right tests to identify gaps in scope and requirements. Ideally, gaps should be identified before testing, but even if found during testing, at least they are dealt with before go-live.

Conclusion

When hiring and evaluating project managers, the heavy focus on schedule and budget overlooks the relationship between schedule and budget, and project risks.  It’s usually the project risk events occurring that cause the budget and schedule problems.  Managing the schedule and budget is really about managing the project risks. In this article, I picked two top risks and discussed common techniques to manage them.

I’ll leave you with a couple of thoughts. First, I think the question about whether the project manager is responsible for anything besides schedule and budget has a definitive answer. Project Management Institute says yes, as the knowledge areas cover a lot more than schedule and budget.  Quite apart from PMI’s body of knowledge, the answer has to be yes, because if you aren’t managing the project risks, it isn’t possible to manage the schedule and budget.

My second parting thought: If the project comes in on time and on budget, but does not deliver the expected scope or meet requirements, what was really achieved?

Copyright 2015 Debbie Gallagher

Identifying and managing project risk by Tom Kendrick (book summary)

In reading Tom Kendrick’s book, Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project (2^nd edition, 2009), I found it a compelling read and thought I’d share my views.

The premise of Kendrick’s book is that the experiences from previous projects, specifically the historical data of project problems and their impacts can help us in identifying risk and managing those risks on our own projects.

PERIL database

Over a period of more than ten years, Kendrick collected data on project problems from hundreds of project managers. He assembled this data in his Project Experience Risk Information Library (PERIL) database. The database provides information on what types of things go wrong on projects, and attributes each to root causes. In addition, the database captures estimates of the impact of the problems that occurred. The PERIL data is mainly based on projects having a dependence on new or relatively new technology; includes mostly projects that had a planned duration between six and twelve months; and twenty or fewer project team members. 

Kendrick analyzed over six hundred projects, and has come up with an interesting approach to allow comparison. For each project, whatever the actual impact of the project issues, he has converted the impact to a time impact.  For example, if scope was reduced to meet the scheduled completion date, the timeline impact has been determined by calculating how late the project would have been if it had delivered its original scope. Kendrick’s approach may not stand up to rigorous scientific scrutiny (and he is open about the bias in the data), but in my opinion, it still provides a very useful way to compare project risks. From these risks come clear risk management strategies. 

Kendrick’s findings

Kendrick’s first analysis is high level and compares the total timeline impact in the PERIL database for eight root causes.  These include, for example, scope changes during the project, failure to meet deliverable requirements, schedule delays, internal staffing.

In later chapters, Kendrick then breaks down the categories of risk/impact into sub-categories. For example, the impact of scope changes during the project is broken down into non-mandatory scope changes, legitimate requirements gaps, and so on.

In the chapters covering sub-categories, the descriptions of issues from the project managers are included along with the frequency and impact figures. For example, end user not involved enough in requirements, supplier not meeting deadlines, system architect not available. In reading these issues from other project managers, some triggered project flashbacks!

The Panama Canal

Throughout the book Kendrick weaves stories of the Panama Canal building projects. The first project, which ran from 1879 to 1889, was a failure. Ten years after the start of the project, it was cancelled, thousands of workers were dead, the costs had spiraled out of control, and there was no canal. A failure indeed!

The second Panama Canal project started in 1902, started re-planning in 1905, and the canal opened in 1914. This project finished under budget and ahead of schedule, and was useable for its intended purpose. Although workers also died on the second project, the death and disease rates were dramatically reduced due to improved insect control, housing and other practices implemented on the project.

Although Kendrick placed the Panama Canal segments to tie each to a specific risk or approach being discussed in the book, for me they were very interesting, not just as project management solutions, but also as an interesting historical sidebar.

Lessons from the book

Although Kendrick makes project management recommendations regarding each sub-category, he does not make recommendations about which are the most critical practices for project managers to adopt overall. He leaves this to the discretion of each project manager, to be determined based on their own specific projects and environments.

In examining the breakdowns in the book, each project manager can determine what the biggest-impact problems are likely to be, either in general or on their own project, and then decide what to do about them. Every reader will likely take something different from the book depending on whether they are looking for general guidance or for insights for their own project.

An example

For purposes of this article, I decided to look at the data from the perspective of “If I wanted to improve my project risk management in just one area, where should I focus to address the project risks that occur most frequently and have the greatest impact?” So, I started by looking for the category that has the greatest number of issues and the greatest impact.  As described above, the greatest impact is from scope changes that occur during the project.  It is also the issue that occurs with the greatest frequency.

Then, within the scope change category, the two sub-categories that have the greatest frequency and impact are non-mandatory changes and legitimate requirements gaps.

My conclusion is that to improve my project risk management practices, I should start by improving scope management. By looking at the sub-categories, I see that the ways to improve scope management the most are: (a) eliminate the non-mandatory changes; and (b) reduce legitimate requirements gaps by either spending more time on requirements or by making a provision in the schedule right from the outset.

Summary

If I was looking at the data before starting a new project, I would be looking to see what might apply to my own project.

The value in Kendrick’s book is the analysis of many technical projects and the comparability of the various causes of problems.  This comparability allows each project manager to assess for themselves what recommendations can be quickly implemented for the highest improvement in their projects. 

The Panama Canal highlights provide interesting examples of the differences in project management techniques and capabilities.

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

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

Friendly fire

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

Background

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

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

What version to implement?

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

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

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

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

Back to requirements

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

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

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

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

Friendly fire

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

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

Implementation

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

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

Conclusion

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

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

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

Copyright 2015 Debbie Gallagher 

What's happening in Yorktown?

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

Background

Acme Corporation determined that updating their existing system to accommodate upcoming tax changes would be nearly as much work as implementing a new system. Because the new system also provided many other advantages, Acme decided to proceed with the new one.

The project was run in two locations: Since most of the sales functions were done in Yorktown, that location was to implement the Sales, Distribution, and Accounts Receivable modules.  The Smithville location, where procurement, manufacturing, and accounting were located, would implement the rest of the system. 

A project director, in charge of the entire project, was located in Smithville. In addition to her overall project responsibilities, she would run the Smithville part of the project.  A project manager was hired to run the Yorktown portion of the project.

The project needed to be done in six months to ensure adherence to the new tax rules.

Yorktown off the rails

In Smithville, the usual number and types of issues surfaced, but in general the work went well and the project was on track.

Each week, the project director had a phone call with the Yorktown project manager to review progress on that part of the project. The Yorktown project manager always sounded confident, and reported that everything was going well in Yorktown, with no significant issues impeding progress.

The project director was very surprised to receive a phone call from the Sales VP in Yorktown after about two months. The VP was very agitated, as she had expected to be attending design meetings to review preliminary set up by this time. However, the VP had not been able to obtain any information from the Yorktown project manager about when the work might be ready for her review.

Rescuing Yorktown

The project director went immediately to Yorktown to investigate. He discovered that there wasn't nearly as work much done as expected.

The project director had a serious problem; the system now had to be ready within four months instead of the planned six months, and there was almost no salvageable work completed.

He fired the Yorktown project manager, and replaced several of the contractors. Then he met with the VP and other key users. He outlined a plan to go-live by the time the tax changes had to be implemented. The key was to determine what functions were critical for the first day of operation of the new system. The users indicated that sales order entry, the logistics methods for their three largest customers, two major billing functions, and cash entry were critical and had to be done for go-live. The rest of the functions were ranked according to when they had to be used for the first time.

Go-live

On the date the new tax law was in effect, the new system was live. Everything in Smithville was running. In Yorktown, the key go-live must-have items worked. There were no management reports, and no other non-key functions.

The remaining items were delivered over the next several weeks according to the ranking done by the users.

The users were relieved. They had been so worried that they would have no system available to run their business and fulfill the requirements of the new tax law.

Conclusion

Once the project director discovered the project was behind schedule, he quickly analyzed the problem and took steps to make sure the main elements of the project finished on time. The deadline could not be moved, due to the impending tax changes. Adding more resources would have been extremely difficult; he already had to get new consultants up to speed. So, the clear choice was to reduce the scope of the project to meet the deadline.

Unfortunately, it took too long for the project manager to find out that the Yorktown project was behind schedule and staffed with poor quality consultants.

The second location for implementation development should have been identified as a risk to the project. Then, the first step in risk mitigation should have been careful selection of the Yorktown project manager and the consultants. It would have been wise of the project director to spend more time on selection and maybe more money on more experienced resources.

The next risk mitigation strategy ought to have involved the development of the approach for Yorktown. It should have included small early deliverables, with appropriate business review and approval. This approach would have allowed the project director to assess the timeliness and quality of the work very early.

During the project, more rigorous reporting practices would have provided the project director a good view of progress. For example, the project director could have insisted that the assistant update the project schedule each week, showing progress on each task, and explaining any discrepancies.

The project director did solve the problem and the must-have components of the project were completed on time. However, earlier recognition of the risk and implementation of mitigation strategies may have allowed the entire project to be delivered on time, with less worry for the users in Yorktown.  

Copyright 2015 Debbie Gallagher 

It's going to cost how much?

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

Background

The Acme Corporation is a large North American retail company, with thousands of stores across the continent. The procurement function was centralized, with purchases made and paid at the head office.

The process for stores to make a requisition was extremely outdated, relying on phone calls, emails, and faxes to make requests and with no insight into the process once it was initiated. Acme decide to replace their procurement system with a web-based system that allowed on-line requisitioning, and the ability for store staff to see at any time the status of their requisitions.

How much money?

During the planning stage, the project manager had the project technical lead do an assessment of what infrastructure was needed to support the new system. When the technical lead assessed the network between the stores and head office, she determined that the new application would run too slowly.

The project manager talked to the Network Services department and discovered that the group had no budget to upgrade the network. They told the project manager that if his project needed the upgrade, it would have to come out of the procurement project budget, at a cost of over $100 million.

The estimated cost of the procurement project was $2 million, so this additional cost would be the end of the project. It wouldn’t be possible to make a business case for the procurement project if the cost was increased fifty fold.

Action taken

The project manager asked the technical lead to do some further analysis, which determined that with the current network, the response time for users would be more than two minutes, which was definitely unacceptable. Without the network upgrade, the project was not viable.

In addition, the project manager asked the Network Services group for a review of the cost estimate, and the Network Services group responded that the cost estimate was accurate.

The project manager was not satisfied, and asked Network Services for another re-work of the cost estimate, with more details, so that it could be included in a report to the project steering committee. This time, the Network Services group found a large calculation error, and revised the cost estimate to $8 million. Although a dramatic reduction, this could still not be accommodated in the budget for the project.

The project manager advised the steering committee that the project was not viable without the network upgrade, but that the cost of the upgrade could not be accommodated in the project budget.

The steering committee realized there was never going to be a single project that could absorb the network upgrade cost and still produce a return on the investment. In addition, the steering committee also felt that the speed of the network would be a recurring theme, as demand for faster processes and instant access to information increased.

The steering committee recommended to Acme management that the network upgrade be approved as a separate project, and Acme management agreed.

Epilogue

The store managers were pleased with the new procurement functions and the timeliness of the information available to them. In addition, store managers who ran multiple stores could see the additional stores more easily than before.

Conclusions

Discovery of the slow network demonstrates the project manager’s thoroughness in the planning stage, taking into account factors other than the application functions themselves. His disciplined approach was also in evidence when he requested additional backup, ensuring his estimates were correct, before reporting to the steering committee.

The steering committee comprised several Acme executives, which was valuable in getting the attention of Acme management when they needed to remove the financial obstacle to upgrading the network.

Copyright 2015 Debbie Gallagher

Management's indecision

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

Background

Until now, the Acme Corporation had published product and customer-support information on its web site. The new project would expand the web site’s capabilities by allowing customers to purchase from the web site.

The schedule was the driving force in planning the project, as Acme wanted to capitalize on the crucial Christmas shopping period. The project manager identified finalization of the technical decisions as a critical milestone in the project. The IT Director would need to evaluate and determine the technical direction timely. The project manager made sure the project steering committee was aware of this significant dependency.

The situation

At the project steering committee meeting where the technical direction was supposed to be presented by the IT Director, he instead covered several discussion items. He reviewed his key considerations such as fit with strategic direction, impact on the existing web site environment, stability, and pricing. However, he had not made a decision.

The project manager made her concerns clear; the lack of decision would have an impact on the project schedule.

The IT Director was dismissive of the project manager’s concerns; surely it was better to wait a bit to get a better decision. The steering committee did not pressure the IT Director to finalize the decision.  

Delay continues

The IT Director continued to delay. The project manager followed up regularly with the IT Director, and moved as much work as possible forward. However, with no environment in which to begin programming, there really was very little that could be done.

The decision is made

Once the IT Director finally made the technical decisions, the project manager could see that the work was already a month behind schedule.

The project manager discussed her concerns about the timeline with the project steering committee. It was clear that the deadline could not be moved, as the retail web site was intended to attract customers during the Christmas shopping season.

The only options were to reduce the scope of the project, or to add resources. The project steering committee members were adamant that that neither was possible. The budget did not permit additional resources, and the entire scope of the project was thought to be completely necessary to its success. The team would just have to manage to get the job done.

Epilogue

The project manager and the team did make a valiant effort to get the job done. The programming and testing team members worked very long hours. However, time did run short, and some scope did have to get cut in order to finish on time.

Although the web site was up and running in time for the Christmas shopping season, it did not perform well under some conditions. The project team was completely exhausted.

Conclusion

The IT Director’s and the project steering committee’s lack of concern for the timeliness of the technical decisions was unreasonable. When the technical decisions were finally made, the project steering committee’s refusal to make a decision regarding resources or scope was also unreasonable.

Both the IT Director and the project steering committee did not recognize that the damage to the project was their own responsibility.  Instead, they claimed credit for the project completing on time and on budget.

Copyright 2015 Debbie Gallagher 

It's bigger than you think

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

Background

A government agency decided to implement a new set of systems that would provide services to all communities in the state. The project required significant participation from staff of the state government, a telephone company, several systems vendors, and a systems integration vendor.

The government engaged Acme Consulting to manage this large complex project.

Acme’s project manager met with the project sponsor from the government agency several times and established the project scope, responsibilities, schedule, and resources needed.

Acme’s project manager brought on a junior project manager and a coordinator to work with him.  These three were to spend eighteen months implementing the new systems and processes, then at go-live, two Acme consultants were to take over and support the new systems for ten years.

The situation

Within two weeks, the junior project manager began to realize that the scope of the project was too vague. There were several sizeable elements of the project where the government agency and Acme Consulting each thought the other was responsible for the task.

The junior project manager discussed this issue with the project manager, who replied that it was too late to be wondering who should be doing what, and told the junior project manager to focus on getting the work done, instead of questioning the work.

With every week that went by, the junior project manager became more worried about the vagueness and confusion related to who was responsible for what. It was clear that Acme Consulting did not have enough staff assigned to the job to do everything the government was expecting. Further comments to the project manager were futile.

About eight weeks into the project, the junior project manager attended a conference to learn how others had implemented similar services. He realized that the gaps in project scope and responsibility were much worse than he had feared. Many of the vaguely described project elements were significant jobs, requiring weeks or months of effort.

Escalation

The junior project manager documented his concerns in writing to the project manager. When the project manager continued to ignore this information and push the junior project manager to ‘just do it’, the junior project manager talked to an Acme VP about his concerns.

By now, the project was nearly three months along. The VP was very worried when she heard about the junior project manager’s concerns, and began to investigate. At the same time, the project manager finally began to realize that the project had been poorly defined and understaffed.

Recommendation to client

The project manager began to speak more openly to the government sponsor about the problems of project scope and responsibility. The sponsor was quick to grasp the problems and to realize that he too had misunderstood the effort involved in developing and implementing the new services.

With the consent of the sponsor, Acme Consulting began to re-define the project scope and work plan in more detail. This process took the entire fourth month of the project.

At the end of the month of scoping and planning, it was clear that more detailed planning would be required to ensure completeness and clarity. However, there was enough information to determine that the project would take at least three years to complete, and would require eight more staff.

Epilogue

The government wanted Acme Consulting to provide the eight additional staff, but did not have a way to adjust the total project budget. It was decided to reduce the amount of support time for the ten post-implementation years, and apply that money to the implementation phase instead.

The government sponsor and the Acme Consulting VP were unhappy with the project manager who had originally made the deal, and who was slow to recognize the shortcomings in the scoping and responsibility assignments for the project. The project manager was replaced.

Conclusion

There are two things the project manager should have done differently on this project.

First, on a project this large and complex, the amount of effort put into planning and scoping was completely inadequate. Instead of several meetings to determine the project scope and resources, the project manager should have recommended to the government that the planning and scoping be a separate, predecessor project. Resource planning and therefore pricing could not reasonably be done without two or three months of effort.

Second, when the project started, and the extent of the gaps between the government’s and Acme’s understanding started to show, the project manager should have discussed the problem with the VP and the client immediately. Since the project manager had made the agreement that was so inadequate, he was probably reluctant to own up to the error.

The junior project manager, although less experienced, was quick to realize that the project was bigger than they thought. The advice given to him, to ‘just do it’, was not the right advice. The junior project manager was correct to escalate his concerns to the VP.

Copyright 2015 Debbie Gallagher