Information technology (IT) project implementations are complex anywhere, but even more so in Japan given its management style and project team structures. Moreover, because of Japan’s spectacular success in the areas of manufacturing and construction, approaches similar to those taken by these industries have been adapted for IT projects. However, software development did not replicate the successes.
Being inherently complex, medium to large technology-implementation projects often fail. Anyone with long experience in IT will have come across a few abandoned development efforts. And those with experience of multinational firms will also have seen projects failing, while efforts were being made to customise, for Japan, systems that have run successfully elsewhere—typically in the US and Europe—so as to reflect the requirements of compliance, audits, calculation methodologies (even a ¥1 mismatch is a no-no) and so forth, which are quite different here. Further, many designers do not realise that Japan-specific requirements are unique.
Quite a few global studies and statistics have consistently shown that software project failures are surprisingly high and are often abandoned or do not achieve their objectives.
Project management and costs conundrum
Many firms in Japan model their project management approach, planning and team structures along the lines of construction industry processes. A large project is typically managed by a systems integrator who manages subordinate implementers (layer one). Layer one firms don’t always do all the engineering and development tasks, but often engage other subordinate firms and vendors (layer two) to complete lower-level jobs and components.
A multi-layered project structure means high communication and management overheads between each layer that, together with other factors, impact costs. More critically, this kind of structure becomes an obstacle when handling requirement and specification changes, and rectifying design errors—all of which are not uncommon.
Add the issue of delayed projects (as in the often-quoted Brooks’s Law in The Mythical Man-month) and it is easy to understand the spiralling of costs—which are pretty high anyway—when trying to complete projects (while sometimes also trying to reduce the scope, as the situation becomes desperate). Again, this wouldn’t be an unfamiliar situation for many in senior positions in IT departments.
Although there aren’t any silver bullets to resolve these issues, it’s always worth carefully considering a few extremely important points before embarking on a new initiative.
Fallacy of man-month-based comparisons
The key factors for successful delivery are solid, flexible design; quality coding; and efficient project management and tracking mechanism. This is possible only when the project team is a well-knit group of skilled and experienced technologists, with an in-depth understanding of the business and relevant domain.
Unfortunately, these are the important points that get drowned in endless man-month-based calculations comparing different vendors and consultants. The relationship between skills and experience of an engineer and his or her monthly charge-out rate is one of the least thought-out fundamental problems of project planning and budgeting.
Unless the correlation between skill, experience and charge-out rates is meaningfully established, calculations and cost projections will be grossly misleading.
There is no substitute for a sound and flexible architecture preceded by a rigorous analysis of the requirements, not just for the present phase, but also for future ones, so that the designers can keep provisions for additional enhancements and future components.
An endless number of iterations go into fine-tuning the specifications, and this might go right up to initial testing phases—a stage at which many offshore firms fail to deliver and quite a few projects fizzle. This is important and, in most cases, inevitable. While perseverance is key, it depends on how well the design can cope with the important last-minute changes.
Big not always better
It is important to realise that size is not necessarily indicative of productivity. Team size should be decided bearing in mind the project stages.
The idea that only a large firm can ensure continuity and support for major projects ignores the fact that people are important, and that very often when key people leave projects this action seriously hampers progress. Software codes are not necessarily easy to hand over and, usually, not enough time is given for the task. It is not uncommon to hear that, even a year after a key person has left a project, they continue to receive calls from a former client about support issues. This indicates that even huge consulting firms have limitations in terms of continuity of maintenance and support.
Conclusion
The best way to ensure success in implementing complicated technology projects in Japan is to invest sufficient time in selecting the implementation team. One must ensure that it has a deep understanding of the market here; technical prowess in the areas of design, coding and project management skills; and that it is sufficiently persevering and meticulous. All these qualities are indispensable if challenging projects are to be successfully completed.
