Barriers in implementing quality systems such as ITIL, COBIT, and ISO 27001

About me

Level: Intermediate

Prerequisite: Basic understanding of some industry standards such as ISO 27001, ITIL and COBIT

To implement a successful quality system such as ITIL, COBIT and ISO 27001; there are more than just technologies. For the companies implementing those quality systems, the following barriers I have observed are the things we have to deal with:

>they don’t really understand what they can benefit from that. In other words, it’s difficult to get their buy-in. We need to educate them and give them success stories as well as concrete benefits.

>normally, it’s costly to implement the quality systems, especially for large companies with existing heavy and not well-documented processes. Without sufficient fund, it’s almost impossible to implement an appropriate quality system and as already mentioned above, companies want to see tangible benefits. Otherwise, they feel they are being charged for something that doesn’t have a clear target.

>as for managerial view, they sometimes cannot get transparency from their auditors or certification bodies. They don’t really know what are happening. The reason might be the process is so complex and the auditors are not explaining themselves clearly. Besides that, it can be the case in which the management skill of the auditors are not strong enough so managers are kept outside and they don’t know what is happening actually except for some general status reports. Management skills are also mentioned here simply because implementing any quality systems is also a project.

>now there are diverse quality systems on the market, and all are saying they are the best. That can make companies confused. They need consultation that can assist them in understanding and taking appropriate actions.

>for quality standards to become really helpful, auditors should understand the business of the companies they are working for. It means they should have a very close relationship with the companies which is not easy at all. Sometimes it can take months to really understand the whole process and time is critical for companies.

>lack of management’s support, implementing a standard is a project in itself and it is believed that to make a project successful, there must be adequate support in terms of resources and political forces from the managers.

>lack of training, education and communication

Any technologies, any quality systems are built to support people. Without people, they cannot give any positive results. However, quality systems are sometimes complex and it’s recommended to teach the users so they know why they have to do that and how to do that. The reason is that they don’t have the same level of capabilities and background.

>the indicators are not set clearly. After or during implementing the quality systems, business executives want to see the progress. Hence, this is a required skill for auditors to balance between technology and business to create views that can be understandable for different people in the business. Once again, we have to remember the background of the people we have to submit reports to so we have to transform technical things to monetary information.

>moreover, it can be the case in which the auditors hired are not helpful. Put it another way, they don’t have enough knowledge or they just have only the understandings for some standards but not the general view that can guide the company in selecting which standards are suitable for them. After that, they should show companies the way to implement the quality systems based on the existing infrastructure of the companies. To do this, once again, they need to understand the companies and map the current infrastructure against the standards to analyse the gaps and to see what needs to be improved.

>sometimes after implementing the quality systems, they don’t feel they are getting something that is of value to them. The reasons can be 1) they didn’t have enough knowledge in choosing which systems are right for them 2) it takes time to have something new become really beneficial and tangible because the gains from these quality systems are sometimes intangible such as efficiency and staff/customers’ satisfaction. Furthermore, everything needs improvement. It means they need to keep doing it and keep improving it continually so that it can show its value. 3) lack of information due to lack of appropriate goals and indicators set out when companies decided to build the quality systems. Sometimes, the lack of information can lead to misinterpretation of the results of building the quality systems.

>misled intention: some companies are running after these standards because they want to have good reputation not because of the quality or benefits. Hence, after getting the certifications of these standards, everything gets back to normal and no continual improvement will be performed probably. To make this really happen, the companies need to put in more commitment, especially from the managers.

A comparison of the business and technical drivers for ISO 27001, ISO 27002, COBIT and ITIL

About me
Level: Intermediate
Prerequisite: Basic Understanding of ISO 27001, ISO 27002, COBIT and ITIL

Firstly, ISO 27001 is a security standard but COBIT and ITIL are frameworks with best practices. ISO 27001 are often used in conjunction with ISO 27002 because ISO 27001 include only requirements for what needs to be done and ISO 27002 introduces the guideline for doing that.

