On the other hand, they are highly oblivious to some of the concerns of the team. Some of their solutions are difficult to implement and requires tremendous amount of effort and manpower. For example, there was a request for them to configure the system such that the Retail and Sales group can capture an important data required for a unified messaging service. The data was to be collated and then send to Marketing group for evaluation. Instead of coding the program such that the data is sent automatically to the Marketing group, the Retail staff has to manually send it via email. This result in information not send on time as the staff tasked to do it has forgotten. When feed backed, the IS development group aggress that it can be done but they insist that the staff should send manually. It was only after much persuasion and getting the Retail Group’s director to personally endorse it that IS development did the changes. Such issues are common and it boils down to the fact that they do not understand concerns and the working environment of the other groups. This waste a lot of time, frustrate the team and leaves a bad taste in both the IS group and Retail and Sales group.
The 4 phases of building a system are:
- Initialization
The need to have a new system or to make changes to a current system as to tackle a problem or situation. Will generally need to decide on who are involved, how the system should work
- Development
The process of taking the requirements from the initialization phase and put in into a working system. Will typically require software programming, hardware purchase. These will usually round up with UAT (user acceptance test) to make sure that the system works as per the functional requirements.
- Implementation
Putting the developed system into its intended working live environment. May require the old system that it is replacing to run in parallel to make sure there is reduncy in case the new system fails.
- Operation and maintenance
The constant monitoring of the system to make sure that it is in a healthy state and is running as per intended. Will involve handling of hardware failures and at time software patches to improve its performance or to rectify any bugs that were not filter out during UAT.
The 4 phases can be explained is the scenario that I faced in my organization.
There is a need to have a unified messaging replacement system and being a part of Product Development group, I was tasked to do it. The initialization for this project was realized because the current system running the unified messaging is nearing EOL (End of Life) for support and hardware. Now of course, it is not justifiable to have just a similar system to replace the old one. The bosses wouldn’t agree on that and we wanted to leverage with this opportunity to improve some features. We got in our marketing folks who had conducted surveys etc and got those inputs and put them into functional requirements for the new system. We defined the new ideas, how the system is going to work and called for a tender with several participants. A review of their proposal was done with factors like cost, do they fit our requirements into consideration and a vendor was then chosen.
Development of the system came next. We broke it down into several phases. As the developers were external party, I had to monitor their progress thoroughly. Many times they ran into problems that weren’t foreseen in the initialization phase and we had to go back to a drawing board to come up with alternative solutions. We had to compromise here and there but generally, we kept to our milestones and all necessary changes were communicated to the relevant stakeholders and we got their consent. The hardware was set up and the software was loaded into the system and the vendors did their test before cutting the project over to me for UAT (User Acceptance Test). This process was the toughest as my team had to filter out the bugs and there were patches done to the system. Finally, after several round of testing, we are convinced that the system was ready to be put into a live environment.
Implementation of the system was a challenge. We had to migrate existing customer information over to the new system. We could not just shut off the old system, and transfer the information over due to service mandates by the local Telecommunication Authority. Thus both systems had to be kept running in parallel and subscribers are given means to access the old system via a key stroke in the TUI (Telephone User Interface). Prior preparation was done and the subscribers of the affected service were informed. Although the cutover was successful, we kept both systems as we need to monitor the stability of the system.
Operation and Maintenance was taken care by the Operations team. Basically, they monitor the system to make sure it is stable, inform me when the storage is insufficient to support the growing number of subscribers so that I can purchase storage extensions and the required licenses. Regular patches had to be applied to the system to keep it updated especially the anti virus software and firewalls and whenever we discovered bugs that wasn’t filtered out by the UAT test in development.
The challenges were encountered in the scenario explained in part 1 of the question. Since the project was implemented in phases we can also categorize the challenges as per in the four phases.
During the initialization phase, we asked ourselves like how do I improve the competitiveness of the service? How can I make my service stand out? We got our marketing group to pool ideas and improvise them into our system. We had new features that make full use of existing internet facilities that are readily available. Are they sufficient in giving us the edge? We had 7 racks for the old system and we want to reduce it thus the hardware has to be small to save ground area and to be portable. What are major trends in technology that can help us achieve this? What protocol should we use? SIP to give us better interoperability and connectivity? These are all critical decisions we make.
In development, we had to maximize our infrastructure and context. How can we make full use of the LAN facilities that is in place in our Exchanges? Do we really need a 2nd layer LAN for the system? If we do, what are the cost and benefits? In short, how we can cut costs by not having unmanaged redundancy? We had to response to the common system related risks too. Is the system able to take the peak to peak load? Do we have sufficient E1s to handle the amount of voice traffic calls? What happens if there is a fire? Do we have backups?
Implementation - We had to involve many people. It is a critical part of the service cutover. We had to extend our human skills. We had to make sure our subscribers will not be bogged down by the new interface. We had to train our Customer Service Officers so that they can be equipped to handle the queries. We had representatives from the Customer Service group involved from the start of the project. We want them to be motivated to implement the new system. They have their concerns and we want to take care of those too.
In operation and maintenance, we want to be able to make full use of available information. Logs of daily traffic pattern were taken. We made use of this information for a variety of situation. We knew that traffic was high at a certain time of the day. Thus all patching or flushing of the system was arranged to make sure that it is at off peak hours. We knew what features are being embraced. Those that had little users went back to the drawing board with questions like – why aren’t they using that feature? Is it difficult to use? Is it not useful at all? Necessary changes were done to make the service more viable and to be a step ahead of our competitors.
In an overview, the challenges apply to many areas and there is no real time solution to them. Plugging in a solution will only help you out to certain extend. They are more of questions that we have to constantly evaluate. They have to be revisited again and again in order to make sure that the business remains competitive.
One framework that is commonly used in my company is a financial framework that we term as Business Case framework. As part of the product development team in my company, we always conceive up new ideas for products and services. After a conceptual service is defined, we will use the business case framework to breakdown the crucial components that will have a impact on whether the business is viable. We have to look at the cash flow – do we have sufficient cash for this investment? Return of interest – would we be better off if we have put the money into a bank? The payback period – when will profit come in? CAPAX (fixed assets) – what is the cost of fixed assets required for this? OPEX (operating expenses) – what are the operating expenses from all the departments? Revenue and loss – will we make a loss if we do not meet our target take up? All products/services must be analyzed and evaluated with the help of this framework before the product/service can be launched. As shown below, all these factors have a impact on whether the business is viable.
Another common framework that I’ve encountered is a functional requirement framework. Whenever we were to launch a service after the business case, we will use this framework to gather requirements and concerns from the various groups. This framework allows us to view the service as a total package. We will have a discussion on the concerns of all affected groups. For example, how is retail going to sell the service? What training is required for Customer Service group so that they can handle the complaints or queries that will come? For network planning, what kind of network is required to drive the service? What are the efforts needed by the IS group? Finally, are they able to agree on the final functional requirements? The costs for these have already been forecasted by the business case framework and this framework calls for a detail analysis of the functional requirements by the various department.
Working in the Product Development group, we have to constantly come up with new products and services. However, not all of them can be commercially successful. I dread working on a business case as it will involve a lot of financial analysis and finance is definitely not my forte. However, I do have to agree that the Business Case framework does help to align myself from a very business perspective. This is exactly what is required when building an IS. (As a Telco, most of the organization’s services will require some form of IS support) As an executive in Product Development group, it is inevitable that when we have a new and exciting idea, we would want it to be launched. The mindset there and then is that the service will take off and it will have an impact on the market and roll in the profits. However, the Business Case framework helps us to align ourselves back into the position of the organization as a whole unit.
A practical example here is that I had worked out an idea that will encompass mobile with data features. Not quite GPRS but something more high speed. It was initially much appreciated and the organization was quite excited about it as we can use it as a gradual transfer to 3G mobile services in future. However, what we had missed out was that if we were to launch the service, it will cause cannibalization of one of the service from a sister organization. We didn’t want to take something out of our right pocket and put it into the left pocket. As such, the Business Case framework helped us to realize the situation and we avoided a lose-lose situation with the sister organization.
On the other hand, I didn’t quite agree to the stance of the organization in making the functional requirement framework compulsory. What happens here is that some of the group tends to abuse the framework. The very nature of this framework is for us to gather all the necessary and required information thus as to conceive the functional requirements and the required internal processes to support the service.
However, at times, some of the groups tend to give very unreasonable requirements that are not technically possible. For example, Marketing group wanted a 3G video call to drop automatically down to a 2G environment if the receiving party is terminated to a 2G voicemail system. We were not technically capable of that at that time but the Marketing group just wouldn’t listen and would not sign off the functional specs. We explained to them that it wasn’t technically possible at that point of time but to no avail. We had to get our technical director to step in order to get the project rolling.
Such cases though few still impacts us as projects are sometime delayed because of such a scenario.
The eight elements can be seen as per in the diagram attached below.
Customers are the ones who use the service. Ultimately, they are the ones who determine if the Business is actually successful. In this scenario, they are the students who will register for class.
Products and services is what the Business Process does to produce. They are the services that are sought by the customer and directly impact the way the customer feels about the organization. Actual placement in a class is the service required by the students. Information on the class are also services sought by the students.
Business Process is the driving force of the services provided here.