Your SlideShare is downloading. ×
It project development fundamentals
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

It project development fundamentals

613

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
613
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. August 2004 Page 1 of 39 INFORMATION TECHNOLOGY PROJECT DEVELOPMENT FUNDAMENTALS 1 ALEJANDRO DOMÍNGUEZ-TORRES JADOMING@MAIL.UNITEC.MX SCHOOL OF POSTGRADUATE STUDIES UNIVERSIDAD TECNOLÓGICA DE MÉXICO (UNITEC), WWW.UNITEC.MX CONTENTS 1 INTRODUCTION ....................................................................................................................................... 6 1.1 CONTEXT .............................................................................................................................................. 6 1.2 OBJECTIVES .......................................................................................................................................... 6 1.3 KEY WORDS.......................................................................................................................................... 7 1.4 ASSESSMENT ACTIVITY......................................................................................................................... 7 2 INFORMATION TECHNOLOGY PROJECT DEVELOPMENT BASICS......................................... 9 2.1 SUMMARY ............................................................................................................................................ 9 2.2 IT PROJECT DEVELOPMENT ................................................................................................................... 9 2.3 IT PROJECT DEVELOPMENT ELEMENTS................................................................................................ 11 2.3.1 People............................................................................................................................................ 11 2.3.2 Process.......................................................................................................................................... 13 2.3.3 Product/service ............................................................................................................................. 13 2.3.4 Information.................................................................................................................................... 14 2.3.5 Tools.............................................................................................................................................. 15 2.4 THE RELATIONSHIP AMONG THE FIVE ELEMENTS ................................................................................ 16 2.5 BIBLIOGRAPHICAL REFERENCES ......................................................................................................... 18 3 CAPABILITY MATURITY MODELS................................................................................................... 19 3.1 SUMMARY .......................................................................................................................................... 19 1 Development and administration of information projects. At a distance course. Inter-american Center for Social Security Studies. September 2003.
  • 2. August 2004 Page 2 of 39 3.2 BACKGROUND .................................................................................................................................... 19 3.3 CMM FOR SOFTWARE......................................................................................................................... 20 3.3.1 The software project development process.................................................................................... 20 3.3.2 S-CMM components...................................................................................................................... 21 3.3.3 S-CMM framework........................................................................................................................ 22 3.3.4 Key process areas (KPAs)............................................................................................................. 24 3.3.5 Goals............................................................................................................................................. 25 3.3.6 Common features .......................................................................................................................... 27 3.3.7 Key practices................................................................................................................................. 27 3.3.8 S-CMM in organisations ............................................................................................................... 28 3.3.9 Conclusion .................................................................................................................................... 30 3.4 CMM FOR PEOPLE .............................................................................................................................. 30 3.4.1 Background ................................................................................................................................... 30 3.4.2 Themes .......................................................................................................................................... 30 3.4.3 Key process areas (KPAs)............................................................................................................. 31 3.4.4 Implementation.............................................................................................................................. 32 3.5 BIBLIOGRAPHICAL REFERENCES ......................................................................................................... 34 4 COMMUNICATION PROCESS WITHIN AN IT PROJECT............................................................. 35 4.1 SUMMARY .......................................................................................................................................... 35 4.2 ELEMENTS OF A COMMUNICATION PLAN............................................................................................. 35 4.3 COMMUNICATIONS STRATEGIES.......................................................................................................... 36 4.3.1 Project Characteristics and Requirements.................................................................................... 36 4.3.2 Communications requirements...................................................................................................... 37 4.3.3 Technical capabilities ................................................................................................................... 38 4.3.4 Staff considerations....................................................................................................................... 38 4.4 CONCLUSIONS..................................................................................................................................... 39 4.5 BIBLIOGRAPHICAL REFERENCES ......................................................................................................... 39
  • 3. August 2004 Page 3 of 39
  • 4. August 2004 Page 4 of 39 FIGURES FIGURE 1. FORMAL AND INFORMAL INFORMATION. ............................................................................................... 15 FIGURE 2. RELATIONSHIP OF THE FIVE ELEMENTS: EQUILIBRIUM. ......................................................................... 16 FIGURE 3. BUILDING A MORE DIFFICULT PRODUCT/SERVICE BY INCREASING CAPABILITY FROM PEOPLE............... 17 FIGURE 4. BUILDING A MORE DIFFICULT PRODUCT/SERVICE BY INCREASING CAPABILITY FROM PROCESS............. 17 FIGURE 5. BUILDING A MORE DIFFICULT PRODUCT/SERVICE BY INCREASING CAPABILITY FROM PEOPLE AND PROCESS....................................................................................................................................................... 17 FIGURE 6. MATURITY LEVELS REPRESENTATION. .................................................................................................. 20 FIGURE 7. THE FIVE LEVELS OF SOFTWARE PROCESS MATURITY............................................................................ 23 FIGURE 8. S-CMM STRUCTURE. ............................................................................................................................ 24 FIGURE 9. EXAMPLE OF A KEY PRACTICE............................................................................................................... 28 FIGURE 10. PROJECT COMMUNICATION CHANNELS................................................................................................ 39 TABLES TABLE 1. TOPICS FOR DEVELOPING IT PROJECTS. .................................................................................................... 9 TABLE 2. SOME IT PROJECTS AND THEIR DESCRIPTION. ........................................................................................... 9 TABLE 3. STAKEHOLDERS RESPONSIBILITIES. ........................................................................................................ 12 TABLE 4. STATEMENTS ABOUT PROCESS. .............................................................................................................. 13 TABLE 5. FORMAL AND INFORMAL INFORMATION. ................................................................................................ 14 TABLE 6. TOOLS FOR PROJECT DEVELOPMENT....................................................................................................... 15 TABLE 7. CRITERIA FOR THE EVALUATION AND SELECTION OF PROJECT DEVELOPMENT TOOLS............................. 15 TABLE 8. STEPS FOR DEVELOPING A SOFTWARE PROJECT. ..................................................................................... 21 TABLE 9. SOME S-CMM COMPONENTS. ................................................................................................................ 22 TABLE 10. S-CMM LEVELS. .................................................................................................................................. 23 TABLE 11. S-CMM KPAS. .................................................................................................................................... 24 TABLE 12. GOALS FOR EACH KPA......................................................................................................................... 25 TABLE 13. COMMON FEATURES DESCRIPTION........................................................................................................ 27 TABLE 14. S-CMM LEVEL 4 AND 5 ORGANISATIONS. ............................................................................................ 29
  • 5. August 2004 Page 5 of 39 TABLE 15. PERCENT IMPROVEMENT COMPARED WITH RESULTS AT PREVIOUS LEVELS. ......................................... 30 TABLE 16. P-CMM LEVELS. .................................................................................................................................. 31 TABLE 17. P-CMM THEMES.................................................................................................................................. 31 TABLE 18. KPA NECESSARY TO ADDRESS EACH OF THE FOUR THEMES OF THE P-CMM. ...................................... 32 TABLE 19. EXAMPLE FOR THE TRAINING KPA. ..................................................................................................... 33 TABLE 20. BASIC ELEMENTS TO BE CONSIDERED FOR ANY COMMUNICATION PLAN............................................... 35 TABLE 21. KEY FACTORS FOR EVERY PROJECT. ..................................................................................................... 36 TABLE 22. COMMUNICATIONS REQUIREMENTS ANALYSIS: THE PURPOUSE............................................................ 37
  • 6. August 2004 Page 6 of 39 1 INTRODUCTION 1.1 CONTEXT Information Technology (IT) industry moves rigorously toward new methods for managing the increasing complexity of IT projects. In the past there have been several evolutions, revolutions, and recurring themes of success and failure. At present, success of IT projects depends on having in equilibrium five main components: People, Information, Process, Tools, and Products/Services. All of the five components are important at the moment of developing any IT project. Two of them have been explored in detail in the past. These two components are: People and Process. People and process require having a conducting channel permitting communication among their several composing elements as well as between them. Without communication there is no way of developing any IT project. Study and description of the relation and equilibrium of these five components, paying special attention in People and Process, as well as the communication as “glue” of IT project development, are the purposes of this first module. Chapter 1 discusses IT project development as part of the delivery of IT services and functions, presents the major five elements of IT project development as a foundation for the specification of standard practices and procedures, and shows the relationship among the elements and how changes in one element affect the others. Chapter 2 goes into Process and People components and discusses two models for project development success. These models are the Software Engineering Institute (SEI) “Software Capability Maturity Model (S-CMM)” and “People Capability Maturity Model (P-CMM)”. Finally, Chapter 3 discusses two main topics: elements of a communication plan and some communication strategies. 1.2 OBJECTIVES  Analyse the major five elements of IT project development as a foundation for the specification of standard practices and procedures, as well as the relationship among these elements.  Analyse two international standards for project development associated to People and Process.  Analyse the importance of communication in project development.
  • 7. August 2004 Page 7 of 39 1.3 KEY WORDS Common Features Communication Strategies Communications Plan Goals Information Information Technology Project Development Key Practices Key Process Areas Maturity Level People People Capability Maturity Model Process Product/Service Software Capability Maturity Model Software Process Capability Tools 1.4 ASSESSMENT ACTIVITY Consider the actual situation of an organisation; this one could be either where you work for or one you chose (this organisation must develop software applications). Using the following table, assess that organisation in order to know how far is from S-CMM level 2. Fully Satisfied Not Satisfied Not Applicable Not Rated Fully Satisfied Not Satisfied Not Applicable Not Rated Configuration management Software quality assurance Software subcontract management Invalid grid Project tracking and oversight Invalid grid Project planning Invalid grid Invalid grid Requirements management Goal 4Goal 3Goal 2Goal 1Repeatable KPAs Configuration management Software quality assurance Software subcontract management Invalid grid Project tracking and oversight Invalid grid Project planning Invalid grid Invalid grid Requirements management Goal 4Goal 3Goal 2Goal 1Repeatable KPAs Once you have analysed organisation’s situation, rate each goal and write (in MSWord) a justification for it. Each justification will be clear, concise, and less or equal than a half a page. The document you write must follow next structure:  Front page, give the following data: name, e-mail, city, country, name given to your work, and date  Abstract page (no more than 200 words)
  • 8. August 2004 Page 8 of 39  Organisation background (this is the organisation where assessment is applied). It should contain information to know the type of organisation you are assessing  The assessment and their justification  For each “not satisfied” mark, indicate how to proceed in order to change this mark to a “fully satisfied” mark; that is, say how you solve the problem (again, the solution for each “not satisfied” will be less than a half a page)  Give some conclusions of your own
  • 9. August 2004 Page 9 of 39 2 INFORMATION TECHNOLOGY PROJECT DEVELOPMENT BASICS 2.1 SUMMARY This chapter presents some useful guidelines to develop Information Technology (IT) projects as shown in the following Table. Table 1. Topics for developing IT projects. SECTION SECTION ABSTRACT 1.1 IT PROJECT DEVELOPMENT Discusses IT project development as part of the delivery of IT services and functions 1.2 IT PROJECT DEVELOPMENT ELEMENTS Presents the five major elements of IT project development as a foundation for the specification of standard practices and procedures 1.3 THE RELATIONSHIP OF THE FIVE ELEMENTS Shows the relationship among elements and how changes in one element affect the other ones 2.2 IT PROJECT DEVELOPMENT IT is present in all business matters. However, if business goals are to be met, 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. TYPE OF IT PROJECT DESCRIPTION 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
  • 10. August 2004 Page 10 of 39 Nevertheless, the list given 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. 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 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. 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. 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;
  • 11. August 2004 Page 11 of 39  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. 2.3 IT PROJECT DEVELOPMENT ELEMENTS 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. 2.3.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 project team participates (at some level) in the design process and be responsible for completion of assignments. It is important to have a defined formal organisation for project and for project staff. This provides each individual with a clear understanding of the authority given and responsibility necessary for successful accomplishment of project activities. Project team members need to be accountable for 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;
  • 12. August 2004 Page 12 of 39  On smaller projects, role assignments may be performed part-time, with staff sharing in the execution of multiple functions. 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 project solution (also known as “the project team”): o Requirements development staff; o Business rule specifications staff; o Project management staff; o Subject matter experts; o Documentation (user and technical) staff; o Training staff; o Technical staff; o 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. 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, 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. STAKEHOLDER RESPONSIBILITY 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/service of the project
  • 13. August 2004 Page 13 of 39 2.3.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. STATEMENT DESCRIPTION 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 Chapter 2 for more details) 2.3.3 PRODUCT/SERVICE 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. Product/service pays the bills and ultimately allows people to work together in a process and build IT. Always keep product/service in focus. The current emphasis on process sometimes causes to forget 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 product/service:  Difficulty of building product/service;  External and internal quality. Difficulty of product/service influences the process needed. "Difficult" is subjective and depends on how familiar people are with product/service. For example, for some people a text editor is a very difficult product, while an intelligent image analyser is simple for other ones. Answering the following questions determines the "difficulty" of product/service and the type of process needed:  Is product/service familiar or new to people?  Is it new to everyone in the World?  Is the user interface a major portion of product/service?
  • 14. August 2004 Page 14 of 39 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 product/service. External quality is what the customer sees. The customer is happy if 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 product/service quickly and easily. These quality factors also influence 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. 2.3.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 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. TYPE OF INFORMATION CHARACTERISTICS 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
  • 15. August 2004 Page 15 of 39 Formal information: usually quantitative, produced by known rules, objective Informal information: usually qualitative, no produced by known rules, subjective Formal information: usually quantitative, produced by known rules, objective Informal information: usually qualitative, no produced by known rules, subjective Figure 1. Formal and informal information. 2.3.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 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 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
  • 16. August 2004 Page 16 of 39 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. 2.4 THE RELATIONSHIP AMONG 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. People Information ProcessTools Product/Service Figure 2. Relationship of the five elements: Equilibrium. Figures 3 through 5 show that the added capability needed to build a more difficult product/service 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.
  • 17. August 2004 Page 17 of 39 People Information ProcessTools Product/Service Figure 3. Building a more difficult product/service by increasing capability from people. People Information ProcessTools Product/Service Figure 4. Building a more difficult product/service by increasing capability from process. People Information ProcessTools Product/Service 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 a new thing with the same old people and expect something wonderful to happen. It must be improved people, process, information, tools, or all of them. 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
  • 18. August 2004 Page 18 of 39 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. 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. 2.5 BIBLIOGRAPHICAL REFERENCES Edman, E. G. The project management analysis companion: Creating and implementing standards for IT project management. Right Track Associates, Inc. www.ittoolkit.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.
  • 19. August 2004 Page 19 of 39 3 CAPABILITY MATURITY MODELS 3.1 SUMMARY This chapter presents 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 success since are the result of many years of experience of a number organisations. In order to introduce both models, this chapter is started studying how an organisation should mature each of the five elements. Discussion continues exploring the main features of both aforementioned maturity models. 3.2 BACKGROUND As it was seen in Sections 1.3 and 1.4, the five elements are fundamental for any IT project development. These elements change once 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 an agreement 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 projects are developed a successful process is repeated, then there is a risk reduction in the development and an increasing of success. Due to this, this level of maturity is known as “repeated maturity 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 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
  • 20. August 2004 Page 20 of 39 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, products/services successfully developed could have a higher complexity. People Information ProcessTools Product/Service Initial Maturity Level Repeated Maturity Level Defined Maturity Level Managed Maturity Level Optimized Maturity Level 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 Section 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 Section 2.3. 3.3 CMM FOR SOFTWARE 3.3.1 THE SOFTWARE PROJECT DEVELOPMENT PROCESS Before starting 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 three-step 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”.
  • 21. August 2004 Page 21 of 39 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 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. STEP ACTIVITIES 1.REQUIREMENTS  Client gives a set of product requirements to the organisation  Organisation discusses these requirements with client  Discussion is focused on removing any ambiguity, conflict, or any other issues related to the product/service in question  The outcome of this discussion is ideally 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 are defined to facilitate project monitoring  Plans are also made to outsource any part of the project 3.ON WITH THE PROJECT Organisation is ready to start actual work on the project 4.CONTINUOUS MONITORING Organisation continuously monitors the project progress against plans and milestones made in Step 2 5.SUB-CONTRACTORS CONTINUOUS MONITORING Sub-contractors (if any) are managed and their progress monitored closely in order to ensure that no delays occur due to lapses caused by them 6.SOFTWARE QUALITY ASSURANCE Organisation ensures that no work is done in violation of any standard and any system requirements 7.CHANGE MANAGEMENT  Organisation ensures that all bits-and-pieces of the project remain well coordinated  Organisation determines if a change made to one piece of the product also requires a change to one or more other pieces, and if it does then those changes must be made accordingly (this is called “Configuration Management”) It is obvious that the above mentioned activities are performed by almost all 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 discussion so far 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. 3.3.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,
  • 22. August 2004 Page 22 of 39 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. COMPONENT 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 Goals summarise the key practices of a KPA and can be used to determine if a project has effectively implemented the KPA. 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" COMMON FEATURES The key practices are divided among five Common Features parts:  Commitment to perform  Ability to perform  Activities performed  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. Other four ones describe the institutionalisation factors, which make a process part of the organisational culture KEY PRACTICES Each KPA is described in terms of key practices that, when implemented, help to satisfy the goals of that KPA. Key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalisation of the KPA 3.3.3 S-CMM FRAMEWORK S-CMM is a framework that characterises an evolutionary process improvement path toward a more mature organisation. An organisation can use 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)
  • 23. August 2004 Page 23 of 39 Table 10. S-CMM levels. LEVEL DESCRIPTION 1.INITIAL 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 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 5.OPTIMISED Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies 2. Repeatable 1. Initial 3. Defined 4. Managed Disciplined Process Standard, Consistent Process Predictable Process Continuously Improving Process Unpredictable and poorly controlled Can repeat previously mastered tasks Process characterised, fairly well understood Process measured and controlled Focus on process improvement 5.Optimised Project Management Integrated Engineering Process Product and Process Quality Managing Change 2. Repeatable 1. Initial 3. Defined 4. Managed Disciplined Process Standard, Consistent Process Predictable Process Continuously Improving Process Unpredictable and poorly controlled Can repeat previously mastered tasks Process characterised, fairly well understood Process measured and controlled Focus on process improvement 5.Optimised Project Management Integrated Engineering Process Product and Process Quality Managing Change Figure 7. The five levels of software process maturity. Each maturity level has been decomposed into constituent parts. With the exception of level 1, 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 parts called Common Features. Common features specify the Key Practices that, when collectively addressed, accomplish the goals of the KPA.
  • 24. August 2004 Page 24 of 39 Process capability Goals Implementation or institutionalisation Infrastructure or Activities Maturity Levels Key Process Areas Common Features Key Practices Contain Organised by Contain Indicate Achieve Address Describe Process capability Goals Implementation or institutionalisation Infrastructure or Activities Maturity Levels Key Process Areas Common Features Key Practices Contain Organised by Contain Indicate Achieve Address Describe 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 section further breaks the above levels down according the S-CMM structure. 3.3.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. Table 11. S-CMM KPAs. LEVEL KEY PROCESS AREAS 1. INITIAL No KPAs 2. REPEATABLE a. Software Requirement Management b.Software Project Planning c. Software Project Tracking & Oversight d.Software Sub-Contract Management e. Software Quality Assurance f. Software Configuration Management 3. DEFINED a. Organisational Process Focus b.Organisational Process Definition c. Training Program d.Integrated Software Management e. Software Product Engineering f. Inter-Group Co-ordination g. Peer Review 4. MANAGED a. Quantitative Process Management b.Software Quality Management 5. OPTIMISED a. Defect Prevention b.Technology Change Management c. Process Change Management
  • 25. August 2004 Page 25 of 39 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. 3.3.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. Table 12. Goals for each KPA. KPA GOAL LEVEL 2: REPEATABLE 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 Software Project Planning  Goal 1: Software estimates are documented for use in planning and tracking the software project  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 Software Project Tracking & Oversight  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 Software Sub- Contract Management  Goal 1: The prime contractor selects qualified software subcontractors  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  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 Software Configuration 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
  • 26. August 2004 Page 26 of 39 LEVEL 3: DEFINED Organisational Process Focus  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 Organisational Process Definition  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 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 software-related 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 Co- ordination  Goal 1: The customer's requirements are agreed to by all affected groups  Goal 2: The commitments between the engineering groups 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 LEVEL 4: MANAGED 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 LEVEL 5: OPTIMISED 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
  • 27. August 2004 Page 27 of 39 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 3.3.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. COMMON FEATURES DESCRIPTION COMMITMENT TO PERFORM It describes 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 Activities Performed common feature 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. 3.3.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.
  • 28. August 2004 Page 28 of 39 Maturity level: 2, Repeatable Maturity level: 2, Repeatable KPA: Software project planning KPA: Software project planning Common feature: Activities performed Common feature: Activities performed 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 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 Process capability: Disciplined process Goal 1: Software estimates are documented for use in planning and tracking the software project Implementation or institutionalisation: Implementation Infrastructure or activities: Activity Indicates Contains Achieves Organised by Address Contains Describes Figure 9. Example of a key practice. 3.3.8 S-CMM IN 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. 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.
  • 29. August 2004 Page 29 of 39 Table 14. S-CMM level 4 and 5 organisations. COUNTRY NUMBER OF S-CMM LEVEL 4 ORGANISATIONS NUMBER OF S-CMM LEVEL 5 ORGANISATIONS AUSTRALIA 2 CANADA 1 CHINA 2 FRANCE 1 INDIA 27 50 IRELAND 1 ISRAEL 1 RUSSIA 1 SINGAPORE 1 USA 39 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. 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. 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%.
  • 30. August 2004 Page 30 of 39 Table 15. Percent improvement compared with results at previous levels. CRITERIA LEVEL 1 - 2 LEVEL 2 - 3 LEVEL 3 - 4 REDUCE DEFECTS 12% 40% 85% REDUCE CYCLE TIME 10% 38% 63% REDUCE COST 8% 35% 75% SCHEDULE VARIANCE 145% 24% 15% 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. 3.3.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. 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. 3.4 CMM FOR PEOPLE 3.4.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. 3.4.2 THEMES P-CMM defines success in terms of an organisation’s “maturity”. The structure of P-CMM demonstrates how an organisation can progress sequentially through increasing levels of maturity to a summit of optimal performance.
  • 31. August 2004 Page 31 of 39 There are five defined maturity levels in the P-CMM: Table 16. P-CMM levels. LEVEL DESCRIPTION 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 5.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 3.4.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.
  • 32. August 2004 Page 32 of 39 Table 18. KPA necessary to address each of the four Themes of the P-CMM. MATURITY LEVELS PROCESS CATEGORIES THEME 1: DEVELOPING CAPABILITIES THEME 2: BUILDING TEAMS AND CULTURE THEME 3: MOTIVATING AND MANAGING PERFORMANCE THEME 4: SHAPING THE WORKFORCE LEVEL 5: OPTIMISED Coaching Personal Competency Development Continuous Workforce Innovation LEVEL 4: MANAGED Mentoring Team Building Organisational Performance Alignment Team-Based Practices Organisational Competency Management LEVEL 3: DEFINED Competency Development Knowledge and Skills Analysis Participatory Culture Competency-Based Practices Career Development Workforce Planning LEVEL 2: REPEATABLE Training Communication Communication Compensation Performance Management Work Environment Staffing LEVEL 1: INITIAL No process categories 3.4.4 IMPLEMENTATION 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 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:  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
  • 33. August 2004 Page 33 of 39 Table 19. Example for the Training KPA. GOALS COMMITMENTS TO PERFORM ABILITIES TO PERFORM ACTIVITIES PERFORMED MEASUREMENT AND ANALYSIS VERIFICATION OF IMPLEMENTATION Training in the critical skills required in each unit is provided 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 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 A responsible individual(s) verifies that training activities are conducted according to the unit’s plan and the organisation’s documented policies 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 The training needs for each unit are identified Unit measures of training status are collected and aggregated at the organisational level Executive management periodically reviews the organisation’s training activities to determine if they comply with its documented policies Training opportunities are made available to all individuals Training time is made available to each individual according to the organisation’s training policy Each unit develops and maintains a plan for satisfying its training needs Individuals responsible for identifying training needs are trained in methods relevant to their responsibilities Individuals and/or groups receive the training they need to perform their assigned tasks Individuals developing or providing training have the necessary training and/or experience required to perform their responsibilities Relevant training opportunities are identified and made available to support each individual’s development Training is tracked against the unit’s training plan
  • 34. August 2004 Page 34 of 39 In order to aid in the interpretation and implementation, 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. 3.5 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-TR-024 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://www.msi.ms/MSJ/People- Capability_Maturity_Model.htm. Visited August 2003.
  • 35. August 2004 Page 35 of 39 4 COMMUNICATION PROCESS WITHIN AN IT PROJECT 4.1 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. 4.2 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: 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 With these goals in mind, an effective Project Communications Plan can serve several key purposes:  To ensure that important information gets to the right parties on a timely basis;
  • 36. August 2004 Page 36 of 39  To identify and raise potential problems via scheduled, consistent status reporting;  To generate excitement and enthusiasm for a project;  To facilitate decision making and change control;  To provide a specific process for feedback and conflict resolution;  To ensure appropriate transition upon project closure;  To enhance and facilitate teamwork, cooperation and collaboration. 4.3 COMMUNICATIONS STRATEGIES To begin planning any communications strategy, it must be first considered the specific requirements of the project at hand. The approach to communications planning will vary based upon project needs, complexities and sizing. For example, formal communications activities will take on far more significance in a large, organisation project, than in an internal IT initiative, having a more limited focus and smaller group of players. There are four key planning variables to be considered for developing the appropriate communications strategies:  Project Characteristics and Requirements;  Communications Requirements;  Technical Capabilities;  Staff Considerations. 4.3.1 PROJECT CHARACTERISTICS AND REQUIREMENTS To create a realistic and effective communications plan, it should first be considered the requirements and characteristics of the project at hand. Every project has its own personality, formed by a combination of several key factors. In order to facilitate and plan for effective project communications, it must first be considered the needs presented by each of these factors: Table 21. Key factors for every project. KEY FACTOR DESCRIPTION PROJECT TYPE The specific type of project to be completed (i.e., migration, rollout, application development, relocation, etc.) PROJECT SIZING The number of phases and tasks involved EXPECTED DURATION The length of the project PROJECT RISKS The degree of risk to the business and the sponsoring organisation TECHNICAL COMPLEXITY The extent to which multiple systems are involved and degree of complexity in the technical solution PROJECT ORGANISATION The size and structure of the resource organisation required to complete and support the project COSTS AND BUDGETS The cost of the project in terms of deliverables project execution BUSINESS VALUE The value and significance of the project to the business
  • 37. August 2004 Page 37 of 39 Costly, complex projects, of a substantial duration and notable risk, will require a greater attention to detail, and as such, will likely require more extensive communications programs. On the other hand, smaller, simpler projects will still depend on communication for success, but that communication can be less structured and more informal. 4.3.2 COMMUNICATIONS REQUIREMENTS When analysing project communications requirements, it should be considered two primary issues:  The parties involved in the project. With whom is it needed to communicate?  The purpose of the intended communications. Why is it needed to communicate? When exploring the first of these two questions, it is needed to look beyond name and title, and give full consideration to a broader perspective, considering roles, responsibilities, politics, and communications requirements. The following series of questions can be used as a guideline through this analytical process  Who has a vested interest in the project, either in terms of process or outcome?  Who has information or expertise to contribute?  Who has functional responsibility for the project or its outcome?  Who is needed to make project decisions?  Who has the authority to approve project expenditures and purchases?  Who would benefit from participation or observation (i.e. for staff development)?  Who needs to be involved from an organisational or political perspective? Having considered the players, it is now needed to review the communications purpose: What are the communications goals and how can those goals best be realised? The following chart lists and defines seven elements of project communication, designed to help in the evaluation of communication needs according to “purpose”. Table 22. Communications requirements analysis: The purpouse. ELEMENT OF PROJECT COMMUNICATION PURPOSE GENERAL COMMUNICATIONS Keep all project participants informed of project activities, decisions, and events STATUS REPORTING Keep the project team and stakeholders informed of overall status providing key information for further planning and corrective actions MEETING MANAGEMENT Plan and schedule effective, productive meetings ISSUES MANAGEMENT Organise and track technical and operational issues PROBLEM ESCALATION Track and escalate problems and delays FEEDBACK MANAGEMENT Provide mechanisms for effective feedback CHANGE MANAGEMENT Allow for and facilitate the communication and control of project change requests
  • 38. August 2004 Page 38 of 39 As this list demonstrates, project communication can serve multiple goals, and some may be more important than others depending on the nature of the project at hand, and the parties involved. As project communications strategies are planned, it will be needed to keep a watchful eye on following question: Of the seven basic communications elements, which ones must be addressed by this project communications plan, and to what degree and proportion? The answer will determine the framework of the resulting plan. Depending on the project, it may be needed to address all seven (7) elements, or it may be focused on some more than others. As previously noted, project communication is a complex combination of factors, and as a result, communication plans will vary from project to project. 4.3.3 TECHNICAL CAPABILITIES Effective communication is a key element of project success. To keep all parties informed, and to maintain positive working relationships, every available mechanism for communication must be utilised to the fullest extent possible. Communication systems provide the technical means by which project information is distributed, progress is reported, and feedback is solicited and acquired. To develop effective communications strategies, it must be understood both the availability and capabilities of these various systems. Based on the individual environment, the choice of project communications tools may include any or all of the following:  Project management software;  E-mail;  Discussion databases & GroupWare;  Calendaring and scheduling systems;  Telephone conferencing;  Videoconferencing;  Wireless communications;  Web sites. As it is planning the communications strategies and activities, it will be need to consider the availability of these various communications systems, and how they can be best used to meet project needs in view of project characteristics and communications requirements. 4.3.4 STAFF CONSIDERATIONS While the rewards and results are well worth it, formal project communications activities require a good deal of time and effort, both in terms of planning and execution. Therefore, when planning communications strategies and activities, it is important to consider project schedules, resource constraints, and overall IT workload. It will be needed to balance informational requirements against time spent in actual communication activities, such as status reporting and meeting participation. Status reporting activities should not be allowed to interfere with actual project activities, and it must be kept in mind the time spent in meetings and report preparation.
  • 39. August 2004 Page 39 of 39 4.4 CONCLUSIONS Effective communications plans will be born out of a careful balancing of project needs, communications requirements, technical capabilities, and staff considerations. Each of these four elements will be combined differently as projects and business circumstances change. However, with the use of a structured process for requirements review and communications planning, these elements can be easily identified and analysed as needed, to be utilised as the very foundation upon which the communications plans are built (see next Figure). Project manager Client, sponsor, or project director Provides requirements, guidance and funding Project team members, contractors, and subcontractors Requires leadership, planning, and coordination Line managers of other departments, staff people, and other project managers Requires negotiation and coordination Top management Provides organisational support and encouragement Informal communication Formal communication Direction and clarification Progress reports Project directives Progress reports and forecasts Organisational policies Status reports and forecasts Project direction Status reports Figure 10. Project communication channels. 4.5 BIBLIOGRAPHICAL REFERENCES Edman, E. G. The IT Project Communications Planner: Communications Strategies for Information Technology Projects. Right Track Associates, Inc. www.ittoolkit.com. USA, 2001-2002. Project Management Institute. A guide to the project management body of knowledge: PMBOK Guide. 2000 Edition. www.pmi.org. Visited August 2003. Wideman, Max. Project Info/Coms Links. Issues and Considerations (ISSACONS) http://www.maxwideman.com/issacons4/iac1439/sld003.htm. Visited August 2003.

×