According to the diagram, COBIT covers more domains than ISO 27001 and ITIL but with little guidance. However, ITIL is easier to do with more checklists and procedures. Besides that, ISO 27001 is a standard so it’s deeper in the domains. Specifically, COBIT has 4 processes and 34 domains, ITIL has 9 processes and ISO 27001 has 10 domains.

Generally speaking, COBIT for measuring and assessing IT controls, ITIL to improve internal IT services, and ISO 27001 for IT governance.

The function of COBIT is to map IT processes to business objectives. ITIL is to address service management. ISO 27001 is to get companies compliant to international standards regarding various aspects of security management such as establishment, implementations and improvement of information security management systems.

COBIT is to maximize the benefits derived through the use of IT with appropriate governance and control by providing managers, auditors with a set of acceptable measures, indicators.

COBIT can provide a systematic approach to identify root causes of deficiencies.

COBIT is business-oriented. COBIT is usually chosen by companies who are performing audit to give their manager an in-depth view of their infrastructure’s efficiency.

ISO 27001 is a standard but ISO 27002 is best practices and it’s really a guideline regarding how to implement ISO 27001. In each domain in ISO 27001, there are specific requirements that companies need to fulfill in order to be compliant but there’s no specific guideline or technical requirements such as which infrastructure must be built, how to build. That’s why ISO 27001 and ISO 27002 often go together.

ITIL is quite similar to COBIT but ITIL is more IT service-based and COBIT is more process-based. In other words, the unit for measuring in ITIL is service but process in COBIT.

According to the website SecurityProcedure, the end result of implementing COBIT is information system audit, for ITIL is manage service level and for ISO 27001 is the compliance to security standard.

From the implementation view, ITIL is probably the easiest one to be implemented because it is best practices with checklists and guidelines. Besides that, ITIL can be implemented partially according to the website SecurityProcedure. Hence, a company can decide to implement one layer first such as IT service delivery layer, IT release management; then it can implement the others in the next year. However, for ISO 27001 and COBIT, it’s unfeasible because they take into account a broad view of the whole system first, and then go to implementation phase. As for ISO 27001, it is a standard related to 3 aspects of a company: people, process and technology; so it requires a deep understanding of the company’s profile. However, the final choice is still up to companies. It actually depends on their budgets and their goals.

ITIL has a more robust certification system for IT professionals. However, there are some criticisms regarding the price of the books. They are not affordable for non-commercial users. In other words, it seems to be too proprietary. For COBIT, it’s not a standard and companies cannot say COBIT compliant. However, ISO 27001 is an information security management system standard and can be compliant to.

Moreover, from a technical view, companies get compliant to ISO 27001 to avoid ad hoc in information security management; to establish, implement and improve continually the system. For COBIT, it’s to map IT goals to business goals and vice versa, to create clear ownership of processes with clear performance indicators. And ITIL is to improve IT services.

Bibliography

COBIT Introduction

http://www.vpit.ualberta.ca/frameworks/ppt/cobit_introduction.ppt

Comparison between COBIT, ITIL and ISO 27001 http://beefchunk.com/documentation/security-management/comparison_between_COBIT_ITIL_and_ISO_27001.pdf

CobiT / ISO 20000 / ITIL / ISO 27001                       

http://www.derkeiler.com/Mailing-Lists/securityfocus/security-basics/2008-02/msg00487.html

The Business Advantages of ITIL

http://www.cutter.com/content/risk/fulltext/updates/2007/ermu0706.html

Using iso27001 to your advantage

http://www.ctg.com/infosecurity/pdf/using_iso27001_to_your_advantage.pdf

Communication in Requirement Acquisition of Software Development

About me

INTRODUCTION

