Comment 1: No Giving Up, No Gain

By Wang Quangeng

This is a typical case of IT project management. What the IT company and its client encountered in the case is quite common in the real world. Both sides are responsible for the failure, and the reasons for the failure could be easily identified in the case. Therefore, the discussion of the case will generate practical as well as theoretical value. .

THE ROOT CAUSE: UNREASONABLE AMBITION
The desire of grabbing everything lays the potential danger for the project.

Nowadays the software market is full of ups and downs, mergers and splits. Everyone in software companies, from the management to the sales people, is preoccupied by things such as how to meet the sales target, how to increase the market share and how to quickly enhance P/E ratio, which are all No. 1 priorities in the task list. For a company with such a mindset, any clients, any orders, and any customer requirements will be accepted. Of course there are also companies that only sell products while ignoring all customer requirements. In this case, Yida already had a mature product ? AHZ fee-calculation software, but in order to tap into the overseas market, to gain a higher international reputation and to promote the share price in NASDAQ, it decided to take the order from Kaye without sufficient knowledge of the overseas market or necessary preparation of technologies and skills. The core function of Yida's product is account-management and fee-calculation, yet fearing that it might lose the deal, Yida eventually agreed to produce an OA system. And in the final stage, what Kaye required of Yida was almost an ERP system.

The client Kaye was no better. Hence, some companies take the initiative of installing or updating their IT system to expand the company scale rapidly, reorganise the company's business, and solve the problems from the past. However, there are others who do it merely for the sake of "keeping up with the Jones. "Look at them! They have got ERP. Do something, or we are bound to lag behind. As a result, a company may ask all its departments to install a new software system at the same time, expecting to settle the issue once for all. In the case of Kaye, it began with the need of a fee-calculation software and later required more functions such as tracking the internal workflow, generating feedback, managing internal operations and providing support to relevant functional departments. What Kaye wanted was in fact an OA system. When all these functions were realised, Kaye further demanded that the workflow should be accomplished in a single interface to follow its employees' previous operation habit. After these problems were solved, the issue about the business interface between different departments was raised. Even when main questions raised by Kaye were successfully addressed, it still went on to make more requirements in more specific aspects. For example, Kaye wanted the new system to be able to provide more powerful supportive function to the marketing department. What they asked for in this stage was functions of ERP software.

It was because both Yida and Kaye desired to grab everything that the new system was stuck in the endless construction, modification and reconstruction. Thus this new system lost the chance of being applied to real operations. The project was thus trapped in a never-ending circle of revision.

THE FATAL MISTAKE: INADEQUATE PREPARATION
The initial preparation determines the fate of a project by 80%.

During the initial preparation, and even before signing the contract, one has to make sure that the work is done properly in the following aspects.

Communication
The two sides need to have effective communication. The software company should listen carefully to the customer and learn about its overall and specific needs. And at the same time, it has to help the customer fully understand the functions and the supportive capacities of the product. Through sufficient communication, both sides could then reach initial consensus on the project implementation strategy. And then based on the communication with the client and its own rich practical experiences, the software company will be able to customise an implementation strategy with detailed procedures for its client. Nevertheless, Yida failed to do all these. It didn't have a genuine understanding of what Kaye really wanted until the later stage of the project. And in the same way, Kaye had no idea whatsoever of the specific functions of AHZ software; not until after the project was launched, did it realise that AHZ could not meet its needs.

Clear positioning and good planning
Both sides need them. The IT company must ask itself the following questions: Who are my targeted customers? Who are my competitors? What are the comparative advantages of my product? What kind of customer needs could my product satisfy? The client company should make a business plan with a well-defined corporate strategy, a smooth internal workflow and a clear perception of the way in which its IT strategy supports its business strategy. Yida's positioning was obviously very ambiguous, given the fact that it originally focused on fee-calculation system, but then switched to OA system, and even tried ERP. Similarly, Kaye had little idea of what it really needed; its internal workflow was chaotic; and it had no defined rules to clarify the responsibility division among different departments. No wonder Kaye changed the requirements of the IT functions again and again, and had no well-articulated IT strategy at all. This situation determined that the project would have a small chance of surviving.

