Lessons Learned for Billing and CRM Implementations

In strict project management terms, a project is successful if it is done on time and within budget. In reality, the success of a project is not as scientific or quantifiable as most would think.

Success in a billing and CRM project relates to perceptions by its benefactors (usually business managers and end users) and any positive political changes that result from the project. This could mean, for example, that the project resulted in a satisfaction rate of over 80 percent among its users (even this expectation is a bit optimistic) and that the project's staff members feel a sense of contented accomplishment.

In addition, assuming quantifiable benefits warranted the project, success means that those benefits have been accomplished—such as increasing customer satisfaction or capturing a small market, and a positive ROI.

However, project success is rare, and several factors can cause failures. These range from flawed management and organization to mistakes in technology and finance.

Management Mistakes

Management mistakes are extremely common, but they can also be the most difficult to discern. For example, how many people are willing to admit that politics coupled with short-sighted fears and need for control is one of biggest reasons that projects fail? How many times are the wrong individuals given assignments they are incapable of handling? Or how many times do people avoid dealing with key individuals because they dislike them or just don't want them to succeed? How many times do people avoid pressing for solutions because they are afraid doing so will be political suicide?

The first lesson is that no project should ever depend on one person. No one knows that much, and no one should convince us of that. Unfortunately, dictatorial leadership is rampant in this industry. Leaders with large egos and a constant need to indiscriminately impose their vision on their organizations have made, are making and will continue to make more mistakes. Unwilling to listen or simply too microscopic in their views, these types of leaders pose the biggest threat to project success. Their employees (except for their cronies) hate them and do their best to get back at them in undetectable ways. If the team members do what they are told to do, but do not buy into it or relate to it, they end up doing only what is asked of them, and not an ounce more—even if they know it doesn't make sense.

For example, the leader of one project was one of the most enormous egomaniacs ever encountered. Any decision he made, people immediately jumped to execute. They gave him what he wanted knowing that its impact on other details would be detrimental. They executed, but in reality retaliated by supporting his shortsighted decisions, thus encouraging him to make mistakes. That was their motive. Suddenly the project did not matter to the employees anymore. In addition, this leader chose people who said 'yes' to him no matter what he said. A "no" was severely punished and ruined many careers. The project failed, he failed, and the people failed due to his ego. Ultimately the corporation wasted hundreds of million of dollars, and the project got rolled back.

Many of the leaders of those projects start out with preconceived ideas about how the world should work. They come in with favorite toys and gadget ideas and think the world would use them. Many find out later that these are too expensive or have a negative economic return. It is imperative that the chosen leader let the business define what is needed.

Bottom line: No matter how brilliant the leader, the team will always treat the leader based on how that person treats them. If the people on the project hate the leader, the project is doomed. It will bleed because the people are not motivated. (Note: The "people" referred to here are not the senior staff or directors; they are the first-level managers, senior programmers and analysts.)

Choosing the right leader is probably the most important decision. The right leader will be acutely aware of all shifting elements in the environment within and outside the project: how politics are conducted; the team's people and skills; how groups and subgroups are interacting; how money is spent; how vendors, contractors and employees are deployed; and most important, how the psychology of the project perception changes. In addition, the right leader must have the following attributes:

•The ability to inspire followers.

•Intelligence in knowing what is at stake and how to execute.

•A willingness to surround himself or herself with people who can respectably and positively challenge his or her decisions. Pick the best person for the job, not the person whose company you like most. Cut a deal with them to help you, and you help them.

•Self-confidence. An insecure leader will perceive everyone who contributes positively as a threat and will have constantly clouded judgment. In addition, team members will detect that lack of self confidence and harbor doubts about the leader's ability to drive the project. It is, however, very important to differentiate between self-confidence and arrogance. It is key that the leader be secure but show humility to accept that he or she can make mistakes and can use help.

•A good sense of how the psychology of people and the group reacts and evolves.

Organizational Mistakes

One of the critical success factors is having a politically clean organization to drive the project. This means an organization that is enabled and empowered, but respectful of the driving forces of the project. An organization has to be built such that it induces positive politics and cooperation. It must be built to avoid unhealthy inter-group competition, and no group should own 100 percent responsibility for any success or failure.

