Errors

Evolution in software industry has lead to evolution in many different industries, what was achievable only by mechanical machines, could be achieved now by software program and this increased the importance of software industry. However, there is no software without bugs or coding errors, those errors could be minor and fixed easily, others could threaten human lives, or result in failure of software products.

During our disaster recovery site building we have purchased a software to automate failover of windows based servers to the alternative site, as well the software was supposed to do an automated failback process of the previously failed over services to the main site. The software was sold to us on this basis, and the company’s sales team along with technical personal confirmed those features to be part of the solution design. Vendor produced the initial project plan and committed to complete the project within two weeks, at that time we had a believe that our setup is too complex to be complete in two weeks, and we have informed the vendor with our concern, but they confirmed to us that the same setup was done by them multiple times. After achieving partial failover of our servers and services, we wanted to test the failback procedure but we couldn’t. The software had an error that prevented partial failover, for the software to work properly we have to failover all our services and then fail them back again all together. Now we are stuck in the middle, we cannot failover services to the alternative site as this will impact services availability, and at the same time we cannot failback to main site because the software doesn’t support partial failback. Apparently the cause of the error was limitation in design to support multiple failover scenarios, and the problem was not identified earlier because testing partial failover was not performed or designed for by the vendor. In our case, this error jeopardized our operations could have resulted in data loss if reverse replication took place before understating the error consequences.

Software errors could result in manageable or unmanageable consequences; quality assurance and testing are two major processes should be conducted by introducing new software to avoid late discovery of errors, and minimize the impact of errors.

Reference:

Luguo, C, Xiaobo, W, & Chau, L 2011, 'An Approach to Improving Bug Assignment with Bug Tossing Graphs and Bug Similarities', Journal Of Software (1796217X), 6, 3, pp. 421-427, Computers & Applied Sciences Complete, EBSCOhost, viewed 23 June 2012.

Zaineb, G, & Manarvi, I 2011, 'IDENTIFICATION AND ANALYSIS OF CAUSES FOR SOFTWARE BUG REJECTION WITH THEIR IMPACT OVER TESTING EFFICIENCY', International Journal Of Software Engineering & Applications, 2, 4, pp. 71-82, Computers & Applied Sciences Complete, EBSCOhost, viewed 23 June 2012

Reducing Risk

One of the most valuable assets to a company its information and electronic data, this data contains monetary figures, customer information, inventory updates, accounts payable and account receivables, in addition to plenty of critical data that its loss could lead to catastrophic consequences. In certain industries regulations are held to force companies to protect their and their customer’s data for certain number of years, as well minimal unplanned outage is targeted. There are general guide lines companies need to follow to reduce the risk of data loss, and minimize its impact on the company’s operations.

Top management should not consider data protection as part of the IT strategy only, whilst as a company’s business continuity plan to protect the organization rather than the IT department itself. Companies should consider protecting electronic information by the introduction of high availability design within the same datacenter as well as within multiple locations, in addition to that backup and restore of electronic data should be designed to ensure full electronic data backup and test restores periodically. A good practice would be by having an alternative copy of backup tapes at different location, and perhaps different locale. One more good practice would be by building alternative site, where all business critical and business important services and data be available incase of natural or unnatural disaster hit the main site. As a best practice, the alternative site should be in a different building, city or country. Instead companies could go for hosted services to host their data and services with less startup cost, as well high availability and resilience guaranteed. My company has to build and test its business continuity plan to be compliant with Central bank regulations, business continuity plan covered all departments to ensure normal operations incase of disaster, we rented a new location far from the head office and equipped it with necessary furniture, computers, and communication lines. Based on the Business Impact analysis conducted by business continuity and risk department we defined the RTO, RPO and RCO. From this point, IT department started working on multiple projects to satisfy business requirements, we focused on upgrading communication lines in main site to accept the additional traffic, as well we rented a new location from the service provider to host our servers and storage at that site to be our disaster recovery site, the site was pre equipped with necessary power and cooling. One of the projects we have raised was automation of failover and failback procedures, we have purchased to new solutions to help us achieve this objective as well reduce recovery time to meet business requirements. Our daily backup media is transferred to the disaster location on daily basis, and we conduct restore tests quarterly. One last process we initiated was the transfer of backup tapes to a different country on monthly basis to avoid risk of natural and unnatural disasters in Qatar. After we tested the efficiency of our setup, we are planning now to have a second alternative site in a different country.

Risk of data loss is a nightmare for business owners, senior management and IT management. Loss of customer information has devastating impact on company reputation, and existence. Senior management should take ownership and invest to ensure that company’s electronic data is well protected against expected and unexpected disasters.

Reference:

Forbes, G, & Steven, B n.d., 'A framework for business continuity management', International Journal Of Information Management, 26, pp. 128-141, ScienceDirect, EBSCOhost, viewed 23 June 2012

Wainwright, V 2007, 'Business continuity by design. Don't let a disaster impair your facility's performance', Health Management Technology, 28, 3, pp. 20-21, MEDLINE with Full Text, EBSCOhost, viewed 23 June 2012

Staffing

Human resources in an organization are the pillars to its success; they are required to maintain its operations and to participate in new projects. Projects could require recruiting new resources with certain skills, certain abilities and expertise. Project success rely heavily on the quality of project resources, and management are usually facing difficulties with employee turnover, maintain employee motivation, managing team workload, maintain and build in-house knowledge and more. Below I will list and discuss key management issues in IT-project staffing.

· Employee turnover: this is one of the key issues IT organizations and IT departments are suffering from. High employee turnover could downgrade employee productivity, as well increase costs incurred by organization for recruiting new employees, and maintain project performance. It has great impact on project deadlines, budget and scope.

· Manage employee motivation and workloads: demotivated project team produce less that motivated project team, and one of the key challenges management face is keeping high motivation during project timeframe. Management should consider intrinsic and extrinsic motivation techniques to maintain project team motivation. In addition to that, employee workload should be managed, as high workload could result in decrease in motivation and project performance.

· Organization growth: introduction of new projects, and future project team responsibilities should be communicated ahead of time. In my organization we are facing an issue with a new project that resulted in cancelling all vacations for the coming year for all employees. This is a major project and the management believe that vacations assemble a high risk on the project, however if this was communicated properly including project team responsibilities, I believe this could have been avoided either by training employees to replace their colleagues during leave, or any other way.

· Keeping staff knowledge and skills: IT industry is training intensive, IT staff require to keep their knowledge up to date with new technologies. For that IT management should ensure that project team has the required knowledge and conducted in the proper trainings to support the project. Each project might require separate training budget for technical and non-technical team members.

· Knowledge transfer: Since most IT projects require hiring outsourced consultants, management should consider knowledge transfer and handing over sufficient documentation to help internal staff maintain the environment in non project mode.

Identifying and handling above-mentioned key issues help management reduce staffing risks and impact on project success, successful implementation of IT project rely mainly on human resources capabilities, knowledge and motivation. Human resources should be maintained, and satisfied to enhance probability of project success. Identifying listed issues help management in planning and developing projects more wisely.

Reference:

Ahilton, B, Márcio de O., B, & Cláudia M.L., W n.d., 'Staffing a software project: A constraint satisfaction and optimization-based approach', Computers And Operations Research, 35, Part Special Issue: Search-based Software Engineering, pp. 3073-3089, ScienceDirect, EBSCOhost, viewed 16 June 2012.

Huidan, L 2011, 'PROJECT MANAGEMENT AND ENGINEERING ISSUES', Annals Of The University Dunarea De Jos Of Galati: Fascicle XIV, Mechanical Engineering, 1, pp. 57-60, Academic Search Complete, EBSCOhost, viewed 16 June 2012.

Project Change

Change management is one of the key components and knowledge areas in project management, the reason behind that relates to the fact every project will require a change during its phases, regardless of its complexity, size, scope or cost. Change is essential and if not handled properly could lead to scope creep, budget overrun, or project failure. From my point of view proper understanding of the change, is the key to managing project change.

Every change has an initiator, this could be a business user due to new functionality required, or fixing a major functionality bug, as well the initiator could be developer, due to discovered bugs. As well each change could come along with disadvantages, in other words, the intention could be to fix a bug, however, the implemented fix could affect performance, or affect the project critical path. Change initiator considers only one direction of the change, and project manager, or project sponsor usually consider the consequences. If the implications of the change are not properly understood and communicated, most probably changes would be resisted, canceled or improperly handled. Other reasons made me consider understating the change as the key to managing changes in projects; those are change implications on staffing, it is important to understand change implication because changes could require new expertise in-house, or outsourced to plan, design or execute the change. As well understanding the change could help in finding alternatives that could be more cost effective and requires less time to perform. Change initiator should ensure that all change requirements; implications, advantages and disadvantages are properly addresses, analyzed and communicated. This will increase potential of buy in from project manager and project sponsor who eventually approve and have power to approve changes. Ward & Elvin suggest building a change framework that is based on understanding the nature of the change to increase the chance of successful outcome (Ward & Elvin, 1999). Sometimes changes are driven by strategic objectives of an organization, this implies that short term benefits would not be visible to project team, and this could result in discarding the change, while understanding that this changes was initiated for a long term benefit for the organization would help project team understand the actual value of the change an act based on that.