The software industry is one of the fastest growing industries around the world today and there has been much research carried out in order to cope with the complications resulting from the abstract nature of software. Increasingly, the term 'Software Development Lifecycle' (SDL) is becoming very popular in the computing world. According to Maciaszek and Liong (2005, p.5), SDL refers to the alterations that occur in the life of the software. It consists of five main phases. They are requirements analysis, system design, implementation, integration and maintenance (Maciaszek & Liong 2005, p.5). Each phase has its own complexity and discipline. However, it is commonly believed that the first phase, requirements analysis, is extremely critical to the development of a project because it provides input to the subsequent phases.

Sommerville (2007, p.118) defines the word 'requirements' as the description of the system-provided services and its operational constraints. From that, he identifies that requirements analysis encompasses the activities of eliciting, analyzing, documenting and validating the services and constraints. The first activity is more user-oriented but the others are more skill-oriented. It means that communicating with users is dominant in the elicitation activity and the other activities mainly focus on the skills of software developers (SDs).

There have been a great number of engineering books written and much research carried out on the methodologies for SDs to improve their technical skills. In contrast, there is only a small amount of research on the methods to improve SD's communication skills. Generally, it might be believed that the success and failure of a certain project is the responsibility of the Software Company. Yet, to a certain extent, it is also the responsibility of the customers who order the software. The reasons are that SDs cannot presume what the customers need and they cannot develop a complete system without knowing the customers' expectations. Hence, the communication between customers and SDs is very important. However, this factor is often ignored and left for SDs to deal with. Therefore, it is worth considering this aspect in SDL. The scope of this paper does not allow for discussing regarding the techniques to elicit users' requirements. Rather, this research will focus on addressing the following questions:

1. What are the common problems that lead to a low level of SD's communication skills?
2. What are the possible solutions for those problems?

With the combination in comprehending the common problems and the possible solutions, a better skill in dealing with the customer in order to deeply understand the software requirements can be achieved.

LITERATURE REVIEW

There is a very strong connection between requirements elicitation and communication. Sommerville and Sawyer (1997, p.63) state that the process of using communication with software-involved users such as customers to identify requirements for software is referred as 'requirements elicitation'. Therefore, communication seems to play a very important role in the whole process of SDL. According to Sommerville and Sawyer (1997, p.2), most of the problems that can lead to the decline or failure of a system are associated with identifying software requirements. They also suggest some of the common problems: (1) the real needs of the customers are sometimes ignored, (2) the inconsistency and incompleteness of requirements can occur, (3) changes to requirements would be very expensive after they have been agreed and (4) misunderstandings between customers and SD can happen. It is likely that all the problems mentioned above are caused by the lack of communication or communication breakdown. In some cases, the impacts of the problems can be so significant that the whole project might collapse. Hence, it is almost certain that finding solutions for those problems is of importance.

Communication can improve the quality of software. Strano, Mohan and McGregor (1989, p.6) define communication as 'the sharing of information, ideas or attitudes between or among people' and it is obvious that the software requirements are the 'information, ideas or attitudes' that SD must obtain from the customers. Hence, if SDs can communicate effectively, the objectives for the software being developed can be fulfilled. In addition, Christensen and Thayer (2001, p.406) claim that 'Communication is the key to keeping the project moving in the right direction'. In other words, effective communication is the most important factor that can ensure the success of a project. The reason for this could be that it ensures the clarification of what is expected by the customers.

SD's PROBLEMS IN COMMUNICATION

In discussing 'Overcoming Communication Barriers Between People', Hahn (2005) suggests the common barriers in communication are different points of view, background differences, poor listening, distorting filters, language problems and differing emotional states. However, the suggestions for the communication barriers (CBs) are mentioned in normal daily circumstances. It is advantageous to study to what extend the barriers can influence the development of a software. In addition, at the time this paper is conducted, there might be no books or research that addresses these suggestions in the software industry so the following ideas related to these CBs will be presented from a personal view.