The other mistake commonly made by management is to preserve old organizations that have evolved over the years based on extraneous factors such as certain loyalties, previous successes, political debts or simply that they have become entrenched over time. This is not to say that the people or leaders in that organization are not capable of running the project, but rather that the flow and delineation of responsibility makes no sense any longer.

To understand how this problem arises, keep in mind that projects consist of certain key parts. These key parts can be defined as whole entities on their own, but together they complete the project. Some examples include data conversion, requirements management, testing and configuration. Although these elements are independent, they all are streams—also referred to as "swim-lanes"—in the critical path.

Traditionally, organizations are built to reflect these swim-lanes. This structure causes the organization to follow a serial set of events, and thus all inter-task or milestone dependencies become naturally inherited by the organization. Dependencies in the organization give birth to finger pointing and blaming, and hinder positive politics and cooperation.

One way of detecting these issues is to look at an organization and the critical path of the project. If they are similar in breakdown and names, then that should be an alert that the organization is only considering tasks, not people—which is what organizations consist of. The organization should be reexamined and re-wired to avoid too many linking dependencies across its parts.

The simplicity of a project is linked tightly to the number of dependencies it has—the more dependencies, the more complex. Thus, to simplify a project, we often try to find ways to create streams and tasks that have as few dependencies as possible. This approach will create more opportunities to do parallel work and ultimately reduce time. Likewise, an organization has a number of leaders, with sub-organizations behind them. When the organization is complex or too serial, it forces one part to constantly deal with or depend on other parts to finish a task. That increases friction and the chances of failure and unhealthy competition.

For example, development and testing groups always screamed at each other, because the testing schedule always seemed to get shorter and shorter. Each side felt the other was incompetent or lazy, thus hurting the schedule. By re-wiring the two organizations to rotate in people, the animosity was defused.

In practice this could mean that instead of having one release of software from the development organization that is then tested by the testing organization, one could rewire the two organizations by combining them and breaking them later into many sub-teams. Each sub-team can be responsible for one release. Each sub-team comprises both developers and testers, so the same sub-team must deliver the release to production with a certain quality that has to be realistically defined, and each individual's performance is tightly tied to that quality.

Another example involved how the user community dealt with the IT organization, which resembled the behavior of a dysfunctional family, with competition and finger pointing rampant. Finding a way for both organizations to team up and share responsibility can bring a fresh solution. It's not easy to achieve, but worth the fight, because it can bring success at a cheaper cost. The user community should understand and deal with what it takes to develop solutions for their requirements, and the IT organization should deal with the marketplace and the need of end users. The lesson here is that making both groups feel each other's pain can solve a lot of problems.

One additional lesson here is for the leader: Secure senior management support. Explain to senior managers how breaking boundaries between IT and the business side can help the project and ultimately the corporation. If senior management is supportive, it can make life a lot easier.

Respecting Data Conversion

When selecting a solution, always understand the cost of the data conversion. Do not assume data is cheap to convert—it is the one item that will cost more than forecasted. In almost every project undertaken in this industry, the cost of data conversion is underestimated. Check the data model of the new solution and how it differs from what already exists, and try to minimize the difference between the two. Having said that—and this is not an easy task—enlist the help of a good data architect.

The best of breed is not necessarily what is needed—that may be what you want, but not what you need. Being humble in understanding what is needed, and making sure that it fits exactly what you are looking for, can save a lot of pain and help avoid failure. Gadgets are expensive, require costly maintenance and more than likely will become impractical in the long run, adding more reasons to fail.

If you buy from a vendor, check its survivability. If it goes out of business, you will be in expensive trouble.

A technology fit study must be performed. It should examine the existing architecture and the impact of adding new hardware or software.

If you opt for a vendor package, make sure to know up front who will be performing the implementation, and carefully study your options. Choose one that will cause you the fewest headaches.

•Having the vendor implement the solution (if the vendor offers that option) may be the safer route to take from a technology perspective, but usually it is very expensive, and it is almost like the wolf watching the henhouse.