Changes are required and occur in every project, failing to control them could lead to project failure, I believe the key to managing project changes is understanding change nature, implications and requirements to better analyze its impact on the project and the organization.

Reference:

Legris, P, & Collerette, P 2006, 'A ROADMAP FOR IT PROJECT IMPLEMENTATION: INTEGRATING STAKEHOLDERS AND CHANGE MANAGEMENT ISSUES', Project Management Journal, 37, 5, pp. 64-75, Business Source Premier, EBSCOhost, viewed 16 June 2012

Ward, J, & Elvin, R 1999, 'A new framework for managing IT-enabled business change', Information Systems Journal, 9, 3, pp. 197-221, Business Source Premier, EBSCOhost, viewed 16 June 2012

PM Software

With the increased importance of project management, the number and variety of project management tools increased. Some of these are proprietary applications, others are open sourced or even web-based with subscription. Project management tools are essential for project managers to plan, monitor, and manage projects, resources, investments, tasks, and more. One of the famous and widely used tools is Microsoft project professional, and I will be comparing this tool with open workbench, which is an open source project management tools.

Open workbench is often defined as the free alternative to Microsoft project tool; still they have some differences and each of them certain features that distinguish it from the other. As well share similar features, some of those features are:

· Ability to identify and track the critical path.

· Ability to track milestones.

· Track resources

· Create WBS

· Create and define dependencies.

Those differences are listed in the table below

Feature	MS Project	Open workbench
Resource scheduling	Schedule is based on time duration	Schedule is based on effort
Schedule	User selected option (manual or automatic), dependency or top down.	Manual. Critical path or top-down driven.
Inter-project dependency	Requires many steps to create.	Easy and streamlined.
Working holiday	Does not allow scheduling tasks during holiday	Allowed
Resource replacement	Requires creation of work estimates, and default scheduling is set and need to be reworked.	Replacing a resource is easier as all schedules, tasks, and work estimates are maintained.
Multiple project accessibility	Individual plans must be opened before accessing the master plan. And resources appear as duplicated because they are defined in each plan seperatly.	Master plan is created and accessing it provides access to other project plans. Resources could be assigned to single project or the master project plan.
Email Integration	Available	Not Available
Cost	Above $800	Free

Cost of acquiring MS project is above $800 for individual, while open workbench is a free tool. However, MS project has an enterprise version, which connects to enterprise project management server and allows controlling portfolio of projects. Both are great desktop based tools, however resource for MS project are more and this makes it easier to learn, many books and training courses are offered to train MS project.

Reference:

Flossnet, (2011), ‘Open Workbench and MS Project Comparison’, [Online]. Available from: http://www.flossnet.org.za/computer-training-courses/29.html

(Accessed 9 June 2012)

Sourceforge, (2012), ‘Open Workbench Description’, [Online]. Available from: http://sourceforge.net/projects/openworkbench/ (Accessed 9 June 2012)

Levine, R., (2009), ‘Comparing Microsoft Project and Open Workbench’, [Online]. Available from:

http://www.brighthub.com/office/project-management/articles/47707.aspx

(Accessed 9 June 2012)

Certification & Hiring

IT project manager should have certain traits and skills to allow him to manage resources, team members, stakeholders, and lead the project success. The project manager should be good in communication, able to motivate team and stakeholders, understand team behaviors and personalities to be able to lead them, identify risks and manage them, as well project manager should have knowledge in certain areas to be able to succeed in hi career, those are procurement, HR, integration, risk, and a lot more. For that IT project manager should have certain organizational skills, knowledge in certain areas, and experience in IT to be able to successfully lead IT projects.

Project management certification such as PMI and PRINCE2 adds a level of respect to the certified candidate, and accredits that the certified candidate has the required knowledge to lead projects. It is the first step to allow a candidate to manage IT projects, however they are not sufficient. There are many traits and skills that are more important and critical on the project success, and those are more important that the certifications. Starkweather & Stevenson conducted a research to investigate the importance of project management certification and found that for recruiters and IT executives PMP certification is the least valued and recognized of other fifteen core competencies (Starkweather & Stevenson, 2011). There research found that project management certification has no relation with increased success rate of IT projects (Starkweather & Stevenson, 2011). It is important to understand the importance of the PMP certification, as candidate get to know the required skills that help them to manage projects, and introfuce the knowledge area required for them to pursue there job, however alone and without IT project management experience it is not sufficient to produce a good project manager. A candidate with the required IT knowledge and experience, and has the soft skills needed to manage projects could be sent to a training program to leverage his skills, researchers in 1990s concluded that effective project management evolved with experience (Stevenson & Ann, 2010). Project management certifications give candidates the guideline to manage IT projects, however managing a billion dollar project might come once in a lifetime, and no training program could ever translate the experience acquired in such opportunity.

In conclusion, I will not consider hiring a certified project manager without adequate and relevant experience in IT projects; on the other hand I will be hiring the experienced project manager although he acquired no certification. Without experience, certified project managers has certain knowledge and they might not has the skills, or the personality to lead and handle project conflicts, this could only be acquired by experience.

Reference:

Deborah H. Stevenson, & Jo Ann, S 2010, 'PM critical competency index: IT execs prefer soft skills', International Journal Of Project Management, 28, pp. 663-671, ScienceDirect, EBSCOhost, viewed 9 June 2012

Starkweather, J. A. and Stevenson, D. H. (2011), PMP® certification as a core competency: Necessary but not sufficient. Proj Mgmt Jrnl, 42: 31–41. doi: 10.1002/pmj.20174

Prototypes

Many system developments turned into a failure after the completion of the project because the customer discovered that the developed system does not fulfill the required and agreed upon requirements. One way to avoid this could be by developing a prototype for the solution prior to developing the solution directly. Prototyping help customers, end users, developers and project managers understand the system requirements and have a chance to test it prior to the final development. As well the prototype could be used to offer a training environment for customers and end users, and offers a sandbox environment for developers to help them understand and find better ways to develop the final solution.

Prototyping could be seen as one of the ways used to develop software, in addition to structural SDLC or a hybrid of both. Prototyping is questioned with regards to its efficiency and effectiveness (Pliskin & Shova, 1987). Authors claim that prototyping is only useful in small problems, and its basic benefit that it helps in determining interaction requirements (Pliskin & Shova, 1987), in complex projects prototyping increased project risk, and cost. The major benefit from building a prototype is that it helps in clearing any misunderstanding between business managers and their user on one side and system developers, as well it helps to identify missing requirements and helps in building the requirements document to form the base for the development of the final solution. What differentiates prototypes from final solutions is that in prototyping phase system changes happen more frequent, and the prototype evolves by time. As well the prototype could help in requirements and specifications gathering, this could be useful for complex solutions, and when business users lack the full picture of the requirements. This type of prototyping is referred to as evolutionary prototyping and it helps when developing solutions with limited understanding of requirements, this type of prototyping has some disadvantages, and those are it provides impractical performance, schedule and budget prospects, and maintenance becomes costly because of the multiple changes the prototype building phase went through.

Evolutionary prototyping could lead to poor documented solutions, and for that a hybrid technique could be more effective, and the benefits of prototyping could be seen in small projects. I do support the perception that claims that prototyping is poor technical solution only if the solution to be developed is complex. In small projects prototyping could be more effective than structural SDLC and more effective, as it helps in delivering the project in shorter time, and provides a better visibility to build system requirements.

Reference:

Glushko, B., (2008), ‘Prototyping’, [Online]. Available from:

http://courses.ischool.berkeley.edu/i290-1/f08/lectures/ISSD-20081117.pdf

(Accessed 2 June 2012)

Pliskin, N. & Shoval, P., (1987), ‘END-USER PROTOTYPING: SOPHISTICATED USERS SUPPORTING SYSTEM DEVELOPMENT’ DATA BASE Summer, [Online]. Available from: http://www.itu.dk/~evahel/speciale%20artikler/end-user%20prototyping.pdf

(Accessed 2 June 2012)

Walker, M., Takayama, L. & Landay, J., (2002), ‘HIGH-FIDELITY OR LOW-FIDELITY, PAPER OR COMPUTER? CHOOSING ATTRIBUTES WHEN TESTING WEB PROTOTYPES’, [Online]. Available from: http://dub.washington.edu:2007/projects/fidelity/pubs/Walker_HFES_2002.pdf (Accessed 2 June 2012)

Requirements Gathering

Requirements gathering, and requirements analysis are the most important parts of any software development project and IS projects in general. IS facilitates and helps all industries to be more productive and automate manual work for departments within organizations. Business people explain their requirements to project manager or system analysts, and then developers start to develop and build applications to satisfy those requirements. All stakeholders should be committed to the requirements gathering process because it’s the foundation for any software development project.

