Business Essays - Technosource Energy Software

Published:

Technosource Energy Software

Operational Aspects of Technosource Energy

1.Introduction

This report is an assessment of operations management within Technosource Energy Limited, a UK based software Development Company. The report is a result of an interview with Jill Annette the chief personnel officer. The report first of all identifies the main inputs, outputs and transformation process involved, also included is a detailed account and critique of quality management and capacity management issues within the business.

This will then be compared and contrasted with my findings with relevant referenced sources in section 5, in addition to this there will be a description of their relevance in the business environment, citing examples of their use. The report will then finish with a conclusion and possible recommendations for Technosource in regards to their operational management style and how it could be improved.

2. Organization Analysis

2.2 Technosource Energy

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

Technosource Energy is a large UK based software development company which offers scalable information technology solutions and support services that meet the requirements of the oil & gas industry. These include System design & implementation, back & front end technology, Network design, and off-the- shelf up & downstream systems.

It delivers mission & safety critical enterprise solutions to major oil and gas companies around the world who operate from multiple oil rigs across. It had revenues of more than £9 million and net profits of nearly £4 million in 2006, with about 900 employees in total, the company has been CMMI assessed at level 5 with a number of external clients for whom it develops a wide range of business applications.

2.2.1 Products & Services

  • Seabed seismic monitoring systems 
  • Fibre optic sensing Systems for underwater exploration 
  • Onboard truck computers, terminal automation systems (TAS),
  • VSAT systems
  • 2D, 3D and 4D towed streamer array interface for land seismic data acquisition
  • Keyed-Data-Terminal (KDT) to multiple oil rigs across various platforms
  • Controlled Source Electromagnetic Imaging (CSEMI) front-end for direct hydrocarbon determination
  • Borehole Geophysics Interface
  • Wireless sensors for underwater surveys

2.2.2 Approach to Quality

According to Bartlett (2005), the consequences of faults in safety critical systems can be much more serious and the developers will be at legal risk if the software product fails or its descriptions are inaccurate. In line with its commitment to deliver error free software, Technosource conducts a very detailed software development lifecycle which recognizes that analysis of the user requirement and testing the software is the company’s best investments in reducing its litigation risk.

Its operations management is also of a high standard; as it utilizes a combination of plan driven design methodology, with emphasis on capturing the user’s requirement which according to the The Standish Group (CHAOS 2001) is responsible for 70% of software failure.

3. Main Inputs, Outputs & Transformation Process

3.1 Lifecycle Approach

According to Cockburn (2000), all software projects follow a life cycle approach which comprises of a series of phases from project inception to delivery of the software. The software lifecycle can either be based on the traditional plan driven or the lightweight people driven methodology. This approach currently utilized by Technosource Energy in the design of its software is the plan driven – waterfall lifecycle, which is prescribed for in the design of safe critical systems [25].

3.2 Activities

The main inputs, outputs and the transformation process starts when a software product is conceived through correspondence with the customer and ends when it has been accepted by the customer, i.e. it contains the whole of the development, operations and maintenance activities.

The products of the software development project are delivered in a timely manner fit for purpose [25]. Software development activities are systematically planned and carried out with a ‘life cycle model’ structures which is divided into ‘phases’ and defines what activities occur in which phase.

  • UR phase - Definition of the user requirements
  • SR phase - Definition of the software requirements
  • AD phase - Definition of the architectural design
  • DD phase - Detailed design and production of the code
  • TR phase - Transfer of the software to operations

6. OM phase - Operations and maintenance

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

The first four phases end with a review. These phases must occur whatever the size, the application (e.g. scientific, administrative, real time, batch), the hardware, the operating system or programming language used, or whether the project is carried out by in-house staff or by a virtual team staff.

The delivery of the User Requirements Document (URD) to the developer for review is the first activity of the software life cycle. Following the approval of the URD, three ‘development’ phases must take place before the software is transferred to the users for operations.

The deliverables of each phase must be reviewed and approved before proceeding to the next. After a period of operations, the software is finally accepted. This event marks the end of the software life cycle.

3.3 Milestones

There are six major milestones that mark progress in the software life cycle. These milestones are the:

  • Approval of the User Requirements Document (URD);
  • Approval of the Software Requirements Document (SRD);
  • Approval of the Architectural Design Document (ADD);
  • Approval of the Detailed Design Document (DDD), the Software User Manual (SUM), the code, and the statement of readiness for provisional acceptance testing;
  • Statement of provisional acceptance and the delivery of the Software Transfer Document (STD);
  • Statement of final acceptance and the delivery of the Project History
  • Document (PHD).

