Промышленный лизинг Промышленный лизинг  Методички 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [ 19 ] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

Identifying Your Project Maturity

Many companies are very aware of the important role project management plays in their companies, but many are somehow unable or unwilling to make a transition to develop their project philosophy to the next level. Companies want to know exactly (1) how well they are currently doing and (2) where they would like to be on a project maturity level. After all, a company is more than just existing processes, policy, and procedures.

To use an analogy, if you had to take a life-saving drug that was developed by a company certified at capability maturity model (CMM) Level 5, compared to a company with only a CMM Level 1 certification, you would go with the company with the Level 5 certification. After all, it gives you the sense of a mature project-based organization, which has its act together. If project management is to take a leading role in a company, it needs to be good in a few areas, which follow:

A project management philosophy is firmly entrenched in the company.

Management has bought into project management as a core competency.

The company is focused on making projects succeed.

The necessary project processes and infrastructure are established.

An effective reporting system is established.

The project methodology and development methodologies are well documented. Project staff is provided continuous training to update their skills. Project information is communicated continuously.

Projects are monitored against performance.



Quality and delivery excellence are built into all projects from day one. Projects are routinely audited for compliance with company standards.

The Capability Maturity Model (CMM)

So what is the buzz all about when it comes to CMM and why should we care? The Software Engineering Institutes (SEI) CMM is not actually a life cycle methodology, but rather sets of strategies for improving the software process on a projects. Therefore, I have not included CMM in Chapter 3. Many companies using CMM are stuck in a default waterfall methodology mentality and have neglected the spiral or iterative development methodologies. This is not CMMs fault at all, but project managers should understand that the waterfall approach is not always the best way to proceed. However, CMM has made advances in covering aspects of iterative methodology projects, although this doesnt always come across as being communicated to the project community. CMM tends to overemphasize inspections, peer reviews, and enforces strict quality assurance (QA) adherence, forcing many projects into paper and meeting overload, which is also not good.

The primary objective for any company is to achieve a Level 3 CMM certification. Many companies are rated on how well their processes and systems meet the best project standards. In other words, if it does the prescribed set of foundation project activities, it is a Level 2. If it then does a prescribed set of project activities as a company, it is Level 3, and so on. Essentially designed by SEI to help organizations overcome their problems, the system provides an effective and proven method for gradually gaining control of and improving product development processes, a yardstick against which companies periodically measure their production process, and data with which to prioritize and manage improvement efforts. I have included CMM in this book because many people are convinced that it is a variant of a project methodology, which is untrue. The areas of CMM are: (1) SW-CMM for software, (2) SE-CMM for systems engineering, (3) IPD-CMM for integrated product development, (4) SA for software acquisition, and (5) P-CMM for human resources.

An instrument for assessing a companys current maturity level and project practices is a software capability evaluation (SCE), which determines whether a company says what it does and does what it says. Therefore, to gauge a companys actual performance, you need to perform an accurate assessment, which is not always done; instead, CMM is applied as both the development and assessment standard. The RUP or ISO 12207 standards are other references.

Together, this set of strategies is being integrated into what is now known as CMM Integration (CMM). The CMMI is a more activity-based approach, which integrates many of industrys modern best practices and discourages an alignment with the waterfall mentality. Hence, CMMI is more iterative in concept versus the traditional CMM waterfall concept.

CMM describes both unique product development practices and the common management practices that any organization must perform. These practices are organized into five levels, each level describing increasing control and management of the production environment, starting with ad-hoc performance and culminating in controlled, structured, continuous improvement. An evaluation of the organizations practices against the model, called an assessment, determines the level, establishing where the organization stands and which management practices the organization should focus on to see the highest return on investment.



SEI Fellow Watts S. Humphrey created CMM in 1987. CMM is more than 10 years old and has greatly influenced the software industry by having us focus on the development and project process. However, technological shifts are taking place that require development to be more proactive. Originally funded by the U.S. Department of Defense, CMM is used by more than 5,000 government and private companies in more than 42 countries. Large portions of the Level 5 assessments that have been made are based in India. One of its primary goals is to identify and reduce errors during the initial coding process and thereby reduce the amount of rework required from finding errors during testing. The CMM is organized into five maturity levels:

Level 1: Initial. This describes a company with an immature or undefined process. The software process is characterized as ad hoc and, occasionally, even chaotic or unpredictable. Few processes are defined, and success depends on individual effort and heroics.

Level2: Repeatable. Project management structures and controls begin here. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The key components of project management at this level are: requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management.

Level 3: Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organizations standard software process for developing and maintaining software. The key process areas at Level 3 address both project and organizational issues. At this level, the company establishes an infrastructure to institutionalize software engineering and management processes across all projects. Compliance with these standards for all projects and by all project managers and development teams is needed.

Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood, controlled, and evaluated by an executive and related staff. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are quantitative process management and software quality management. It is at this level that analysis tools such as function point analysis and other performance metrics are implemented.

Level 5: Optimized. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement defect prevention, technology change management, and process change management.

Getting your company to make an effort to move up the CMM ladder may not be easy. CMM focuses mainly on activities and supporting documents associated with a conventional waterfall process, such as plans, specifications, QA audits, inspections, and formal documented processes and procedures. Its very documentation orientated, and



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [ 19 ] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101