Requirements gathering process should be documented and communicated with all stakeholders, as this will form the basic design document that the software development will be based on. It is important to understand the differences in perception between business users and developers with regards to requirements, business users care most about the user requirements, which are the tasks and features the system should offer to the end user to allow him to perform his job. While for developers, requirements could be the technical requirements for them to be able to satisfy users requirements; developer’s technical requirements are referred to as functional requirements. On the other hand, system requirements refer to the top-level requirements for a product that contains multiple systems; this could be software, hardware, human resources and more (Wiegers, 2009). User requirements should be defined, maintained and under the responsibility of the business managers, while functional requirements should be defined, maintained, and under the responsibility of Information system managers, each functional manager should define and take ownership of the responsibility that fit under their area of expertise to develop the best set of details required to satisfy the project requirements. And both being IS management, and business management are responsible for the system wide requirements, its definition, maintenance, analysis, and communication. IS software is built to facilitate and help business managers perform tasks for their departments; they have to insure that their requirements are properly defined, documented and satisfied.

Defining requirements is under the responsibility of both parties being IS management and business management, each should define his requirements, as well both are responsible for defining, maintaining and satisfying system wide requirements, else the project won’t deliver the required functionality and won’t satisfy its objective.

Reference:

Paetsch, F., Eberlein, A. & Maurer, F., (2003), ‘Requirements Engineering and Agile Software Development’, IEEE, [Online]. Available from: http://www2.enel.ucalgary.ca/People/eberlein/publications/WETICE_03.pdf

(Accessed 2 June 2012)

Wiegers, K., (2009), ‘Software Requirements, Second Edition’, O’Reilly, [Online]. Available from:

http://books.google.com.qa/books?hl=en&lr=&id=WcO3Ca9NuvQC&oi=fnd&pg=PT1&dq=system+requirements+responsibility&ots=d94hFeG6Ag&sig=0r0hrJ6sMwhAG4PbCx9X5Q3huWo&redir_esc=y#v=onepage&q=system%20requirements%20responsibility&f=false

(Accessed 2 June 2012)

Zisman, A., Spanoudakis, G., Pérez-Miñana, E. & Krause, P., (2003), ‘Tracing Software Requirements Artefacts’, [Online]. Available from:

http://www.soi.city.ac.uk/~gespan/serp03.pdf

(Accessed 2 June 2012)

Small Businesses

Due to its limited resources, and huge impact of business incase of failure or success, the adoption of IT in small business is different than in large businesses, and small business have to be more careful in IT investment decision making. IT is business enabler, and not business driver. Based on that the three main concerns I would have in the case of running a small business with no IS expertise, and all software is purchased would be Interoperation, fit for purpose, cost.

Interoperation is one of the main concerns that I would consider as a concern in small business, the need of exchanging data smoothly between systems is a critical success factor for small businesses. It might not be a concern for large businesses as they have the money to go for middleware solutions, develop integration layer between systems and so on. Small business systems need interoperation specially when introducing new software, to insure proper flow of data between systems and thus help the business achieve its goal and benefit from IT systems with less cost. A second key concern would be the selection for solutions, small business solutions requirements should be analyzed and the solution selected should be fit out of the box for the business, and part of this category the business should make sure that SLA exist between software vendors for support, reliability and maintainability. This is very important because an organization with no IS expertise should be focusing on having reliable systems due to their lack of support. Usually those businesses consider outsourced support and development services, and thus local existence of this support is mandatory. A third concern and it might be one of the most important in small businesses is cost of adoption, small businesses are short in funding specially for technology systems, as those solutions might not be justified for business owners, and IT investments might not be budgeted for in such organizations.

When spending investments in IT for small businesses multiple factors should be taken into consideration, those could be interoperation, and that the software is fit for purpose and satisfies businesses requirements with minimal overhead and support, as well solution cost and that it fits within the allocated budget as small businesses IT investments might not be justified and catered for.

Reference:

Haug, A., Pedersen, S., & Arlbjorn, J., (2011) "IT readiness in small and medium-sized enterprises", Industrial Management & Data Systems, Vol. 111 Iss: 4, pp.490 – 508, DOI: 10.1108/02635571111133515, [Online]. (Accessed 26 May 2012)

Sarosa, S. & Zowghi, D., (2003), ‘Strategy for Adopting Information Technology for SMEs:Experience in Adopting Email within an Indonesian Furniture Company’, Electronic Journal of Information Systems Evaluation Volume 6 Issue 2, (2003) 165-176, DOI: 10.1.1.68.7342 [Online]. (Accessed 26 May 2012)

Build vs Buy

Software enterprises often have to decide whether to buy software of the shelf, or use internal resources to build software that fit enterprise needs and requirements. Such decision is usually controlled and guided by plenty of factors that should be considered prior to taking this decision. Those factors include internal resources skills and capabilities, cost and budget allocated, time to market, maintenance and a lot more.

Organizations with limited IS resources and expertise might not have the option to build or develop in-house software, and usually tend to buy ready solutions or contract a development company to build the software based on their needs. However, for software enterprises with available resources and IS expertise it might sound more feasible to build and develop the software in-house rather than buy ready software. However, it is not that easy to take such decision, Starling (Starling, 2003, cited in Langer, 2012) provided key decision categories that would help CIO’s to decide when not to buy software, and build it in-house:

1) Special skills in design and development are required and those are available only inside the organization.

2) Future development is required to help in keeping the application fit for the organization.

3) Software development is critical for the success of the company and its customers.

Basing the decision on the defined criteria, CIO’s should consider build in-house software incase they have the IS expertise to do so, and when other criteria factors are met such as the development of the application in-house would help the organization succeed. In addition to this criterion, it is crucial to consider total cost of ownership, Langer mentioned that 70% of organizations decided to buy rather than build because buy option comes with lower total cost of ownership (Langer, 2012), this is valid taking into consideration implementation costs and ongoing software customization and development. My organization is going through a core banking migration as we selected a new core banking solution to replace the existing one, one of the main criteria in core banking selection was implementation cost and the cost the organization need to pay to keep customizing the current core banking system to fit organization requirements.

There are other factors that need to be taken into consideration when making a buy or build decision, one factor could be engagement of current IS expertise in other software projects, an organization could have all the skills required to develop the software in-house, however they are already engaged in more critical developments and engaging them in new developments might affect the delivery of a more important project. In addition to that, ready or out of the box applications implementation time is less than developing the application in-house, and this factor could force the organization to accept out of the box applications, with less functionalities due to business engagements and the need to launch a new product in a specified time frame.

Build of buy decision is bounded by multiple factors, and even if the software enterprise have the required skillset inhouse, it could be more feasible to buy an application rather than build, this is dependent on the TCO, time limitation, and engagement in other projects.

Reference:

Buchowicz, B.S., (1991), ‘A process model of make-vs.-buy decision making. The case of manufacturing software.’, Engineering Management, IEEE Transactions on, V. 38, I. 1, pp. 24-32, DOI:  10.1109/17.65757, IEEE, [Online]. (Accessed 26 May 2012)

Langer, (2012), ‘Build vs. Buy’, Guide to Software Development, pp. 37-48, DOI: 10.1007/978-1-4471-2300-2_3, Springer, [Online]. Available from:

http://www.springerlink.com.ezproxy.liv.ac.uk/content/m8567774k075642n/fulltext.pdf

(Accessed 26 May 2012)

Hackers

Computer crime has increased with the spread of computer usage in the world; hackers use many tools such as viruses, spyware, Trojans, phishing, and fraud schemes. Hacker is not always an outsider; an employee within an organization might assume unprivileged access and steal data from the organization’s technology systems. Hackers believe that it is acceptable to do anything computer as long as the hacker has a good intention, and the motivation isn’t to gain profit from his actions. I do not accept such believe, as I do not feel comfortable to trust someone who broke into my house, and claim good intention and honest motivation.

Information and digital data should not be thought of as free or should be available to all, the author and owner of this information has the right to give access to his own property to everyone or only certain people, or keep it to himself. It is common in the digital world to read the same article by two different authors, everyone claim that he is the author, with the intension of helping everyone and making the information available to all. Laws and regulations should protect digital information or creativity will be destroyed, the problem exists due to the ease of copying in the digital world, and the use of blogs that made everyone able to post his ideas only, while others copy them. It should be clear to all Internet users, hackers and normal users that no one has the ultimate right to distribute the information except the original author of this information, however the verification of the original author isn’t easy. Accepting such claim or request by hackers about the information being free to all, clearly negative human right of privacy, as well gives a permission to everyone to check on other people financial accounts without permission, or their personal files, photos and even more. The problem is not with the hackers good intention, and no profit motivation, the main problem is with the intrusion for personal information, and personal life’s of others. Patents, copyrights, and intellectual property rights are forms of innovation and creativity protection, should be respected and adhered to. In my personal opinion, digital information and documents that were published on Wikileaks should be free. Although this might seem to be contradicting with my point of view, however it is not. The difference here is that this information should have been set public from the very beginning, and governments should stop lying, and the relationship between governments and citizens should be more transparent.