The last milestone does not fall at the end of a phase, but at the end of the warranty period. These milestones have been selected as the minimum necessary for a workable contractual relationship.

4. Critique of Operational Activities

4.1. Quality Management

According to Rose (2005), in the context of software systems quality software is reasonably bug-free, delivered on time and within budget, meeting the user requirements and/or expectations. Although producing high-quality software on schedule is one of the major priorities of Technosource, however, the consequences of faults in the safety critical systems which the company develops can be much more serious and as a result defects are no longer a problem the company feels should be managed, in their own words, they have to be envisaged and removed.

This resolve by Technosource is in line with Wysopal et al (2006), who states that anticipating errors in during software development reduces the potential of a reoccurrence of such faults. At Technosource, quality is beyond delivering error free software the company views its processes and methodologies as an inherent feature that would enable exceeding customer expectations. Quality is a way of life at Technosource covering all processes, interactions and deliverables.

4.1.1 Quality Assurance & Standards

The quality processes at Technosource are benchmarked against international standards like ISO and CMMI. The company is ISO 9001:2000 and ISO 27001:2005 certified and an SEI CMMI level 5 assessed companies. To ensure highest quality solutions to their customers, they work towards predicting and preventing software defects from happening, rather than removing them later. The company’s focus on software quality is therefore to maintain SEI CMMI Level 5 rating throughout the organization.

4.1.2 Quality Control: Software Validation & Verification

According to Bartlett (2005), Verification and Validation is the process of demonstrating that software meets its specification (verification) and meets the real needs of its stakeholders (validation) [7]. The ANSI/IEEE gives a simpler definition which is: ‘the evaluation of software at the end of the software development process to ensure compliance with the user requirements’.

At Technosource, software products are evaluated against their specifications or requirements at each stage of the product’s evolution to ensure that the right product is being built and the product is being built right. The two primary methods used for software product evaluation are peer reviews (for paper-oriented products) and testing (for executable products).

4.1.2.1 Test Team Structure

At Technosource, the virtual teams of software submit their codes to the CVS repository which is then verified. The persons responsible for evaluating a software product are not the persons who developed the product; although the persons who developed the software product may be involved, for example, as participants in a walkthrough of the product before, or as a part of, its inspection.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Software team members prepare records of each software product V&V and the project maintains those records for the life of the project. Software product V&V records include (but are not limited to) inspection and certification records (when the V&V method is inspection) and problem and test reports (when the V&V method is testing).

4.1.2.2 Activities

Peer Review Methods

  • Technical reviews, walkthroughs and software inspections;
  • Checking that software requirements are traceable to user requirements;
  • Checking that design components are traceable to software requirements;
  • Document Reviews

Testing Methods

  • Checking formal proofs and algorithms;
  • Functional (black box) testing
  • Structural (white box) testing
  • Unit testing;
  • Integration testing;
  • System testing;
  • Acceptance testing; 
  • Audits.

4.2 Capacity Management: Chase Planning Strategy

Technosource utilizes the chase planning strategy which is defined by Slack et al (2004) as a scenario where the supply can be changed to meet the fluctuating level of demand. This way demand is met by capacity so waste in resources is avoided and customer demand is met. This plan was adopted as demand for software stays fairly stable all year round in the oil and gas sector. So it makes sense to use this method as the need for staff and other resources must be considered.

Technosource has got a total of 900 employees, of this number 300 are part time programmers and sub-contractors spread across the six continents working at varying hours, although these are paid over-time when the demand is high. However in the long run, the company makes massive savings on overhead and in line with its objective of lean production. Managers are therefore able to control the company’s operations by altering the capacity of the organisation to be even with demand.

4.2.1 Capacity Planning: Data Warehouse Tool

Technosource utilizes a capacity plan that enables the development, implementation, and maintenance of its resources to meet the performance needs of its developers who are the main users of the system. In 2002 due to rapid expansion of its services across Europe, Asia and Africa, the existing infrastructure required re-planning to scale the business to meet anticipated growth. This resulted in a capacity management solution which utilizes data warehouse technology in collecting performance into a centralized data warehouse where it can be viewed by top management.

4.3 Product planning, targeting, segmentation and positioning

With a team of 400 IT programmers geographically distributed around six continents, Technosource is currently a leader in the niche IT systems segment of the oil and gas petroleum industry, and to retain that status the company in 2002 switched to the Direct Business Model in order to collaborate with its customers in oil installations all around the world, especially in the remote parts of Africa, Asia and the Middle-east.