•Opting for a systems integrator (SI) may be good for creating neutral ground, but SIs come with their own problems. In this situation SIs will almost certainly compete with the vendor, and you'll have to manage that rivalry constantly.

•Deciding to complete the implementation in house may save a lot of money, but the staff will need intensive training, and it will be a steep learning curve.

The answer may lie in one of these options alone, or a smart and carefully crafted combination. Obtain as many independent views as possible, but beware of special biases or conflicts of interest.

Always test on converted data. Any other data is a waste of time, and many people will be trying to persuade you to use mocked data, because it is easier. Don't fall for that trap. Testing on converted data reveals a lot about how the software deals with the data in ways you would never guess. This can reveal ahead of time how the software and the data will behave in production. Testing on mocked data can help, but it is still not valid.

Always test old-side/new-side—old bill and new bill comparisons. Compare carefully a statistically prepared set of customers representing the different money-generating elements and their collective reports. This is not easy to perform but absolutely crucial to ensure that the financials won't inexplicably change.

Convert one database at a time. Do not dip into part of multiple databases, which creates too many issues when trying to manage both the legacy and new system. Move entire blocks such that the legacy of the selected part is decommissioned and you do not need to manage both.

Choose your pilot to cover the customer set that is the least complex (usually retail consumers), and choose a small entity representing that segment (a regional entity, for example). Do not select a complex customer such as a big business with a complex hierarchy. The volume of the customers is not important; what matters is how simple they are to convert. Simpler customers have simpler products and simpler billing calculations. Choosing the database with the simplest customer layout allows you to flush the system in the pilot to find out undetected basic errors. Once the system is clean at the core, you can add more complex customers so that you can concentrate on their issues alone.

Lastly, pick the right business manager for the pilot, who should be prepared for the pain of installing new systems and should work to help fix errors rationally. If you pick a manager difficult to work with for the pilot, rest assured that all other business managers will become difficult as well. If the perception is created that the first pilot was too difficult or encountering too many issues, the rest of the conversions will follow suit. Win small in the beginning, and build from there.

People Mistakes in Billing

In discussing people mistakes, remember two things: First, people make projects successful, and not the other way around. Second, billing projects are often characterized as "death marches." But how did these projects turn into death marches? By making and then repeating and ignoring mistakes. People mistakes are deadly, but unfortunately they are very hard to measure and detect, due to our colored view of each other. If we consider a task and choose an individual to perform it, we're logically choosing someone we think is the most capable of doing it. But because we are not always so sure what the task is on the inside, we are not able to choose the best individual to perform it.

Billing serves telecom, and telecom is a money-earning utility. Utilities are not very accommodating to down time. Operators collect their revenue from billing their customers, and thus they deal with real dollars, which is what stock analysts watch for. But mistakes in billing are common and cause the operator to either under-bill, thus losing hard earned money, or over-bill, causing customer complaints, a nightmare to manage in the marketplace, and churning of customers. Since billing is driven by money, you will need accountants.

Since technologists are not accountants (and perhaps even the antithesis of accountants), this requirement can pose a dilemma. This is not to say that you need to replace technologists with accountants, but complement technologists with accountants (or people with accountant-like profiles). Billing and customer care always go together, so you need the type of individual who well understands customer care and how it works with billing.

In short, you need four types of individuals: technologists, accountants, customer service specialists and strong analysts.

Mistakes on the people side stem from not having the right mix of individuals and choosing the wrong people for the job. For example, you are consolidating pricing plans and the requirements team is asked to do it, which is typical. Consolidating pricing plans is a simple task on the surface, but in reality it is very tricky. A common mistake occurs when only the recurring charge (the fixed monthly fee) of price plans is analyzed. The requirements team will likely look at two seemingly similar plans (almost the same monthly) and decide that they should be consolidated. It deletes one and replaces it with the other, and all the customers riding on the first plan are moved to the new one.

