Development and administration of information projects: distance course

Texto completo

(1)Este documento forma parte de la producción editorial del Centro Interamericano de Estudios de Seguridad Social (CIESS), órgano de docencia, capacitación e investigación de la Conferencia Interamericana de Seguridad Social (CISS) Se permite su reproducción total o parcial, en copia digital o impresa; siempre y cuando se cite la fuente y se reconozca la autoría..

(2)

(3) Development and Administration of Information Projects At-a-Distance Course. Study material. Inter-American Center for SociaC Security Studies. Education, training and research organ of the Inter-American Conference on SociaC Security Mexico City, September 2003..

(4) Index Page What does my didactic material consist of and how should I use it?. 5. Module I. Information technology project development fundamentals By Alejandro Dominguez Torres. 7. Topic 1. Information technology project development basics. 11. Topic 2. The Capability Maturity Models. 27. Topic 3. The communication process within an it project. 47. Evaluation exercises and activities. 59. Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(5) ['What does my didactic material consist of and how should I use it?. The didactic material consists of a didactic guide and the study material for each one of the Modules of the Course. Didactic guide The purpose of the didactic guide is to offer you a general orientation on the procedures for the development of the Course and recommendations as to how to obtain utmost benefits from the Course. It is important that you read the entire didactic guide before starting with the study material and even that you review it before initiating a new module. The didactic guide contains the following chapters: Outline of the Course: this chapter presents the basis, objectives and outcome profile, which will allow you to delimit the purposes of the Course and to have a point of reference that will permit you to evaluate if it meets your learning expectations. It also includes a scheme which indicates the order of the modules, so that you may carry out a follow up of the modules and distinguish the internal relationship of each one of the parts of the Course. Likewise, the key words and the evaluation exercises for each module are presented, as well as the characteristics of the final paper. Methodology: includes the communication media through which you can maintain contact with this Center and be aware of the responsibilities of your tutor. In the chapter What is expected of me as participant in an at-a-distance course? certain recommendations are included as to how to obtain utmost benefits from the Course. In the chapter What activities do I have to perform and how will my pegeormance be evaluated? The deadlines are established for the delivery of each exercise. In the study material, at the end of each module, these activities are also described. Likewise, the procedure and the characteristics of the credits that the CIESS will grant for your successful completion of this Course are also described. Educational team: In this section the coordinators and tutors are introduced. Glossary: Offers a list of important terms for the study of the topics approached in the Course.. 5 Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(6) Study material This material is divided according to the three modules. It describes the topics selected taking into consideration the learning objectives presented in a sequential manner to permit a gradual and progressive assimilation. For the achievement of the learning objectives of each module it is important that the corresponding texts are read before working on the exercises and activities designated for the evaluation. After finalizing your evaluation activity, remember to send it in due time to the CIESS in accordance with the specified dates.. Centro Interamericano de Estudios de Seguridad Social.

(7) itioduCe I. Information technology project development fundamentals. INTRODUCTION The informatics industry has developed new methods for the administration of the growing complexity of information projects. In the past there were several evolutions, revolutions and recurring success and failure topics. At present, the success of information projects depends on the ability to find an equilibrium of five principal components: people, information, processes, tools and products/services. The five components are important at the time of developing any information project. During several years, two of these elements have been explored in detail. These two components are: people and processes. People and processes require a conducting channel that will permit communication among various of their component elements, as well as between them. Without communication there is no way to develop any information project. The study and description of the relationship and equilibrium of these five components, with special attention to people and processes, as well as to communication as the integrating factor of the development of projects, are the purposes of this first module. Topic number one discusses the development of information projects as part of the assignment of the functions and of information services; it presents the five elements of the development of information projects as the basis for the specification of normalized practices and procedures, and shows the relationship among the elements and how any change in an element will affect the others. Topic number two deals with the processes and people components and discusses two models for the success of the development of projects. These modules are the "Software Capability Maturity Model (SCMM)" and 'People capability Maturity Model (P-CMM)". Both generated by the Software Engineering Institute (SEI). Finally, topic number three discusses two main subjects: the elements of a communication plan and certain communication strategies.. Curso a Distancia Desarrollo y Gestian de Proyectos Infonniticos.

(8) e. (. OBJECTIVES. • Analyze the five fundamental elements for the development of informatics projects as the basis for the specification of normalized practices and procedures. • Analyze the two international standards for the development of projects associated to people and processes. Analyze the importance of communication in the development of projects.. KEY WORDS Common characteristics Communications plan Communication strategies Development of information projects Goals Information Key practices Key processes areas. Maturity level People People Capability Maturity Model Processes Product/Service Software Capability Maturity Model Software processes capability Tools. TOPICS 1. Information technology project development basics 2. The Capability Maturity Models 3. The communication process within an it project Author of all the topics: Alejandro Dominguez Torres. ft. I. EVALUATION EXERCISES AND ACTIVITIES. -=,-r,-: \. First activity (individual exercise). 1. Consider the current status of an organization; this may be the organization in which you work or any other (this organization must develop software applications). 2. Using the following chart, evaluate that organization with the purpose of determining how far it is from level 2 of the S-CMM.. Centro Interamericano de Estudios de Seguridad Social.

(9) Repeatable KPAs. Goal 1. Requirements management. Goal 2. Goal 3. Goal 4. Invalid grid. Invalid grid. Project planning. Invalid grid. Project tracking and oversight. Invalid grid. Software subcontract management. Software quality assurance. Configuration management. 4111. Fully Satisfied. 4110 Not Applicable. 41111. Not Satisfied. 41Ir1. Not Rated. After having analyzed the situation of the organization, evaluate each goal and write a justification for each one of them. Each justification must be clear, concise and no longer than half a page. The document generated must have the following structure: • Tide or introductory page, indicating the following data: full name, electronic mail address, city, country, name of the document and date of creation. • Résumé page (no more than 200 words). • Background of the organization where the evaluation will be applied. It must contain enough information to show the type of organization being evaluated. • The evaluation and its justification. • For each "Does not Comply" indicate how to proceed to change this evaluation to "Total Compliance", that is, indicate how to solve the problem (again, the solution to each "Does not Comply" must be no longer than half a page). • Conclusions your own and original).. Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(10) Topic 1. Information technology project development basics By Alejandro Dominguez Torres. Summary This section presents some useful guidelines to develop Information Technology (IT) projects as shown in the following Table.. SUBSECTION. SUBSECTION ABSTRACT. 1.2 IT PROJIA r DEVELOPMENT. Discusses IT project development as part of the delivery of IT services and functions. 1.3 IT PROJECT DEVELOPMENTELEMENTS. Presents the major five elements of IT project development as a foundation for the specification of standard practices and procedures. 1.4 THE RELATIONSHIP OF THE FIVE ELEMENTS. Shows the relationship among the elements and how changes in one element affect the others. Table 1. Organisation and presentation of project development guidelines. 11 r."-■. Curso a Distancia Desarrollo y Gestic% de Proyectos Informaticos.

(11) Topic 1. Information techno fogy project development basics By Alejandro Dominguez Torres. 1.1. IT PROJECT DEVELOPMENT IT is present in all business matters. However, if business goals are to be met, the processes by which IT solutions are chosen, designed, and implemented have to be developed by a carefully crafted set of strategies and procedures. This is the essence of IT project development. IT project development consists of a set of structured process for achieving a specific and unique outcome in a defined and bounded period of time. Successful outcomes are more likely when an IT project is properly defined, designed, implemented, and controlled. IT projects come in many different shapes and sizes, some of them are shown next. Table 2. Some IT projects and their description. T1 PE OF IT. PROJECT. DI SI RIP I ION. FEASIBILITY STUDIES. The evaluation of IT and its use in an organisation, which may include the selection of IT solutions and recommendations for future strategies. IT DEVELOPMENT. The design, testing, integration, and implementation of customised IT applications, and related platforms and interfaces. IT UPGRADE. The upgrade of existing IT platforms, solutions, and products. IT MIGRATION. The replacement and/or removal of existing IT platforms and solutions; typically replaced by different products. SUPPORT SERVICES. The participation of IT as a change agent; it includes office renovations, relocations, organisation mergers, training programs, and internal reorganisations. IT MANAGEMENT. Relate to the improvement of IT performance and service delivery; it includes IT process re-engineering, maintenance, security audits, and documentation projects. Nevertheless, the list does not end here. For when IT is chosen and installed, it must also be maintained and supported. Moreover, the fast pace of technological change mandates an ongoing cycle of IT enhancement, upgrade, and renovation. 13. Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(12) Whether the IT development goal is to design, install, or re-engineer, IT initiatives are often driven by aggressive deadlines and periods of frequent change. To accomplish the goals, resources must be identified and allocated, and activities must be properly organised and structured in accordance with business and IT requirements. However, considering the variety of available IT solutions, applied within a diverse range of business and professional environments, IT project development is not an easy task, for example: • IT functionality issues are often mistaken for technical problems; • There is a limited tolerance for downtime that may greatly complicate the implementation of platform upgrades and migrations. As such, the traditional boundaries that exist between IT projects and ongoing operations tend to blur in the IT world, creating unique development challenges. IT project development best practices can be used to address those challenges. Considering the need for consistent quality and fast delivery, any practices designed to deliver performance and productivity will prove worthwhile, provided that the practices are not allowed to overtake the purpose. As with any other discipline, IT project development must be put in proper organisational perspective. To practice effective IT project development, it must have: • Defined policies and procedures for project selection, definition, design and control; • Supported and committed management; • Trained and committed staff; • An environment that fosters teamwork and cooperation; • Strong technical capabilities; • An understanding of business goals and objectives; • The right IT tools sized to suit project requirements and technical capabilities; • The authority to enforce and update IT project management practices as needed.. 14 Centro Interarnericano de Estudios de Seguridad Social. IT project development must be put in proper organisational perspective..

(13) Most organisations face many different types of IT projects, each with its own degree of urgency and business priority. IT project development best practices can add structure and definition to this chaos, but not by accident. When they are applied, restrictions and boundaries influence decisions and activities. Speed, creativity, and innovation must find a place within an environment of standards, rules, forms, and templates.. Speed, creativity, and innovation must find a place within an environment of standards, rules, forms, and templates.. The project success is increased when the required deliverables are produced on time and within budget. Moreover, to be truly successful, IT projects should have: • Realistic and workable plans; • Strong management commitment; • Proper oversight and monitoring; • Effective analysis of risks; • Strong business justifications; • Controlled costs; • Sound technical designs and deployment plans; • Realistic expectations; • Strong teamwork. To deliver successful results on a consistent basis, workable, realistic standards and best practices must be defined and applied. These standards must be aligned with organisational requirements, internal capabilities, and project characteristics.. 1.2 IT PROJECT DEVELOPMENT ELEMENTS. e•-•. Any IT project development includes five main elements: People, Process, Product/ Service, Information, and Tools. Successful IT project development requires keeping these five elements in harmony. Balancing the elements means looking at who is trying to build what, so it becomes important to think about the elements at the project's development start.. 15. Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(14) 1.2.1 People The primary element of any IT project is the People: • • • •. People gather requirements; People interview users (People); People design IT for People; No People — no IT.. The best thing that can happen to any IT project is to have: • People who know what they are doing and have the courage and self-discipline to do it; • Knowledgeable people to do what is right and to avoid what is wrong; • Courageous people to tell the truth when others want to hear something else; • Disciplined people to work through projects and do not cut corners. A successful IT project development requires that the project team participate (at some level) in the design process and be responsible for completion of assignments. It is important to have a defined formal organisation for the project and for the project staff. This provides each individual with a clear understanding of the authority given and responsibility necessary for the successful accomplishment of project activities. Project team members need to be accountable for the effective performance of their assignments. Project Organisational Structures come in many forms. However, their impact can be seen throughout the project. For example: • On a large project, individual role assignments may require full-time attention to the function; • On smaller projects, role assignments may be performed part-time, with staff sharing in the execution of multiple functions. The project team includes a diverse mix of people and skills. It goes beyond just the project member performing specific tasks. The required mix for any project team will include, but not be limited to, the following people: People specifically charged with implementation of the project solution (also known as "the project team"):. 16. Centro Interamericano de Estudios de Seguridad Social. It is important to have a defined formal organisation for the project and for the project staff..

(15) o o o o o o o o. Requirements development staff; Business rule specifications staff; Project management staff; Subject matter experts; Documentation (user and technical) staff; Training staff; Technical staff; Leaders/decision makers;. • Customers (both internal and external) of the product/service created; • Project sponsor; • Stakeholders. Stakeholders are individuals and organisations that have a vested interest in the success of the project. The identification and input of stakeholders help to define, clarify, drive, change, and contribute to the scope and, ultimately, the success of the project. To ensure project success, the project team needs to identify stakeholders early in the project, determine their needs and expectations, and manage and influence those expectations over the course of the project. Stakeholders on every project include the following people and groups:. Table 3. Stakeholders responsibilities STARLUOLDER. RESPONSIBII III. PROJECT MANAGER. Who has ultimate responsibility for ensuring project success. PROJECT SPONSOR. Who takes the lead in getting the need for the project recognition as well as possibly providing financial resources. ORGANISATIONAL MANAGEMENT. Who defines the business needs of the project. PROJECT TEAM MEMBERS. Who are responsible for performing the work on the project. CONFIGURATION MANAGEMENT ENTITIES. Who are responsible for manage project configuration within the boundaries of the project. QUALITY ASSURANCE TEAMS. Who verify the ability of the product/service to meet the stated necessary requirements. ORGANISATIONAL PROCUREMENT PERSONNEL. Who assist in procuring project resources. CUSTOMER. Who is the person(s) or organisation(s) using the product of the project. 17 Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(16) 1.2.2 Process Process is how people go from the beginning to the end of a project. All projects use a process. Many IT project managers, however, do not choose a process based on the people and product/service at hand. They simply use the same process they have always used or misused. There are two main statements regarding process: Process Improvement and Right Process Use. These two statements are discussed in the table below.. Table 4. Statements about Process DESCRIPI IO. STATEMENT PROCESS IMPROVEMENT. • It is the key to increasing the ability to produce IT • There must have a process before it can be improved. RIGHT PROCESS USE. • There are different and useful process models • A good and standard processes models are "The Software Capability Maturity Model (S-CMM)", and "The Capability Maturity Model for People (P-CMM)" • S-CMM and P-CMM have a series of levels through which an organisation can progress from the chaotic level 1 (Initial) up through level 5 (Optimised) (see Section 2 for more details). 1.2.3 Product/Service The product/service is the result of an IT project. The desired product/service satisfies the customers and keeps them coming back for more. Sometimes, however, the actual product/service is something less. The product/service pays the bills and ultimately allows people to work together in a process and build IT. Always keep the product/service in focus. The current emphasis on process sometimes causes to forget the product/service. This results in a poor product/service, no money, no more business, and no more need for people and process. Instead of discussing different types of products/services (computer systems, data networks, voice networks, etc.), it is better to focus on two other aspects of the product/service: • The difficulty of the product/service; • The external and internal quality. The difficulty of the product/service influences the process needed. "Difficult" is subjective and depends on how familiar people are with the product/service.. 18 Centro Interamericano de Estudios de Seguridad Social. Many IT project managers, however, do not choose a process based on the people and product! service at hand..

(17) For example, for some people a text editor is a very difficult product, while an intelligent image analyser is simple for other people. Answering the following questions determines the "difficulty" of the product/ service and the type of process needed: • Is the product/service familiar or new to the people? • Is it new to everyone in the world? • Is the user interface a major portion of the product/service? Difficult products/services demand process models that allow for experimenting and learning. Easy products/services call for process models that are simple, straightforward, and efficient. Difficult products/services become easier when it is brought in people with knowledge of the product/service. On the other hand, it is always important to keep in mind the external and internal quality of the product/service. External quality is what the customer sees. The customer is happy if the product/service has all the required functions, is easy to learn and use, runs quickly, and does not demand so many resources to operate. Internal quality is what the builder sees. High internal quality indicates, among other things, that the design is easy to understand and result is according to customer specifications. When the customer announces changes in the IT platform, high internal quality lets to change the product/service quickly and easily. These quality factors also influence the people and process. For example, if portability (internal quality) is important, it must be available people having expertise in several IT platforms. If these people are not available, it must be allowed for learning and risk in the process.. High internal quality indicates, among other things, that the design is ea g to understand and result is according to customer Jpeczfications.. 1.2.4 Information Information is an essential commodity for the operation and development of a project and its organisation. In order to understand the nature of information, it is important to understand the purposes for which is provided. However, the primary purpose of information is aid to decision making.. ^. The estimation of the value of information is a difficult area. In some cases a quantitative measure may be placed on the provision of speedier information, as in debtor control, or in the reduction of uncertainty. These are, however, intangible benefits. It is difficult, if not impossible, to analyse the contribution of more effective information to make a better decision, or to isolate the impact of greater information availability to customers on their purchases. It is a great mistake to 19. Curso a Distancia Desarrollo y GestiOn de Proyectos Informaticos.

(18) ignore the intangible, no-measurable benefits in assessing the overall benefits to the firms of a proposed IT. Finally, it is important to notice that IT project development will be based on available information both formal and informal (see Table and Figure below):. Table 5. Formal and informal information CHARACTERISTICS. TYPE OF INFORMATION. FORMAL INFORMATION. It is produced by standard procedures, is objective and is generally regarded as relevant to a decision. INFORMAL INFORMATION. This is often subjective, passed by word mouth, and involves hunches, opinions, guesstimates and rumour. It generally involves explanatory and/or evaluative information. •. Formal information: usually quantitative, produced by known rules, objective. Informal information: usually qualitative no pro uce y nown rules, su. Figure 1. Formal and informal information. 1.2.5 Tools. Project development tools are the means by which process become reality. Through the use of software, templates, training and communications systems, process directives are given form and substance (see Table below). As a result, these tools stand as tangible proof of development's commitment to the practice of project development. Table 6. Tools for project development TOOL. PURPOSE. SOFTWARE. For automating project management activities. TEMPLATES. For documenting project activities. TRAINING. For educating staff and end-users. COMMUNICATION SYSTEMS. For sharing knowledge, information and status. 20. Centro Interamericano de Estudios de Seguridad Social.

(19) Before any tools can be chosen and properly integrated into the project standards program, certain key criteria have to be addressed (see Table below). These form a useful set of criteria for the evaluation and selection of project development tools.. Table 7. Criteria for the evaluation and selection of project development tools CRITERIA. DESCRIPTION. PROJECT DEVELOPMENT OBJECTIVES. What will the product/service accomplish and what role will software, training, templates, and communication play in product/service delivery and execution?. PROJECT AND ORGANISATIONAL CHARACTERISTICS. Software tools must match project characteristics and requirements, including size, duration, task complexity, reporting, resource allocations and the need to manage multiple projects across an organisation. TECHNICAL CAPABILITIES. It must be considered the capacities and characteristics of the current technical environment. These considerations may include, but are not limited, to Internet access, intranet access, computing power, access to shared printing, LAN/WAN connectivity, electronic mail access, and the ability to share data with external service providers and telecommuters. COMPATIBILITY WITH CURRENT TECHNOLOGICAL PLATFORMS. To fully assess technical compatibility, it will be needed detailed information on platform configurations, capacities and structural limitations, as well as the corresponding requirements for the products and toolsets to be considered. STAFF SKILL AND RESOURCE AVAILABILITY. IT project development may require some degree of maintenance and administration. These requirements must be considered when evaluating skill levels and resource availability. COST TO PURCHASE AND MAINTAIN. When considering the selection and deployment of project development tools, thought must be given to the costs of testing, evaluation, acquisition, development, deployment, and maintenance.. It will be needed detailed information on platform configurations, capacities and structural limitations, as well as the corresponding requirements for the products and toolrets to be considered.. 1.3 THE RELATIONSHIP OF THE FIVE ELEMENTS Figures 2 through 5 show an integrated graphical view of the five elements. Figure 2 shows a situation of equilibrium (equilateral pentagon) among the elements. This is a desired situation in any IT project development. The pentagonal region shows the difficulty of developing a product/service. Obviously, it is easier to build products/services near the centre since they are less complex. Easy products/ services do not require much capability from the other four elements. As products/ services move away from the origin, they become more difficult and demand more from the complementary elements.. 21 Curso a Distancia Desarrollo y GestiOn de Proyectos Informaticos.

(20) People. Information. Product/Service. Process. Tools. Figure 2. Relationship of the five elements: Equilibrium. Figures 3 through 5 show that the added capability needed to build a more difficult product can come through different combinations of improving people. Product/ Service has the same difficulty in all three figures. In each of them, the product/ service moves from a difficulty lower to a higher. In Figure 3, the needed capability comes from people. This extra capability could be achieved by adding experts or training the people. Figure 4 shows that the same amount of extra capability can come from improving the process instead of the people. Using an incremental delivery model or stretching the schedule is the way to add capability. Figure 5 shows that the extra capability can come from improving both the people and process. This could be done by bringing in a consultant a few hours a week, sending one person to training, using rapid prototyping on one part of the product/service development, using incremental delivery on another, and so on. People. Product/Service. Information. Tools. Process. Figure 3. Building a more difficult product/service by increasing capability from people 22. Centro Interamericano de Estudios de Seguridad Social.

(21) People. Product/Service. Information. Tools. Process. Figure 4. Building a more difficult product/service by increasing capability from process. People. Product/Service. Information. Tools. Process. Figure 5. Building a more difficult product/service by increasing capability from people and process. The point of the graphs is that building a more difficult product/service requires more capability from somewhere. It cannot be done the a new thing with the same old people and expect something wonderful to happen. It must be improved the people, the process, the information, the tools, or all of them.. r"-■. Successful IT projects do not happen as often as they should. One way to increase their frequency is to achieve the proper relationships among the five elements. Given a product/service to build, choose people, a process, information, and tools that match. Given a product/service to build and the people to do it, choose a process, information, and tools that match. Given people who prefer one type of process and have some type of information and tools, try to build only products/services that match.. One way to increase their frequency is to achieve the proper relationships among the five elements.. 23 Curso a Distancia Desarrollo y Gestien de Proyectos Informaticos.

(22) The capability to build difficult products/services must come from people, process, information, and tools. Tougher products/services require people with knowledge in the product/service area, or doing something different with the process, information and tools. Select courageous and disciplined people who know the product/service and can work in the process using the maximum capabilities of information and tools. Use a process, information and tools that allow the people to build the required product/service. It is important to say that only should be attempted to build products/services within the capabilities of people, process, information, and tools. On the other hand, do not use more capability than is needed. Using desktop publishing experts on a text editor is a mistake; they will get bored and leave. Think about people, process, information, tools and product/service. There is always some flexibility on a project. Choose people, process, information, tools, and product so that they will fit one another.. Bibliographical references Edman, E. G. The project management analysis companion: Creating and implementing standards for IT project management. Right Track Associates, Inc. wwwittoolkit.com. USA, 2001-2002. McConnell, Steve. Rapid development. Microsoft Press, McGraw-Hill. USA, 1997. McConnell, Steve. Software project survival guide. Microsoft Press, McGrah-Hill. USA, 1998. Phillips, Dwayne. The software project manager's handbook. IEEE Computer Society Press. USA, 1998. Phillips, Dwayne. People, process, and product. http://members.aol.com/ dwaynephil/CutterPapers/ppp/ppp.htm . Visited August 2003.. 24. Centro Interamericano de Estudios de Seguridad Social.

(23) Topic 2. The capability Maturity Nlodels By Alejandro Dominguez Torres. Summary This section presents the two international standard models for project development associated to the Process and People components discussed so far. These are, respectively: • The Software Capability Maturity Model; • The People Capability Maturity Model Both models are basic for project development successes since are the result of many years of experience of several organisations. In order to introduce both models, this section is started studying how an organisation should mature each of the five elements. The discussion continues exploring the main features of both maturity models aforementioned.. 25. Curso a Distancia Desarrollo y Gestinn de Proyectos Informaticos.

(24) J. ✓. ✓. ✓. ✓. ✓.

(25) Topic 2. The capability _Maturity _Models By Alejandro Dominguez Torres. 2.1 BACKGROUND. As it was seen in Subsections 1.3 and 1.4, the five elements are fundamental for any IT project development. These elements change once the product/service element is changed. Hence, building a more difficult product/service implies an increase of capacity for the other four elements. Increasing the capacity of the five elements requires an increasing of maturity for managing each of them. If at the beginning of each project development there is not agree in a set of developing steps, then the maturity for managing project issues is at its lowest level (initial maturity level). At this level, a common terminology is probably known and shared and project success depends on individual efforts and heroics. If each time a project is developed a successful process is repeated, then there is a risk reduction in the development and an increasing of project success. Due to this, this level of maturity is known as "repeated maturity level".. --„. If at the beginning of each project development there is not agree in a set of developing steps, then the maturity for managing project issues is at its lowest level.. On the other hand, if various developing activities and the processes of management are formally defined, documented, and integrated, then the level of maturity is said to be "defined maturity level". Moreover, if it is stressed the importance of quantitatively measuring the quality of the products/services delivered by each process setting quantitative goals for both products/services as well as processes, then the level of maturity is called "managed maturity level". At the fifth level of maturity, called "optimised maturity level", the focus is on the continuous process improvement pro-actively identifying its strengths and weakness, with the aim of preventing the occurrence of defects. Here continuous improvement becomes institutionalised into the development process. Instead of merely correcting defects as they are found, the main aim at this level is to stall future defects and address the key to those defects by planning in advance. Next Figure is a graphic representation of levels. In this figure, it is seen that at the initial level the products/services successfully developed are those having a low complexity, meanwhile at optimised level, the products/services successfully developed could have a higher complexity. 27 Curso a Distancia Desarrollo y Gesti6n de Proyectos Informaticos.

(26) •. People — Initial Maturity Level. Information. Product/Service. — Repeated Maturity Level Defined Maturity Level Managed Maturity Level —Optimized Maturity Level. Tools. Process. Figure 6. Maturity levels representation. The set of maturity levels for software processes in an organisation is known as "Software Capability Maturity Model (S-CMM)". This model has been developed by the Software Engineering Institute (SEI) and is discussed in Subsection 2.2. It is important to notice that S-CMM has only been developed for software projects and not for any IT project. As well, SEI has developed a framework for improving the way in which an organisation manages its human assets known as "People Capability Maturity Model (P-CMM)".This model is discussed in Subsection 2.3.. 2.2. CMM FOR SOFTWARE. 2.2.1 The software project development process Before starting the discussion, the term "process" must be defined in a software development context. Process defines a way to do a project, projects typically produce a product (software), and product is something that is produced for a co-worker, an employer, or a customer. This definition can now be used to achieve project success. To do that, a threestep strategy will be followed: • Analyse the current process by which the organisation executes its projects; Figure out the strengths and weaknesses of the current process; • Improve upon the process's strengths and remove its weaknesses. The above seemingly simple steps have baffled the software industry for years. Different software organisations have adopted different techniques to implement the three-step recipe, with varying degree of success. The problem now is trying to interpret and master this "three-step approach to success". Consider the normal course of steps that follow when a software project is undertaken. Details of these steps will only be outlined, without going into the 28. Centro Interamericano de Estudios de Seguridad Social.

(27) details of each; since the purpose is to highlight the most common events and not their particular details, as they may vary depending on the nature of the project (see next Table). Table 8. Steps for developing a software project SOP. A( FIN I FILS • The client gives a set of requirements of the product to the organisation • Organisation should discuss these requirements with the client. 1. REQUIREMENTS. • The discussion will focus on removing any ambiguity, conflict, or any other issues related to the product/service in question • The outcome of this discussion will ideally be a "well-defined set of functionalities that the product will achieve". 2. PLANNING (COST AND TIME ESTIMATES). • Organisation should estimate and allocate both human and non-human resources • Various milestones will be defined, to facilitate project monitoring • Plans will also be made to outsource any part of the project, if deemed necessary. 3. ON WITH THE PROJECT. Organisation is ready to start actual work on the project. 4. CONTINUOUS MONITORING. Organisation should continuously monitor the project progress against the plans and milestones made in Step 2. 5. SUSCONTRACTORS CONTINUOUS MONITORING 6. SOFTWARE QUALITY ASSURANCE. 7. CHANGE MANAGEMENT. Sub-contractors (if any) should also be managed and their progress monitored closely in order to ensure that no delays occur due to lapses caused by the sub-contractor Organisation should ensure that no work is done in violation of any standard and any system requirements • Organisation should ensure that all the bits-and-pieces of the project remain well coordinated • Organisation must determine if a change made to one piece of the product also necessitate a change to one or more other pieces, and if it does then those changes must be made accordingly (this is called "Configuration Management"). Organisation must determine if a change made to one piece of the product also necessitate a change to one or more other pieces.. It is obvious that the above mentioned activities are performed by almost all the software projects; then what is it that makes an organisation differs from another one? The answer is simple: Not all the organisations observe the above steps with the same vigour. These steps are all very simple to understand but extremely difficult to execute effectively. The purpose of the above discussion was to appreciate the need for a road map that software organisations can follow to produce quality software, with in budget and with in time. One such roadmap is called Capability Maturity Model for Software (S-CMM). It must be realised that S-CMM is a tricky model to fully understand and is even trickiest to successfully implement.. S-CMM is a tricky model to fully understand and is even trickiest to successfully implement. 29. Curso a Distancia Desarrollo y Gestidn de Proyectos Informaticos.

(28) 2.2.2. S-CMM components. S-CMM is the outcome of decades of research and study of successful and unsuccessful projects. The major philosophy of S-CMM is very similar to life itself. When a child is born it is at a very "initial" level of maturity: The child grows up, learns and attains a higher level of maturity. This keeps on going until he/she becomes a fully mature adult; and even after that, the learning goes on. According to S-CMM, a software organisation also goes (or should go) through similar maturity evolutions. It should be noticed that S-CMM is NOT a software development life cycle model. Instead it is a strategy for improving the software process irrespective of the actual life-cycle model used. Given below is a brief explanation of various components of S-CMM. This explanation has been extracted from SEI's official documents.. Table 9. Some S-CMM components. COIIPONTNT. EXPLANATION. MATURITY LEVEL. It is a well-defined evolutionary plateau toward achieving a mature software process. The five maturity levels provide the top-level structure of the S-CMM. SOFTWARE PROCESS CAPABILITY. It describes the range of expected results that can be achieved by following a software process. It provides one means of predicting the most likely outcomes to be expected from the next software project. KEY PROCESS AREAS (KPAS). Each maturity level is composed of its own KPAs. Each KPA identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for establishing process capability at that maturity level.. For example, one of the KPAs for level 2 is "Software Project Planning". GOALS. The goals summarise the key practices of a KPA and can be used to determine if a project has effectively implemented the KPA. The goals signify the scope, boundaries, and intent of each KPA. An example of a goal from the Software Project Planning KPA is "Software estimates are documented for use in planning and tracking the software project" The key practices are divided among five Common Features sections: • Commitment to perform • Ability to perform • Activities performed. COMMON FEATURES. KEY PRACTICES. • Measurement and analysis • Verifying implementation These are attributes that indicate whether the implementation and institutionalisation of a KPA is effective, repeatable, and lasting. The Activities Performed Common Feature describes implementation activities. The other four ones describe the institutionalisation factors, which make a process part of the organisational culture Each KPA is described in terms of key practices that, when implemented, help to satisfy the goals of that KPA. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalisation of the KPA. 30 Centro Interamericano de Estudios de Seguridad Social.

(29) 2.2.3 S-CMM framework The S-CMM is a framework that characterises an evolutionary process improvement path toward a more mature organisation. An organisation can use the S-CMM to determine their current state of software process maturity and then to establish priorities for improvement. An organisation's current state of maturity can be categorised as Initial, Repeatable, Defined, Managed, or Optimised. Therefore, S-CMM defines five levels of maturity (see next Table and Figure). An organisation's current state of maturity can be categorised as Initial, Repeatable, Defined, Managed, or Optimised.. Table 10. S-CMM levels. DESCRIPTION. LEVEL 1.INITIAL. The software process is characterised as ad hoc and occasionally even chaotic. Few process are defined and success depends on individual effort. 2. REPEATABLE. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier success on projects with similar applications. 3. DEFINED. The software process for both management and engineering activities is documented, standardised, and integrated into a standard software process for the organisations. All projects use an approved, tailored version of the organisation's standard process for developing and maintaining software. 4. MANAGED. Detailed measures of software process and product quality are collected. Both software process and products are quantitatively understood and controlled. S. OPTIMISED. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. Continuously Improving Process Predictable Process Standard, Consistent Process. „--,. 1. Initia. Unpredictable and poorly controlled. improvement. 4. Managed. Process measured and controlled. 3. Defined. Process characterised, fairly well understood. 2. Repeatable Disciplined —• Can repeat previously Processr mastered tasks N. 5.Optimised. Focus on process. Managing Change. Product and Process Quality. Integrated Process. Project Management 4 Figure 7. The five levels of software process maturity.. 31 Curso a Distancia Desarrollo y Gestion de Proyectos Informalicos.

(30) Each maturity level has been decomposed into constituent parts. With the exception of level 1, the decomposition of each maturity level ranges from abstract summaries of each level down to their operational definition in the key practices, as shown in next Figure. Each maturity level is composed of several KPAs. Each KPA is organised into five sections called Common Features. The Common Features specify the Key Practices that, when collectively addressed, accomplish the goals of the KPA.. Indicate Contain. (Goals Address. C. Implementation or institutionalisation. Contain. Describ. Key Practices. Infrastructure or Activities. Figure 8. S-CMM structure. The above discussion may produce some confusion. S-CMM is a vast subject, and a few lines cannot even begin to explain it. However, in order to understand it, the rest of this subsection further breaks the above levels down according the S-CMM structure.. 2.2.4 Key Process Areas (KPAs) Each level has been divided into certain KPAs. For an organisation to achieve a certain maturity level it must fulfil all the corresponding KPAs. Since every organisation is at least at level 1, there are no KPAs for level 1. This means that an organisation does not need to do anything to be at level 1. KPAs may be thought as a task list that must be performed. A KPA contains a group of common activities an organisation must perform to fully address that KPA. Given below is the list of KPAs for each maturity level.. 32 Centro Interamericano de Estudios de Seguridad Social. A KPA contains a group of common activities an organisation must perform to fully address that KPA..

(31) Table 11. S-CMM KPAs LEVEL. KEY PROCESS AREAS. INITIAL. No KPAs. REPEATABLE. Software Requirement Management Software Project Planning Software Project Tracking & Oversight Software Sub-Contract Management Software Quality Assurance Software Configuration Management. DEFINED. Organisational Process Focus Organisational Process Definition Training Program Integrated Software Management Software Product Engineering Inter-Group Co-ordination Peer Review. MANAGED. Quantitative Process Management Software Quality Management. OPTIMISED. Defect Prevention Technology Change Management Process Change Management. Therefore, there are 18 KPAs in S-CMM. What S-CMM tells by virtue of the above KPAs is: For an organisation to level with the best, it MUST address all the 18 KPAs. Failing to address one or more of the above KPAs would result in a relatively immature organisation, hence resulting in a decreased productivity and increased risk.. 2.2.5 Goals Looking at the KPAs, the only way an organisation can be sure that it has successfully addressed a KPA is achieving ALL the goals associated with that KPA. Given below is the complete list of GOALS associated to each of the above 18 KPAs.. 33 Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(32) Table 12. Goals for each KPA LEVEL. GOAL. IMP.-A Software Requirement Management. •. Goal 1: System requirements allocated to software are controlled to establish a baseline for software engineering and management use. • Goal 2: Software plans, products, and activities are kept consistent with the system requirements allocated to software • Goal 1: Software estimates are documented for use in planning and tracking the software project. Software Project Planning. Software Project Tracking & Oversight. •. Goal 2: Software project activities and commitments are planned and documented. •. Goal 3: Affected groups and individuals agree to their commitments related to the software project. •. Goal 1: Actual results and performances are tracked against the software plans. •. Goal 2: Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans. •. Goal 3: Changes to software commitments are agreed to by the affected groups and individuals. • Goal 1: The prime contractor selects qualified software subcontractors REPEATABLE. Software Sub-Contract Management. • Goal 2: The prime contractor and the software subcontractor agree to their commitments to each other • Goal 3: The prime contractor and the software subcontractor maintain ongoing communications • Goal 4: The prime contractor tracks the software subcontractor's actual results and performance against its commitments. Software Quality Assurance. Software Configuratio n Management. DEFINED. Organisation al Process Focus. Organisation al Process Definition. •. Goal 1: Software quality assurance activities are planned. •. Goal 2: Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively. • Goal 3: Affected groups and individuals are informed of software quality assurance activities and results •. Goal 4: Non-compliance issues that cannot be resolved within the software project are addressed by senior management. •. Goal 1: Software configuration management activities are planned. •. Goal 2: Selected software work products are identified, controlled, and available. •. Goal 3: Changes to identified software work products are controlled. •. Goal 4: Affected groups and individuals are informed of the status and content of software baselines. •. Goal 1: Software process development and improvement activities are coordinated across the organisation. •. Goal 2: The strengths and weaknesses of the software processes used are identified relative to a process standard. •. Goal 3: Organisation-level process development and improvement activities are planned. •. Goal 1: A standard software process for the organisation is developed and maintained. • Goal 2: Information related to the use of the organisation's standard software process by the software projects is collected, reviewed, and made available. 34 Centro Interamericano de Estudios de Seguridad Social.

(33) Training Program. • Goal 1: Training activities are planned • Goal 2: Training for developing the skills and knowledge needed to perform software management and technical roles is provided • Goal 3: Individuals in the software engineering group and softwarerelated groups receive the training necessary to perform their roles. Integrated Software Management. • Goal 1: The project's defined software process is a tailored version of the organisation's standard software process • Goal 2: The project is planned and managed according to the project's defined software process. Software Product Engineering. • Goal 1: The software engineering tasks are defined, integrated, and consistently performed to produce the software • Goal 2: Software work products are kept consistent with each other. Inter-Group Coordination. • Goal 1: The customer's requirements are agreed to by all affected groups • Goal 2: The commitments between the engineering group s are agreed to by the affected groups • Goal 3: The engineering groups identify, track, and resolve intergroup issues. Peer Review. • Goal 1: Peer review activities are planned • Goal 2: Defects in the software work products are identified and removed. Quantitative Process Management. • Goal 1: The quantitative process management activities are planned • Goal 2: The process performance of the project's defined software process is controlled quantitatively • Goal 3: The process capability of the organisation's standard software process is known in quantitative terms. Software Quality Management. • Goal 1: The project's software quality management activities are planned • Goal 2: Measurable goals for software product quality and their priorities are defined • Goal 3: Actual progress toward achieving the quality goals for the software products is quantified and managed. Defect Prevention. • Goal 1: Defect prevention activities are planned • Goal 2: Common causes of defects are sought out and identified • Goal 3: Common causes of defects are prioritised and systematically eliminated. Technology Change Management. • Goal 1: Incorporation of technology changes are planned • Goal 2: New technologies are evaluated to determine their effect on quality and productivity • Goal 3: Appropriate new technologies are transferred into normal practice across the organisation. Process Change Management. • Goal 1: Continuous process improvement is planned • Goal 2: Participation in the organisation's software process improvement activities is organisation wide • Goal 3 The organisation's standard software process and the projects' defined software processes are improved continuously. MANAGED. OPTIMISED. 35 Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(34) 2.2.6 Common Features KPAs are organised by Common Features. These are attributes that indicate whether the implementation and institutionalisation of a KPA is effective, repeatable, and lasting. The five common features are listed below.. Table 13. Common features description. DESCRIPTION. COMMON FEATURES COMMITMENTTO PERFORM. It describes the actions the organisation must take to ensure that the process is established and will endure. It typically involves establishing organisational policies and senior management sponsorship. ABILITY TO PERFORM. It describes the preconditions that must exist in the project or organisation to implement the software process competently. It typically involves resources, organisational structures, and training. ACTIVITIES PERFORMED. It describes the roles and procedures necessary to implement a KPA. It typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary. MEASUREMENT AND ANALYSIS. It describes the need to measure the process and analyse the measurements. It typically includes examples of the measurements that could be taken to determine the status and effectiveness of the Activities Performed. VERIFYING IMPLEMENTATION. It describes the steps to ensure that the activities are performed in compliance with the process that has been established. It typically encompasses reviews and audits by management and software quality assurance. The practices in the Common Feature Activities Performed describe what must be implemented to establish a process capability. The other practices, taken as a whole, form the basis by which an organisation can institutionalise the practices described in the Activities Performed common feature.. 2.2.7 Key Practices Each KPA is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalisation of the KPA. Each key practice consists of a single sentence, often followed by a more detailed description, which may include examples and elaboration. These key practices, also referred to as the top-level key practices, state the fundamental policies, procedures, and activities for the KPA. The components of the detailed description are frequently referred to as subpractices. Next Figure provides an example of the structure underlying a key practice for the Software Project Planning KPA.. 36 Centro Interamericano de Estudios de Seguridad Social.

(35) Maturity level: 2, Repeatable ains. Indicates. Process capability: Disciplined process. KPA: Software project planning. Achieves. Organised by. Goal 1: Software estimates are Common feature: documented for use in Activities performed planning and tracking the software project Address. Implementation or insfitutionalisation: Implementation. Contains. Key practice: Activity 9. Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure Describes. Infrastructure or activities: Activity. Figure 9. Example of a key practice.. 2.2.8 S-CMM in the organisations Many organisations have successfully implemented S-CMM, and have reported considerable improvement in almost all the aspects of software life cycle. Some of these organisations are: Bull HN, GTE Government Systems, Hewlett Packard, Hughes Aircraft Co., Loral Federal Systems (formerly IBM Federal Systems Company), Lockheed Sanders, Motorola, Northrop, Schlumberger, Siemens Stromberg-Carlson, Texas Instruments, United States Air Force Oklahoma City Air Logistics Centre , United States Navy Fleet Combat Direction Systems Support Activity. Fundamentally speaking S-CMM helps an organisation in two ways: • S-CMM instils definite practices, resulting in an increase in profitability; • It brings and immediate change in an organisation's culture and mentality, thereby helping it to climb up the S-CMM ladder. Among some 900 plus organisations, which contribute their assessment data to the SEI, a majority of them fall within level 1 and level 2, the percentages being 34.9 and 38.2 respectively. 37. Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(36) However, the journey to reach a higher level of process maturity requires a considerable amount of time and effort. The S-CMM-based enhancement effort that organisations initiated in 1992 and later has shown that the time to move from one level to the next averaged as follows: • From level 1 to level 2: 25 months; • From level 2 to level 3: 22 months; • From level 3 to level 4: 36.5 months. The illustration below shows the number of organisations which have qualified for Level 4 and Level 5 as on October 2002.. Table 14. S-CMM level 4 and 5 organisations. COUNTRY. NUMBER OF S-CMM LEVEL 4 ORGANISATIONS. AUSTRALIA. 1 _. NUMBER OF S-CMM LEVEL 5 ORGANISATIONS. CANADA. 1. CHINA. 2 I. FRANCE INDIA. 27. IRELAND. I. ISRAEL. I 1. RUSSIA SINGAPORE. I 39. USA. 50. 20. The advantages of moving up the S-CMM ladder are evident in a large number of organisations. Upgrading to each higher level is accompanied by an improvement in the overall performance level of the organisation. Some of S-CMM's major plus points include: • • • • • • • • •. A shift from re-active to pro-active management; Helps build a skilled and motivated workforce; Cuts cost in development and support system; Shortens delivery schedules and improves delivery of requirements; Results in customer satisfaction; Improves quality of software products; Induces robustness; Improves management decision-making; Introduces newer technology thus creating competitive advantages.. 38. Centro 1nteramericano de Estudios de Seguridad Social.

(37) The S-CMM levels are like a prescription provided by a doctor. Just as standards in life have to be followed to improve the overall quality of life, similarly following the key process criteria of the S-CMM helps an organisation to improve its overall health and prosperity. The scaling up of each level enhances the performance and core competency of the organisation significantly.. The key process criteria of the SCMM helps an organisation to improve its overall health and prosperity.. It helps to improve the growth of software engineering from an ad-hoc level to a disciplined and managed level and is well supported by up to date technology In addition to this it is advantageous for an organisation to achieve the maturity level from a purely business point of view. According to reports, when S-CMM is applied properly, it can (see also next Table): • Improve productivity three-fold; • Improvement in time-to-market by 0-70%; • Decrease in product defects by 90%. Table 15. Percent improvement compared with results at previous levels.. CRITERIA. LEVEL 1 - 2. LEVEL 2. -3. LEVEL 3. REDUCE DEFECTS. 12%. 40%. 85%. REDUCE CYCLE TIME. 10%. 38%. 63%. REDUCE COST. 8%. 35%. 75%. 145%. 24%. 15%. SCHEDULE VARIANCE. -4. S-CMM by itself does not guarantee that the work done will be outstanding and successful. It rather makes sure that the practicing organisations work in an orderly manner thereby implying that results will be predictable. Through practicing the S-CMM process, an organisation can reach new heights and look forward to the sky as its limit.. 2.2.9 Conclusion It can be concluded that S-CMM helps in judging the software processes of an organisation as well as identifying the pre-requisites necessary to enhance the overall maturity level of these processes.. 39. Curso a Distancia Desarrollo y Gesti6n de Proyectos Informaticos.

(38) It furthermore points the way down a well-defined path to improve the management and development of software products in a disciplined and orderly way. Applied in a proper manner, S-CMM is indeed a powerful system, which can help transform an IT organisation and help it to reach its pinnacle.. 2.3 CMM FOR PEOPLE 1.2.1 Background Every employee in an organisation has an impact on the quality of the product/ service. It is imperative that the level of employee development reflects the quality expectations placed on each and every employee. Since well-trained and competent employees are a strategic advantage for an organisation, it is sensible for an organisation to take a strategic approach to their training activities. The People Capability Maturity Model (P-CMM) was also developed by the Software Engineering Institute (SEI) of Carnegie-Mellon University in Pennsylvania. The SEI collaborated with representatives from industry, government, military, and academic organisations to develop an evolutionary model intended to develop and optimise employee training and competence in organisations.. 2.3.2 Themes The P-CMM defines success in terms of an organisation's "maturity". The structure of the P-CMM demonstrates how an organisation can progress sequentially through increasing levels of maturity to a summit of optimal performance. There are five defined maturity levels in the P-CMM:. 40. Centro Interamericano de Estudios de Seguridad Social. The structure of the P-CMM demonstrates how an organisation can progress sequentially through increasing levels of maturity..

(39) Table 16. P-CMM levels LEA EL. DI s( RIP I ION. 1. INITIAL. No processes initiated. 2. REPEATABLE. Processes focus on establishing basic workforce practices and eliminating problems that hinder work performance. The intent is to instil basic discipline into workforce activities. 3. DEFINED. Processes address organisational issues, as the organisation tailors its defined workforce practices to the core competencies required by its business environment. The intent is to identify primary competencies and align workforce activities with these competencies. 4. MANAGED. Processes focus on building competency-based teams and establishing a quantitative understanding of trends in the development of knowledge and skills and in the alignment of performance across different levels of the organisation. The intent is to quantitatively manage organisational growth in workforce capabilities and establish competency-based teams. S. OPTIMISED. Processes cover issues that both the organisation and individuals must address in implementing continuous improvements in their capability. The intent is to continuously improve methods for developing personal and organisational competence. There are relationships which link the maturity levels so that progress can occur on a set path. Through these themes, the implementation of processes at one maturity level can serve as a foundation for practices and capabilities at a higher level. The Themes of the P-CMM are:. Table 17. P-CMM Themes THEMES. DESCRIPTION. DEVELOPING CAPABILITIES. The trend starts with identifying current training needs within a unit, progresses to the identification of core competencies developed by the organisation, and evolves to having individuals being able to establish their own program of professional development. BUILDING TEAMS AND CULTURE. The trend in building teams and culture begins with establishing basic communication skills, grows to developing a participatory culture, and continues on into formal team-building and continuous improvement of team capabilities. MOTIVATING AND MANAGING PERFORMANCE. The trend in motivating and managing performance begins with establishing basic performance management and compensation practices, then improves these practices through adaptation to competency development and team building. From this level, the trend optimises by looking for constant sources of innovation. SHAPING THE WORKFORCE. The trend in shaping the workforce begins with establishing basic staffing practices, grows to developing plans for workforce development, sets and tracks objectives for competencies in the workforce, and then looks for constant sources of innovation. The trend evolves to having individuals being able to establish their own program of professional development.. 41. Curso a Distancia Desarrollo y Gestic% de Proyectos Informaticos.

(40) 2.3.3 Key process areas (KPAs) KPAs refer to the particular tasks and activities which must be completed in order for an organisation to gain maturity and progress towards optimising their training initiatives. The following Table identifies the appropriate KPA necessary to address each of the four Themes of the P-CMM, and allow the organisation to mature. Table 18. KPA necessary to address each of the four Themes of the P-CMM MATURITY LEVELS PROCESS CATEGORIES. MAT( RITY LEVEL 5: OPTIMISED. MATURITY LEVEL 4:. THEME!: DEN ELOPING CAPABILITIES. THEME 2: BUILDING TEAMS AND CULTURE. DEFINED. MATURITY. LEVEL 2: REPEATABLE. THEME 4: SHAPING THE WORKFORCE. Coaching Personal Competency Development. Mentoring. Continuous Workforce Innovation. Team Building. MANAGED. MATURITY LEVEL 3:. MEM E 3: MOTIVATING AND MANAGING PERFORMANCE. Competency Development Knowledge and Skills Analysis. Participatory Culture. Organisational Performance Alignment Team-Based Practices Competency-Based Practices Career Development. Organisational Competency Management. Workforce Planning. Compensation Training Communication. MATURITY LEVEL 1:. Communication. Performance Management Work Environment. Staffing. No process categories. INITIAL. 2.3.4 Implementation The implementation of the P-CMM requires support and approval from the different areas of an organisation. This model will not be effective if it is imposed or forced on department. Since the model is generic in nature, it has to be interpreted and customised in order to make it appropriate to the nature of the organisation. This model was designed to impart benefits at every maturity level. It does not benefit an organisation to skip a level, or to disregard the processes characteristic 42 Centro Interamericano de Estudios de Seguridad Social.

(41) of an early maturity level. The outputs of each level serve as the foundation for the practices of subsequent maturity levels. This is best described through the four Themes of the model.. "-■. To aid with the interpretation and the implementation of this model in an organisation, the P-CMM has identified the following acceptance criteria for each KPA: • • • • • •. The outputs of each level serve as the foundation for the practices of subsequent maturity levels.. Goals; Commitments to perform; Abilities to perform; Activities performed; Measurement and analysis; Verification of implementation.. As an example, this is the breakdown for KPA: Training.. In order to aid in the interpretation and implementation, the P-CMM provides similar descriptions for each KPA in a thorough and detailed manner. The application of this system is intended as a guideline for organisations. The development of employees into productive and strategic assets is a worthwhile initiative that can bestow great rewards for an organisation. To achieve these rewards, an organisation should examine the various processes and activities outlined in the P-CMM, and determine an applicable and appropriate strategy to optimise employee performance.. 43. Curso a Distancia Desarrollo y Gestidn de Proyectos Informaticos.

(42) Table 19. Example for the Training KPA. GOALS. COMMITMENTS To PERFORM. ABILITIES To PERFORM. ACTIVITIES PERFORMED. MEASUREMENT AND ANALYSIS. VERIFICATIO N OF INIPLEYIENT A TION. Training in the critical skills required in each unit is provided. The organisation follows a documented policy for its training activities. Within each unit, an individual(s) is assigned responsibility for ensuring that training activities are conducted. Individuals receive timely training that is needed to perform their assignments. An organisational role(s) is assigned responsibility for assisting and advising units on training activities. Adequate resources and funding are provided for implementing the planned training activities. Training opportunitie s are made available to all individuals. Training time is made available to each individual according to the organisation's training policy Individuals responsible for identifying training needs are trained in methods relevant to their responsibilities Individuals developing or providing traininghave thenecessary training and/or experience required to perform their responsibilities. Critical skills required for performing critical tasks are identified in each unit. Measurements are made and used to determine the status of training activities within each unit. The training needs for each unit are identified. Unit measures of training status are collected and aggregated at the organisational level. Each unit develops and maintains a plan for . . satisfying its training needs Individuals and/or groups receive the training they need to perform their assigned tasks Relevant training opportunities are identified and made available to support each individual's development Training is tracked against the unit's training plan. 44 Centro Interamericano de Estudios de Seguridad Social. A responsible individual(s) verifies that training activities are conducted according to the unit's plan and the organisation's documented policies Executive management periodically reviews the organisation's training activities to determine if they comply with its documented Rolicies.

(43) Bibliographical references Bardoloi, Sabyasachi. Quality: A Health Capsule to Retain Growth. Pinnacle Systems, Inc. ftp://projectperfect.com.au/CMM.pdf. Visited August 2003, Curtis, Bill. William E. Hefley, and Sally A. Miller. People Capability Maturity Model® (P-CMM®), Version 2.0. CMU/SEI-2001-MM-01. July 2001. www.sei.cmu.edu. Visited August 2003.. ^. Hefley, William E. Where Does Team Building Fit As A Component of Mature Software Development Processes? http://hsb.baylor.edu/ramsower/ais.ac.96/ papers/hefley2.htm. Visited August 2003. Manzoor, Kashif. CMM — an introduction. http: / /homepages.com.pk/kashman/ CMMIntro.htm. Visited August 2003. Paulk, Mark C. Using the Software CMM in small organizations. 1998. www.sei.cmu.edu. Visited August 2003. Paulk, Mark C., Bill Curtis, Mary Beth Chrissis. and Charles V. Weber. Capability Maturity Model for Software, Version 1.1. Technical Report CMU/SEI-93-TR024 ESC-TR-93-177. www.sei.cmu.edu. February 1993.. .......... Paulk, Mark C.. Bill Curtis. Mary Beth Chrissis. and Charles V. Weber. The Capability Maturity Model for Software. www.sei.cmu.edu. February 1993. Zrymiak. Dan. People - Capability Maturity Model. http://wwwmsi.ms/MSJ/ People-Capability_Maturity Model.htm. Visited August 2003.. 45 Curso a Distancia Desarrollo y Gestic% de Proyectos Informaticos.

(44) Topic 3. The communication process within an it project By Alejandro Dominguez Torres. Summary Communication is the cornerstone of how work gets done among different parties within a project. Communication is not an easy task and requires a great effort of the parties to achieve it. In order to get and approach of how communications should be managed in an IT project development, in what follows will be developed two main topics: elements of a communication plan and some communication strategies.. 47 Curso a Distancia Desarrollo y Gestion de Proyectos Informaticos.

(45) i'oyic 3. The communication process within an it project By Alejandro Dominguez Torres. 3.1. ELEMENTS OF A COMMUNICATION PLAN. Successful IT projects are achieved through a combination of effective, timely decisions, actions and strategies. Projects are rarely completed by a single person working alone in a vacuum. Most IT projects are completed by a team of individuals with varied roles and responsibilities. Depending upon the size and nature of the project, these teams can include, among others, any combination of (see Section 1.2.1):. ,■•■■..„. • • • •. The project team; Customers (both internal and external) of the product/service created; Project sponsor; Stakeholders.. Each project team member may bring different levels of technical and project management expertise, and may even have different attitudes and opinions about overall project direction and eventual goals. Keeping this diverse group fully informed and working as a unit is a challenge that can only be met by a carefully crafted set of creative, yet practical, communication strategies. When formed into policy and action, these strategies become a Project Communications Plan. And, to achieve project completion and ultimate success, this plan must be enforced from the first day of a project through to the last. While the details of any project communications plan will vary in accordance with project complexity, size and duration, every plan should address the following three basics elements:. Keeping this diverse group fully informed and working as a unit is a challenge that can 011y be met by a carulbf crafted set of creative, yet practical, communication strategies.. Table 20. Basic elements to be considered for any communication plan BASIC ELEMENT. MEANING. PURPOSE. The goals of formal and informal project communication. METHODS. The mechanisms and formats for project communications. FREQUENCY. The timing and frequency of formal communications activities. 49 Curso a Distancia Desarrollo y Gestic% de Proyectos Informaticos.

Figure

Table 1. Organisation and presentation of project development guidelines

Table 1.

Organisation and presentation of project development guidelines p.10
Table 2. Some IT projects and their description.

Table 2.

Some IT projects and their description. p.11
Table 3. Stakeholders responsibilities

Table 3.

Stakeholders responsibilities p.15
Table 4. Statements about Process

Table 4.

Statements about Process p.16
Table 5. Formal and informal information

Table 5.

Formal and informal information p.18
Figure 1. Formal and informal information

Figure 1.

Formal and informal information p.18
Table 6. Tools for project development  TOOL

Table 6.

Tools for project development TOOL p.18
Table 7. Criteria for the evaluation and selection of project development tools  CRITERIA

Table 7.

Criteria for the evaluation and selection of project development tools CRITERIA p.19
Figure 2. Relationship of the five elements: Equilibrium

Figure 2.

Relationship of the five elements: Equilibrium p.20
Figure 3. Building a more difficult product/service by increasing capability  from people

Figure 3.

Building a more difficult product/service by increasing capability from people p.20
Figure 5. Building a more difficult product/service by increasing capability  from people and process

Figure 5.

Building a more difficult product/service by increasing capability from people and process p.21
Figure 4. Building a more difficult product/service by increasing capability  from process

Figure 4.

Building a more difficult product/service by increasing capability from process p.21
Figure 6. Maturity levels representation

Figure 6.

Maturity levels representation p.26
Table 8. Steps for developing a software project  SOP

Table 8.

Steps for developing a software project SOP p.27
Table 9. Some S-CMM components

Table 9.

Some S-CMM components p.28
Figure 7. The five levels of software process maturity.

Figure 7.

The five levels of software process maturity. p.29
Figure 8. S-CMM structure

Figure 8.

S-CMM structure p.30
Table 11. S-CMM KPAs

Table 11.

S-CMM KPAs p.31
Table 12. Goals for each KPA

Table 12.

Goals for each KPA p.32
Table 13. Common features description.

Table 13.

Common features description. p.34
Figure 9. Example of a key practice.

Figure 9.

Example of a key practice. p.35
Table 14. S-CMM level 4 and 5 organisations

Table 14.

S-CMM level 4 and 5 organisations p.36
Table 15. Percent improvement compared with results at previous levels.

Table 15.

Percent improvement compared with results at previous levels. p.37
Table 17. P-CMM Themes

Table 17.

P-CMM Themes p.39
Table 16. P-CMM levels  LEA EL  1. INITIAL  DI s( RIP I ION No processes initiated  2

Table 16.

P-CMM levels LEA EL 1. INITIAL DI s( RIP I ION No processes initiated 2 p.39
Table 18. KPA necessary to address each of the four Themes of the P-CMM

Table 18.

KPA necessary to address each of the four Themes of the P-CMM p.40
Table 19. Example for the Training KPA  GOALS  Training in  the critical  skills  required in  each unit is  provided  COMMITMENTS To PERFORM The organisation follows a documented policy for its training  activities  ABILITIES  To PERFORM Within each unit,

Table 19.

Example for the Training KPA GOALS Training in the critical skills required in each unit is provided COMMITMENTS To PERFORM The organisation follows a documented policy for its training activities ABILITIES To PERFORM Within each unit, p.42
Table 21. Key factors for every project  KEY FACTOR

Table 21.

Key factors for every project KEY FACTOR p.47
Table 22. Communications requirements analysis: The purpouse  Et 1_, Nit NT OF PROJECT

Table 22.

Communications requirements analysis: The purpouse Et 1_, Nit NT OF PROJECT p.48
Figure 10. Project communication channels

Figure 10.

Project communication channels p.50

Referencias

Actualización...