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

Head in the sand

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

The data conversion

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

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

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

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

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

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

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

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

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

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

The project manager starts to worry

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

Conclusion

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

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

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

Copyright 2015 Debbie Gallagher

The 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

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

We're not concerned about the budget

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

Estimates are wrong

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

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

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

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

Behind schedule, over budget

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

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

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

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

Payments stop

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

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

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

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

Conclusion

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

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

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

Copyright 2015 Debbie Gallagher

Friendly fire

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

Background

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

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

What version to implement?

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

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

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

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

Back to requirements

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

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

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

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

Friendly fire

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

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

Implementation

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

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

Conclusion

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

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

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

Copyright 2015 Debbie Gallagher 

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