Management of Projects in Controlled Environments - Case Study Example

Portfolio Table of Contents Portfolio Summary 9 This portfolio is divided into three sections: Projects in Controlled Environments version 2 (PRINCE2), Project Management Body of Knowledge (PMBOK) and managing a project. All these sections contain different information which is summarised as follows. In the first section, a brief overview of the PRINCE2 project management methodology is presented. This covers the following subtopics related to project management: processes, components and techniques. For the PRINCE2 methodology, it can be seen that a project is seen as being composed of different processes that involve different components. The components are linked to the processes using different techniques. In the second section, a brief comparison of PRINCE2 and PMBOK is presented. This section highlights differences between the two methodologies which are evident in the way aspects such as overall approach, documentation and management of the project are treated in the two methodologies. In the last part of the portfolio, an analysis of an engineering project management is presented. The analysis is based on how software development projects are carried out at Toshiba Software Factory. This is analysed in terms of the following: project initiation, project planning, project execution and project closure. From the analysis, it can be seen that the success of engineering management projects at Toshiba Software Factory are as a result of diverse factors. 9 Part 1 – Overview of PRINCE2 Project Management Methodology 10 PRINCE2 is a project management methodology that is the standard operating practice for both public and private institutions in the United Kingdom (Office of Government Commerce 2002, p. 1). This methodology can be viewed in terms of three key areas: processes, components and techniques. These are described in the sections that follow. 10 Processes 10 Essentially, PRINCE2 methodology can be viewed as a process-based approach to project management. The methodology comprises specific management activities which are supposed to be carried out in the course of a project. Under this methodology, the first process to be undertaken is starting up the project. This process serves the important purpose of ensuring that all the prerequisites for a successful project management, which include design, approach and the risk log, are in place. The second process entails directing the project from the start to its closure. In general, directing a project entails decisions and choices made by the project board throughout its course. Although such decisions cover a broad area of the activities of the project, they can be viewed as covering the following: initiation, scope, overall direction and the closure of the project (Office of Government Commerce 2002, p. 11). 10 The next process under this methodology is initiating the project. This process uses the Project Initiation Document which gives comprehensive details about the specifications of the project. This process is important in that it provides the baseline for the decision making processes required for the entire project to be achieved. The next process is managing stage boundaries which, by producing important documents such as the End Stage Report, Current Stage Plan and Revised Project Plan, enables the project board to make decisions on whether or not to continue with the project. The control processes describe all the monitoring and control activities that will be undertaken by the project manager during the course of the project. Also, another process involved in the management of a project under this methodology is managing project delivery. The objective of this process is to ensure that all products required in the project are created and delivered in time. Team plans, project issues and checkpoint reports are used to ensure that the objectives are achieved. Lastly, the project manager initiates a controlled closure to the project. Although the closure may be at the end or premature, the basic process is that the project manager provides input to the project board so that confirmation is received to the effect that the project may close. Although these processes do not apply to every single project, all projects that are run under this methodology will have the processes applied in one form or another. This also entails the planning process which entails repetitive activities that play an important role in all the other activities. 11 Components 11 Under the PRINCE2 methodology, project management can be seen as involving different components which address key issues in the course of the project. To begin with, a project entails the business case and overall stakeholder analysis. Since this methodology requires that the business viability of a project exists as a control condition, the project manager provides all the information necessary for the social and economic viability of the project to be evaluated. This methodology provides that the business case of the project must show the business need, the customer, and a clear analysis of both realistic and realizable benefits and lastly, both tangible and intangible costs. 12 The organization component of a project aims to structure the roles and responsibilities of all individuals involved in the project. Responsibilities of the project management team as well as the project board are outlined in this component. Additionally, concerning risk management, PRINCE2 defines key moments when anticipated risks may occur in the course of the project and contingency plans are developed to counter them. Another component of managing a project under this methodology is quality in the project environment. This ensures that the objectives of the project are met by using three key parts: planning, control and assurance. Plans and controls provide important information that permits effective decision making to avoid potential problems in the project. 12 Configuration management as a component of project management under this methodology entails tracking all the components of a final product and their versions for release (Hederman, van Heemst & Fredriksz 2010, p. 88). This methodology not only defines the requirements and facilities necessary for the success of this component but also shows how it is related to other components, techniques and processes of managing a project under this methodology. Lastly, the change control component of project management, which is implemented using change control techniques, is used to emphasize the need for controlling different changes that are bound to occur in the course of managing a project. 12 Techniques 13 One of the defining features of PRINCE 2 is that it offers very few techniques of managing a project. By doing this, the methodology leaves the choice of the methodologies to be used to be determined by the users under the influence of special circumstances surrounding the project. There are only three techniques of managing products provided in this methodology. The first one is product-based planning. The essence of this technique is to enable the users to establish standards of quality which the final product of the project should conform to. In addition, since this technique provides a product-based planning that is used at the start of the project, it involves a planning framework that addresses the following: establishing what products are required, determining the order in which the products will be delivered and defining the form and content of each product of the project (Office of Government Commerce 2002, p. 17). As well, PRINCE2 provides techniques necessary to control various changes that are inevitable in the course of managing a project. The change control technique provided in the methodology is applicable for organizations which do not have a change control mechanism in place in the first place. The third technique provided in this methodology is quality review. This technique is used for testing the quality of products that are based on documents. 13 Part 2 – Comparison of PRINCE2 with PMBOK 14 The first difference between PRINCE2 and PMBOK is seen in the way the two methodologies approach the project life cycle and the major processes involved in the process of managing a project (Blokdijk 2008, p. 50). Essentially, PRINCE2 views a project as a life cycle of different processes, components and techniques. A project is presented as being made up of eight primary processes which cover the starting up to the closure of a project. Through many other sub-processes, the project is made up of processes and components that are linked to each other through different techniques. On the other hand, PMBOK presents a project as being made up of distinct function-based knowledge areas. This means that PMBOK does not differentiate between phases and stages of managing a project, as is the case for PRINCE2. 14 Another difference arises in terms of how projects are managed and responsibilities shared among the key personnel. Whereas PRINCE2 recognizes four different levels of management involved in a project, PMBOK recognizes the project manager as the person who is fully in charge of all the affairs of a project. Under PRINCE2 methodology, the management of a project is carried out at four different levels: corporate management, directing a project, managing a project and managing product delivery of the project. On the other hand, PMBOK recognizes the sponsor as one of the stakeholders responsible for provision of financial resources for the project. 14 Another difference between PRINCE2 and PMBOK is evident in the type and number of documentation involved in the process of managing a project under the two approaches. It can be seen that under PRINCE2, a project is managed through a long series of different documents that define the progress of the project at different stages and phases. On the other hand, PMBOK provides for a far less number of documentation in the course of managing the project. 15 Another difference between PRINCE2 and PMBOK is seen in the approach taken towards planning for the project. Under PRINCE2, project planning is undertaken using three basic techniques which include producing a product breakdown structure, writing product descriptions and producing a product flow diagram (Sudhakar 2010, 218). On the other hand, project planning under the PMBOK guide is seen as part of the general management skills necessary in the course of managing a project. Planning is seen as an ongoing effort throughout all the different knowledge areas of the project in order to provide consistency and coherence. 15 The last difference between the two approaches is evident in the approach taken towards the control of the project. Under PRINCE2, control is seen as a technical work that is implemented through work packages. Control is used as a central tool to enable the project produce the required results and meet all the criteria in terms of quality. This is in contrast to PMBOK in which control is discussed under the Project Implementation Management section of the guide (Project Management Institute 2000, p. 47). This means that in PMBOK, control is treated in the same way as planning. 16 In conclusion, although both PRINCE2 and PMBOK are effective methodologies of managing projects, using PRINCE2 presents the users with slight advantages. This is demonstrated not only in the overall approach towards managing a project that is presented in the methodology but also in the level of attention given to issues such as teamwork during project management. 16 Part 3 – Analysis of an Engineering Management Project: Toshiba Software Factory 16 This section contains an analysis of an engineering management project together with its successes, failures and lessons learnt from the project. A case study of software engineering processes at the Toshiba Software Factory in Japan is presented. Established in 1976, the factory produces software product lines for use in domains for electrical power generation (Matsumoto 2012, p. 2). This is analysed in line with the four basic phases that define engineering management projects: project initiation, project planning, project execution and project close. 16 Project initiation 17 Theoretically, project initiation in an engineering management project entails a series of different activities which are carried out at the site of the project. These include: analysing the request for a quote that has been sent in by the customer; a thorough estimate of the scope of the entire project; and defining the project information (PeopleSoft Incorporated 2003, p. 2). Project information entails several aspects of the project such as defining the work breakdown structure, schedules of the tasks to be carried out during the project and the estimated costs associated with the project. 17 For the software engineering at the Toshiba Software Factory, the project initiation phase is carried out through a series of steps. First, the requirements provided by the client are used to find a feasible software solution that can be developed by the factory. This is done using existing domain-based meta-models which are made by applying spiral processes (Matsumoto 2012, p. 17). These models are also used as tools for determining and negotiating for the requirements received from the client. They are also important tools used in doing feasibility studies for the projects. 17 There is also a complex network of work breakdown structure and other features of project information used at the factory. First, there is the Unit Workload Order Sheet (UWOS) which is distributed across all personnel involved in the software development engineering projects carried out in the factory (Matsumoto 2002, p. 8). The UWOS provides information about a set of assembled components which are supposed to be built under the responsibility of a single individual. As such, the document contains the following information: requirements, specifications, standards and constraints in terms of costs and timings. Second, work breakdown structure entails the use of Unit Workload (UW), which is the unit of work assignment that is ascribed to an individual person in the course of the project (Matsumoto 2002, p. 9). Both Unit Workloads and Unit Workload Order Sheets are intricately linked throughout the course of the projects. This relationship is exemplified in the product, through the specifications required, as well as in the processes, which involve the recipe, construction steps and solution steps. 17 Project planning 18 Project planning at the factory also takes place through a complex series of steps, each being linked to another to form a complex network of processes. It begins after an agreement is reached with the client with regard to the quotation. All the financial information as well as the scope, task and schedule of the project are refined at this stage. All these activities precede the development of the project baseline which comes at the end of the planning phase. For the Toshiba Software Factory, project planning is accomplished by developing a Unit Workload network. This is made up of different Unit Workloads that are linked to each other in a hierarchical order using complex communication paths (Matsumoto 2002, p. 11). Apart from fulfilling the basic requirements of assigning resource to tasks, it enables the project to fulfil the requirements of the client of the order by tracing changes in requirement specifications for each Unit Workload in the project. 18 During the execution and control phase for the projects, the factory uses the critical path method, in conjunction with the UW network to increase control and manageability of the entire project. Additionally, different schedules, progresses and critical paths in the project are controlled using Program Evaluation and Review Technique (PERT) charts (Matsumoto 2002, p. 19). These charts are used to visualize all the processes associated with the project. This is so because PERT charts are usually used in large scale projects in which there is need to identify and track a large number of projects (Eisner 2011, p. 100). Also, with regard to review and inspection, the factory uses inspection teams that are organized around each project baseline. All these activities enable the project management team to measure the progress of the project as well as take corrective action when needed. 19 Project closure 19 Lastly, during the closure phase of the project, activities that are related to shipment of the products, asset capitalization and final reporting are carried out (PeopleSoft Incorporated 2003, p. 1). For the Toshiba Software Factory, the following activities are carried out to mark the closure of a software development project. First, visitors from the Reusable Management Team are invited to the factory. Their function is to oversee how reusable components are managed. Second, components that qualify for reusability are extracted from the specifications, design descriptions, codes and processes (Matsumoto 2002, p. 20). Moreover, after analyzing the economic benefit of developing reusable components, closure of the project is done by making a plan for the needs of maintenance and development (Biggerstaff 2000, p. 20). 19 There are several lessons which can be learnt about the engineering management project at the Toshiba software development factory. These lessons arise from the successes and failures of the software development projects run at the company. For instance, the success of the Toshiba Software Factory lies in the way the company manages to balance the competing demands of the four basic concepts that a Software Factory is modelled upon. Theoretically, success in software factories is based on organizing the development processes of the factory as well as the environment around four basic building blocks: software product line development, reusable software assets, contextual guidance and a using a model-driven approach (Lenz & Wienands, 2006 p. 8). Another success is demonstrated in the way the factory successfully uses reuse technology, formalised languages and other associated standards in its software development projects. According to Biggerstaff (2000, p. 21), these factors enable the company to leverage on its productivity and the quality of the codes. 20 References 20 Biggerstaff, T J 2000, ‘An assessment and analysis of software reuse’, in Yovits, M C (ed), Advances in computers, Academic Press, San Diego. 21 Blokdijk, G 2008, Prince2 100 Success Secrets: the Missing Foundation and Practitioner Exam Training, Certification and Project Management Guide, Lulu Publishers, New York. 21 Eisner, H 2011, Essentials of project and system engineering management, John Wiley & Sons, Hoboken. 21 Hederman, B, van Heemst, G V & Fredriksz, H 2010, Project management based on PRINCE2 2009, Van Haren Publishing, Zaltbommel. 21 Lenz, G & Wienands, C 2006, Practical software factories in .NET, Academic Press, San Diego. 21 Matsumoto, Y 2002, ‘Essence of Toshiba Software Factory’, viewed 18 February 2014, 21 Office of Government Commerce 2012, PRINCE2, The Stationery Office, Office of Government Commerce, London. 22 PeopleSoft Incorporated 2003, ‘Enterprise One: Engineering Project Management 8.9 PeopleBook, viewed 18 February 2014, 22 Project Management Institute 2000, A Guide to the Project Management Body of Knowledge: PMBOK Guide, Project Management Institute, Pennsylvania. 22 Sudhakar, G P 2010, Elements of software project management, PHI Learning, New Delhi. 22 Portfolio Summary This portfolio is divided into three sections: Projects in Controlled Environments version 2 (PRINCE2), Project Management Body of Knowledge (PMBOK) and managing a project. All these sections contain different information which is summarised as follows. In the first section, a brief overview of the PRINCE2 project management methodology is presented. This covers the following subtopics related to project management: processes, components and techniques. For the PRINCE2 methodology, it can be seen that a project is seen as being composed of different processes that involve different components. The components are linked to the processes using different techniques. In the second section, a brief comparison of PRINCE2 and PMBOK is presented. This section highlights differences between the two methodologies which are evident in the way aspects such as overall approach, documentation and management of the project are treated in the two methodologies. In the last part of the portfolio, an analysis of an engineering project management is presented. The analysis is based on how software development projects are carried out at Toshiba Software Factory. This is analysed in terms of the following: project initiation, project planning, project execution and project closure. From the analysis, it can be seen that the success of engineering management projects at Toshiba Software Factory are as a result of diverse factors. Part 1 – Overview of PRINCE2 Project Management Methodology PRINCE2 is a project management methodology that is the standard operating practice for both public and private institutions in the United Kingdom (Office of Government Commerce 2002, p. 1). This methodology can be viewed in terms of three key areas: processes, components and techniques. These are described in the sections that follow. Processes Essentially, PRINCE2 methodology can be viewed as a process-based approach to project management. The methodology comprises specific management activities which are supposed to be carried out in the course of a project. Under this methodology, the first process to be undertaken is starting up the project. This process serves the important purpose of ensuring that all the prerequisites for a successful project management, which include design, approach and the risk log, are in place. The second process entails directing the project from the start to its closure. In general, directing a project entails decisions and choices made by the project board throughout its course. Although such decisions cover a broad area of the activities of the project, they can be viewed as covering the following: initiation, scope, overall direction and the closure of the project (Office of Government Commerce 2002, p. 11). The next process under this methodology is initiating the project. This process uses the Project Initiation Document which gives comprehensive details about the specifications of the project. This process is important in that it provides the baseline for the decision making processes required for the entire project to be achieved. The next process is managing stage boundaries which, by producing important documents such as the End Stage Report, Current Stage Plan and Revised Project Plan, enables the project board to make decisions on whether or not to continue with the project. The control processes describe all the monitoring and control activities that will be undertaken by the project manager during the course of the project. Also, another process involved in the management of a project under this methodology is managing project delivery. The objective of this process is to ensure that all products required in the project are created and delivered in time. Team plans, project issues and checkpoint reports are used to ensure that the objectives are achieved. Lastly, the project manager initiates a controlled closure to the project. Although the closure may be at the end or premature, the basic process is that the project manager provides input to the project board so that confirmation is received to the effect that the project may close. Although these processes do not apply to every single project, all projects that are run under this methodology will have the processes applied in one form or another. This also entails the planning process which entails repetitive activities that play an important role in all the other activities. Components Under the PRINCE2 methodology, project management can be seen as involving different components which address key issues in the course of the project. To begin with, a project entails the business case and overall stakeholder analysis. Since this methodology requires that the business viability of a project exists as a control condition, the project manager provides all the information necessary for the social and economic viability of the project to be evaluated. This methodology provides that the business case of the project must show the business need, the customer, and a clear analysis of both realistic and realizable benefits and lastly, both tangible and intangible costs. The organization component of a project aims to structure the roles and responsibilities of all individuals involved in the project. Responsibilities of the project management team as well as the project board are outlined in this component. Additionally, concerning risk management, PRINCE2 defines key moments when anticipated risks may occur in the course of the project and contingency plans are developed to counter them. Another component of managing a project under this methodology is quality in the project environment. This ensures that the objectives of the project are met by using three key parts: planning, control and assurance. Plans and controls provide important information that permits effective decision making to avoid potential problems in the project. Configuration management as a component of project management under this methodology entails tracking all the components of a final product and their versions for release (Hederman, van Heemst & Fredriksz 2010, p. 88). This methodology not only defines the requirements and facilities necessary for the success of this component but also shows how it is related to other components, techniques and processes of managing a project under this methodology. Lastly, the change control component of project management, which is implemented using change control techniques, is used to emphasize the need for controlling different changes that are bound to occur in the course of managing a project. Techniques One of the defining features of PRINCE 2 is that it offers very few techniques of managing a project. By doing this, the methodology leaves the choice of the methodologies to be used to be determined by the users under the influence of special circumstances surrounding the project. There are only three techniques of managing products provided in this methodology. The first one is product-based planning. The essence of this technique is to enable the users to establish standards of quality which the final product of the project should conform to. In addition, since this technique provides a product-based planning that is used at the start of the project, it involves a planning framework that addresses the following: establishing what products are required, determining the order in which the products will be delivered and defining the form and content of each product of the project (Office of Government Commerce 2002, p. 17). As well, PRINCE2 provides techniques necessary to control various changes that are inevitable in the course of managing a project. The change control technique provided in the methodology is applicable for organizations which do not have a change control mechanism in place in the first place. The third technique provided in this methodology is quality review. This technique is used for testing the quality of products that are based on documents. Part 2 – Comparison of PRINCE2 with PMBOK The first difference between PRINCE2 and PMBOK is seen in the way the two methodologies approach the project life cycle and the major processes involved in the process of managing a project (Blokdijk 2008, p. 50). Essentially, PRINCE2 views a project as a life cycle of different processes, components and techniques. A project is presented as being made up of eight primary processes which cover the starting up to the closure of a project. Through many other sub-processes, the project is made up of processes and components that are linked to each other through different techniques. On the other hand, PMBOK presents a project as being made up of distinct function-based knowledge areas. This means that PMBOK does not differentiate between phases and stages of managing a project, as is the case for PRINCE2. Another difference arises in terms of how projects are managed and responsibilities shared among the key personnel. Whereas PRINCE2 recognizes four different levels of management involved in a project, PMBOK recognizes the project manager as the person who is fully in charge of all the affairs of a project. Under PRINCE2 methodology, the management of a project is carried out at four different levels: corporate management, directing a project, managing a project and managing product delivery of the project. On the other hand, PMBOK recognizes the sponsor as one of the stakeholders responsible for provision of financial resources for the project. Another difference between PRINCE2 and PMBOK is evident in the type and number of documentation involved in the process of managing a project under the two approaches. It can be seen that under PRINCE2, a project is managed through a long series of different documents that define the progress of the project at different stages and phases. On the other hand, PMBOK provides for a far less number of documentation in the course of managing the project. Another difference between PRINCE2 and PMBOK is seen in the approach taken towards planning for the project. Under PRINCE2, project planning is undertaken using three basic techniques which include producing a product breakdown structure, writing product descriptions and producing a product flow diagram (Sudhakar 2010, 218). On the other hand, project planning under the PMBOK guide is seen as part of the general management skills necessary in the course of managing a project. Planning is seen as an ongoing effort throughout all the different knowledge areas of the project in order to provide consistency and coherence. The last difference between the two approaches is evident in the approach taken towards the control of the project. Under PRINCE2, control is seen as a technical work that is implemented through work packages. Control is used as a central tool to enable the project produce the required results and meet all the criteria in terms of quality. This is in contrast to PMBOK in which control is discussed under the Project Implementation Management section of the guide (Project Management Institute 2000, p. 47). This means that in PMBOK, control is treated in the same way as planning. In conclusion, although both PRINCE2 and PMBOK are effective methodologies of managing projects, using PRINCE2 presents the users with slight advantages. This is demonstrated not only in the overall approach towards managing a project that is presented in the methodology but also in the level of attention given to issues such as teamwork during project management. Part 3 – Analysis of an Engineering Management Project: Toshiba Software Factory This section contains an analysis of an engineering management project together with its successes, failures and lessons learnt from the project. A case study of software engineering processes at the Toshiba Software Factory in Japan is presented. Established in 1976, the factory produces software product lines for use in domains for electrical power generation (Matsumoto 2012, p. 2). This is analysed in line with the four basic phases that define engineering management projects: project initiation, project planning, project execution and project close. Project initiation Theoretically, project initiation in an engineering management project entails a series of different activities which are carried out at the site of the project. These include: analysing the request for a quote that has been sent in by the customer; a thorough estimate of the scope of the entire project; and defining the project information (PeopleSoft Incorporated 2003, p. 2). Project information entails several aspects of the project such as defining the work breakdown structure, schedules of the tasks to be carried out during the project and the estimated costs associated with the project. For the software engineering at the Toshiba Software Factory, the project initiation phase is carried out through a series of steps. First, the requirements provided by the client are used to find a feasible software solution that can be developed by the factory. This is done using existing domain-based meta-models which are made by applying spiral processes (Matsumoto 2012, p. 17). These models are also used as tools for determining and negotiating for the requirements received from the client. They are also important tools used in doing feasibility studies for the projects. There is also a complex network of work breakdown structure and other features of project information used at the factory. First, there is the Unit Workload Order Sheet (UWOS) which is distributed across all personnel involved in the software development engineering projects carried out in the factory (Matsumoto 2002, p. 8). The UWOS provides information about a set of assembled components which are supposed to be built under the responsibility of a single individual. As such, the document contains the following information: requirements, specifications, standards and constraints in terms of costs and timings. Second, work breakdown structure entails the use of Unit Workload (UW), which is the unit of work assignment that is ascribed to an individual person in the course of the project (Matsumoto 2002, p. 9). Both Unit Workloads and Unit Workload Order Sheets are intricately linked throughout the course of the projects. This relationship is exemplified in the product, through the specifications required, as well as in the processes, which involve the recipe, construction steps and solution steps. Project planning Project planning at the factory also takes place through a complex series of steps, each being linked to another to form a complex network of processes. It begins after an agreement is reached with the client with regard to the quotation. All the financial information as well as the scope, task and schedule of the project are refined at this stage. All these activities precede the development of the project baseline which comes at the end of the planning phase. For the Toshiba Software Factory, project planning is accomplished by developing a Unit Workload network. This is made up of different Unit Workloads that are linked to each other in a hierarchical order using complex communication paths (Matsumoto 2002, p. 11). Apart from fulfilling the basic requirements of assigning resource to tasks, it enables the project to fulfil the requirements of the client of the order by tracing changes in requirement specifications for each Unit Workload in the project. During the execution and control phase for the projects, the factory uses the critical path method, in conjunction with the UW network to increase control and manageability of the entire project. Additionally, different schedules, progresses and critical paths in the project are controlled using Program Evaluation and Review Technique (PERT) charts (Matsumoto 2002, p. 19). These charts are used to visualize all the processes associated with the project. This is so because PERT charts are usually used in large scale projects in which there is need to identify and track a large number of projects (Eisner 2011, p. 100). Also, with regard to review and inspection, the factory uses inspection teams that are organized around each project baseline. All these activities enable the project management team to measure the progress of the project as well as take corrective action when needed. Project closure Lastly, during the closure phase of the project, activities that are related to shipment of the products, asset capitalization and final reporting are carried out (PeopleSoft Incorporated 2003, p. 1). For the Toshiba Software Factory, the following activities are carried out to mark the closure of a software development project. First, visitors from the Reusable Management Team are invited to the factory. Their function is to oversee how reusable components are managed. Second, components that qualify for reusability are extracted from the specifications, design descriptions, codes and processes (Matsumoto 2002, p. 20). Moreover, after analyzing the economic benefit of developing reusable components, closure of the project is done by making a plan for the needs of maintenance and development (Biggerstaff 2000, p. 20). There are several lessons which can be learnt about the engineering management project at the Toshiba software development factory. These lessons arise from the successes and failures of the software development projects run at the company. For instance, the success of the Toshiba Software Factory lies in the way the company manages to balance the competing demands of the four basic concepts that a Software Factory is modelled upon. Theoretically, success in software factories is based on organizing the development processes of the factory as well as the environment around four basic building blocks: software product line development, reusable software assets, contextual guidance and a using a model-driven approach (Lenz & Wienands, 2006 p. 8). Another success is demonstrated in the way the factory successfully uses reuse technology, formalised languages and other associated standards in its software development projects. According to Biggerstaff (2000, p. 21), these factors enable the company to leverage on its productivity and the quality of the codes. References Biggerstaff, T J 2000, ‘An assessment and analysis of software reuse’, in Yovits, M C (ed), Advances in computers, Academic Press, San Diego. Blokdijk, G 2008, Prince2 100 Success Secrets: the Missing Foundation and Practitioner Exam Training, Certification and Project Management Guide, Lulu Publishers, New York. Eisner, H 2011, Essentials of project and system engineering management, John Wiley & Sons, Hoboken. Hederman, B, van Heemst, G V & Fredriksz, H 2010, Project management based on PRINCE2 2009, Van Haren Publishing, Zaltbommel. Lenz, G & Wienands, C 2006, Practical software factories in .NET, Academic Press, San Diego. Matsumoto, Y 2002, ‘Essence of Toshiba Software Factory’, viewed 18 February 2014, Office of Government Commerce 2012, PRINCE2, The Stationery Office, Office of Government Commerce, London. PeopleSoft Incorporated 2003, ‘Enterprise One: Engineering Project Management 8.9 PeopleBook, viewed 18 February 2014, Project Management Institute 2000, A Guide to the Project Management Body of Knowledge: PMBOK Guide, Project Management Institute, Pennsylvania. Sudhakar, G P 2010, Elements of software project management, PHI Learning, New Delhi. Read More