Good preparations
Are both sides ready to launch the project? Has the IT company made proper preparation in personnel, technologies and skills, capital, and project management when they decide to expand business scale, explore new business, or start a new project? Has the client company clearly understood its business needs before a new project is launched? Has the top management reached an agreement on the project? Are there strong leadership and dedicated team members? Are there any opponents? These questions all need to be answered beforehand. Yida went to the global market without sufficient knowledge of overseas market rules or personnel with qualified skills for overseas business, for example, the language ability to communicate in English. How could it possibly make progress in the project? Kaye's situation was not promising either: it did not understand its own business needs; there was not enough support from the top management; the project leader Masaku was a powerless leader incapable of organising and controlling his people; Zhou Yuan was not cooperative at all; the whole project team of Kaye was not committed from the very beginning; different departments quarreled about the business interface definition and responsibility division. With such a project team and business operation, the project is doomed for failure!

Risk management
What risks might emerge in the project? How could these risks be effectively controlled? Every project involves risks, though the scales might vary. Before launching the project, the IT company should foresee the risks and set up a risk alert system offering timely solutions to different degrees of risks. The client company also needs to predict the risks of a new project, for example, if the old system has been deserted whereas the new system fails to be set up, all previous efforts are made in vain. Installing a new IT system is like carrying out a radical reform. Hence, a comprehensive analysis has to be made beforehand on all the stakeholders, and an overall risk management strategy has to be produced. Both Yida and Kaye were over-optimistic before the project started. Neither of them took troubles to analyse and predict possible risks. For Yida, its project development process hid potential risks, for instance, some points in the SOW were not specifically defined. The way of calculating the income based on the percentage of the project completed was another potential trap. For Kaye, both Zhou Yuan and Masaku were risk factors, and so were the ambiguous business needs and poorly-defined department responsibility.

GIVING UP: MORE GAINS
The difficulty in making a strategy is not deciding on what to gain, but rather on what to give up. One needs to know what to do and what not to do, because the resources are limited. That's where the strategy comes in. Only when one learns to give up, could he eventually gain what he wants.

An IT company should not do everything. Rather, it should choose carefully what to do. Firstly, the company needs to segment the market to identify the target customers. Even with these target customers, instead of serving all of them, it has to choose some and give up the rest. When the company singles out the right customers, it is halfway to success. Secondly, with the products, the company has to find a focus, have a clear positioning, develop its comparative advantages against its competitors and work intensively on its core products rather than try extensively. Lastly, when exploring the new market and products, the company should adopt an approach of gradual progress, starting with easy jobs and steadily developing the capacity to deal with more tough tasks. It is not advisable to over-stretch the frontline. Kaye was in fact a potential client of OA system, so Yida should give it up and go on to look for more suitable customers so as to promote the mature product of AHZ more quickly. Even if Yida desired to enter a new market, it still needed to produce a business strategy to decide what to focus on and what to give up.

As for the client company, its IT construction should be undertook in the same manner. First and foremost, it needs to make an overall corporate business plan; then it could identify some key areas to make breakthrough. Take Kaye for example, it could formulate an initial plan to restructure diverse business functions and then according to the current business priorities, it might choose the one that mostly needed a new IT system. For instance, AHZ could be installed to first realise fee-calculation functions, which were not supported by the original system AS400 and had to be done manually. When the new system was proved effective in this function, then other modules could be adopted. Secondly, there should be a long-term plan for the company's business development. Then the company may follow it up with specific objectives for different stages and make efforts to meet each target. For Kaye, a better approach was to produce an anticipative plan for the business growth of the following three years, then to set specific goals for different phases and eventually to accomplish all of them step by step. Finally, the application of IT system has to be done gradually and steadily so that the real value of the system could be fulfilled. Kaye could begin with simpler module and take further steps after the previous one was settled. It was unwise to come up with new requirements constantly and always change the existing system. A key to successful application of an IT system is to use it in the real operations. Otherwise its value could never be achieved.

The author is CEIBS EMBA04 participant, now working as VP of Metersbonwe.