This was achieved by developing the IPQS systems (the first of its kind) a unique digital collaborative platform developed with satellite technology which allows communication between its geographically distributed virtual teams and customers, thus linking the different roles in the software design lifecycle. This rapid sharing of resources between all the stakeholders in any part of the world reduces response time with its customers and to ensure production of software of high quality and functionality.

This line of thinking is in agreement with to Carr (2004) who states that through the creative use of information systems, competitors are able to differentiate themselves with an otherwise undifferentiated product.

4.3.1 Market Segmentation

4.3.1.1 Market Share & Target Market

Segmentation is defined as targeting the needs of one or two groups of people better than trying to appeal to the market as a whole (Brassington and Pettitt, 2003). As at today, almost 80% of the lifecycle and customer support issues are handled through the IPQS system.

Technosource is able to achieve a larger market share in this sector by targeting oil companies located in remote locations in Africa, Asia and the Middle-east who previously would have had to travel long distances and face logistics challenges getting across to IT suppliers. With this solution, using their satellite devices from anywhere in the world they can within minutes communicate with virtual teams as opposed to the co-located teams who are restricted by distance.

4.3.1.2 Justification for Product Segmentation: Convenience

The justification for adopting this approach was based on a post modernist theory in defining their market. This looked at the oil and gas environment which is mainly in remote part of towns and the idea of the software technician communicating with them from any part of the world regarding technical issues would appeal to current and would be clients, and so far that has worked as they have locked in most of their clients in Africa and the middle-east for more than six years.

4.3.2 Benefits: Lean Production

With the direct business model and IPQS system, Technosource is able to cut out the middlemen benefit in many ways. For its off-the-shelf products it will not have to fill traditional sales channels and as a result there would not be products sitting in inventory as it waits for a customer’s order before developing the product, which means it can operate with an extraordinarily lean production system.

In addition, since it gets upfront payment from its customers for a product before it pays its suppliers for the parts that went into it, there is the benefit of negative working capital, and it gets direct information on demand trends, which it can use to always optimize the set of products it offers.

4.3.3 Skill Maximization

  • Clients can now geographically collaborate with the system developers and strategically carry out the traditional mechanisms used to coordinate software development, such as project status, gathering requirements, system-level design, testing, troubleshooting, schedules, and defined processes.
  • For the 400 IT programmers geographically distributed, the information they require is now readily available whenever they need it, delivered in a uniform format and is far more easily accessible than previously, as users are in a position to make decisions more quickly, allowing the entire organisation to become more responsive to market developments.  
  • The solution empowers the organization to track shifts in demand for products and maximize the skill of its workforce. In contrast with work performed in a central location where employees and their performance are directly observed, with the IPQS, supervision is accessed electronically and evaluation is based on targets met, quota, and output by deliverable, achievements, thus identifying significant variances to act upon.

5. Research Findings: Comparison with Referenced Sources

5.1 Input / Output/ Transformation Process: Lifecycle

According to the findings of a recent study by Lytinen (1999), and Cockburn (2000), the lifecycle approach utilized by Technosource Energy, falls short in the new software development environment, as it is unable to keep up with fast-paced, ever-changing software projects. Going through the Standish Group, “CHAOS 2001: A Recipe for success, [29]revealed that from 1999 till date, a total of £3 billion had been lost on failed information systems implementation and further investigation suggested that 70% of the project failures were down to poor management of the requirements and scope of a project [29].

User requirements are often not clear at the start, for a number of reasons: users may be unsure of what they want [29]; it may be difficult to identify their tacit knowledge about day-to-day processes; they may not have been consulted sufficiently; and they may be misunderstood [29].

Arguing in the same line, Mahoney (2000) and Lytinen (1999) in reviewing 100 failed IT projects states that most of the time at software project inception, the customer may have only a general idea of the software requirements, suggesting that determination of the detailed requirements may follow later or may even be part of the ongoing process [25, 28].

Mahoney (2000) therefore suggests that it is imperative for systems / software developers to utilize an IS project methodology that would be flexible to get the end user involved throughout the product’s engineering life cycle [28] recommending a combination of plan and people driven approach, so in that way the more likely the expected product will result successful [25]. This involvement is particularly crucial during the requirements analysis and design activities early in the life cycle [28]. It is also important to try to get end-user involvement at milestone reviews [28].

