Best Practices of Software Engineering Firms and their Progression across the Levels of Project Management Maturity Models Affiliation

Contents
Abstract 2
1. Introduction 5
2. Research Aim 6
3. Research Method 6
4. Project Management 7
5. Project Management Maturity Model and Best Practices 7
6. The Capability Maturity Model Integration (CMMI) 25
7. Knowledge Areas 30
8. Case Study 1: IBM 36
9. Case Study 2: Hewlett-Packard Development Company 38
10. Case Study 3: Microsoft, Inc. 41
11. Summary and Conclusion 45
12. Recommendations 51
13. References 52
Abstract
As the world market becomes more open to different businesses, many new and old existing business organizations are expanding. As a result the creation of new software to accommodate their expansion needs is becoming more and more in demand. As such, the selection of the most competitive software company is of primacy to expanding firms. In order to become a competitive software engineering company, a business must make its project management as efficient as possible. There are tools that can help software companies achieve their optimum efficiency – they are called maturity models. In this research, different maturity models such as the Project Management Process Maturity (PM)2 Model, Capability Maturity Model Integration (CMMI), and the Portfolio, Programme, Project Management Maturity Model (P3M3). The best practices of three highly competitive international companies, Hewlett-Packard Development Company, IBM, and Microsoft, Inc., were researched in order to serve as basis for what kind of best practices must starting companies and those which are at the lower levels of the aforementioned maturity models should do in order to progress to higher levels of maturity. A systematic literature review was conducted in order to accomplish such aim. Research results showed that in order for software engineering companies to progress and even reach the highest level of maturity it should be able to accomplish the following best practices: use of live codes during the determination of business requirement for the software being developed, so that the client and software engineering business representatives can better have an idea of the requirements use of project definition documents in the determination of software business requirements during the planning stage extensive software development life-cycle that documentation identify symptoms of problematic software development: poor software quality unacceptable software performance software that is hard to maintain or extend inaccurate understanding of end user needs inability to deal with changing requirements late discovery of serious project flaws identify the root causes of the problems: ambiguous communication overwhelming complexity insufficient testing insufficient requirements management undetected inconsistencies among requirements, designs and implementations and brittle architecture project managers must implement the following: develop iteratively manage requirements use component architecture model software visually verify quality and control change use of previous documents such as work plans as basis for future documents proactive role of human resources department to make sure that each member of the business organization is well trained and disciplined creation of metrics to monitor project activities and efficiencies both quantitatively and qualitatively identify risk upfront and manage them as they come have a delineated and clearly defined roles and responsibilities as well as management process project managers should guard against scope creeps in managing issues categorize them based on their urgencies engage in work specialization but make sure that employees develop professionally o different fields of expertise associated with software development allow innovation and controlled risk taking protect the brand your customers trust know your business and support it with secure solutions understand the technology of the software ensure compliance to governance, regulations, and privacy know the basic tenets of software security ensure the protection of sensitive information design software with secure features develop software with secure features deploy software with secure features and educate yourself and others on how to build secure software plan the work by utilizing a project definition document create a planning horizon define project management procedures up front look for other warning signs ensure that the sponsor approves scope-change requests guard against scope creep identify risks up front continue to assess potential risks throughout the project and resolve issues as quickly as possible establish a business organizational culture that fosters privacy, and security and invest on appropriate technology to foster security and efficient software development. It was concluded in the research that for software engineering firms must be efficient in managing their people, technology, and protocols.
1. Introduction
Today`s business environment is characterized by projects which are becoming the essential or fundamental components of the each company`s business operation. As such, project management has, in the 21[st] century, became the subject of much researchers on their studies. Grant and Pennypacker (2006: 23) reported on their study that the past ten years since 2006 has witnessed how business organizations put much focus on employing project management in order to maintain or have a competitive advantage over their rivals. They have also noted in their research, that such efforts do not always meet the results expected, in other words, some companies loose the competition. They have then suggested the incorporation of the Project Management Maturity Models, in the employment of project management among companies in order to increase the probability of such efforts. They have further explained that when maturity models are considered in the employment of project management, then such models can be sources of different approaches to continuously improve the business organization on diverse areas (Millosevic, Martinelli and Wadell, 2007: 123). Duffy (2001: 21) noted in his study that the application or use of maturity models is essential to strategy development as well as in the formulation of responses to the different changes in the business environment. He further explained that the usefulness of maturity models depend on their uses as positioning and analysis tools.
The stability and competitiveness of a particular business, such as those involved in software engineering, greatly depend on its efficiency in implementing its business process. Each project needs to be managed efficiently. By efficient we mean, that the aims or goals of the projects are met, at the highest quality at the shortest time possible. In order to accomplish such, project companies aim for the maturity of their business process. There are guiding principles in accomplishing such level of maturity, and these principles are described on project maturity models. Using project maturity models, a company may opt to determine its best practices, document them, and then implement them in its future business process. Nevertheless, it should be pointed out that there are different levels of maturity a business organization may start from the lowest level up to the highest in order to reach its goals.
2. Research Aim
This research aims to identify the best practices which would allow different software companies to progress across the different levels of the Project Management Maturity Model, particularly the most current models such as the P3M3 and the CMMI.
3. Research Method
This research will used secondary information from past related literatures by conducting a systematic literature review of the most current studies. The time line for the related studies to be used in this study is from the year 2000 up to the present, in other words, all researchers performed at the 21[st] century. The reason behind these exclusion criteria was used to add to the reliability and validity of the acquired information. Note that software development is continuously changing and improving and hence it is essential to identify the most current studies in order to capture such changes (Whitten, Bentley and Dittman, 2003: n.d.).
4. Project Management
The ability of project managers to effectively manage their respective projects determine the level of maturity of each business organization. In order to understand more fully the level of maturity for project management, it is essential to have a clear understanding of the definition of the term, “project management.” The Office of the Government Commerce (OGC) has provided a definition for the term. Note the OCG is one of the many departments of the United Kingdom government assigned to help different public sector organizations improve their overall efficiencies. Nevertheless, the process of improvement proposed by the said department can also be adapted by different non-government organizations such as business organizations, particularly those under the software industry. Accordingly, the OGC defines project management as the planning, control, and monitoring of all the aspects of a project as well as in the motivation of everything involved in it. Such planning, monitoring, and control are implemented in order to achieve the project objectives at a specified cost, performance, and quality (United Nations Development Programme, 2013: 1). What this simply means is that project management involves the creation and improvement of protocols, the creation of metrics to estimate project success and failures, and the development of business organizational ethics to support the entire project management process (Project Management Solutions Inc. 2012: 1).
5. Project Management Maturity Model and Best Practices
Before delving deeper into the discussion on how “Project Management Maturity Models” can be useful in increasing the level of maturity and, hence, the competitiveness of Software Engineering Industries it is first essential to understand what this tool is. Accordingly, concept of Project Management Maturity Models was first conceived sometime between 1986 to 1993at the Carnegie Mellon University, United States of America, USA (Paulk, Curtis and Chirssis, 1993: n.d.). Numerous researchers have since then drew out different Project Management Maturity Models from the concept hence the proliferation of numerous maturity models since 1993 up to the present. Each model has their respective strengths and limitations (pmforum.org, 2008). All maturity models focus on total quality management. What this means is that each of the models focus on the different business organizations` current position in the market, as well as the aims of such organizations in the future. In other words, maturity models help organizations mature from their current level to the next level of maturity (Cooke-Davies, 2002: 3). The business organizations` commitment to do the necessary changes in its current business process in order to mature to the level is of high importance if the maturity models are to be of great use. As such, the changes should be well understood and supported by the business organizations` senior managements, which includes the managerial and the executive level. Since the changes will be different for different companies – due to their differences in the product or services produced – then one maturity model may not be sufficient to facilitate all the changes, hence the need for diverse kinds of project management maturity models. It is therefore crucial to identify the correct or proper maturity model which will be used by a certain company (Brookes and Clark, 2009: 7 – 8).
Brookes and Clark (2009: 9) explained that there are three disparities among the many maturity models. These disparities include their definition of the “maturity” construct, the different project management knowledge they encompass, and their scope. Nevertheless, despite these differences, all maturity models identify a starting point of maturity, and an end point – the pinnacle of maturity – and that each business organization should be able or should aim for the pinnacle. Anderson and Jessen (2003: 458) has defined “mature” or the “highest level of maturity” as the state of maximum or full natural development. According to Brookes and Clark (2009: 3) this definition is the only feature that is common to all existing maturity models from 1993 up to 2009. The project monitoring and control context revolves around the task of comparing what is happening to what is due to happen. Note further, that it is not only the actual creation of the software that should be monitored but also the different aspects of the project, which includes: monitoring of the project planning parameters, monitoring of the project risks, monitoring of the stakeholder involvement, conducting milestone reviews, monitoring of commitments, monitoring of data management, and monitoring of progress reviews. In line or simultaneous with the monitoring and controlling initiatives is the managing of corrective actions until the closure of the project. Accordingly, identified issues should be analyzed. After analyzing the issues solutions and corrective actions should be done, which will also require the management of corrective actions (Archer and Ghasemzadeh, 2004: 243).
As pointed out on the previous discussions, in order for an organization to become “mature” it should undergo a series of changes to progress from one level to another (Kwak and Williams, 2002). Anderson and Jessen (2003: 459 – 461) proposed the following levels of maturity: Performed, Managed, Defined, Quantitatively Managed, and Optimizing. In the lowest level, which is termed, “Performed” the business organization has an unpredictable process, or that their process if poorly controlled and is highly reactive. Highly reactive means that there is no existing protocol on how to go about resolving a certain issue. For example, in software engineering, a software industry under the “performed” level would have no limit to its “if – else” branches in encoding the program, it also does not have a protocol for resolving issues. In such cases the software engineer or anyone in the group can think of a solution to a certain issue encountered, and is free to implement it (Artto, 2009: 11). The “performed” stage is similar to the brain storming stage of a problem solving process, where anybody and anything can be spawned out to solve a certain issue. After the “performed” level is the “managed” level. In this level the business organization has a defined process, but it is still often reactive. There reasons for this reactiveness despite the existence of a defined process, one is that the defined process does not fully capture all the scenarios that could take place for the business organization. In other words, the organization still lacks some experience to anticipate all the possible scenarios, challenges, or issues which they might encounter. It may also be associated with the culture of the business organization. A business organization which is just transitioning from “performed” will most likely revert back to it, instead of abiding by the new created managed business process. The next level is “defined.” At this level the business organization has a well-defined business process and its members are proactive in carrying out the said business process. The next level is called “Quantitatively Managed.” At this level the business organization monitors the implementation of the business process quantitatively. Note that the purpose of monitoring is to understand the project`s progress with the aim of making necessary corrective measures when something deviates from what was planned (Zemel, 2009: 23). Moreover, aside from being measured, the process is also being controlled. Lastly, the highest level is called “optimizing.” At this level, all the information to further improve or optimize the business process are taken into account, and necessary changes are done. These levels of maturity are in accordance with the Carnegie Mellon maturity model. It should be noted that this maturity model has five levels, and the majority of the other maturity models uses the same number of levels, but with different definitions or descriptions (Gray and Larson, 2007: 273). The use of five level has also received a general acceptance among researchers and business organizations since 1993 and onwards. An example of the most current maturity models are the Project Management Process Maturity (PM)[2] Model, the Portfolio, Programme, Project management Matudirty Model or P3M3, and the Capability Maturity Model (CMMI) model.
Although still being used at present, the Project Management Process Maturity (PM)[2] Model is a little older than the other two maturity models, nevertheless the principles included in it are the bases for other models so it is worth discussing it here. The (PM)[2] model is a tool for identifying and measuring different project management levels. The model is composed of nine PM knowledge areas and each the process areas have five project processes under a quantified schema. The model is well suited to asses a particular organization`s project management level as well as its process maturity. Moreover the model provides a disciplined and orderly process to achieve higher levels of PM maturity. The model, however, should be continuously refined to reflect the new advances in the knowledge in project management. Hence, the model has been refined by numerous researchers into what it is today. The said model is applicable to different industries even the IT and software industry. The model was inspired quality management theories. The five incremental stages were introduced into the model to as early as the late 1970s. This schema is adapted by numerous maturity models such as the P3M3 and the CMMI.
Portfolio, Programme, Project management Matudirty Model or P3M3 is one of the most modern maturity models that is extensively used at present. P3M3 describes and defines the portfolio, programme, and project-related processes and activities done within the business process areas that are highly contributing to achieving success on projects (Sauer and Reich, 2009: 188). There are different levels defined and described by the P3M3 (Jamieson and Morris, 2007: 58). Each of these levels shows how key process areas must be structured in a hierarchical order so that they define a progression capability. This progression capability can then be used by a business organization in setting their goals or strategies, as well as I planning their journey for improvement. The different levels also help business organizations transition from one immature or lower maturity level to a higher maturity level with an objective basis for monitoring and judging quality as well as solving project and programme issues. Just like the previous maturity models, P3M3 also considers the different project management activities that need to be carried out at the individual, team, and organizational levels (Tichy and Bascom, 2008: 31). P3M3 uses a five level maturity schema, namely: Initial process (Level 1), Repeatable Process (Level 2), Defined Process (Level 3), Managed Process (Level 4), and Optimized Process (Level 5) (Young, Young and Zapata, 2011: 1 – 24). At level 1, the business organization runs projects informally having no standard process or even metrics which they may use for tracking success. At level 2, the business organization assures that each project has its own set of activities, rules, and procedures, but the projects may have limited consistency or even coordination. At level 3 the business organization has its own centrally controlled programme or project process. It can also adjust its individual programmes or projects within this centralized control process in order to meet the objectives of the projects or programmes. At level 4 a business organization begins to obtain quantitative information on project performance. It can also perform Quality Management in order to make predictions of future performance. At level 5, which is the highest maturity level according to the P3M3, the business organization performs a continuous process improvement, accompanied by proactive problem and technology management initiatives. Note that technology plays a very important role in the P3M3 model. Accordingly, technologies can be used to reinforce proper project management. For example, it required that certain level of privacy be implemented for a particular project. Accordingly, if the client (the future owner of the software being created) does not want to divulge any of its information to any people even the lower ranking software engineers who are working on the codes or on testing and fixing bugs, then the business organization can do so by using restrictions on information access about the project. Example of such is the use of passwords on computers used in the project, as well as the use of monitoring devices and software (Lycett, Rassau and Danson, 2004: 289 – 293).
Another maturity model which is extensively used by different software engineering firms is the Capability Maturity Model (CMMI) (Zemel, 2004: 2). The CMMI is specially created for software development hence, it is necessary to understand the software development process or the software development life-cycle (SDLC) (Dache, 2004: 1). SDLC is a structure used to develop a software product, and is usually considered as one of the subsets of the systems development life-cycle. There are diverse models describing the software life-cycle but there are general steps included on most of these life-cycle models. Example of such models include the ISO/IEC 12207 and the Spiral Life-Cycle Model. Each of these models have the life-cycle stages, which are heretofore discussed (McConnelll, 2004: 140). There are numerous models that describe the software development life-cycle and one of the most common and widey used model is the Waterfall Model. The waterfall model divides the software development life-cycle into six stages: requirements specification or requirements analysis, software design, implementation and integration, testing or validation, deployment or installation, and maintenance. All these stages are interrelated and may be performed more than ones throughout the software development life-cycle. Nevertheless, in a strict waterfall Model, each stage proceeds after the previous one is finished starting from the requirements analysis up to the maintenance stage. Reviews may be performed after every stage before proceeding to the next stage – such initiative may involve the formal change in control process (Jugdev and Thomas, 2002: 11). The conducted reviews are also be used to make sure that the stage is indeed finished or complete. Note that the stages are also known as phases. For each phase to be considered complete it must meet certain completion criteria which are termed “gates”. Each gate must be satisfied first before moving on to the next phase. In the pure or strict Waterfall Model, revisiting any of the previous stages is not allowed, but today such change in the model is already performed, allowing software engineers to revisit finished phases when some bugs are identified and are not easily fixed. There are many best practices in going about performing the different stages of the software development life-cycle, which are discussed henceforth (Kwak and Ibbs, 2002).
The first stage in the software development life-cycle is the planning stage. At this stage the objectives of each activity involved in the development of a particular software product are defined. It is in this stage that the requirements and the requirements analysis for the software product are defined. Also, during this stage the client or customer present their abstract ideas regarding what they want or need for their business. In other words, there is not yet much detail as to the specifications of the software product being developed. At this point, the role of software engineers is to identify the ambiguous, incomplete, or the contradictory requirements mentioned by the client. A best practice at this stage is the use of live codes so that the client and software engineering business representatives can better have an idea of the requirements (Ralph and Wand, 2009: 234). The Tech Republic (2001: 1 – 2), has emphasized the importance of the planning stage in software development life-cycle. Accordingly, incorrect planning can lead to complete failure in meeting the project objectives. Tech Republic, hence, advised the use of the best practice of using project definition documents. The project definition document must contain the following information: the project overview, objectives, scope, assumptions and risks, approach, organization, and initial cost, effort and duration estimates. Under the project overview, the software engineers and other representatives of the project team answers why the “exchange migration” needs to take place, that is, what are the drivers and benefits the software can bring to the client`s business as well as to the software engineering firm. For the objectives, the team must indicate the goals of the project team as well as the goals of the client. Under scope, the people and the department involves are taken down into writing, as well as their respective roles and expected benefits from the project. It is also under this requirement that the scope of the project is defined, what are features that are needed to be developed in the software and which features need not be included. Under scope, the means of communications between clients and the business organization are set, including the contact persons on both sides. For Assumptions and risks, the events that are to be taken for granted as well as the events that are of concern as listed down and analyzed for their possible impacts on the software development life-cycle (Goldenson and Gibson, 2003: 131). It is also here that the capacity of the team is assessed in accordance to the requirements of the client – the network capacity as to whether it is sufficient for the planned software is an example of assessment performed at this stage. Under approach, how the project migration will proceed and unfold is assessed. For organization, the different business organization members which will be directly and indirectly be involved in the software development project are identified (Lovallo and Kahneman, 2003: 291). Here the project manager is identified, as well as the sponsors. It is in this stage that communications with, and the support of the business organization`s executives are highly important (Gray and Larson, 2008: n.d). Other stake holders, which may not be part of the business organization are also selected and evaluated during this stage. The signature page will then be created wherein all the stakeholders are to sign showing their consent or agreement to plan. Note that this may be the most important part of the document, as their signatures are attestations of everything that is to be done in the software development life-cycle. A document whose stakeholders did not sign is useless on disputes hence a project team should strive hard to get all the signatures down into the document`s signature page. Another important part of the definition document is the initial effort, cost, and duration estimates. This part of the document is usually the basis of stakeholders for signing the document, particularly among sponsors. Estimates should not be too conservative neither liberal, they should be close to the real cost, efforts needed, and project duration, and can only be so with the aid of experienced software engineers (Cooke-Davies and Arzymanow, 2006).
After meeting with clients the software engineers gather all the general requirements from the client, analyze the scope of the development and clearly and state it. A document which shows the scope is created for this purpose, and it is called the scope document. Note that there are times that there are functionalities that are not part of the scope, which are asked later by the client to be incorporated. The scope document is highly important in such cases, especially when the client files a dispute when the additional specs or functionalities were not added. Hence, I can be deduced from this particular stage of the software development life-cycle that documentation is a best practice which business organization must implement. At the end of the day, when disputes between clients and software engineering firms are filed, the documents will be of great weight (McConell, 2004: 140). Software engineering firms may also create a standard in coding, such the standard number of loops or if-else functions in the code. Such standardized coding can help the identification of bugs as well as in fixing them (Tech Republic, 2001: 3). Note that aside from the project definition, the Tech Republic (2001: 2) also emphasized the creation of a work plan. The work plan must be created I accordance with the project definition. The work plan should reflect the step-by-step instructions for the construction of the different project milestones or deliverables. Note that clients usually demand milestones deliverable in order to make sure that their orders are being done in accordance to the agreed upon schedule and quality. The work plan also contains instructions on how to manage the project. As a best practice in the creation of work plans, previous work plans should be used as models for creating new ones. Note that the previous work plan should be similar to the current migration effort. If previous work plan is not available, an old-fashioned one can be created from the work-breakdown structure and network diagram (Hewlett-Packard Development Company, 2012: 7). The work plan should be as detailed as possible. Such details that should be included in it are the resources and the estimates of the work – this part of the work plan is often called the planning horizon. The work plan is changed continuously from the onset of the project up to the end of the software development life-cycle, especially when there are changes that need to be made (Fisher, 2001: 1). There are certain levels of uncertainty at the beginning of the project, but these uncertainties become clearer in the work plan as the work progresses. Such uncertainties include the project duration and cost (Raymond and Young, 2001: 34). Still under the planning stage is the creation of project management procedures. The project management procedure provides an outline of the resources which will be utilized to the efficiently manage the project in view of the project definition. This document shall contain information on how to manage issues, risk, scope change, quality, communication, etc. Note that it is of high importance to manage the project rigorously as well as proactively. It is also necessary to ensure that the team and all the stake holders of the software being created have a mutual and common understanding on how the project management will proceed. This is where the different software engineering firms at different levels of maturity differs. Creating the project managemet procedure is fairly easy for firms which already have existing common procedures, because they can utilize this. Those who do not have common procedures, however, will have to start from scratch with high uncertainty as to the effectiveness of the management process which they will be creating. After the document has been created, actual management and control can be carried out. Note however, that despite the fact that the three essential documents have been created: the project definition, work plan, and the project management procedure, the conduct of the project may not run as smooth as expected, due to the fact that each project is fairly distinct to another. What this means that even though the three documents are well prepared, there as some aspects of the software development life-cycle which will not proceed as expected. In such scenario, the real challenge for project teams is have the discipline and rigor needed to become efficient in applying project management skills proactively and correctly. Hence, one of the best practices for business organization is for its human resources department that its employees are well trained and disciplined. And such effort starts in the recruitment phase, when employees are selected from numerous applicants. Another aspect of project management which needs careful attention is the managing of the work plan. Accordingly, the work plan should be reviewed regularly in order to determine the progress of the project in terms of the budget and schedule. Monitoring the work plan schedule my need the use charts and tables. It a common practice among companies to compare the actual cost and estimated cost on figures in order to correctly evaluate the work plan in terms of the budget. Aside from such monitoring initiatives which require the gathering of quantitative data (time, and cost), best practices in project management also involves the monitoring of qualitative indicators of project success. Accordingly, there are some indicators of success that are based on the morale and fulfillment of project team members, and these bases should be taken into consideration in project management. The project manager should always check on the morale of each team member especially when there is an issue being resolved. There are also times when expected outputs are not being met, reports that are inaccurate of what is happening in actuality, such as deliverables that appear to have been delivered or migrated but in reality are still not, or small backlogs on project schedules. The deterioration of project deliverables as the project progresses is also something the managers should look into and assess. When such things happen, it is a best practice to use risk management, and then create a plan which will proactively ensure that the project stays on track. An issue may also be raised to superiors when such issues are hard to resolve at the team level (Josler and Burger, 2005: 1 – 30).
Managing the scope is another effort that needs to be handled correctly if the project gals are to be attained efficiently. Just like schedule management, scope management determines whether the project will stay or stray from track. Managing scope is especially important when there is a change in scope facilitated from the client`s side. In other words, the client requires some deliverables which are not part of the original agreement on the project definition and business requirement. In such case, despite having an excellent scope change management process, it is still essential to understand the concept of scope creep, as well as understanding the customer. Accordingly, during scope change, it is essential to communicate with the project sponsor or the person or party funding the project. Note that project sponsors may be a single or organization, many organizations, an individual or group of individuals. When any of the stake holders, particularly from the client`s side a change in scope request, no-other stakeholder can give a go signal or authorize the implementation of the change in scope other than the sponsor. Such process annihilates the possibility of misunderstanding among stake holders. It also facilitates the ordered flow of the software development life-cycle. Hence it can be deduced from this particular scenario that one of the best practices for project management maturity is to have a delineated and clearly defined roles and responsibilities as well as management process. Note that such roles and responsibilities should be known by all of the stakeholders of project so as to manage their expectations. As pointed out previously, efficient project management guards against scope creeps (Hayes, 2007: n.d.). According to the Tech Republic (2004: 8), while it is common that project managers have the necessary skills in invoking scope change management procedures whenever there is a functionality which needs to added to the existing scope, very few recognize the impact of multiple minor scope change which get added together overtime. There are some instances when a stakeholder request for minor changes over time, since these are only small changes in the scope, if considered individually, then project managers are tempted to simply allow them. An efficient project manager however carefully weighs each minor scope change. The accumulation of minor changes is termed scope creep, and is to be avoided in proper project management. As one of the best practices in project management, project managers should guard against scope creeps (Hewlett-Packard Development Company, 2012: 4).
As part of the planning stage is the creation of risk management plan. Risk management pertains to the proper handling and management of circumstances which are outside of the project team`s control and may pose adverse effect to the software development life-cycle. The best practice for managing risks is to identify them at front. What this means is that considerable time and effort should be allotted to identify potential risks as well as the possible contingency plans when they occur. In order to this effectively, the project management, after identifying all the possible risk must also identify the probability that each risk might occur, as well as the probable impact of each risk to the software development life-cycle. Some companies such the IBM and Accenture, Inc. – both are successful international companies and both are engage in software development – categorize the different risks according to the perceived severity of effects to the software development life cycle. Such categorization includes the categories: low- level risks, medium-level risks, and high-level risks. It should not be construed, however, that risk assessment and the identification of possible risk should only be done prior to the start of the software development. In fact risks may arise in the middle of the software development life-cycle. Hence, risk management and risk assessment should be done continuously throughout the software development life-cycle (Tech Republic, 2001: 9). The last phase of the planning stage is the creation of plan to manage issues. Issues management pertains to the management of risks which pose big problem not only in the team but to the entire business organization and the stakeholders as well. An example of an issue is that the newly purchased exchange servers which will be used in the migration process are not configured and are not ready on time. Such will result to delay in project schedule, budget, and quality of the deliverables. A best practice in managing issues is by categorizing them based from their urgencies. The highly urgent issues needs to be resolved first while those which are not as urgent may be resolved by themselves as the software development progresses (Fairley, 2004: 57 – 58).
The second stage is Implementation, testing, and documenting. At this stage, the actual code is made by the software engineers. After which software testing is done to check if the code meets the functionalities indicated in the scope document. It is also at this stage where identified and fixed. Simultaneous with the testing process is the documentation process. During documentation everything from the design of the software, to the testing, to the fix, and to the implementation are documented. The document produced is then used for future maintenance and enhancement which may be necessary in accordance with the warranty stated in the contract made between the software engineering firm and the client (Ralph and Wand, 2009: 233). Note that despite the fact that almost all software engineering firms implement these three processes within the second stage, their manner of implementation varies. A firm, for example, may use the same human resources for the coding, testing, and fixing processes, while other firms may use different human resources. In other words, firms may implement specialization in tasks among its employees. It may even form new departments within a project team, or make departments or divisions within its organization structure to perform such specialized task. While it is a proven fact that specialization of task produces faster and higher quality od results, it may also create some unwanted disturbance within the business organization. Note that each member of the organization has his or her own sets of personal goal. When the personal goals are not met due to the specialization, the personal fulfillment of the respective employees turn low and their work satisfaction is not achieved. In such cases, the software firm may lose some of its members, and may even lose some of its best people and talents. This is an example where the firm becomes highly competitive at short term, but will eventually become less competitive as time progresses because it will continue to lose its best people (Hewlett-Packard Development Company 2012: 8). In order to avoid such scenarios while still implementing specialization, one of the best practices is rotate the organization members among the many tasks. For example, for a particular project a group of employees will work as coders, then on another project, the same group may perform as testers or bug fixers. In this strategy, the personal growth or the knowledge acquisition of employees is enhanced, making them progress professionally and in knowledge. During the implementation stage, the University at Texas (2013: 1) notes that one of best practices which software engineers and project managers must implement is identifying the symptoms of problematic software development. These symptoms include: poor software quality unacceptable software performance software that is hard to maintain or extend Inaccurate understanding of end user needs inability to deal with changing requirements late discovery of serious project flaws. The educational institution also advises the identification of the root causes of the problems. The most common root causes of software development problems include: ambiguous communication overwhelming complexity insufficient testing insufficient requirements management undetected inconsistencies among requirements, designs and implementations and brittle architecture. Furthermore, in order to properly manage the root causes of the problems it is essential that project managers implement the following, most importantly, in the implementation stage: develop iteratively manage requirements use component architecture model software visually verify quality and control change.
With regards to the “develop iteratively,” it is an important best practice that critical risks are first resolved before making large investments into the software being developed. The initial iterations will allow end use feedbacks, and this feedback can be used to carryout change management more timely and effectively, and hence saving expenditures. Moreover, testing and integration must be done continuously. The monitoring of milestones will of great value quantifying the success of the testing and integration process. For the managing of requirements, it is necessary to assume that the requirements are dynamic, which means that project managers should expect possible changes in what was already indicated in the scope document. Note that the changes may not be coming solely from the client side but also from the developer`s side, because the developer understands of the software may mature as the development progresses. In order to facilitate change faster and more efficiently, therefore, software engineers or the project management must make sure that they obtain an agreement with the client as to what the software or system would do and not necessarily on how the system of software should do it. This way the changes can be made only internally – within the team involved directly in the software development. It is also important to maintain a backward and forward traceability of the requirements. It is also a common best practice in software development to use component based architecture. Note that, the entire software can be divided into component parts, and hence component codes. What is advantageous about such strategy is that some of the components may be reused as components to other software codes. As the business organization matures and gains experience, such codes will pile up, and hence the possible reusing the component codes becomes greater. Dividing the entire software into component codes also allows the maintainability and extensibility of the software (Srivannaboon and Milosevic, 2006: 502). This strategy also promotes clean division of work among the project team members involved in the coding process. The next best practice is visual modeling of the software. Visual models help software engineers determine the codes for the software. The visual images should incorporate all the relevant business requirements. Note that such visual images are also highly helpful for software testers, as they can easily see the functionalities that should be checked in the software. It is also necessary to control the showing of details of the software from the software engineers. Only the details relevant to the task at hand should be shown. Moreover, the project management should make sure to promote unambiguous communication. The fifth best practice in the software development life cycle is the verification of components quality. As aforementioned, the entire software can be divided into component parts. Each component part should be tested or verified to make sure that the entire software is of high quality when assembled together. Note that the quality of the software is determined by what was agreed upon by the client and the project team. The measures of product quality should be objective. Note that software problems should be identified before deployment because software problems are one hundred to one thousand times more costly to repair after it was deployed, than when it is still being constructed. In accordance with the aim of identifying and resolving all problems first before deployment, testers should always check for functionality, reliability, and performance. Lastly, the project management should always exert control over any change in the software (Markus, Axline, Petrie, and Tanis, 2000: 253). The most efficient way of doing this is to decompose the architecture into different subsystems and then assign responsibility of each of the subsystems to different members of the team. It is essential that these members have efficient communication with each other in order to make the changes uniformly (Ye, 2001: 1 – 6).
The third stage in the software development life-cycle is the deployment and maintenance stage. At this stage the software is transitioned to the client. The software engineering firm transitions the software to the client by teaching or training individuals from the client side on how to use the said software or whatever that was agreed upon in the contract. Usual contracts include the maintenance of the software to a limited span of time – this is called software training and support. Such maintenance may be paid or free. As part of the software deployment stage are the activities such as installation of hardware and software, customization which includes the setting of parameters according to the client`s values, testing and validation, and extended period of evaluation (Zemel, 2004: 5-7). There are times when faults in the code may be discovered during the transition stage, such events are highly avoided, but they do occur. In which case, the software firm may become better prepared by creating a standard process for resolving such faults. Nevertheless, there are times when the fault, in order to be resolved, needs complete redesign of the software. Hence, time and resources management as well as professional, and good relationship with the client are highly important (Tech Republic, 2001: 5).
6. The Capability Maturity Model Integration (CMMI)
As pointed out previously, business organizations, particularly those belonging to the software industry need models in order to identify and implement the best practices – examples of which were aforementioned – in order to progress from one maturity level to another. One of the most extensively used maturity models is the Capability Maturity Model Integration or CMMI. The CMMI was created by the Software Engineering Institute (SEI). It is a tool or a model which can be used as a guide for process improvement in system and software engineering. Accordingly, it can be used to evaluate the capabilities of a particular organization and then provides a guideline to improve the overall capability. CMMI focuses on project management, engineering, organization process, and support activities. It is comprised of two representations, which include: continuous representations and staged representations it has four disciplines, which include: software engineering, systems engineering, integrated product and process development, and supplier sourcing (Gallagher, 2003: n.d.). Just like the P3M3, it has five maturity levels. These levels include: performed, managed, defined, quantitatively managed, and optimizing. Under the performed level, which is the lowest level of maturity, the business organization performs its business process reactively, uncontrolled, and is unpredictable. Under the managed level, the business organization starts to have defined projects and project process, nevertheless, the process usually shift to being reactive. At the defined level, the business process starts to become proactive and organized. At the quantitatively managed and controlled level, the business process is measured quantitatively and controlled. Finally at the optimizing level, the business organization is already focusing on process improvement. In each of these levels, the numbers of process areas are included. Note that the process areas are analogous to the knowledge areas discussed previously. Moreover, every maturity level of the CMMI serves as a foundation to the next. What this means is that an organization cannot jump from one level to another level other than the next. Every process area in CMMI is consists of number of specific and generic goals (Crawford and Pollack, 2007: 93 – 94). For an organization to become mature or to go from one level to another must first fulfill all the goals of the previous level. Also, each process area has its own sets of practices and features. There five capability levels for each process area, and each of these levels is characterized by a particular set of generic practices. Note that it is possible to achieve different levels of capability on different process areas (Chrissis, Konrad and Shrum, 2003: 345 – 347). There is no grouping among process areas because the business organization may opt to choose its own process areas bases on its business goals and needs. In other words, the CMMI model is characterized by continuous representations (Lee and Anderson, 2006: 31). Table 1 shows the summary of the levels, the focus, and the process areas.
Table 1: The five maturity levels of CMMI, their focuses, and their corresponding process areas
CMMI Maturity Level
Focus
Process Areas
Performed
Managed
Basic Project Management
Management of the requirements
Planning of the project
Monitoring and control of the process
Management of supplier agreement
Measurement and analysis (metrics and metrics interpretation) Quality assurance for process and product quality
Configuration management
Defined
Standardization of the Process
Requirements development
Technical solutions
Product integration
Validation
Verification
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Integrated Supplied Management
Risk Management
Decision Analysis and Resolution
Organizational Environment for Integration
Integrated Teaming
Quantitatively Managed
Quantitative management
Quantitative project management and organizational process performance
Optimizing
Continuous process improvement
Organizational Innovation and Development
Causal Analysis and Resolution
Source: (Zemel, 2004: 8)
The CMMI then suggests generic practices for different business organizations which may be assigned on either of the last four levels (levels 2 to 5). It is through these generic practices where the best practices are derived from (Morris and Pinto, 2007: n.d.). Accordingly, for software engineering firms at level 2, the following generic practices are advised: establishment an organizational policy – such policies may include the communications policies, and privacy policies provide resources, assign responsibility, which necessitates that the organization also performs portfolio management as describe in the P3M3 train it members both on technical knowledge such as programming protocols as well as the business process manage configurations, which means that the business organization starts to configure all its technical resources and align these configurations to project goals identify and involve relevant stakeholders monitor and control the process and objectively evaluate adherence and review status with high level management. At level 3, the organization expected to: establish defined processes, and collect improvement information. Note that such practices expected to be done in using CMMI shows that in order to reach the highest maturity level, the business organization, must not revert back to its previous level. It can do just this by reinforcing its process with appropriate technology, ethics, and culture, which are more extensively discussed on the next section (Reyck, 2005: 530 – 533).
7. Knowledge Areas
Because a business process if multifaceted, business organizations consider different areas of project management, and then determine whether each of these areas meet the level desired. What this means is that there are different factors that determine a business organization`s competitiveness, and hence each of these factors must be accounted for in assessing the overall maturity level of the company (Skulmoski, 2001: 15). For example, while the human resources have a very high maturity, it is possible that the work process is still not on the same level (Patanakul, and Milosevic, 2005: 1). These factors were categorized into knowledge areas, which are usually nine, but there are also different works which show varied numbers (Brookes and Clark, 2009: 10). Anderson and Jessen (203: 257) suggested using 12 body of knowledge which are then further categorized under three (3) dimensions, which include: attitude, knowledge, and action Cooke-Davies and Arzymanow (2003: 1 – 4) used 10 and Crawford (2006: 1) used only nine. A summary of these knowledge areas is given in table 2.
Table 2: Summary of knowledge areas for Project Management Maturity Model
Andersen and Jessen (12 knowledge areas)
Cooke-Davies and Azrymanow (10 knowledge areas)
Crawford (9 knowledge areas)
Attitude – insecurity and risk
Project Culture
Integration
Attitude – responsibility sharing and power
Organizational Leadership
Scope
Attitude – soft and hard values
Business Culture
Time
Attitude – Co-operation
Multi-Project Management
Cost
Knowledge – Suppositions
PM Structures, Systems and Methods
Quality
Knowledge – Ways to Work
Degree of Authorization
Communication
Knowledge – Desirable Results
Location of Information
Human Resources
Knowledge – Totality
Matching of Teams to Projects
Risk
Action – at the Strategic Level
Capability of Project Management Staff
Procurement
Action – at the Tactical Level
Functional Management vs Strength of Project
Action – at the Administrative Level
Action – at the Operational Level
The five levels of maturity and the knowledge areas are then applied to three levels of the business organization composition, which includes: Individual level, Team level, and the Organizational level. In other words, in order to make sure the best practices are implemented, and the highest maturity level is reached then each member of the business organization, each team within it, and the entire organization itself contribute to the achievement and implementation of the best practices. At the individual level, each member of the organization should have a clear understanding of the organizational politics. What this means is that each team member should know how to deal with peers and superiors, and to subordinates. In order to facilitate such, it is important that the company educated its members accordingly. It is in this stage that role of the human resources and the organizational culture – which is one of the knowledge areas – plays a crucial role. The human resources must do its best to search, identify, and recruit the best people which may become part and could easily fit within the organizational politics (Scharff, 2000: 87). The business organization must create a culture wherein each member would be exposed and assimilate into. Such culture includes respect for the individual, innovation, etc. (Killen, Hunt and Kleinschmidt, 2008: 29) Note that for large company, such as an international software company which employs people of different nationalities races, it is important the company facilitates efficient communication and smooth relationship among its members it is for this particular purpose that a culture of respect for the individual must be assimilated among members, such will also facilitate the good relationship between project managers and functional managers. At the “team level,” the team should have a clear definition of what success is (Jugdev, Mathur and Fung, 2007: 561). For example, a team may define success as the professional and knowledge growth of each team member, or the accomplishment of team goal. The team should then define clearly and concisely the wrong each team member must play in order to achieve success. The creation of metrics is essential in determining the success of the team, such as the meeting of milestones of a software development team, or a software testing team. Other metric may include the number of bugs, and the number of bugs identified and fixed throughout the software lifecycle. Another important factor that should be maintained or instilled at the team level is the loyalty of each team member to the teams project. Note that for a software engineering company which creates software for clients, the clients consider this software as competitive advantages against their rivals. Each team member should be loyal enough not to divulge pertinent information about the team`s project therefore. When team members are loyal to the team project, then they also work at their highest efficiencies. Such efforts in the team level can be reinforced at the organizational level. At this level are the rules and regulations created by the business organizations. Such rules would include the nondisclosure of project information. For example, the business organization may implement a rule or a scheme for each project. Project codenames and jargons are an efficient way to minimize the leaking of information about projects being handled by the organization. On the efforts of each individual and the team, the business organization must make sure that its senior management supports each project. The organization must continuously monitor the progress of each individual or each member of the organization hence managing their portfolio. It is based on these portfolios that the organization must govern. The manner of governance must be in accordance with the organizational strategy, and the organization must make sure that it properly aligns everyone according to the company`s strategy and in according to the members` portfolios (Artto, Martinsuo, Dietrich and Kujala, 2008: 51 – 52). Table 3 summarizes the three business organizational levels.
Table 3: Business Organization Levels
Individual Level
Team Level
Organizational Level
Understanding the power structure and the politics within the organization
The team should have a clear definition or understanding of what “success” is
The senior management should show full support to the project
Maintaining the good relationship between project managers and functional managers
The team must fully and concisely define the role of each team member
The organization should have a clear and defined strategy
The project team member should give his or her loyalty to the project
There should be a proper portfolio management and governance process
The roles of project managers should be concisely defined to that of the functional managers in order to avoid conflicts, or over stepping on roles and responsibilities.
Each project team should be aligned according to the organizational strategy.
In general a Project Management Maturity Model shows the interrelationship between three factors, and how these three factors can must be improved in order to achieve the highest level of maturity desired by an organization (Ibbs and Kwak, 2000: 35). The interrelatedness of the three factors is shown in the figure below.
Knowledge Areas
Levels of Maturity
Business Organizational Levels
Figure 1: Interrelatedness of the organization`s level of maturity, knowledge areas, and the business organizational levels
In order to better appreciate and fully understand the different maturity models ad their applications in software engineering business, it is essential to research on how they are being applied by some of the world`s most competitive software firms. Presented henceforth are the cases of IBM, HEWLETT-PACKARD DEVELOPMENT COMPANY, and Microsoft Inc.
8. Case Study 1: IBM
On a research article written by Bleakley, Collyer, and Scouler (2013: 1 – 12), entitled, “Best practices for systems and software development: An introduction to IBM Rational Solutions for Systems and Software,” they have presented how IBM used maturity models in order to improve its systems and software development life-cycles, and propel its brand into the competitiveness it is known today.
IBM Rational Solutions is described as consisting of a particular set of rational tools, practice conent, and services. Note that practice content is defined as a set of practices which is used to provide guidance in supporting a solution. IBM currently provides solutions through software engineering to aerospace and defense firms, automotive engineering firms, and solutions for firms producing medical devices. From this background, it is obvious that IBM has diverse types of clients which are specializing on their own sets of fields. So how does IBM provide all the software solutions these diverse companies need? The answer to this is its efficient business process which is characterized by its numerous best practices. Accordingly, each of IBM`s solutions (aeronautics, automotive, and medical) contains practice content which have been developed, tested, and optimized to provide complete life-cycle management solution for the target industry or client, which are in this case divided into the three solutions. Practice content refers to the descriptions on how to develop a certain product or system, which, in the case of IBM are the software and software systems needed by their respective clients. IBM incorporates in its practice contents the use of third-party tools and Rational. The practice content for each type of client or project is managed with the IBM Rational Method Composer or IBM-MC. IBM-MC has a domain language which is based on the Unified Method Architecture (UMA). Note that the terminologies used in the practice content are all derived from the UMA. What this means is the fact that each project has its own set of practice contents, methodologies, or processes, IBM does not have a hard time monitoring each project on a centralized database because each project content is also derived from one source – the UMA. Note that through the following discussion about IBM, Practice and Process are distinct from each other. Accordingly, practices pertain to the things that the individual, the team, or the business organization should do or the tasks, while the process pertains to the structure for how to go about doing the said tasks. Moreover the process determines the order in which the practices should be done so as to achieve the desired engineering result. Practices also leverage the IBM systems as well as the software engineering procedures which explains the tasks as well as the order by which they are needed to be performed or carried out to obtain specific work products. The IBM process has the following phases: project preparation, requirement analysis, functional analysis, design analysis, implementation, and unit test. In order to complete the entire process or all the phases, IBM carefully delegates it human resources to perform specific tasks based from the aforementioned phases. For example, some software engineers would be involved in the design phase while other software engineers would have to perform the unit test (. The IBM project managers make sure that there is an efficient and open communication between the different groups performing different but interrelated tasks. Such efforts are aided with the acquisition of appropriate technologies, such as communication software or testing and coding software. In order words, IBM concentrates not only on its business processes but also on its people and its technologies (Bleakley, Collyer, and Scouler, 2013: 1 – 12).
9. Case Study 2: Hewlett-Packard Development Company
On a research article published by Hewlett-Packard Development Company, Inc. (2012: 1 – 8), entitled, “Best practices in project and portfolio Management: Practical advice for achieving greater value and business benefits,” the company shares it secrets for its high competitiveness in the world market for providing different types of products and services to its customers around the globe. Accordingly, it collects and then re-applies its best practices which it had experiences through the length of its existence as a business organization. Hewlett-Packard Development Company considers its best practices as a collection of wisdom, and hence its competitive advantage over rivals. The company claims that its best practices are based on experience that they are the result of hundreds or even thousands of deployments on its different branches worldwide. It`s best practices have matured and evolved over time.
Hewlett-Packard Development Company groups its best practices into three categories, namely: People, Process, and Technology. These three categories are interrelated and, hence, reinforce each other ensuring a stable, reliable business organization. In order to facilitate the efficient interrelatedness of these three categories, the company uses the Portfolio and Project Management Model or Process, also known as PPM. The PPM processes are considered comprehensive, and are focused on the software development life-cycle. According to the company, the effective use of the PPM processes lies on the addressing of numerous issues, and risk of the full portfolio of business projects in the entire life-cycle. Accordingly, the activities of its human resources are supported by its technologies. This necessitates the creation of software modules which are created specifically to meet the requirements of the particular processes that are needed to be performed by its organization members in the PPM. The PPM process includes portfolio management, resource management, financial management, program management, and time management (Hewlett-Packard Development Company, (2012: 1 – 2).
Portfolio management is concerned with making strategic decisions for both projects and non-project investments made by the company. The main goal of portfolio management is to optimize business value across such investments within an allowed level of risk (Moore, 2002: 121). In other words, one of the best practices of Hewlett-Packard Development Company is that it allows risk taking among its project teams. Nevertheless, such risk taking are implemented with consideration to the projects constraints on time, financials, and resources. Before implementing its best practices, Hewlett-Packard Development Company first considers the different decisions which have to be made. It implements a logical process of assessing project proposals, by first categorizing each proposal into six groups which include: Strategic projects that enable business growth, Projects that improve operational efficiency and reduce costs, Projects that are necessary for regulatory compliance, Projects that maintain normal business operations (keep the lights on, or KTLO), Continued funding for large, existing projects that cross fiscal years, and Non-project work to maintain existing applications and IT services. These groups are then mapped to standard investment categories, which are called “Project Classes” by the company. These project classes include: innovation, growth, efficiency, operations and maintenance, and regulatory compliance. This segregation of projects into project classes enables Hewlett-Packard Development Company to perform efficient monitoring of project quality and performance as well as balance its financials (Hewlett-Packard Development Company Inc., 2012: 5). It also uses these proposals as the basis for the designation or allotment of funds, which is done annually. The main reasons for the implementation of this process are two-fold: simplicity, and consistency. Accordingly, each proposal contains a workflow which is designed for evaluation and approval. Using proposals as bases for approval during annual planning provides a consistent process for traceability and control. This process also allows the clear identification of new or even incremental budget resource requirements. Such process also simplifies reporting due to the fact that reports can be targeted at the proposal. It is also possible to reduce or minimize end-user confusion and improve internal adaption rates. Hewlett-Packard Development Company also recognizes the importance of project history in project management and hence I organizes its project progress into two segments namely: current, and next segments. It then uses its software tools in documenting and segmenting the project history. The tool then allows the project managers to accurately monitor the project progress as then can have a clear view of what is being done and what is still left to be done simultaneously using the tool. Necessary adjustments can then be made based on the comparison between the current and next segments. Hewlett-Packard Development Company also has its best practices in resource management. It considers resource management as one of the management areas that needs significant focus in order to meet the demands for its services and products. The aim of resource management is to optimize resource utilization. Other objectives of resource management include: to plan the portfolio more accurately which will allow the balancing of resource supply and demand, to predict and plan for future resource requirements, to increase the utilization of resources in order to have a higher value of work, to improve the resource planning accuracy, to increase the efficiencies related to resource management functions, and to reduce project budget and avoid project schedule deviations resulting from poor resource management (Hewlett-Packard Development Company, Inc. 2012: 7).
10. Case Study 3: Microsoft, Inc.
On a research article written by Mark Curphey (2013: 1 – 8), entitled, “The Ten Best Practices for Secure Software Development,” he discussed how Microsoft, Inc. became successful in software development. The article listed tem best practices which other software companies need to apply in order to attain high competitiveness in the software industry. These ten best practices are: Protect the Brand Your Customers Trust Know Your Business and Support it with Secure Solutions Understand the Technology of the Software Ensure Compliance to Governance, Regulations, and Privacy Know the Basic Tenets of Software Security Ensure the Protection of Sensitive Information Design Software with Secure Features Develop Software with Secure Features Deploy Software with Secure Features and Educate Yourself and Others on How to Build Secure Software (Kotler, 2002: 41 and Cleland and Ireland, (2007: 141).
First among its list of best practices is the protection of Microsoft`s brand for customer`s trust. Note that the competitiveness of a certain software company lies on the number and reputation of its clients. What this means is that, not all prospective clients will become real clients. The software company should also choose its clients in order to build a good image for itself also. Moreover, companies who have good reputation in the industry where they are a part of are more likely to attract customers than those whose reputations are tarnished. Note however, that protecting the brand does not simply mean projecting and establishing reputation within the industry, it also means protecting the brand from piracy or from cybercrimes. Brand image is important, especially when the brand is popular. In order to maintain the brand image the company need to file for patents and other intellectual property rights. It may file for patent for its logo (Hill, Lederer and Lane, 2001: 17). In protecting against cybercrimes, the company might opt to create a security department which will focus on protecting the company properties against information theft, hacking, etc. Note that that the Harvard Business Review, on one of its special publications, entitled, “Breakthrough Ides for 2008,” identified “cybercrime service economy” as one of the top 20 significant transformations in the business world. According to the article the new generation of hackers has become more sophisticated. They not only interrupt business processes, but they also threated the undermining commercial confidence as well as the customer trust. How does this happen? Note that as aforementioned, software is usually considered by clients as ways to gain competitive advantage. If hackers will divulge the information about certain software projects to the rest of the World Wide Web, then competitors of the client who will own the said software will become better prepared – perhaps making their own software. Hence, a software company which cannot protect itself from hackers will most likely not get the trust of clients. At the end of the day when crucial or confidential information of clients are hacked, the one that will be held liable is the software company handling the project. This means that the adverse effect of successful hacking is two-fold: the loss of trust by the clients to the software company, and the possible legal issues that the software company will face in case the client decides to follow suite. Note that security is an issue which should be addressed regularly, in other words, a company should continuously invest in protecting itself in order for it to become highly competitive. According to Curphey (2013: 2), software firms should always see to it that it creates for itself a security department or division which can always keep ahead of cybercriminals, if not, it is assured that the company will suffer dire financial consequences aside from the more troublesome effect of losing customer trust. The main point here is that software firms should always make sure that each project is performed securely. The second among the best practices is knowing your business and then supporting it with secure solutions. What this means is that aside from having sophisticated hardware and software to protect the business from any possible information theft such as hacking, it is essential for company managers to understand the business process. What this means, is that security exists for the business and not the business for security. In other words, the company should not spend more than that which is needed to maintain highly efficient security else security becomes an impediment to the business. The company`s security could be used to gain a competitive advantage as well. For a secure software lifecycle professional, it is essential to understand the business in order to help in the identification of possible security risks, architecture to be used, users to be educated and trained, and technical controls. It is interesting to point out in this best practice that, again, technology, process, and people are used to form a strong support to security. At the end of the day, the people within the business organization will be the ones who can contribute significantly in ensuring the security of the company and its business process. As noted previously, security can be used to increase the competitiveness of the software company. As an example, internet banking organizations will need to deal with some specific regulatory requirements such as safeguards, financial privacy, and pretexting rules in order to comply with the Gramm Leach Bliley Act (GLBA). In such scenario, having a highly efficient security department will be a competitive advantage to proceed with business transactions. The third is, understanding the technology of the software. What this means is that the business organization must only use technologies which it fully understand in order to optimally use them and avoid any errors in the software development life-cycle. A lack of understanding of the software used will usually lead to time delay, inefficient use of resources – particularly financial resources – and insecure implementation of the software. In general, the company should invest first in its people who will handle the software (Gareis and Hueman, 2000). In other words, the company must efficient train its personnel to use the software. The third is assurance to comply with governance, regulations, and privacy. What this means is that the company should always strive to educate its people to comply with the rules of governance, regulations, and privacy policies while they are working for the company. The rules of the company should be properly taught to each member of the organization, and enforced. There is an effective way of doing this, which is by creating an organizational culture, which includes the ethical standards that each member will abide in. The remaining best practices are with regards to maintaining security through strict protocols in software development, and in communication among members of the organization, and between member of the organization and other people outside the business organization. The core principle is to always get the people, technology, and protocols working together to ensure the security and efficiency of the business organization and its processes (Milosevic and Patanakul, 2005: 188).
Note that the best practices of each of the three companies are in accordance with the CMMI. Accordingly, they all integrate project management and engineering practices. They all also deal with organizational and single-project practices, and continuously improves their organization`s process with the creation and acquisition of the right people and right technologies. The real basis for the maturity of a business organization therefore, is its efficiency in creating protocols which will eventually harmonize the functions of technology and its people. Thee protocols are acquired not just at one time, but it takes time to acquire the best practices and then organize them into protocols which will eventually be further improve as the business organization gets more matured in the market (Gibson, Goldenson and Kost, 2006: n.d.).
11. Summary and Conclusion
Discussed heretofore are the different maturity models which software firm use in order to monitor and improve their business process, more particularly, the process which they use in project management for software development. There is numerous maturity models created since its conception in the 1960s to 1990s. At present there are numerous maturity models, which include the P3M3 and the CMMI. Nevertheless, despite the diverseness of maturity models the majority of them divide maturity into five levels. Each company can assess itself to fit on any of the levels, and they can then work their way up to the highest level of maturity. A business organization`s stride to go up from lower levels to higher levels of maturity in characterized by the refining of its business process, on software engineering firms, it is equivalent to the refining of the project management strategy, as they can be considered as the microcosm of the entire business organization. What this means is that, if each project is managed well at a highest quality possible, then it is most likely that the entire business organization will also be managed well and gain significant competitive advantage against its competitors (Galin and Avrahami, 2005). A summary of the best practices discussed in this research is given in table 4.
Table 4: Summary of the best practices for rising from one maturity level to another
Source(s)
Best Practice
Ralph and Wand, 2009: 234 Crawford, 2006 Grant and Pennypacker, 2006: 61
Use of live codes during the determination of business requirement for the software being developed, so that the client and software engineering business representatives can better have an idea of the requirements
Tech Republic, 2001: 1 Gray and Larson, 2008
Use of project definition documents in the determination of software business requirements during the planning stage
McConell, 2004: 140
Extensive software development life-cycle that documentation
University at Texas, 2013: 1
Identify symptoms of problematic software development: poor software quality unacceptable software performance software that is hard to maintain or extend Inaccurate understanding of end user needs inability to deal with changing requirements late discovery of serious project flaws.
Identify the root causes of the problems: ambiguous communication overwhelming complexity insufficient testing insufficient requirements management undetected inconsistencies among requirements, designs and implementations and brittle architecture.
Project managers must implement the following: develop iteratively manage requirements use component architecture model software visually verify quality and control change.
Tech Republic, 2001: 2 Gray and Larson, 2008
Use of previous documents such as work plans as basis for future documents
Josler and Burger, 2005: 1 – 30
Proactive role of human resources department to make sure that each member of the business organization is well trained and disciplined
Josler and Burger, 2005: 1 – 30
Creation of metrics to monitor project activities and efficiencies both quantitatively and qualitatively.
Tech Republic, 2001: 7
Identify risk upfront and manage them as they come
Tech Republic, 2001: 8
Have a delineated and clearly defined roles and responsibilities as well as management process
Hewlett-Packard Development Company, 2012: 4
Project managers should guard against scope creeps
Fairley, R. 2004: 57 – 58 Hayes, 2007
In managing issues categorize them based on their urgencies
Hewlett-Packard Development Company 2012: 8 Zemel, 2004: 5-7
Engage in work specialization but make sure that employees develop professionally o different fields of expertise associated with software development.
Hewlett-Packard Development Company, 2012: 1 – 2
Allow innovation and controlled risk taking
Curphey, 2013: 1 – 8 Jugdev, Mathur and Fung, 2007
Protect the Brand Your Customers Trust Know Your Business and Support it with Secure Solutions Understand the Technology of the Software Ensure Compliance to Governance, Regulations, and Privacy Know the Basic Tenets of Software Security Ensure the Protection of Sensitive Information Design Software with Secure Features Develop Software with Secure Features Deploy Software with Secure Features and Educate Yourself and Others on How to Build Secure Software.
Hewlett-Packard Development Company, 2012 Curphey, 2013 Cooke-Davies, 2002: 1 – 4
Plan the work by utilizing a project definition document Create a planning horizon Define project management procedures up front Look for other warning signs Ensure that the sponsor approves scope-change requests Guard against scope creep Identify risks up front Continue to assess potential risks throughout the project and Resolve issues as quickly as possible.
Curphey, 2013
Establish a business organizational culture that fosters privacy, and security
Curphey, 2013 Cooke-Davies, 2002: 1 – 4 Jugdev, Mathur and Fung, 2007
Invest on appropriate technology to foster security and efficient software development
It can be concluded in this study the best practice does not only involve the process associated with the creation of products or services, such the creation of software on software engineering companies. The success of the company of the company lies on its level of maturity. The level of maturity, in turn, is dependent on how the company utilizes and manages its human resources, technology, and protocols. Accordingly, a business organization should make sure that everything in the product or service creation is extensively documented. The protocols should be in place. Nevertheless, it should be noted that the creation of standard protocols may need time, as efficient protocols can only be created through experience, meaning, as the business organization progresses from the lowest level of the maturity model upwards to the highest maturity level. Throughout the journey of the business organization across the different maturity levels, it should always maintain a record of best practices. These best practices can then be organized to become protocols for future projects. It can also be concluded, that even if standard protocols are in place, their optimum beneficial effect to the business organization will not be possible without the people implementing, enforcing, and obeying them. Hence, the role of human resources is also important in achieving the highest level of maturity. Accordingly, the human resources should select the best people from different institutions and recruit them to work for or become a part of the business organization. After recruiting the best people, the business organization should make sure they progress professionally – meaning their knowledge continue to increase. By doing this, employees become motivated to work. The company should also create a business organizational culture which will facilitate the efficient performance of the protocols. Such culture should also instill the appropriate ethics and values to the minds and hearts of each member. Such ethics and values include loyalty and adherence to the protocols. It is also concluded in this research that the role of technology is indispensible if a business organization wants to attain the highest level of maturity of any of the diverse maturity models (Duffy, 2001: 31). Accordingly, technology should reinforce the proper performance of the protocols, and that the technology used are well understood by the business organization members. Lastly it is concluded in this research that best practices reinforce each other. In other words, best practices can only be made as effective as they can when they are all considered and performed within the business organization. Accordingly, each project team, department, division should develop and implement their respective best practices simultaneously. This simultaneous application of best practices among the components of the business organization will propel it to the top of the maturity model (Young and Jordan, 2008: 721). In other words, a business organization is like software with many component codes, when one code does not perform at its best, the rest of the software could not perform the entire task it was design to do.
12. Recommendations
While this research has been successful in determining the numerous best practices that a particular business organization should consider in progressing to the highest level of maturity, it did not compare different business organizations at the different levels of maturity. Such comparison could be highly important in order to have better understanding of the differences among such business organizations. This aspect can be further investigated on future studies. Moreover, there is only a small number of studies which investigates whether maturity models indeed contribute to the level of maturity of different business organization. While it is a fact that the said business organizations employ the use of maturity models, there is no research yet to quantize the effects of the different maturity models to the business organization`s competitiveness (Winter, Smith, Morris and Cicmil, 2006: 644). Nevertheless, such was assumed in this study hence it is essential that the relationship between the types of maturity models and the contribution to the competitiveness of business organization be studied more in the future.
13. References
Andersen, E.S. and Jessen, S.A. (2003) Project maturity in organisations. International Journal of Project Management, 21(1): 457-461.
Artto, K. (2009) Foundations of program management: a bibliometrix view. International Journal of Project Management, 27(1): 1-18.
Artto, K., Martinsuo, M., Dietrich, P. and Kujala, J. (2008) Project strategy: strategy types and their contents in innovation projects. International Journal for Managing Projects in Business 1(1): 49-70.
Archer, N. and Ghasemzadeh, F. (2004) The Wiley Guide to Managing Projects (Vol. 3 eds). CA: John Wiley & Sons. Pp. 237-255,
Beynon, D.R. (2007) Interpreting Capability Maturity Model(R)Integration (CMMI(R)) for Business Development Organizations in the Government and Industrial Business Sectors . Retrieved from: < ftp://ftp.sei.cmu.edu/pub/documents/07.reports/07tn004.pdf> . (Accessed 11 January 2014).
Brookes, N. and Clark, R. (2009). Using Maturity Models to Improve Project Management Practice. Retrieved from: . (Accessed 10 January 2014).
Bleakley, G., Collyer, K. and Scouler, J.L. (2013). Best practices for systems and software development: An introduction to IBM Rational Solutions for Systems and Software. Retrieved from: < http://www.ibm.com/developerworks/rational/library/systems-software-lifecycle-development/systems-software-lifecycle-development-pdf.pdf>. (Accessed 11 January 2014).
Cleland, D. and Ireland, L. (2007) Project Management: Strategic design and implementation (5th Edition). NY: McGraw-Hill.
Cooke-Davies, T. (2002) Project management maturity models – does it make sense to adopt one? Project Manager Today, 1(1): 1-4.
Cooke-Davies, T. and Arzymanow, A. (2006) The maturity of project management in different industries:An investigation into variations between project management models”, International Journal of Project Management, 21(1): 471-478.
Crawford, J.K. (2006) The Project Management Maturity Model. Information Systems ManagementOn Line Journal. Retrieved from: < www.ism-journal.com>. (Accessed 8 January 2014).
Crawford, L. and Pollack, J. (2007) How generic are project management knowledge and practice? Project Management Journal 38(1): 87-97.
Chrissis, M.B., Konrad, M. and Shrum, S. (2003) CMMI: Guidelines forProcess Integration and Product Improvement. Boston, MA: Addison-Wesley.
Curphey, M. (2012). The Ten Best Practices for Secure Software Development. Retrieved from: < https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/ISC2_WPIV.pdf>. (Accessed 9 January 2014).
Dache, G. (2004). Capability Maturity Model Integrated (CMMI) Configuration Management Considerations. Retrieved from: http://www.cmwg.org/meetings/200403Mtg/CMMIforCMStaff.pdf. (Accessed 12 January 2014).
Duffy, J. (2001) Maturity models – Blueprints for e-volution. Strategy and Leadership, 29(6): 19-26.
Fischer, G. (2001). The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design. Retrieved from: . (Accessed 11 January 2014).
Gallagher, B. (2003) Interpreting Capability Maturity Model Integration (CMMI) for Operational Organizations. Retrieved from: (Accessed 11 January 2014).
Galin, D. and Avrahami, M. (2005) Do SQA programs work – CMM works. a meta-analysis. Software- Science, Technology and Engineering, Proceedings. IEEE International Conference, pp. 22-23 Feb. 2005, pp. 95 – 100.
Gareis, R. and Hueman, H. (2000) Project management competences in the project-oriented organisation, in Gower Handbook of Project Management.
Gibson, D.L., Goldenson, D.R. and Kost, K. (2006) Performance Results of CMMI-Based Process Improvement. Retrieved from: .
Goldenson, D. and Gibson, D. (2003) Demonstrating the Impact and Benefits of CMMI: An update and priliminary results. PA: Carnegie Mellon University, Pittsburg,
Grant, K.P. and Pennypacker, J.S. (2006) Project Management Maturity: An Assessment of Project Management Capabilities Among and Between Selected Industries. IEEE Transactions on Engineering Management, 53(1): 59-68.
Gray, C. and Larson, E. (2008) Project Management – the Managerial Process (4th Edition), NY: McGraw Hill.
Harvard Business Review (2008) Breakthrough Ideas for 2008. Retrieved from: . (Accessed 12 January 2014).
Hayes, P. (2007) The Theory and Practice of Change Management, (2nd Ed). Retrieved from: . (Accessed 9 January 2014).
Hewlett-Packard Development Company (2012). Best practices in project and portfolio management: Practical advice for achieving greater value and business benefits. Retrieved from: < https://ssl.www8.hp.com/us/en/secure/pdf/4aa2-3112enw.pdf>. (Accessed 9 January 2014).
Hill, S., Lederer, C., and Lane, K. (2001) The Infinite Asset: Managing Brands to Build New Value. Cambridge, MA: Harvard Business School Press.
Iamratanakul S., Patanakul, P. and Milosevic, D.Z. (2008) Innovation and factors affecting the success of NPD projects: Literature explorations and descriptions. International Journal of Management Science and Engineering Management, 3(3): 176-189.
Ibbs, C.W. and Kwak, Y.H. (2000) Assessing Project Management Maturity. Project Management Journal, 31(1): 32-43.
International Information System Security Certification Consortium, Inc. (2013). The Ten Best Practices for Secure Software Development. Retrieved from: . (Accessed 9 January 2014).
Jamieson, A. and Morris, P. W. G. (2007) The Wiley Guide to Project, Program, and Portfolio Management. The Wiley Guides to Project Management, 3(1): 34-62.
Josler, C. and Burger, J. (2005). Project Management Methodology in Human Resource Management. Retrieved from: .
Jugdev, K. and Thomas, J. (2002) Project management maturity models: The silver bullets of competitive advantage? Project Management Journal, 33(4): 4-14.
Jugdev, J., Mathur, G. and Fung, T.S. (2007) Project management assets and their relationship with the project management capability of the firm. International Journal of Project Management, 25(1): 560-568.
Kerzner, H. (2009) Project Management: a systems approach to planning, scheduling and controlling (10 edn), NY: John Wiley & Sons Inc.
Killen, C. P., Hunt, R. A. and Kleinschmidt, E. J. (2008) Project portfolio management for product innovation. International Journal of Quality and Reliability 25(1): 24-38.
Kotler, P. (2002) Marketing Management. Upper Saddle River, NJ: Pearson Education.Kwak,Y.H. and Ibbs, C.W. (2002) Project Management Process Maturity (PM)2 Model. Journal of Management in Engineering, 1(1): 150-155.
Kwak, Y.H. and Williams, C. (2002) Project Management Process Maturity PM[2] Model. Journal Of Management In Engineering, 18(3): 150 – 155.
Lovallo, D. and Kahneman, D. (2003) Delusions of success: how optimism undermines executive`s decisions. International Journal of Project Management, 1(1): 289-299
Lee, L.S. and Anderson, R.M. (2006) An Exploratory investigation of the Antecedents of the IT Project Management Capability. e-Service Journal 1(1): 27-42.
Lycett, M., Rassau, A. and Danson, J. (2004) Programme management: a critical review. International Journal of Project Management 22(1): 289 – 299.
Markus, M. L., Axline, S., Petrie, D. and Tanis, C. (2000) Learning from adopters` experience with ERP: problems encountered and success achieved. Journal of Information Technology, 1(1): 245-265.
McKenna, L. (2002) Managing Change Through Project Management: A Practitioners Guide. Retrieved from: . (Accessed 9 January 2014).
McConnell, Steve. “7: Lifecycle Planning”. Rapid Development. Redmond, Washington: Microsoft Press.
Millosevic, D. Z., Martinelli, R. and Wadell, J. M. (2007) Program Management for Improved Business Results. NY: John Wiley & Sons.
Milosevic, D. and Patanakul, P. (2005) Standardised project management may increase development projects success. International Journal of Project Management, 23(1): 181-192.
Moore, G. (2002) Crossing the Chasm. New York, NY: HarperBusiness.
Morris, P. and Pinto, J. (2007) The Wiley Guide to Project, Program, and Portfolio Management (Vol. 3), NY: John Wiley & Sons.
Mullaly, M. (2006) Longitudinal Analysis of Project Management Maturity. Project Management Journal, 36(3): 62-73.
Nieto-Rodriguez, A. and Evrard, D. (2004) Boosting Business Performance through Programme and Project Management: A first global survey on the current state of project management maturity in organisations across the world. PA: Pricewaterhouse Coopers.
Office of Government Commerce (2006) Portfolio, Programme and Project Management Maturity Model (P3M3). Retrieved from: . (Accessed 9 January 2014).
Patanakul, P. and Milosevic, D. (2005) Project Perspectives. Retrieved from: . (Accessed 11 January 2014).
Patanakul, P., Milosevic,D.Z. and Anderson,T.R. (2007) A decision support model for project manager assignments,” IEEE Transactions on Engineering Management, 54(4): 548-564.
Patanakul, P., and Shenhar, A.J. (2010) Exploring the Concept of Value Creation in Program Planning and Systems Engineering. Systems Engineering, 13(4): 340-352.
PM Forum (2008) Organizational Project Management Maturity Models. Retrieved from: . (Accessed 9 January 2014).
PMI (2004) A Guide to the Project Management Body of Knowledge (PMBOK Guide), 3rd Edition, Project Management Institute.
Project Management Solutions, Inc. (2013). What is the Project Management Maturity Model (PMMM)? Retrieved from: < http://www.pmsolutions.com/resources/view/what-is-the-project-management-maturity-model/>. (Accessed 9 January 2014).
Ralph, P., and Wand, Y. (2009) A Proposal for a Formal Definition of the Design Concept. A Ten-Year Perspective: Springer-Verlag, pp. 103-136
Reyck, B. D.(2005) The impact of project portfolio management on information technology projects. International Journal of Project Management, 23(1): 524 – 537.
Raymond, E. S. and Young, B. (2001) The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O`Reilly & Associates, CA: Sebastopol.
Sargeant, R. (2010) Creating value in project management using PRINCE2. England: Queensland University of Technology.
Sauer, C. and Reich, B. H.(2009) Rethinking IT project management: evidence of a new mindset and its implications. International Journal of Project Management, 27(1): 182-193.
Scharff, E. (2000) Transcending the Individual Human Mind — Creating Shared Understanding through Collaborative Design. ACM Transactions on Computer Human-Interaction, 7(1): 84-113.
Shenhar, A.J., Dvir, D., Milosevic, D.J., Mulenburg, J., Patanakul, P., Reilly, R., Ryan, M., Sage, A.,Sauser, B., Srivannaboon, S., Stefanovic, J. and Thamhain, H. (2005) Toward a NASA specific project management framework. Engineering Management Journal, 17(4): 8-16.
Skulmoski, G. (2001) Project Maturity and Competence Interface. Cost Engineering, 43(1): 11-19.
Srivannaboon, S. and Milosevic, D. Z. (2006) A two-way influence between business strategy and project management. International Journal of Project Management 24(10): 493-505.
Strassmann, P. A. (2005) The Politics of Information Management. WA: Information Economics Press.
Tech Republic (2001). Project management best practices. Retrieved from: . (Accessed 9 January 2014).
Thiry, M. and Deguire, M. (2007) Recent developments in project-based organisations. International Journal of Project Management, 25(1): 649-658.
Thomas, J. and Mullaly, M. (2008) Researching the Value of Project Management. PMI.
Tichy, L. & Bascom, T. (2008) The business end of IT project failure. Morgage Banking, 68(1): 28-35.
United Nations Development Program (2013). Maturing. Retrieved from: . (Accessed 9 January 2014).
University at Texas (2013). How are we doing with the software field? Retrieved from: < http://www.cs.utexas.edu/~mitra/csSpring2013/cs329/lectures/bestPractices.html>. (Accessed 9 January 2014).
Whitten, Jeffrey L. Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods. 6th edition. Print.
Wheatley, M. (2007) Maturity Matters. NY: PM Network, pp. 48-53.
Winter, M., Smith, C., Morris, P. and Cicmil, S. (2006) Directions for future research in project management: The main findings of a UK government-funded research network. International Journal of Project Management 24(1): 638 – 649.
Ye, Y. (2001) Supporting Component-Based Software Development with Active Component Repository Systems, Ph.D. Dissertation, Department of Computer Science, University of Colorado, Boulder, CO.
Young, R. and Jordan, E. (2008) Top management support: Mantra or necessity? International Journal of Project Management, 26(1): 713 – 725.
Young, M., Young, R. and Zapata, R. (2011) A Critical Assessment of P3M3 in Australian Federal Government Agencies: Project, Programme and Portfolio Maturity Levels. Retrieved from: < http://www.governanceinstitute.edu.au/magma/media/upload/media/529_P3M3-Anzsig-Insight.pdf>. (Accessed 11 January 2014).
Zemel, T. (2004). Project Management according to the Capability Maturity Model (CMMI). Retrieved from: < www.pmi.org.il/index.php?option=com_docman&task=doc.ppt>. (Accessed 12 January 2014).