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

Put money aside for more lumber!

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

Starting with lessons learned

The City of Yorktown was starting a project to replace its financial and human resources systems. The city had a history of technology projects that were completed late and over budget, and the sponsor for this project was determined that this project would be different. He and the project manager decided to start with lessons learned.

The project manager spent time researching what other cities had done and what had worked well. As a result of this research, there were some things she decided were important to Yorktown’s project: (a) all departments would be involved in and committed to the preparation of the business case; (b) the structure of the contracts with the various vendors involved would ensure one vendor was responsible for managing all of the vendors; (c) the vendors would be treated as business partners; and (d) the budget would have plenty of contingencies.

Implementing the lessons

Before choosing a software package and vendors, the business case and requirements were prepared. In every department at Yorktown, the department heads signed off on the cost savings and other benefits expected from the new system, including agreement that specific budget cuts would be made to the department once the system was implemented. The cost savings and budget cuts would be made over a five-year period as staff retired, since there were to be no layoffs.

The Request for Proposal (RFP) was issued with a requirement that the vendors bid together as a team, and that the system integrator take responsibility for managing the other vendors. The proposal was to include software and hardware recommendations.

After the applications and vendors were selected, the business benefits were re-worked, taking into account the specific package that had been chosen and its particular capabilities. Again, each Yorktown department head signed off on the business benefits, including the planned budget reductions. At the same time, the costs were refined, based on current information about the package, the infrastructure and the implementation fees.

The contracts with the vendors were negotiated and included some important elements: (a) the system integrator was to have responsibility for managing the software and hardware vendors; and (b) the vendors were asked to put up some extra contingency dollars. The additional dollars were not laid out in the contract itself but were negotiated at the same time and were to be managed outside of the contract.

The project manager knew that each vendor would already have included some unallocated budget in their own bids, in order to ensure they were not going to lose money on this fixed-fee price. She too had a miscellaneous category in her own project budget. However, she also wanted all parties to provide additional assurance by sharing costs for situations on the project where the responsibility for picking up the extra costs could not be clearly defined. She felt this would prevent cost overruns and also lead to the city and vendors acting as partners instead of each protecting their own budget.

The shared contingency dollars were to be spent on a case-by-case basis when agreed by all parties during the project. The total of the shared miscellaneous budget was approximately one percent of the project budget

Using the shared contingency dollars

The implementation was to take seven months. Almost immediately, Yorktown and the vendors used nearly a quarter of the shared reserve of funds, as additional hardware needs were identified during the set up of the infrastructure.

During the rest of the project, several smaller items were agreed to be paid out of the shared reserve fund. Most of the remainder of the reserve was used for additional processors, storage, and database licensing.

In each case, when an issue arose that would cost more money, Yorktown and the vendors would, as expected, try to negotiate so that another party would pay for the new item. However, when it became apparent that some items could not be agreed upon, the parties agreed to pay out of the shared reserve.

The outcome

The project completed on time and on budget, and is expected to deliver the planned business benefits. Yorktown and the vendors did maintain a collegial relationship during the entire implementation.

Conclusions

The time the project manager spent on planning and research was time well spent. The project manager learned a lot from her discussions with other cities. She focused on making sure the key success factors were in place and that potential points of failure were mitigated.

She ensured commitment from the business users by involving them in defining the system requirements and having them take responsibility for budget reductions related to implementation of the new systems.

The contracts were structured so that one vendor could manage the others, reducing the conflict that can arise when no one vendor is responsible for the outcome.

The shared reserve was an innovative concept that allowed the project manager to honour her commitment to the sponsor and city council to complete the project without going over budget. Just as important, because the reserve was shared by Yorktown and the vendors, there was more of an implied partnership between the parties. They had a means to resolve budget issues that might otherwise cause each to dig in their heels to protect their own budget.

According to the project manager, who built in an extra contingency, when each party already had a contingency, the old expression should be “Measure Twice, Cut Once – And Have Money Handy For More Lumber!”

Copyright 2015 Debbie Gallagher

The penny pincher

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

Losing staff and saving money

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

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

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

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

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

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

Go-live

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

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

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

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

Conclusions

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

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

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

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

Copyright 2015 Debbie Gallagher

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

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