Example of IT Mieruka target (IT projects)

1 Marginal Capacity of the PMBOK

The PMBOK clarifies PM processes by defining 9 common management knowledge areas. The PMBOK has gained worldwide popularity by evolving PM’s methods towards a more scientific style. However, the PMBOK does not totally cover IT-specific knowledge since it focuses on commonly held knowledge that applies to a broad spectrum of project management.

To be sure, we tried to identify the IT specific management knowledge by analyzing some cases of projects which achieved not only planned QCD but also planned business performances at 2002. As a result, new knowledge including that related to customers, which the PMBOK does not have, has been pointed out to be necessary for IT project management. However, this analysis could not show the total view of IT specific knowledge and systematize it. The reason is that the number of the cases is not enough for the systematization because the cases analyzed is based on the author’s experiences.

However, the author had a chance to analyze more cases (the 193 cases) which had been collected from different companies and summarized by IPA at 2008. It is expected to be able to derive more clear view of IT specific knowledge system.

Actually, when necessary check items (350 items) are extracted not to reproduce the 193 cases of actual IT failure projects, by lessons learned from the actual cases and tried to assign them to the PMBOK knowledge areas, 106 items (30.3%) of all of the 350 items could not be assigned to the 9 knowledge areas.

Furthermore, 6 new knowledge areas were found by classifying the 106 check items. The Figure 1 summarizes what has been mentioned above.

 

2 Marginal Capacity of the CMMI

The CMMIas applied to IT attempts to standardize engineering processes for software development. It also has gained a worldwide popularity by defining 5 levels to decide the maturity of processes executed in IT companies and introducing systems to certificate the level of the maturity. Effects of its introduction can be expected when requirements of buyers have less ambiguity and are decided in the detail of physical specification, and there is less major change or additional scope during the project execution. The CMMI can be expected to be effective lower-context environments. Since it corresponds to the environment of projects that design programs, make code, and test software, the main Japanese application areas of the CMMI are thought to be lower level contractors in Japanese organizational structure of multi-layer subcontractors. However, there are many cases when buyers hardly have any power to decide their order specifications from the beginning even if times go over the dead line. Moreover, even after the specifications have already decided upon, requests for additional scope or change scope may continue.

In projects which accept such requests of buyers, the occurrence of risks of defective quality, delays of launch dates, or cost overruns becomes higher particularly in the lower development phases. When such risks occur and the failed projects are investigated, there often observed problems such as the absence of written master schedules or the lack of system configuration diagrams. In such field projects, the required scope, progress, and quality of products in development are becoming more invisible due to recent changes such as an increased number of stakeholders and shortened development periods. Since buyers with less IT experience and prime vendors with less knowledge of business and culture of new application areas increase due to radical expansion of applying IT as stated in earlier stage, projects with higher context environment also increase. This results in the increase of invisible projects not only in Japan, but also the world.

These problems are not caused by an engineering process, but rather by management, which should be executed in an environment of higher context, where projects are invisible.

Major areas covered by engineering processes as described in the CMMI are shown in the zone A in the Figure 2. On the contrary, methods of the management mentioned above (shown in the zone B in the same figure) have not been proposed. Thus, if such management methods are not developed, future projects will be subject to failures.

 

3 MIERUKA

The amount of development should be increased because of the increasing demand for IT.

When we increase developments only with legacy standards, it is much more probable that many failure projects occur due to the following causes in the future even when we use enough knowledge of PMBOK and CMMI.

-          Fewer PMs with experience in higher context environments.

-          Less IT-specific management knowledge that is extracted from the failure of projects.

Thus we designed the MIERUKA to resolve such problems by resolving the following issue and try to give it shape.

1) Issue of “individual solutions without systematizing the whole knowledge”

It is required for the proposing method to let PMs be able to judge project risks by showing how the individual solutions in the proposed method are related to each other and how to use whole of the solutions.

2) Issue of “unclear way to be used when the PMBOK is already introduced”

It is also required for the method to make it possible to use the method together with the PMBOK, by making it clear what new knowledge is IT specific knowledge and clarifying the relationships between the solutions in the method and the knowledge in the PMBOK.

3) Issue of “difficulty of immediately introduction to field IT projects”

It is also required for the method to provide tools which do not have any restriction of use and applicable phase and can be applicable throughout the life cycle of general IT projects.