Hackers claim that information want to be free is not correct, and privacy should be protected. Hackers initiated the concept of open source systems due to their rejection of proprietary software, this could be a good intention, however all the documents generated used the open source system should remain private and owned by the author f those documents.

Reference:

Carroll, J 2008, 'Hacker or digital vigilante?', CA Magazine, 141, 8, p. 14, Computers & Applied Sciences Complete, EBSCOhost, viewed 19 May 2012.

Bodard, K 2003, 'Free access to information challenged by filtering techniques', Information & Communications Technology Law, 12, 3, pp. 263-279, Computers & Applied Sciences Complete, EBSCOhost, viewed 19 May 2012

Hall. P. & Fernandez-Ramil. J., (2007), Managing the Software Enterprise.  London. Thomson Learning..  Print. (ISBN-10:1-84480-354-6 ISBN-13:978-1-84480-354-5

Ethical Dilemmas

Perception of ethical behavior varies between people; this variation is formed due many different factors such as culture, background, experience, religious belief, and many more. Although ethics and ethical behavior judgment comes as a result of multiple factors, I do believe that ethics could be taught, and employees perception could be altered and enhanced. This believe is coming from the fact that International enterprises exist in many different locations, with employees from different cultures and backgrounds and most of them behave ethically with relation to the enterprises ethical principle and rules, else disciplinary actions could be taken.

IT plays a vital role in our life now, and this role in increasing day-by-day. Schools in UAE for instance started to replace the heavy student bags with iPads, and I personally d not know anyone who isn’t an online user, and communicate through social networking websites even the elders. E-business adoption is increasing and people started to use their mobile devices to ecommerce. Every new technology is born with its known ethical dilemmas, and yet more to be discovered by time, that because technology is the gateway to information, personal data, public data, communication and a lot more. In this article I will discuss the presented ethical dilemmas.

Case 1:

Producing a better quality product requires more time, and more time results in missing the deadline. Since the product is acceptable, this means that by delivering the product in the current state should not harm the customer, and the company is not conducting any immoral behavior. On the other hand, missing the deadline could impact the company’s reputation.

Me: I would not miss the deadline, and prefer to deliver the product in its acceptable state. In addition to that, I would inform the management about the finding and initiate a quality enhancement program to revisit products quality and enhance it.

My employees: I would like them to inform me about any future findings that could help the company improve the quality of its products, and focus on deadlines as long as the quality is acceptable.

Case 2:

Policies and procedures in an organization are developed to enhance productivity and control behaviors to benefit the organization. Those procedures should be revisited and enhanced as time advances to improve them and improve productivity. However, it should be in a controlled manner, if every employee believes that a certain action would improve a procedure, and apply his actions the organization will turn into chaos.

Me: I would follow the procedure and recommend the enhancement action either through a change management process, or request policy and procedure owner to revise my recommendation.

My employees: I would encourage them to look for enhancements, and only apply after being approved by the organization.

Case 3:

Every organization might have employees who perform unethical behaviors, however whistleblowing is crucial in such scenarios even if it is going to impact the employees professional life at this organization.

Me: I would report the harassment and request the human resource department to investigate the matter. In addition to that I would encourage the organization to implement a solution that allow employees to report harassment and unethical behavior in an anonymous form.

My Employees: I would encourage them to report harassments and not to have fear from being laid off, if not reported the harassment might happen with them in the future.

Case4:

Reporting mistakes at the very beginning might help the organization to find a solution to its consequences and reduce the impact on the organization, I personally have conducted a mistake that resulted in the loss of data when I first joined my professional life. I informed my management at the very beginning and they helped me by providing me with data recovery tools, and the data was retrieved.

Me: I would inform my management directly, to set expectations and understand the consequences. As well to find a solution that won’t harm the organization.

My employees: I encourage my employees to report any mistakes, and not fear from reactions. Instead of spending time trying to fix the problem, I might be able to help them with the solution.

Ethical dilemmas in Information technology industry are endless, with every new product or technology new dilemmas will rise. It is important to have a corporate understanding and definition for ethical behavior.

Reference:

Desai, M, von der Embse, T, & Ofori-Brobbey, K 2008, 'Information Technology and Electronic Information: An Ethical Dilemma', SAM Advanced Management Journal (07497075), 73, 3, pp. 16-24, Business Source Premier, EBSCOhost, viewed 19 May 2012.

Hall. P. & Fernandez-Ramil. J., (2007), Managing the Software Enterprise.  London. Thomson Learning..  Print. (ISBN-10:1-84480-354-6 ISBN-13:978-1-84480-354-5

Work Environment

Qatar is a small country in the Middle East and a member of Gulf Cooperation Council, it is a rich country and main source of income are Oil & Gas. Development in Qatar in 2008 started working on a new national vision, known as Qatar 2030, this vision is based on four pillars. Those pillars are human, social, economic and environmental development. However, to be able to succeed in its vision and due to lack of Qatari work force, they rely on expatriates to build and develop this country along with its future vision. Driven by this vision, Qatar started to consider revising its labor law, as it will not help them in achieving this vision. In this article I will elaborate about Qatar current working environment, its advantage and disadvantages and the changes toward effective positive working environment the country is witnessing.

Driven by its vision, Qatar started to appear as a great working environment for international companies like Shell, Dolphin and Vodafone. However, the current labor law is still considered as a major barrier towards achieving this vision and the country’s development. The labor law gives ultimate power for the sponsor to control workers, the sponsor can prevent the worker to work in any other company in the country incase of termination or end of service, as well applying for a loan, and requesting a landline phone service requires approval from the sponsor. For any workers to leave the country for vacation or business trip, they require exit permit, which is a sort of approval to leave the country. In addition to all that no minimum wage is set for labors, as well lack of salary guidelines exist which result in discrimination incase two or more candidates apply for the same job, as the package for Europeans differ by multiples from other nationalities, with the same experience and qualifications.

On the positive side, Qatar companies offer high average salaries when compared to its peers within the region, and many companies offer accommodation, and transportation to its workers. The preference in hiring is for Qataris, and that Europeans, other Arab nationalities and then Indians, Philippines, and Nepalese. Foreigners are not permitted to own business in this country, and only allow maximum percentage of 49% while the 51% is for a Qatari regardless of his actual share in this business. Safety of workers is regulated by law, however not enforced by the government. Each company enforces its own safety standards, and rules.

With regards to working environment within companies it is not regulated by the government, each company has its own standards. My organization is a local bank with branches in France and UAE, we adopted an open office environment, this has its own advantages and disadvantages, however I believe its not very helpful for IT skilled personnel who require concentration and focus. The positive working environment in my opinion is reflected on workers motivation and productivity; appreciation and respect, as well satisfying personal needs for workers could really increase workers productivity.

In conclusion, Qatar driver by its vision started to consider changing the labor law and make it more flexible, however no formal announcement for any yet. Companies in this country offer competitive salary packages, however each company has its own rules and regulations to control workers based on the labor law. International companies started to lead the change in working environment by enforcing their standards, which increased the minimum acceptable level of working environment such as trust, appreciation and rewards and other motivating forces.

Reference:

Berrebi, C, Martorell, F, & Tanner, J 2009, 'Qatar's Labor Markets at a Crucial Crossroad', Middle East Journal, 63, 3, pp. 421-442, Academic Search Complete, EBSCOhost, viewed 12 May 2012.

Buchanan, David A., & Huczynski, Andrzeg A. (2010). Organizational Behaviour. Prentice Hall.

Hall, Patrick & Fernandez-Ramil, Juan. (2007) Managing the Software Enterprise, Software Engineering and Information Systems in Context. London:Thomson Learning.

Stichler, J.F. 2009, "Creating a Healthy, Positive Work Environment", Nursing for Women's Health, vol. 13, no. 4, pp. 341 [online]. (Accessed 12 May 2012)

Virtual Team Challenges

Virtual teams exist in organizations as a reaction to globalization and increasing competition. Technological advances has started and enhanced the quality of virtual teams, it became easier for geographically scattered individuals to communicative, interact and collaborate between each other to achieve a single goal. In education industry, many universities started to offer online education or distant learning experience that utilizes technology to allow instructor who could be located anywhere in the globe to teach students from different continents, with different cultures and backgrounds. The education experience in such environment requires students to collaborate and work in virtual teams to work on a single challenging project with strict deadlines and clear requirements. In this article I will be discussing the challenges classroom virtual teams face while working on academic project, and how to overcome those challenges.

The classroom virtual group consists of geographically dispersed students who interact and collaborate using a mixture of telecommunication and information technology tools to deliver a project. This group is similar to on campus classroom project groups who interact for the same purpose, yet they don’t do face-to-face communication, “they operate across space, time, culture and organizational boundaries” (Shin, 2005). Four dimensions categorize virtual teams, and those dimensions are spatial, cultural, temporal and organizational dispersion as explained by Shin (Shin, 2005), spatial dispersion refers to the degree the team is dislocated across geographical locations, where temporal dispersion refers to the extent the team operate at different ties. The cultural dispersion relates to the degree the team is formed from individuals with different cultures, backgrounds and origin. The forth dimension, which is organizational dispersion relates to the extent individuals works across organizational boundaries (Shin, 2005). Each of these dimensions by itself creates a level of conflict that could result in affecting the performance of the project, as well as motivation of team members. Team members could be faced by build, maintain and lack of trust issues, this could be caused by lack of communication and misinterpretation of actions based on cultural perspectives. To overcome this challenge I will be focusing on identifying flexible communication tools to be used, and use those tools to get to know other team members in a personal level as long as its accepted based on their culture. I my previous modules, our main communication tool place over Skype, personal emails and blackboard discussion board. We shared our Skype ID’s and personal emails since day one, this helped us to overcome the limitation of group chat offered by blackboard as we could reach each other more easily and have a real time conversation most of the time. In some cultures like the one I belong to, it is more appropriate to start any conversation by personal chat such as insuring the member health is fine, and that he is happy and then start with the professional conversation, while in other cultures this is not acceptable and may be interpreted as lack of professionalism and time wasting conversation. Based on other team members cultures and interpretation I would start some personal talk with them to increase the level of trust, and synergy at the same time. Creating team synergy is sometimes difficult in virtual teams due to lack of frequent communication, and this could be achieved by frequent more communication. As well before the meeting I usually and will be doing one-to-one small meeting, the purpose of this is to increase the level of trust as trusted team members will be more interactive and come with healthy challenging ideas, as well to insure that each team member understands the full picture of each weeks project work. To build and maintain team synergy I will communicate each week’s project task to all team members to insure that all team members are aligned, as some team members come to the meeting without previous preparations and could not have read the requirements ahead. After the meeting I will insure that MOM are communicated and posted in the group’s discussion board. Isolation could happen when team members feel ignored, isolated and not appreciated. To overcome this I will insure that each team member is listened to, his/her ideas appreciated, and discussed. As well each team member will have to discuss and help other team members in their tasks, at the end the project is a collaborative work that is build based on other team members work, It should not be treated as hand in assignments. Performance assessment is a crucial issue in classroom virtual teams, however since this is a gradable project, and each member’s grades are and should stay confidential, I will insure that each member’s weekly task is revised by all team members and commented on if necessary. Each work should include academic references, properly cited and relevant.

Team members should understand they come from different cultural backgrounds, and I will encourage each team member to have a second look at other team members BIO, this will help in managing expectations and understanding other members cultural background. It is important to form a group with similar or almost similar time zone; this will ease the communication, and help in having online conversations. However, it is not easy to maintain that because members could be from different time zones, and in such case I will insure that meeting are set at appropriate time for each team member. As well to motivate all team members, leadership will take a rotation shape every week, leader will be responsible for updating group discussion board, consolidating team member’s tasks and steer the meetings. As well the leader should insure that weekly tasks are equally distributed among team members to avoid frustration and demotivation.

In conclusion, classroom virtual teams will face the challenges faced by virtual teams of multinational organizations, conflicts based on interpretation and lack of cultural differences understanding could occur. It is important to insure high level of dedication to the group project by team members, and variety of telecommunication and information technology tools should be used to increase level of trust and team synergy.

Reference:

Buchanan, David A., & Huczynski, Andrzeg A. (2010). Organizational Behaviour. Prentice Hall.

Hall, Patrick & Fernandez-Ramil, Juan. (2007) Managing the Software Enterprise, Software Engineering and Information Systems in Context. London:Thomson Learning.

YUHYUNG SHIN, Conflict Resolution in Virtual Teams, Organizational Dynamics, Volume 34, Issue 4, 2005, Pages 331-345, ISSN 0090-2616, 10.1016/j.orgdyn.2005.08.002. (http://www.sciencedirect.com/science/article/pii/S0090261605000392)

Delivery of Projects

Software development life cycle methodologies were developed over time to help project managers reduce software development failure rate, and improve the quality of developed software as well as its productivity. The principles of software development in specific and project management in general help the humankind to produce more reliable piece of software, this happens by following a process model with multiple phases. Regardless of the SDLC methodology adopted, it is necessary to understand and analyze the requirements before the implementation starts. In the presented case, we have multiple aspects that need to be taken into consideration; those aspects are senior management requirement and the impact of not demonstrating this software at the show. Another aspect is the system analyst feedback on the current and projected time required to complete requirements gathering phase. I will start by analyzing each of those aspects, its consequences and how to overcome its drawback if possible. I will start with system analyst feedback as it provides the current update about the project.

Requirements gathering done by system analyst(s) shows that it requires full eight weeks to complete this phase, and two weeks of those have passed. Requirements gathering phase differ based on the SDLC methodology adopted, waterfall process for instance requires full requirements gathering and analysis be completed before moving into the next phase of the project and that being software design. In this process each phase has to complete and only after that the project manager can move to the next phase, it require lots of time. On the other hand, if a more agile SDLC methodology were adopted such as XP, requirements gathering take place at multiple places during the project lifecycle, and multiple releases are produced until the final version is accepted and only after that the final version is implemented. Since requires gathering process requires sex more weeks to be fully comprehensive the XP SDLC method would help in building multiple releases each depends on the set of collected requirements, and new requirements can be assumed in new releases. It is important to mention that for the requirements to be relevant and accurate, requirements analysis should be conducted to identify the risks at early stages of the project, as well to identify contradicting requirements and find solutions to overcome those limitations.

Another important aspect to consider is the senior management’s requirement to complete this software to be demonstrated in august because it has a great impact on the organization’s existence and future. Due to the high impact the software demonstration could cause, this requirement should be analyzed and possibilities of delivering a bugged software should be considered, sometimes the impact of not demonstrating the software could be less that demonstrating a buggy release that affect the organization’s reputation. a meeting with senior management should be held to explain the current progress to manage their expectations, as well explain to them the consequences of delivering a bugged version and how this could affect the organization’s reputation. It is important as well to explain to them that full team of developers is not the ultimate solution to problem in hand, as for example ten developers will not able to code two times faster than five developers. As the team expands, communication problems become more frequent and communication management becomes more difficult. Software development is tricky and unpredictable, and because of that adopting a SDLC methodology would reduce risks and increase project success rate, it is easier to develop an identified and known requirement, that start developing without a clear roadmap.

As a conclusion, I would manage senior management expectations by explaining project difficulties and make sure they are fully aware on the effect of increasing number of developers and that won’t guarantee project delivery, on the contrary it could delay the project even more. As well I will not ask my team to start coding directly, as this is a guaranteed project failure from my point of view and based on my experience. I would ask my team to start developing gathered parts of the requirements to develop a first release, and try to get a priority list from management on the features that need to be demonstrated to concentrate all efforts to deliver a stable partially ready software. XP methodology would be followed to insure that my team works on parallel streams to try to meet the deadline as this is very important to the companies reputation.

Reference:

Wells, D. (2009) ‘Extreme Programming: A Gentle Introduction’ [Online]. Available from: http://www.extremeprogramming.org/ (Accessed: 04 May 2012)

Paulk, M.C., (2001), ‘Extreme Programming from a CMM prespective’, IEEE Journals & Magazines, [Online]. Volume 18, Issue 6, pp. 19-26. (Accessed 5 May 2012)

Software Failure

Software is used in every industry; the cars we drive and mobile we use rely heavily on software. Companies from varies industries has an annual spending on software projects either to develop new software or maintain existing software licenses, computer hardware or any IT related spending. Charette stated that depending on the business industry the IT spending ranges from 4 – 10 % of its revenue (Charette, 2005), being a government, non-profit organization, financial institution or a retailer each of these industries require spending in IT projects either to introduce new services, products or facilitate its operations. In this article I will analyze the trend behind software failures, and if it is related to a specific industry, or not.

Software failure implications vary based on the criticality of the software and industry, it could lead to waste of billions of dollars, or result in the death of people. As well we could notice that software failure is not limited to an industry as each industry suffered from software failures. People have learned from their mistakes and developed methodologies to manage software development risks, and to minimize the impact and frequency of software failures, in addition to that good project management is needed to achieve better success rate. Based on a report by IBM done to identify success rate trend, it appeared that software project success rate in getting better by time taking into consideration the increased complexity. However, the success rate is increasing slowly, for example the software project success rate in 2001 was 28% while in 2003 its 31% (Marasco, 2006).

Reasons behind software failures are plenty, starting from unrealistic scope, improper identification of requirements, poor project management and a lot of other reasons. I agree with Charette in his finding that rarely software projects fail for one reason only; usually it’s a mixture of reasons that cause software projects to fail and software to fail as well. Hamill and Goseva-Popstojanova in 2009 in their research found that software fail regardless of their industry, development methodologies applied and coding language used; and they fail during implementation phase. And this finding supports the idea that software fails in almost every industry and its not industry related, the translation from user requirements into developers language and the proper understanding of user requirements is very critical to project success.

In conclusion, software failures are not industry related. Software engineers are learning from software failures are developing software methodologies to overcome known limitations and reduce software failure probability, the impact of financial crisis and organization’s tendency to lower cost may have affected and increase software failure rate, this because organizations are expecting more for less.

Reference:

Charette, R.N., (2005), ‘Why Software fails [software failure]’, IEEE Journals & Magazines, [Online]. Vol 42, Issue 9, pp. 42-49. Available from: http://ieeexplore.ieee.org.ezproxy.liv.ac.uk/xpls/abs_all.jsp?arnumber=1502528&tag=1 (Accessed 5 May 2012)

Hamill, K. & Goseva, K. 2009, "Common Trends in Software Fault and Failure Data", IEEE Transactions on Software Engineering, [Online], vol. 35, no. 4, pp. 484-496 [Online]. Available from:http://ieeexplore.ieee.org.ezproxy.liv.ac.uk/xpls/abs_all.jsp?arnumber=4760152&tag=1 (Accessed: 05 May 2012)

Marasco, (2006), ‘Software development productivity and project success rates: Are we attacking the right problem?’, [Online]. Available from: http://www.ibm.com/developerworks/rational/library/feb06/marasco/

(Accessed: 05 May 2012)

Success Factors

The Chaos report version 1995 listed the project success factors based on respondents experiences, those 365 respondents gave user involvement the highest percentage while executive management second while hard-working and focused staff were given the least percentage. Based on my experience I would give executive management support the highest percentage and pick it as the most critical success factor for my ERP development project.

The project I am working on is an in-house ERP development project; the objective of this project is to produce an ERP application that can be used by my organization and later on customize it based on potential clients needs to make it ready for the market. Development of ERP system requires collaboration and commitment from all business divisions, without such commitment the project would fail. Usually commitment from business users is not easy to get, that because they have other priorities, unless business division management is fully committed to the project. Such commitment will be reflected to business users and add more stability to project schedule. In general, project success heavily depends on strong leadership, and commitment from top management. For example my current employer have implemented a system which at the beginning was fully supported by the management, by time management lost interest in this system due to high maintenance cost. Because of that, management has forced a direction to decommission this system and replace it another system that has less maintenance cost, although it might seem that the cost is the main driving factor for such decision, but even costly systems can survive with management support.

Organizational changes caused by projects is another important reason makes me believe that executive management support is the most important success factor, sometimes certain projects require major structural and organizational changes to insure project success, or because the project itself explores a new technology that might lead to staff replacement, and such project would see the sun unless it is supported and blessed by executive management (O’Brochta, 2008). In addition that lots of processes and procedures require management support, especially if they are new to the organization, “follow a documented project plan and ensure that projects are based on documented requirements” (O’Brochta, 2008).

Executive management support will ease project manager job, it will help in getting more resources when needed, put more pressure on certain departments to insure project schedule met, and adds more control over the project by the project manager.

Reference:

Elisabeth J Umble, Ronald R Haft, M.Michael Umble, Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research, Volume 146, Issue 2, 16 April 2003, Pages 241-257, ISSN 0377-2217, 10.1016/S0377-2217(02)00547-7. http://www.sciencedirect.com/science/article/pii/S0377221702005477

(Accessed 21 January 2012)

O’Brochta, M., (2008), ‘Executive Actions For Project Success’, Published in PM World Today – December 2008 (Vol X, Issue XII), [Online], Available from:

http://www.pmforum.org/library/papers/2008/PDFs/OBrochta-12-08.pdf

(Accessed 21 January 2012)

Evaluation Metric

Project evaluation is crucial for any project to measure project status in terms of meeting budget, schedule, resource performance and a lot more. It helps in identifying issues with software development projects, methodologies followed and a lot more. The main purpose from project evaluation is to help “decision-makers in evaluating funding priorities” (). Project evaluation takes place through project evaluation metrics, which require time and effort, and used to help in as identified by Lever:

To offer sharp and real project status information with regards to schedule and cost.

To detect areas for project process enhancement.

To substantiate the results of process improvement efforts.

“To collect a database of project metrics to analyze trend information or provide historic comparators and perhaps used for parametric estimates” (lever, 2009).

Because evaluation metrics consume lots of time and effort to gather and analyze, its not practical to collect all project metrics for a project, instead project manager should identify relevant metrics to evaluate based on project need and stakeholders requirements. Developing metrics that help in project process improvement and enhancement add more value, as well metrics that offer accurate and real data about project status and budget will provide a better understanding of project specific needs, and provides project manager with signs that help in identifying problems and issues before they occur.

In-house ERP development project matrix attached, details discussed below:

First metric to evaluate will be the cost, most importantly comparison between budget approved at the beginning of the project and the actual project budget, this value will be analyzed to derive areas which consumed more budget and reason for such budget drift.

Second metric to evaluate will be schedule, we will be looking at project plan and evaluating current project progress, this will help in identifying root cause of the delay and find ways to put the project back in track.

Third evaluated metric is scope, number of requested changes, approved changes and impact on project time and budget. Scope is evaluated to insure that project won’t lose its original objective and fall into scope creep.

Quality will be he forth metric to evaluate, by quality we mean following processes, procedure and software development methodologies, insuring project phases; changes and code are properly documented. This will help in tracking project, and aligning project to universal quality standards.

Code complexity and lines of code will be measured to evaluate code quality, and identify other ways code could have been developed with, for example sometimes the way a code is written affect performance and major software functionality. For that software metric is very important to measure in an in-house development project.

The last metric to evaluate is defects, this is important because it will help in evaluating application-integrated functions, application fit to use. Number of defects and bugs and their impact should be evaluated during testing phase.

Project evaluation help in increasing number of successful projects for the IT industry in general and for an organization in specific, such evaluation will add value during a project and as well for future projects.

Reference:

Anonymous, (2006), Project Evaluation Framework, [Online], Available from:

http://dnr.wi.gov/org/water/watersheds/planning/documents/project_evaluation.pdf

(Accessed 21 January 2012)

Lever, R., (2009), ‘Project Evaluation and Selecting Project Metrics’ Project Management Metrics a Tool for Project Process Improvement, [Online], Available form: http://roger-lever.suite101.com/project-evaluation-and-selecting-project-metrics-a92421

(Accessed 21 January 2012)

Scope Management

“Project Scope Management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully” (Mathur, 2007). From the definition we conclude that project scope could exceed identified requirements, which could result in project failure, that because project successful completion requires defined and agreed upon scope, else project could fail.

There are many problems in the scope that make it one of the most critical and hard to control within the project lifecycle, scope could be ambiguous and this ambiguity could lead to misperception and needless work. As well project scope could be incomplete, and this leads to schedule slips as mentioned by Mathur. Other scope problems are collaborative, which leads to misunderstandings of requirements and confusion. In addition to those problems, scope creep could result due to the scope being transient; this leads to never ending projects and late deliveries. All those problems could lead to project failures, cost over run and late deliveries, Mathur said that more than 70% of projects fail, and in those 70% its rarely technical reason behind failure (Mathur, 2007). Concrete and solid scope management doesn’t mean that all changes are not accepted during project lifecycle, sometimes there are necessary changes, if not performed project could fail. But the process of controlling those changes should take place to insure proper change and scope control.

Changes during project lifecycle should be controlled, from the beginning to the end; else it will increase the workload on all team members and without any proper outcome. Changes should go through the proper evaluation, justification and approval channels, to insure that all those changes fit for project purpose, and allocate budget and time frame for those changes. As well, any nice to have or not mandatory change should be kept in a wish list. Not doing so will lead to improper scope management and hence project failure or delayed. If the scope is not managed in a correct way, it will definitely lead to unsuccessful projects. On the other hand, proper scope management will increase percentage and possibility of having successful projects.

Scope management is one of the most important knowledge areas in project management; this is due to the importance of the project scope and its impact on project status being a success or a failure.

Reference:

Atkinson, R., Crawford, L., & Ward, S., (2006), Fundamental uncertainties in projects and the scope of project management, International Journal of Project Management, Volume 24, Issue 8, November 2006, Pages 687-698, ISSN 0263-7863, 10.1016/j.ijproman.2006.09.011. (http://www.sciencedirect.com/science/article/pii/S0263786306001438)

(Accessed 14 January 2012)

Mathur, A., (2007), ‘Improve Project Success with Better Scope Management’, PM World Today - August 2007 (Vol. IX, Issue VIII), [Online], Available from:

http://www.pmforum.org/library/tips/2007/PDFs/Mathur-8-07.pdf (Accessed 14 January 2012)

Project Termination

Project closure process includes wining stakeholders and client’s acceptance of the final project deliverables, and transports the project into and well-ordered end. Output of this process could be operational documents to help in running this project after the project is completed; as well lessons learned based on what went right and what went wrong to act as a reference for future projects. In addition to that, all contract are closed with external suppliers.

Project closure is different that project termination process, the former process is held in case of a successful project and normal project end of life. On the other hand, project termination process takes place when the project is successful or when there is a need to terminate a project’s life, this could be caused by various reasons such as unrealistic requirements, technology used became obsolete, and human resources couldn’t be replaced and many other reasons. Project termination doesn’t mean project failure, and terminating a project doesn’t mean that the project manager, and stakeholders failed because it could be resulted by factors beyond their control. However, it is very important to know when to terminate a project, and how to terminate it to minimize the losses and help in turning a certain project’s termination into another’s project success.

There are four project termination modes and those are, extinction, addition, integration and starvation. Project extinction mean end of project life, and this could be reached when the project is successful, executive management no longer support this project, external factors like financial crisis occurred and forced the organization to terminate the project due to insufficient funds, or the project did not achieve its goals and objectives. Termination by addition is when the project turns out into a major achievement for an organization, and transformed into an organizational unit for an organization (Baikunth, n.d.). Termination by integration is cited as the most common mode, and it takes place when the project is successful and operations are handed over to the organization (Baikunth, n.d.). Termination by starvation mode is decreasing project budget until it dies.

Regardless of the main reason behind project termination, it is really important to document termination process, and that by preparing all necessary documents, lessons learned, and follow project closure process to ensure proper documentation to avoid mistakes if any in future projects. “The success of future projects may depend on not only the success of past ones, but also on how unsuccessful projects were treated by the organization and its stakeholders” (Hormozi, McMinn, & Nzeogwu, 2000).

Reference:

Boehm, B.; , "Project termination doesn't equal project failure," Computer , vol.33, no.9, pp.94-96, Sep 2000
doi: 10.1109/2.868706
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=868706&isnumber=18807

Jiancheng, G, Quan, L, & Hui, P 2002, 'MAKING BETTER PROJECT TERMINATION DECISIONS', Research Technology Management, 45, 1, p. 13, Business Source Premier, EBSCOhost, viewed 13 January 2012

Hormozi, A, McMinn, R, & Nzeogwu, O 2000, 'The Project Life Cycle: The Termination Phase', SAM Advanced Management Journal (07497075), 65, 1, p. 45, Business Source Premier, EBSCOhost, viewed 13 January 2012

Baikunth, N., (n.d.), ‘Project Closure/Termination’, IT Project Management, [Online], Available from: http://www.webster.edu/ftleonardwood/COMP5940/Student_Files/Project_Termination/Project_Termination_Lec.pdf

viewed 13 January 2012

Improving Information Technology Project Quality

The International Organization for standardization (ISO) defines quality as “the totality of characteristics of an entity that bare on its ability to satisfy stated or implied need” (ISO, cited in Schwalbe, 2010, p.294). Project quality management aim is to guarantee that the project undertaken will fulfill the needs for which project was initiated. As an impact for globalization, consumer became more demanding for higher quality products, this made quality management a key are to address and budget for in all industries and projects. Project quality management include three main processes those are planning quality, performing quality and quality control. Quality is one of the area which require continuous improvement, this to insure that quality is always at its maximum levels to satisfy customers and project stakeholders.

To improve information technology project there are multiple suggestions that could be addressed, first could be managing quality expectations and cultural differences, second is using maturity models, and third is through promoting quality awareness and reinforcement through project and organizations leadership and top management. Because not all quality aspects could be clearly defined, and because different team members could have different expectations about project quality, it is important to understand various team member’s expectations, try to satisfy them and resolve any conflict caused by difference in expectations (Schwalbe, 2010, p.322). Another important factor that should be taken into consideration while defining project quality within project scope is cultural differences and perception of quality in different countries or between team members from different backgrounds. For example quality standards in EU differ a lot than quality standards in Middle East countries.

Second important factor to improve IT project quality is the use of maturity models, those are frameworks to help organizations improve their processes and systems (Schwalbe, 2010, p.323). Most of them consist of five levels, and there are three popular ones, one of them is Capability Maturity Model Integration, “The Capability Maturity Model for Software (CMM or SW-CMM) is a reference model for appraising software process maturity and a normative model for helping software organizations progress along an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes” (Herbsleb et al., 1997). It helps in enhancing processes for a project, organization or a division within an organization, and provides guidance for quality processes (Schwalbe, 2010, 323).

The third suggestion to improve IT quality is by promoting quality to top management, or project owners. “Although initially this theory holds some truth, in the long run, leadership within the organization plays a more important role in achieving and maintaining quality” (Shiramizu  & Singh, 2007). As long, as project stakeholders are quality sensitive, and promote quality among project team, this will improve project quality, as management will force team members to become quality sensitive and insure good quality projects. Many argue that main cause of quality problems is lack for leadership (Scwalbe, 2010, p.319).

Project quality management is important for project success, and continuous improvement for quality is essential to have successful projects, this improvement could be through managing expectations and cultural differences, leadership or the use of maturity models to enhance quality processes.

Reference:

Herbsleb, J. et al. (1997), Software Quality and the Capability Maturity Model, Communications of the ACM, Volume 40 Issue 6, DOI: 10.1145/255656.255692. (Accessed 7 January 2012)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Shiramizu, S. & Singh, A. (2007), ‘Leadership to Improve Quality within an Organization’, Leadership Manage. Eng. 7, 129 (2007); doi:10.1061/(ASCE)1532-6748(2007)7:4(129) (12 pages), [Online]. (Accessed 7 January 2012)

Project Performance Distribution

Communication management is one of the most essential skills and knowledge areas for successful project management, each project should include a communication management plan where it could be part of project documentation for small projects, or a separate document. By all means it should cover stakeholder communication requirements, the type of information to be communicated, recipients, frequency and escalation procedure for problem solving (Schwalbe, 2010, p.387). Schwalbe stresses on the importance of project communication plan as it guides all stakeholders with agreed upon guidelines, it is important because not all team members have good communication skills, and this plan will help them understand communication requirements for a project.

Communication the proper information at a proper time for the proper person is the ideal goal in any project. There are plenty of ways were team member can distribute information across; technology is one of the heavily depended on mediums to distribute project information and organization communication in general. Team members could use email, instant messaging, collaboration tools, wiki’s or websites to exchange information, project manager could set internal project management information system to organize project documentation, schedule meetings, document minutes of meetings, and change requests, this is useful for large project to help share and make information available for everyone. Still relying only on technology for project communication is not enough, face-to-face meetings is crucial for project success, as sometimes words might be incorrectly interpreted or misunderstood, scholars stress on the importance of body language and tone for successful communication (Schwalbe, 2010, p.391). It is important to use informal communication to distribute project information, some team members might prefer to have coffee chat about project rather than reading status reports, as it helps them more in giving the proper feedback and understand issue clearly with verbal communication.

When it comes to project performance information, mainly there are two types to distribute it, reporting and forecasting. Reports are used to distribute work performance information and measurements (Schwalbe, 2010, p.398), there are two types for reporting those are status reports, and progress reports. They differ in the time frame for each of them, status report “describe where the project stands at a specific point in time” (Schwalbe, 2010, p.398), it describes whether the project is meeting, time, scope and budget or not at a certain time, on the other hand, progress report “describe what the project team has accomplished during a certain period” (Schwalbe, 2010, p.398). Other form of performance information reporting is project forecasts; by this project manager guess future progress and status of the project based on previous information and trends (Schwalbe, 2010, p.398), forecasts help in estimating project budget, time required to complete certain tasks and so on. Other than those two forms of reporting, status review meeting could be used to distribute project performance information, in such meeting top management get status review feedback and update on project performance, and discuss important project isses.

Communication management plan is crucial to set the guideline for project communication; it helps team members to better communicate and report progress to project manager and top management. Project communication could take multiple forms and types, such technology based communication, or face-to-face. However for performance information distribution formal communication, which takes the form of reports and forecasts, is the best way to distribute it.

Reference:

Ronald L. Thompson, H. Jeff Smith, Charalambos L. Iacovou, The linkage between reporting quality and performance in IS projects, Information & Management, Volume 44, Issue 2, March 2007, Pages 196-205, ISSN 0378-7206, 10.1016/j.im.2006.12.004., Available from: http://www.sciencedirect.com/science/article/pii/S0378720607000031. (Accessed 7 January 2012)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

RM Planning

Risk is something that has not happened yet, and has a potential impact over the future. Schwalbe defined the project risk as “an uncertainty that can have a negative or positive effect on meeting project objectives” (Schwalbe, 2010, p.425), for that risk management can be defined as the action to be done to lessen the impact of negative future events. Cervone raises a very important issue with regards to risk management implementation, he said that although project risks could be dangerous, and that risk management is crucial, still its not given the required attention by project managers. He also explains the common practice by project managers of risk estimation, and that by examining issues related to risk and adding a margin of risk, known as WAG technique (Cervone, 2006).

Schwalbe defined planning risk management as “the process of deciding how to approach and plan for risk management activities for a project, and the main output of this process is risk management plan” (Schwalbe, 2010, p.428). The plan itself is a document that contains procedures for managing project risks. Early in the project, the team should hold planning meetings to start developing the risk management plan, as well they have to review project documents and organizations risk policies, risk categories, lessons learned from previous projects, and risk management plan templates (Schwalbe, 2010, 428). Another important aspect that should be considered by project team is project stakeholders risk tolerance, in specific decision makers such as project sponsor and senior management. Risk management plan should address various topics; those are methodology, roles and responsibilities, budget and schedule, risk categories, risk probability and impact, revised stakeholders tolerances, tracking and risk documentation (Schwalbe, 2010, p.429).

Each of those topics should be addressed in a risk management plan; valid questions to answer with regards to methodology are “how will risk management be performed on this project? What tools and data sources are available and applicable?” (Schwalbe, 2010, 429). Risk manager or project manager should gain buy-in from the management to allocate resources to manage risks, create a risk management plan and have it approved by all stakeholders. Risk management plan should include all team members who should be involved in risk management sessions, frequency of these sessions and identifies the risk manager for each risk identified. As well it should include the tools to be used to identify, manage and control risks, tools such as risk register, probability-impact matrix, and software such as Monte Carlo.

With regards to roles and responsibilities, risk management plan should address a question about “who are the individuals responsible for implementing specific tasks and providing deliverables related to risk management?” (Schwalbe, 2010, 429). There should be a risk manager if not the project manager to handle defining the risks, entering them to the risk register, perform meetings to assess risks and define new risks, prioritize risks, help create risk response plans and contingency plans. Each risk should have an owner who watches the triggers for the risk, implement the risk response plan or request the contingency plan to be performed, decide whether or not this risk is still valid and all the project team is responsible for defining risks as they arise. With regards to budgets and schedule, risk management plan address a question about the estimated costs and schedules for performing risk related activities? (Schwalbe, 2010, 429).

With regard to budget and schedule, risk management plan should answer a a question like “what are the estimated costs and schedules for performing risk related activities?” (Schwalbe, 2010, 429). As well the plan should cover risk categories as what are the main risk categories that should be addressed on the project? Risk categories could be technology, unrealistic time estimates, unrealistic cost estimates, lack of resources, hardware compatibility, delays in hardware procurement, unclear requirements and a lot more. As well the plan should address questions related to risk probabilities and impacts of risk items be assessed, in addition to scoring interpretation methods that will be used for analysis? How will the probability and impact matrix be developed? (Schwalbe, 2010, 429). The plan also should question current status of stakeholders risk tolerance, and how a change in risk tolerance could affect the project itself? In this regards, Stakeholders tolerance to risks is either risk averse or risk takers. If the management tends to be a risk averse, then the scoring to the risk from a probability and impact perspective will be higher and hence more contingency reserves will be taken into consideration. Risk takers tend to evaluate risks with lower probability and impact, which means less contingency reserves. Another factor to be addressed in the risk plan is “how will the team track risk management activities how will lessons learned be documented and shared? How will risk management processes be audited?” (Schwalbe, 2010, 429), this could be achieved by performing risk sessions periodically, updating the risk register, and review the watch list for the less important risks. Once the project is on its closing phase, the team members should perform a lessons learned sessions and document the results

“Risk management can make an important contribution to effective project management” (Rangopal, 2003). For that risk or uncertainty management as Rangopal prefers to name it should be given more focus by project managers, and not identify major risks and add a risk margin as described earlier.

Reference:

H. Frank Cervone, (2006) "Project risk management", OCLC Systems & Services, Vol. 22 Iss: 4, pp.256 - 262

DOI 10.1108/10650750610706970 (Permanent URL)

Rangopal, M 2003, 'Project Uncertainty Management', Cost Engineering, 45, 12, pp. 21-24, Business Source Premier, EBSCOhost, viewed 31 December 2011

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

RM Software

Controlling risks in projects is considered a major contributor to projects success, surveys suggested that only quarter of software projects succeed and completed as scheduled, on time and on budget, and this means billions of wasted dollars due to project failures (Charette, 2005, cited in Bannerman, 2008). It is argued that risk management for software projects could improve project outcomes, and I believe the same however, this is not limited to software projects, it covers all projects in varies industries. Good and effective risk management will improve project outcome, and help in increase project success ratio. Although risk management is so important and so effective, its outcome might not be that obvious as long as projects are running smoothly. To assess risk management processes and systems, predefined measurements should exist to better evaluate its outcome. “It is quite difficult to measure the benefits of risk management: successful risk management may prevent some problems from occurring and very few organizations have good enough measurement systems or data points to show the impact of risk management” (Kontio, 2001).

Risk management software can be divided into two main categories, being integrated and standalone. Those categories are with relation to project management software used by organizations, an example of an integrated tool is Monte Carlo add-on tool for Microsoft Project. Although Microsoft project has a PERT module that implements quantitative risk analysis, but Monte Carlo add-on overcomes some of its limitations being accuracy of results is limited to single dominant path through a precedence network, and accurate estimation of optimistic, most likely and pessimistic times (intaver, n.d.). There are other integrated tools such as @RISK and Risk+. On the other hand, standalone risk management software such as “Acertus Securac’s ERM software solution enables organizations to identify, measure, manage and mitigate risk and compliance in all aspects of the organization” (RiskWorld, n.d.). All those tools help in answering to risk related questions, and those are as identified by intaver:

· What is the chance of completing project on schedule and within budget?

· What is the chance that a certain task is on the critical path?

· Which tasks affect project duration?

· What is the project success rate?

The introduction of risk management brings lots of advantages and benefits for organizations, they “enhance various risk management processes” (Schwalbe, 2010). Organizations could use risk management software to create or update risk registers, as well track project risks and quantify them, those software aid in preparing charts and perform sensitivity analysis. “Software can be used to create decision trees and estimate expected monetary value” (Schwalbe, 2010). Advantages of risk management software vary and exceed basic benefits mentioned earlier, depending on complexity of features offered by the tool, for instance Monte Carlo simulation software “could develop models and use simulations to analyze and respond to various risks” (Schwalbe, 2010). As well some tools offer features like probabilistic and conditional branching, “An example of probabilistic branching is when the user defines that there is 40% chance that task A will be successor of task B and 60% chance that task C will be successor of task B. An example of conditional branching is when the user defines that task A task will be followed by task B if task A duration is greater or less then a certain value“ (Intaver, n.d.)

Although those tools ease project manager risk management related task, and increase project success rate, they have some disadvantages and limitations. A major limitation in risk management tools is that they rely on user input, for that if a risk was not presented to the tool because it was not originally identified, or user forgot to present it to the system it cannot be managed. For that project management should not over-rely on those tool, and still they need to identify the risks themselves, and based on their experience. “It takes hard work to develop and implement good risk response strategies” (Schwalbe, 2010, p. 450).

Other disadvantages could be software cost, as risk management software are expensive, and could add to the project budget f not already purchased and installed. Another problem could be conducting user trainings to employees and motivate them to use risk management tools instead of word editing and spreadsheets to maintain and log risks.

Risk management software could be very helpful and a major contributor to project success, as they offer lots of features that ease project manager job. Still those tools should be used with cautious, as they are bug free and require valid and complete input to provide us with expected results.

Reference:

Downes, D 2006, 'Risk management software solutions it's a fragmented marketplace', Accountancy Ireland, 38, 4, pp. 22-24, Business Source Premier, EBSCOhost, viewed 31 December 2011

Intaver, (n.d.), ‘Quantitative Risk Analysis with Microsoft Project’, [Online], Available from: http://www.intaver.com/Articles/Article_MSProjectRiskAnalysis.pdf

(Accessed 31 December 2011)

J Kontio, 2001 “Software Engineering Risk Management: A Method, Improvement Framework, and Empirical Evaluation” available online from: http://lib.tkk.fi/Diss/2001/isbn951225655X/isbn951225655X.pdf

Paul L. Bannerman, Risk and risk management in software projects: A reassessment, Journal of Systems and Software, Volume 81, Issue 12, December 2008, Pages 2118-2133, ISSN 0164-1212, 10.1016/j.jss.2008.03.059. (http://www.sciencedirect.com/science/article/pii/S0164121208000897)

RiskWorld, (n.d.), ‘Risk Related Software’, [Online, Available from: http://www.riskworld.com/software/sw5sw001.htm

(Accessed 31 December 2011)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7