First, differences in viewpoints can be detrimental to software development and this problem is becoming more serious as the trend of outsourcing continues to flourish. Customers would have different perceptions if they come from different cultures. Hence, SDs should take this into account; otherwise software cannot be implemented properly. Furthermore the background differences between SDs and customers also attribute to the difficulties in communication. For instance, a stock trading company can demand stock software that requires SDs to have certain levels of relevant knowledge in order to develop it. When SDs are trying to interview the user from the company, they can misunderstand what the user require because the language they use is different from the language of the user. Moreover poor listening can result in CBs. It might be known that SDs usually pride themselves on their high technical knowledge and this is really an impediment to any conversations between SDs and normal users. As can be seen, this factor can lead to the SD's presumption of the user's expectation. However, the fact that SDs might not have enough knowledge will cause many misconceptions in developing the software. Another CB is twisting filters. This barrier might be created when indirect communications occur. For example, when the information from customers is reported by secretaries to the project manager, the differences in viewpoints or the insufficiency in the understanding of the software being developed of the secretaries can distort the information regardless of their efforts to present it correctly. Besides the CBs mentioned above, it is also important to consider the problem of using language. Given the same word, different regions can have different meanings, especially for those who do not speak the same language. It would raise serious misunderstandings between SDs and their customers. Finally, the effectiveness of communication can be affected by emotional states. Strano, Mohan and McGregor (1989, p.10) state that provoking unfriendliness in the other participants of a conversation can be the cause of distorting messages. Another example is dealing with upset people. They tend to ignore or distort what the other person is expressing and is usually unable to present feelings and ideas properly. It does not mean that all of the communication should be abandoned when the emotional state of the customers or SDs is not appropriate but it does mean SDs have to be aware of what is behind the conversation between them and the customers.

SOLUTIONS

Right People

Selecting right people is very crucial to the success of any communication. The reason could be the credibility of each participant. For example, when developing stock software, obtaining the software requirements from a user with more than ten years of work experience is more reliable than from a user with no work experience. The degree and the specific factors attributed to the required credibility vary depending on the software being developed. Because the aim of this paper is not to improve the technical skills of SDs, the methods to identify right people will not be addressed. However, there are many books written to address this aspect; for instance, Thayer and Dorfman (1990, p.489) suggest a list of criteria for selecting right people depending on the context and the functions of the software. In discussing how to improve the quality of software, Barkley and Saylor (2001, p.276) mention if the sender is not credible, regardless of the information, communication will be ineffective. It is likely that the users chosen to obtain the software requirements have a significant impact on the communication. Because of their credibility, the SDs would feel encouraged to absorb more information. Hence, this solution seems to be able to resolve all the indicated problems.

Listening and Empathizing

Listening is critical in eliciting the user's requirements. However, it might be the least developed skill for SDs. The reason could be the high esteem of SDs. The real expectations of the user can be ignored if the SDs assume that they know all the concepts of the software. The fact that SDs assume that they know all the concepts of the software can lead to the ignorance of the real expectations from the user. Barkley and Saylor (2001, p.277) suggest the requirements of effective listening can be letting others convey their ideas without interrupting and empathizing with their point of view. The second requirement 'empathizing' could also be a solution to the differences in background between SDs and normal customers because it helps SDs try their best to understand customers' viewpoints from different perspectives.

Two-way mode for sharing knowledge

As indicated, one of the common problems in communication is the barriers in language and background of SDs and the customer. It seems, therefore, reasonable to encourage SDs to have two-way communication with the customer. In other words, the process of finding requirements  is not only asking the customer for information but also a real conversation where SDs and the customer exchange their knowledge in order to have a common understanding of the software. In discussing 'Communication on Agile Software Projects', Ambler also agrees on the idea to have 'two-way street' for sharing information to have effective communication. Hence, this way of sharing knowledge is not a new idea but it might be often misconceived by SDs that finding the user's requirements is only asking questions to the user. In addition, this method can also be a solution to the differences in viewpoints because it assists SDs in finding the gaps in understanding between them and the user, especially when the differences in cultures can become an issue in communicating.

Constant review

