SI Project Management

Why do SI projects always blow up at the last minute?

Five major risks and realistic response strategies of SI projects experienced by field PMs

SI projects usually start off similarly.

During the proposal stage, the schedule seems right, and the staffing appears sufficient. The architecture looks plausible, and the client says, 'We look forward to working with you.'

However, from the point when development surpasses 50%, the atmosphere changes.

• Requirements keep getting added

• The interface schedule gets delayed

• The client company starts having conflicting opinions among departments

• Key developers experience burnout

• Testing schedules begin to compress.

And one month before the opening, the project essentially becomes a battlefield.

Those who have been a PM on site know. SI projects are more about 'risk management' than technology.

The patterns through which actual projects fail are mostly predetermined. In this article, I will summarize the five most common SI project risks that occur on site and the response strategies that have proven effective from a PM's perspective.

1. Requirements (Scope) Risk

The main cause of project failures

The most dangerous thing in the SI project is not the technology. Most of the time, the requirements collapse the project.

The initial RFP is usually abstract. The problem is that the project starts with each person understanding it differently.

The client thinks, 'Of course, it would work,' while the development team says, 'It wasn't in the specifications.'

This gap explodes in the later stages.

① Scope Creep — gradually adding until the project collapses.

This phrase comes up very often in the field.

'Isn't this just a simple feature? Can't you just include it?'

The problem is that most of the time, it’s not simple.

Added a screen, and:

• permission structures change,

• batch modifications occur,

• API impacts arise,

• statistical logic needs to be adjusted again,

• and often, entire test cases need to be revised.

If the PM starts verbally agreeing to maintain relationships early on, it will become unmanageable later.

On site, this is expressed as 'a snowball rolling down the hill.'

If the specifications are ambiguous, they will ultimately be reversed at the last minute.

Text-centered requirement definition documents are risky.

The customer imagines a completed screen in their mind, while the developer implements only the minimum based on the document.

In the end, there is a phrase that inevitably comes up during the UAT phase.

'This is not the feeling I wanted.'

If the UI/UX direction goes off track at this point, the project will essentially enter a level of redevelopment.

PM response points

In practice, blocking changes in requirements on site is virtually impossible. What is important is to prevent 'uncontrolled changes.'

In practice, the following three must be addressed.

• All change requests must be documented.

• Approval after impact analysis.

• Formalize schedule/cost trade-offs.

What is especially important is this.

'Additional functionality is possible, but adjustments to the schedule or scope are necessary.'

If this statement is not officially recorded, it will all come back as operational responsibility later.

2. Technology and Infrastructure Risks

The screen appears, but the system does not run

The architecture in the proposal stage always looks perfect.

• MSA

• Cloud Native

• Real-time Integration

• Large-scale Processing

• AI Integration

But the actual operating environment is different.

In the later stages of development, technical debt bursts all at once.

If you introduce new technology without technical validation, an accident will definitely occur.

This is a pattern often seen on-site.

• Introducing a framework that no one has ever used

• Applying a structure without references

• Using open source without operational experience

Everything looks good at first.

The problem starts from integration testing.

• Performance is not coming out

• Memory is crashing

• Transactions are getting tangled

• Failures cannot even be reproduced.

When this state is reached, the project turns from 'development' to 'debugging organization'.

② Interface schedules are almost always delayed

SI projects are ultimately linking projects.

It's more common for ERP, groupware, external organizations, PG, legacy systems, etc. to not interoperate.

The problem is that most of the schedules for linked agencies are out of our control.

Real situations that often occur on-site:

• API specifications keep changing

• Test server is not opened

• Person in charge on vacation

• Awaiting security approval

• Firewall not opened

In the end, the development team will only develop with mock data.

And errors will explode during the final actual integration.

PM response points

Current PMs manage the interface as a separate project.

What is actually important:

• Early confirmation of interface definition

• Securing contact network of liaison personnel

• Operating weekly liaison meetings

• Enforcing Sandbox schedule

• Reflecting firewall schedule in advance

It is.

Especially, the later the interface is set, the harder it is to recover.

3. Schedule and Personnel Risks

In the end, projects are carried out by people

SI is ultimately a people-based business.

No matter how good the process is, if key personnel are shaken, the project will also falter.

① Key-Man exits are more critical than you think

It's always present in projects.

• PL who knows the structure well

• Developer who created the deployment alone

• Key person in charge of the interface

The moment this person leaves, the project stops.

The problem is that even if alternative personnel are put in place, recovery does not happen immediately.

Typically:

• Understanding work

• Source analysis

• Domain comprehension

It usually takes at least a few weeks to do this.

This period is referred to as a 'gap period' on site.

② The schedule is mostly unrealistic from the start.

To be honest, many of the SI timelines are sales timelines.

It is calculated in reverse based on the customer opening schedule.

As a result:

• Test compression

• Design omission

• Document lagging

• Regular overtime

is repeated.

And when the schedule slips, there is a common response.

"Let's add more manpower."

However, it actually slows down.

This is because existing personnel are less productive due to training new personnel.

This is why Brooks' Law continues to be repeated in the field.

PM response points

In actual projects, the following must be managed.

• Eliminating dependence on specific personnel

