Planning Your Projects¶

Deciding what goes into a Project is the first real decision of a modernization, and it is easier to get right than to change later.

There is no single correct way to organize a modernization into Projects. The right approach depends on your organization’s needs.

Think in themes, not customers¶

A Project groups integrations that belong together.

You may want to group all quote-to-cash integrations in one Project and new-hire onboarding in another, because they are thematically separate.

Alternatively, you may consider all integrations related to a specific source or target system as forming a Project.

What a Project is not is a customer. One customer normally has several Projects, and a Project named after the customer rather than the work tells you nothing about what is in it.

Common Project organization strategies¶

By business unit

Create separate Projects for each department or business unit:

Finance integrations
Supply chain integrations
Customer service integrations

By application or system

Group integrations by the systems they connect:

SAP integrations
Salesforce integrations
Legacy ERP integrations

By export file

One Project per export file from your legacy platform:

Production export
Test environment export
Regional export

By rollout schedule

Organize by when the work is due:

First wave: critical integrations
Second wave: standard integrations
Final wave: legacy cleanup

By complexity

Group by difficulty or risk:

Straightforward work, suited to Automatic
Complex work, where Step-by-Step earns its keep
High-risk integrations needing extra validation

One caution about mixing platforms. If your estate runs on more than one integration technology, prefer to keep each platform in its own Project. SLIM does cope with a mixed export - it identifies the platforms it finds, inventories the integrations under each and flags the added complexity in its analysis - but a Project holding one platform gives you a cleaner Export Analysis document, and the platform badge on the export summary card can only name one platform.

Project scope¶

Several exports can be separate Projects, or combined into a single archive, depending on their size and complexity.

Not too small

Creating too many small Projects adds overhead:

More administrative work
Harder to see the big picture
Duplicate setup effort

Not too large

Projects that are too broad become unwieldy:

Difficult to track progress
Harder to estimate completion
Risk of losing focus

About right

A well-scoped Project usually has:

Related business functionality, so the analysis of one integration informs the next
Clear completion criteria, so you know when it is done
A size you are willing to review, since every integration in it produces documents somebody has to read

That last point is the one that decides it in practice. SLIM will analyze as much as you give it; the limit is how much output your team can genuinely check.

Keep names short but descriptive¶

Project and integration names carry through into the names of the files SLIM generates - a simplified form of both appears in the file name of every analysis document. Long names produce unwieldy file names, and names that are not descriptive produce Projects nobody can tell apart. Short and specific beats either.

Who needs access¶

A Project is visible to the Team it is assigned to, and new Projects default to your own private Team. So the question to settle before you create anything is whether this Project should be private to you or shared.

If it needs to be shared, ask an administrator to create a Team for the people who will collaborate on it, and pick that Team when you create the Project. See How Access Works for what members of a Team can and cannot do.