5.2 Quality Management: Standards vs Culture (PSP, TSP)

Whilst Technosource Energy can be commended for sticking to standards, but Ferguson et al (1997) states that whilst quality can be achieved by defining standards, following good practise and following organizational quality procedures is not always achieved in practise, as there is evidence to suggest that there are intangible aspects to software quality (such as: maintainability, security, readability and efficiency etc) that cannot be embodied in standards.

Ferguson et al (1997) suggests that a good quality culture has been proven to have a better effect than following good standards to the letter. From a survey of sixty US software development companies who ditched bureaucratic standards for quality culture, forty-nine of the companies recorded success and better compliance. Rather than standards, quality managers were appointed with the aim of developing a quality culture where everyone responsible for software product development were committed to achieving a high level of product quality.

On the corporate level, software teams were encouraged to take responsibility for the quality of their work through the team software approach (TSP), and on the personal level, software developers were supported in their drive to plan and track their work and to produce quality products with a process called personal software process approach (PSP) [32].

5.3 Capacity Management: Level vs Chase Strategy

According to Slack et al (2004), where the capacity of the organisation is limited and the focus is on influencing the demand to be in line with the available capacity, this is referred to as level strategy. This way the capacity levels are the same even when demand varies. This capacity management strategy will not support the direct business model adopted by Technosource Energy, as Armistead (1994) states that the chase strategy would suit organizations whose objective is lean production and inventory.

5.4 Direct Business Model: Production vs Support Issues

Direct Business model as utilized by Technosource has given it a huge cost and market advantage. However, Osterwalder (2002) argues that the direct business model is viable in the production side but is far less attractive in the support side. Osterwalder (2002) states that selling and collaborating directly with customers brings to bear the responsibility of all support issues such as handling information request, general enquiries, pre and post implementation issues, and for safety critical software systems that would mean skilled personnel available 24/7.

The cost of handling these can be enormous bearing in mind that the company’s operations are spread all over different continents. Osterwalder (2002) states that with any other business model the support costs are offloaded to the resellers and others on the distribution channel.

Although, Magretta (1998) using the case study of Dell computers, states that companies can get round this by getting economies of scale, outsourcing and automating certain support task. However, for safety critical software support, the labour side of it is required as customers need to talk to skilled personnel in a position to troubleshoot or solve their problems.

Ward & Peppard (2002), states that with the proliferation of competitors, to hold onto the market share an organization will have to slash its prices whilst reinvesting in the company resources and in the context of Technosource, it would mean reinvesting in its support side which might hurt their earnings.

6. Conclusion & Recommendations

In concluding, Technosource Energy UK has successfully utilized the direct business model in providing safety critical software IT services to oil and gas companies around the world. This service has thrived mainly due to the fact that the company recognizes the critical role of both quality management and capacity management in the design, delivery and maintenance of safety critical systems.

Operations management in relation to software safety critical systems would require a rigorous process of demonstrating that software meets its specification and meets the real needs of its stakeholders. Depending on how long the company is able to sustain its competitive advantage, but if it loses its advantage, one possible problem is that the company might be confronted in the near future with slashing its prices in a bid to to hold onto the market share whilst reinvesting in the company resources and in the context of Technosource, it would mean reinvesting in its support side which might hurt their earnings. An alternative to that might be re-considering and changing its direct business model to enable traditional sales channels and resellers bear a bit of the cost.

7. Bibliography & Reference

Gupta, V.P. and Graham, D.J. (1997) A customer driven quality improvement and management project at Diamond offshore Drilling. Project Management Journal 28 (3) p22

Berry, L. Pararsuraman, A. And Zeithaml, V.A. (1994). Improving service quality in America: lessons learned. The Academy of Management Executive. 8(2) pp 32-52

Garvin, D. (1984)What does product quality really mean? Sloan Management Review. 26(1) pp25-43

Kerzner, H (2006) Project Management: A Systems Approach to Planning, Scheduling and Controlling. Ninth Edition. Wiley & Sons, New Jersey, USA. Pages 835-40, 851-860, 870.

Gardiner, P.D. (2005) Project Management: A Strategic Planning Approach Basingstoke: Palgrave Macmillan

Association for Project Management (APM) (2006) apmknowledge: APM Body of Knowledge. 5th ed. APM Publishing, High Wycombe

Bartlett, J. (2005) Right First and Every Time: Managing quality in projects and programmes Hampshire: Project Management Today publications