What this approach ignored is the usage element of the plan. Unlike the monthly fee, usage is not fixed and varies month to month and customer to customer, so many requirements teams decide to ignore it. In contrast, a team with an accounting mentality will probably have done a statistical study of usage for each price plan over an extended period (usually a year, using last year's billing and financial reports) and consolidated the price plans based on that study. But once the billing system is in production, it is very common to find that millions of dollars are being lost each month because the analysts did not have a rigorous, detailed mentality like that of an accountant, or simply because they didn't know how to perform a statistically sampled study.

To avoid the second most common mistake, once the right people are chosen, ensure that they don't become bored. Billing projects are long and exhaustive, and people need to be constantly reassured and motivated.

Lastly, do not try to make the new systems behave like the legacy system. This mistake is widespread, and it is one of the most annoying to project leaders.

Financial Mistakes

Lessons learned the hard way from financial mistakes are summarized in the following points:

Be aware that your new system will count pennies differently from your legacy. Your new system will round decimals differently. Collectively over a month of bill cycles this could mean a difference of hundreds of thousands of dollars.

Your system may require a new hierarchy of customers. If you had consolidated new data for bundling or other reasons, you will have new billing calculations that will invariably cause revenue aberrations.

Clean customer data will play an important role in the company's financial numbers. Data cleansing is over-discussed, but when it's related to money it can be detrimental to customer service and billing numbers. Do not wait until pre-production to start cleansing your data. If you do, you will miss your milestone. Rather, use your old-side/new-side testing to uncover those issues earlier and put a team on top of it.

As discussed before, if you have to perform pricing plan consolidations, you will most definitely have billing issues in production and different bill cycle reports, and ultimately monthly billing reports might show an increase but more likely a decrease.

Testing is important, but what to test is more important. Having a good understanding of the business, knowing when to cut your losses, and knowing which battles to fight and which to avoid is very helpful for smooth sailing. The testing team has to have people from customer care and billing operations, in addition to your requirements experts.

Testing ahead can reveal calculation variances; if they are accepted, customer care and billing ops and finance should be alerted. A letter is sometimes sent to alert the customer and avoid an increase in the number of calls to the data center. User acceptance testing is important, but many of the financial variations will not be caught without performing old-side/new-side testing on converted data.

Choose a strong financial team that will work with the requirements teams and conduct old-side/new-side testing (it is expensive, but it will be cheaper than what will occur in production). You do not want to read in the morning newspaper that you have been over-billing your customers.

Project Management Lessons Learned

Manage the business's and the users' expectations. You can never do enough, so do more and do not get bored doing it. Success is driven by the reality and the perception. Perception is reality, when it is all that people know. The user community will be working with a new system that will behave differently from what they are used to. Remember that we all resist change naturally. Manage expectations by having users experience the new system very often and early, and respond to their reactions. Explain (and over-explain) that things will be difficult in the first few months and that their support is needed. Sending the experts to the user field for the first month can help avoid many issues and foster a positive experience for the user.

Training is crucial, so train users more than once. Get them familiar with the system, and help them. If the users are not very well trained, they will issue many trouble tickets to the system, which will cause two problems: more work will be wasted on researching non-issues, and a negative perception will be created.

Manage to the critical path, and manage to it daily. Weekly meeting aren't enough. Manage issues in the same meeting with all the same people, so that everyone is responsible for addressing them in front of everyone else, and force people to work with each other. Do not allow people to issue any action items unless they are present and they issue them in the company of the people who need to address them.

Reward extraordinary teamwork by giving the good teams extra days off, an award or a gift, or even just mention them and thank them publicly. Let them know they did well.

Respect employees, but be straightforward. Do not be afraid to point out discrepancies in what people say. Keeping the management style professional and respectful will ensure that the project psychology is always upbeat and positive.

Include customer care staff in your communications. They will be your gateway for knowing how to deal with the system in production.

Lastly, support production management, if you are not responsible for managing production; if you can, manage it yourself for three months, or until all major issues have been resolved.

Raf Howery is an independent consultant. Raf's experience span many years and mutliple large billing, CRM and IT projects in the US, Europe, and the Middle East. Prior to Raf becoming an independent consultant, he was a vice president with Capgemini (Previoulsy Ernst & Young) responsible for billing and CRM and prior to that as a director at Verizon. You can contact Raf at raf_howery@yahoo.com