• Enforcing code reviews

• Maintaining minimum documentation standards

• Periodic design sharing

• Ensuring a backup system for tasks

In particular, a state of 'we cannot do without that person' should be seen as a situation where risk has already occurred.

4. Communication risks

The more difficult aspect than technology is coordinating people

Even if a project is technically successful, it fails if it does not achieve customer satisfaction.

Especially in large-scale SI, there are too many stakeholders.

• Field department

• IT department

• Security Team

• Infrastructure Team

• Operations Team

• Management

Everyone has different desires.

① Internal conflicts of customer opinions inevitably occur.

It is common in actual sites.

Sales team requirements differ from management team requirements, and there are differences between the standards of field work and IT, as well as between headquarters and branch requirements.

The issue lies with internal customer problems, but ultimately, the pressure of the schedule is borne by the contractor.

② In a subcontracting structure, the boundary of responsibility becomes blurred.

The larger the project:

• Publishing

• Front

• Backend

• Interface

• Infrastructure

The companies operate separately.

If R&R is unclear in this state, the project will quickly lead to disputes over responsibility.

There is a dangerous phrase at the site.

'That's not our scope?'

When this phrase starts to come out, the schedule slips rapidly.

③ The real scariest thing is CEO risk.

What PMs fear most on-site is not actually technical issues.

It’s executive variables.

A typical example:

After designing and developing for 6 months, suddenly during the executive briefing:

'Isn't it about time we incorporate AI?'

One comment can change the direction.

The staff already knows it’s too late.

However, the project gets shaken again.

There is also the risk of management performance going in the opposite direction.

• Excessive orders

• Unrealistic schedules

• Low-cost contracts

• Promise of free features

The site will start with a deficit structure from the beginning.

PM response points

There is no answer to the management risk except for 'early exposure'.

So what’s important:

• Steering Committee

• Regular executive reports

• Early prototype release

• Mid-term demonstration reviews

It is.

Management almost always makes directional adjustments when they see it for the first time at the end.

5. Testing and Data Migration Risks

The project becomes truly risky just before going live

When the latter screens start to appear, the project looks almost complete.

However, the most dangerous point actually begins from that moment.

① Starting to reduce testing is already a warning sign

If the schedule slips, the first thing that gets reduced is testing.

Common situations that arise on-site:

• Omitting unit tests

• Compressing integration tests

• Verifying only the Happy Path

• Unvalidated failure scenarios

Opening in this state will lead to incidents on the first day of operation.

Especially:

• Concurrent access

• Batch collision

• Data consistency

• Permission error

often occurs for the first time in operations.

② Data migration is almost always more difficult than expected

Legacy data is mostly corrupted.

• NULL data

• Code value mismatch

• Duplicate data

• Date format error

• Integrity collapse

Unexpected errors continue to occur on the actual migration day.

Therefore, field PMs conduct multiple data migration rehearsals.

The actual Cut-Over should be the result of repeated rehearsals, not a 'real operation'.

Conclusion

An SI project is ultimately a risk management project.

PMs who have endured on-site for a long time commonly say.

It's not that projects don't have problems; it's important to prevent the project from collapsing even when issues arise.

What's important in SI projects is not perfection.

• Quickly identifying risks and

• sharing them openly without hiding them,

• making directional adjustments early, and

• drawing out decision-making

this is the survival skill of the project.

In the real world, really dangerous projects aren't those with problems but those where no one is talking about the problems.

And most projects don't suddenly break down when they do break.

There have been continuous signals since the beginning.

Conclusion: 'Three Principles of PM Risk Management' for Winning SI Projects.

It's impossible to completely block the risks in the five areas mentioned above. The essence of risk management is not 'preventing risks from occurring' but 'managing shockwaves so that the system does not collapse when risks do occur.' To achieve this, there are three principles that all project leaders must engrave in their hearts.

[Core Cycle of Risk Management]

정기적인 위험 식별(WBS 기반)

  ▼

  투명한 시각화(Red / Yellow / Green)

  ▼

  신속한 에스컬레이션(공식 채널 활용)

First, visualize and share transparently (the end of superficial Green reporting)

In many projects, risks are hidden until the weekly reporting point, at which point they explode into a 'Red' status when it's too late to manage. If there are signs of risk, they must be reflected immediately in the weekly report and dashboard. Issues need to be shared early so that we can receive technical support from headquarters or have the leverage to negotiate scope adjustments with clients.

Second, change management should be handled as a 'process' rather than emotions.

Good relationships with customers are not maintained by fulfilling all requirements. Rather, they completely break down when opened with poor quality. All requirements changes must be documented, and a culture of obtaining approval through a system (CCB) with clearly calculated additional costs and schedule impacts should be established.

Third, consider 'safe phased rollout' over a perfect launch.

A big bang approach to simultaneous organizational launch carries too much risk. It is wise to first pilot open the system for core modules, specific points, or user groups to verify stability and then establish an architecture and schedule strategy for gradual expansion.

An SI project is like sailing through rough seas. You never know when a storm may hit, but if you have a reliable map (checklist) and solid resilience (risk management process), you can dock any project safely at its destination of timely delivery. Is your ongoing project safe?

Daniel(L)