Cadle, J. And Yeates, D. (2004) Project Management for Information Systems. 4th edn. Harlow: FT Prentice Hall

Rose, K.R. (2005) Project Quality Management: Why, What and How J Ross Publishing Inc.

Cooper, R., Aouad, G., Lee, A. And Wu, S. Process and Product Modelling in Morris, PWG and Pinto, (2004) eds. The Wiley Guide to Managing Projects Hoboken, NJ: John Wiley & Sons, inc.

Davis, A.M., Hickey, A.M and Zweig, A.S. Requirements Management in a Project Management Context in Morris, PWG and Pinto, (2004) eds. The Wiley Guide to Managing Projects Hoboken, NJ: John Wiley & Sons, inc.

IDEF www.idef.com last accessed 03 March 2008

Aggarwal, R. And Rezaee, Z. (1996) Total quality management for bridging the expectations gap in systems development International Journal of Project Management 14 (2) 115-120

Barkley, B.T. and Saylor, J.H. (2001) Customer-Driven Project Management: Building Quality into Project Processes 2nd edn. McGraw-Hill

Boddy, D. And Paton, R. (2004) Responding to competing narratives: lessons for project managers International Journal of Project Management 22 (2004) 225-233

Gardiner, P.D. (2005) Project Management: A Strategic Planning Approach, Hampshire: Palgrave MacMillan

Jiang, J.J., Chen, E. And Klein, G. (2002) The Importance of Building a Foundation for User Involvement in Information System Projects Project Management Journal 33 (1) 20-26

E.Johnson, G. And Scholes, K. (2002) Exploring Corporate Strategy 6th edn.NY: Prentice Hall

Meredith, J.R. and Mantel, S.J. Jr. (2003) Project Management: A Managerial Approach 5th edn. Wiley International Edition

Mitchell, R.K., Agle, B.R. and Wood, D.J (1997) Toward a theory of stakeholder identification and salience: defining the principle of who and what really counts Academy of Management Review 22 (4) 853-888

Olsson, N.O.E. (2005) Management of flexibility in projects Management of flexibility in projects International Journal of Project Management 24 (2006) 66-74

Armistead, Colin G, Clark, Graham. (1994). The ‘coping’ capacity management strategy in services industry International Journal of Service Industry Management. Bradford.Vol.5, Iss. 2; pg. 5, 18 pgs

Slack .N, Michael Lewis, Hilary Bates. (2004). International Journal of Operations & Production Management. Bradford: Vol.24, Iss. 3/4; pg. 372

ISO (2002), ISO/IEC 9126-4: Software engineering – software product quality – Part

4: Quality in Use Metrics, International Standards Organisation.

Cockburn, A. (2000, July/August). Selecting a project’s methodology. IEEE Software, 17(4), 64-71.

Highsmith, J. (1999). Adaptive Software Development. New York: Dorset House Publishing.

Nunes, N., & Cunha, J. (2000). Wisdom: A software engineering method for small software development companies. IEEE Software, 113-119.

Lytinen, K. Robey, D. (1999). Learning Failure in Information Systems

Development: Info Systems J. 9, 85-101

The Standish Group, “CHAOS 2001: A Recipe for success” www.standishgroup.com, 2001.

SLACK, N & CHAMBERS, S & JOHNSTON, R (2001) Operations Management, 3rd Edition, Harlow, Pearson education ltd

BRASSINGTON, F & PETTITT,S (2003) Principles of Marketing, 3rd Edition, Harlow, Pearson Education ltd

Ferguson, Pat, Watts S. Humphrey, Soheil Khajenoori, Susan Macke, and Annette Matvya. (1997) “Introducing the Personal Software Process: Three Industry Case Studies,” IEEE Computer, Vol. 30, No. 5, pp. 24-31.

Rappa M.A. The utility business model and the future of computing services, IBM Systems Journal, Vol 41, No. 1, pp. 32-42.

Osterwalder and Y. Pigneur, (2002). “An e-Business Model Ontology for Modelling e-Business,” Proceedings of the 15th Bled Electronic Commerce Conference, 1–12, Bled, Slovenia.

Magretta .J. (1998). The Power of Virtual Integration: An Interview with Dell Computer’s Michael Dell. Harvard Business Review. Harvard Business School Publishing

John Ward, Peppard (2002). Strategic Planning for Information Systems (3rd edition), Wiley

C. Wysopal, L. Nelson, D. Zovi, E. Dustin. (2006). The Art of Software Security Testing: Identifying Software Security Flaws. Addison Wesley.