The 110th Installment
Adapting Project Management to Handle Changes in System Development Environments

by Kiyoshi Sakamori,
Professor, Master Program of Information Systems Architecture

1. Introduction

Project management has become systematized, and standards and guidelines that can be applied to projects in a wide range of fields, including the PMBOK® Guide and ISO21500, have been expanded on and improved. These project management approaches are the result of project managers coming together and systematizing expertise gained from working on projects for the military, for example, that required building large plants and conducting precision operations. Their basic policy is to first strictly define what must be done, then decide on an action plan and do individual tasks according to the plan. System development has been done in waterfall fashion, where the conventional building process is broken into phases and each phase is then carried out to completion. This approach meshes well with project management standards and has been a recommended means of developing systems in line with the PMBOK® Guide and ISO21500, new project management systems in the system development industry.

However, as information technology rapidly advances and work requiring systems diversifies, people are beginning to rethink the traditional method of carrying out projects based on a plan. For example, it is sometimes not possible to define in advance the steps to be taken or what order to do them, then provide a deliverable by working according to a plan. Moreover, project management systems based on standard plans are no longer always a good fit for system development. In agile development, for instance, project teams build systems by providing a function to the best of their ability through repeated prototyping rather than carrying out an overly elaborate plan, for systems for which it is difficult to clearly define the deliverable upfront. Scrum development, which has become particularly prevalent as a form of agile development, is a methodology whereby one first decides on the number of team members and the project period, and when members finish one task, they move on to the next highest priority task. It is a method for effectively carrying out work that defies easy price quotation and that requires different amounts of time and manpower each time.

Furthermore, increasingly sophisticated network technologies have led to more people using cloud services without having any computer room in the office. Advancements have also been made to such services as IaaS, which migrates information systems previously located in companies' computer rooms to hardware or to cloud services at the OS level. A more recent service, SaaS, provides application systems that support companies' operations. Because of these developments concerning the cloud computing environment, we are heading into an age when companies will no longer need to manage their own computer systems and will instead use established operational support systems rather than performing their own in-house system development. This environment will usher in major changes to project management for information system development at ordinary enterprises. When this happens, we will no longer be able to readily apply the PMBOK® Guide, ISO21500, or other such existing standards that have been systematized primarily for development operations, and will need project management standards centered on system planning and procurement.

Below I will explain three characteristic elements of these kinds of project management changes.

2. A need to provide small functions early on and accept changes with flexibility

There are a broad range of operations that support information systems. Some of these, like corporate accounting systems and HR systems, have established operation systems. The particulars of these systems can be designed, and the complexity of the systems means that it is often necessary to design these particulars before development begins. In contrast, there are some systems that support operations in nascent fields where no established operations yet exist and that must be built little by little. A crucial feature for systems that support these operations is that they provide the necessary functions at an early stage, even if they are small, rather than being designed all at once, as well as that they can be adapted regularly if operations require it.

With the latter type of system development, there will be no concept of the finished system at project launch. These projects require a particular kind of management as project scope is not defined and systems are built to be the best they can be within the given cost and schedule limitations.

3. Defining tasks and assigning personnel to those tasks

In standard project management, the standard approach is to logically define what tasks to perform and when, and assign personnel to each task. This approach prioritizes the schedule, with personnel procured according to it. Schedules have to be adjusted and personnel levels equalized when it is difficult to procure the necessary personnel or when personnel levels are imbalanced at certain times. If there are significant discrepancies between quoted and billed amounts for individual tasks, the project plan often fails.

A contrasting approach involves assuming a set number of team members will be present throughout the project, with each member finishing tasks and then moving onto the next highest priority task at their own discretion. Even with projects with strictly defined schedules, this latter approach is often taken among development teams during individual phases of the project. With this method, tasks get done efficiently without needing to create detailed schedules for individual tasks or be specific about personnel assignment. This also makes it easier to accommodate requests for changes during a project. However, since the system's finished form is not defined in advance, client and contractor have to hash out contract terms and other considerations.

Thus, one approach involves assigning people to predefined work, while the other entails predefined personnel doing whatever work they can. The manufacturing industry has long referred to these approaches as push and pull, and has used these methods to produce things efficiently. However, just as there is an optimal approach in the manufacturing industry depending on what is being produced, project management also requires that one choose the best approach based on the nature of the project.

4. Project management in the age of cloud computing

As cloud adoption grows and companies move from having their own computer rooms in the office, the operation of information systems is becoming more focused on supporting client-side networks and client devices. Likewise, increasing SaaS adoption is expected to drive more corporate usage of existing operation support systems and drive down in-house operation system development. These factors will see information systems change from being things that are built to being things that are contracted and used. Consequently, from the perspective of those using systems, system development projects are likely to become system planning and procurement projects. Rather than how a system should be built, project management will come to focus on what systems to use and how. Project managers will therefore need to have business analyst skills.

5. Summary

Prompted by technological innovation in information systems and by changes in how information systems are used, the traditional system of project management standards is likely headed for dramatic change. At the same time, much about system development using traditional methods will remain, and it will be important to follow current project management standards in such cases. However, given this new information technology environment, for projects that involve developing systems whose final shape is difficult to predict or that require building a system first in order to determine what its final shape will look like, a new paradigm for project management systems will be needed.

1. Setting team goals

First, team members establish what is to be achieved and to what extent (the scope) for their project. This is also the basis of project management. Yet, at the initial stage of teamwork, teams often spend too much time considering goals and never begin taking action. In such cases, rather than continuing to discuss what goal to set, it is useful to take action toward a provisional goal while allowing for possible refinement later. Furthermore, goal setting can become more difficult depending on the freedom one has for setting goal parameters made easier depending on how much freedom you have to set the goal. Building a team from people with an interest in the established theme and deciding on conditions that goal achievement should satisfy are some of the means by which goal setting can be made easier.

2. Having all members participate

For the second condition, participation, the goal is for all members to contribute equally to the deliverable. An important point here is that "equivalent contribution" does not mean "same workload." For example, when inspecting a network service, network engineers can contribute to a deliverable by conducting technical inspections or providing explanations. Back office and marketing personnel can contribute to a deliverable by doing research or providing explanations from the perspective of the market. Responsible roles must therefore be decided for every member based on the assumption that they will contribute to the team's deliverable.

3. Creating systems to ensure smooth communication

There should be two kinds of communication: synchronous communication, carried out by people at the same time and in the same place, and asynchronous communication, conducted by members at different times and in different places. Use tools according to the goal, like conducting meetings for synchronous communication and using online forums for asynchronous communication. Carrying out asynchronous communication smoothly is an acquired skill. This is why team members will need to actively communicate asynchronously from the initial stages of the project, while also identifying issues and refining systems.

In this column, I discussed "goals," "participation," and "communication," the three most fundamental conditions for active design aimed at achieving good teamwork. For those who want to know more specifically how to satisfy these conditions, or who feel they satisfy the conditions but want to build an even better team, I provide a list of reference materials that are at this university's (AIIT) library. Please make use of them if needed.

For the course I run, I design a number of things to be used in practicing Project Based Learning (PBL), which includes these three conditions but also group size, task difficulty, and feedback. If you have a chance to take my course, you may find it interesting to think about how I cover these issues.