Misunderstandings always occur no matter how SDs try to overcome. It is applied to not only software development but also normal daily conversations. With regard to this fact, constantly reviewing and clarifying what has been communicated appear to be one of the best solutions to improve the process of eliciting the user's requirements. By identifying the discrepancies between the SD's understanding and the user's expectation, it seems to be able to solve all the common problems discussed above. Kishore and Naik (2001, p.114) cite in the Walkthrough method, one of the review methods, SDs 'walk' the user through the software's prototype and explain each requirement. From the explanation, it appears to be possible for both SDs and the user to discover any differences in the expected system. Kishore and Naik (2001, p.114) also encourage SDs to review the requirements obtained from the user constantly.

CONCLUSION

Communication plays an important role in software development, especially in the requirements elicitation phase. Indeed, the improvement in communication skills can assist SDs in understanding the system requirements from the user. However, due to the barriers discussed in this paper, it is a difficult mission to be accomplished. There are four possible solutions for those barriers. They are selecting right people, listening and empathizing, sharing knowledge in a two-way mode and constant review. The implementation of these solutions can lead to the improvement of the communication between SDs and the customer, thereby improving the quality of the software being developed.

FURTHER RESEARCH

Communication comes in many different forms. It includes verbal and nonverbal forms such as speaking, writing, reading, listening and body language. Because of this complexity, it is very difficult to cover all the possible solutions to improve communication in this paper. Further research can investigate into the solutions for the situations in which misconceptions have happened. In other words, it is important to find a way that can assist SDs in preventing further misconceptions to recur.

REFERENCES

Ambler, SW 2009, Communication on Agile Software Projects, viewed 15 December 2009, <http://www.agilemodeling.com/essays/communication.htm#EffectiveCommunication>

Barkley, BT and Saylor, JH 2001,Customer-Driven Project Management: Building Quality into Project Processes, McGraw-Hill, USA.

Christensen, MJ & Thayer, RH 1947, The Project Manager's Guide to Software Engineering's Best Practices, Angela Burgess, USA.

Hahn, M 2005, Overcoming Communication Barriers Between People, viewed 15 December 2009, <http://ezinearticles.com/?Overcoming-Communication-Barriers-Between-People&id=119628>.

Kishore, S & Naik, R 2001, Software requirements and estimation, Tata McGraw-Hill, New Delhi.

Maciaszek, LA & Liong, BL 2005, PRACTICAL SOFTWARE ENGINEERING : A Case Study Approach, PEARSON Education, US.

Sommerville, I 2007, Software Engineering, 8^th edn, Addison – Wesley, USA.

Sommerville, I and Sawyer, P 1997, Requirements Engineering: A good practice guide, John Wiley & Sons Ltd, England.

Strano, Z, Mohan T & McGregor, H 1989, Communicating, Harcourt Brace Jovanovich Group, Australia.

Thayer, RH & Dorfman, M 1990, System and software requirements engineering, IEEE Computer Society.

About me

My name is Bang. I was born in 1986 in Ho Chi Minh city, a southeast city of Viet Nam.

I spent four years at Le Quy Don high school. It was a great experience for me to study there with all of my great friends and the knowledge I gained. I finished high school in 2004.

After that, I continued to study in International University in Vietnam for four years. During that time, I found a great part time job that I kept working afterward. I got a Bachelor of Science in Information Technology in 2008.

After graduated from university, I went to work as a software engineer for 2 years at the company in which I had my internship before, called Gold Point Company. Started as a developer, I soon became a team leader. I studied lots of new things there not just technical stuff but also managerial skills. Dealing with many challenges that gave me a great amount of experience, I recognized that I could do more than what I had done. Consequently, I determined to quit the job and started my new university life in Australia.

I am persuing a Master degree at Macquarie University in Information Technology. I am quite an ambitious man. I always try to create new opportunities even when facing with difficulties. Working with my best, I hope to have a chance to work in some very professional companies around the world such as IBM and Sun.