Microsoft Project and Visio licensing: a role-based plan

Where the problem with Project and Visio starts

The problem almost always begins not with bad intent but with the habit of "fixing it quickly." Someone urgently needs to open an .mpp file or tweak a diagram, and any available installer, old key or a "free" license gets used — often without anyone being sure of its status.

Microsoft Project and Visio are often purchased "as needed": requested by different teams at different times, without a unified view of roles. As a result, a company can have proper subscriptions, outdated boxed versions and "just-in-case" installations at the same time. When it’s time to clean up, no one can clearly say who really needs the product every day.

A separate risk is "floating" installations. Today an app is installed on one PC, tomorrow it’s moved to another because an employee changed, and the day after it remains on both. Even if done with the best intentions, traces remain in asset records, on workstations and in reports. Later this turns into awkward questions: why are there installations without assigned rights, why the number of users doesn’t match licenses, and who is responsible for control.

Usually the business wants three things at once: not to overpay, to have clear rules and to pass audits calmly. So "licensing Microsoft Project and Visio" is not about finding the cheapest option, but about matching rights and features to real tasks.

Typical signals that the system has already failed:

• people ask to install "just in case" but use the app once a quarter
• the product is present on dozens of PCs while active users are few
• licenses were bought by departments but work is organized by roles and projects
• before an audit you must quickly gather data but inventory is incomplete

The logic is simple: define roles, choose license options for each role, then set up installation control without unnecessary bureaucracy. Below is a practical approach for larger organizations with PMOs, IT, procurement and field users.

If you already have a partner or integrator helping with IT infrastructure and support (for example, GSE.kz), it’s convenient to use this approach as a common language between IT and the business: agree on roles and rules first, then purchase and assign access.

Key terms in plain language

The main confusion starts with a basic fact: an application being installed on a computer does not mean the company has the right to use it. Installation is a technical fact. The right to use — a license — must be purchased and properly assigned.

Conversations about licensing usually involve two models: "per user" and "per device." In everyday terms the difference is this: if a license is assigned to a user, they can use the app on their desktop and, for example, on a laptop during a business trip (within terms). If it’s assigned to a device, the right applies to that specific machine, not necessarily to one person.

Assignment of a license: what it means in practice

Assignment is not an informal agreement, but a record: who or what has been granted the right. Here a trap often appears. If you have 20 Visio installations, that doesn’t automatically mean "20 licenses are enough." What matters is whether the licensing model matches how people really work.

A typical scenario: a project manager had Project installed on their PC, then asked for it on a home laptop for the weekend, later changed roles and the access was never removed. This is how floating installations are born — apps move between devices and people without clear accounting.

Why floating installations appear

Usually for practical reasons: a deadline, hardware replacement, an intern for a month, a contractor on a project. Each time someone says "install it, we’ll sort it out later," and that "later" becomes a risk.

An audit (internal or external) usually checks discrepancies across several sources. Most often one of four issues appears:

• purchases exist but assignments are unclear (who exactly was given the right)
• installations are detected on devices not present in the current registry
• a former employee still has access or an installation remains
• actual users don’t match those the licenses are assigned to

If these terms are clear from the start, it’s easier to choose a licensing model by roles and bring order without stopping work.

Group employees by roles, not by departments

Licensing problems often start where rights are granted by department: give Project to everyone in the PMO, Visio to all engineers. Some use the tools monthly, others do critical work in them, and licenses and installations take on a life of their own. It’s safer to start from the person’s tasks, not a line in the org chart.

Even within the same department there are usually several roles. In a construction project there’s the project manager, the scheduler and team members. For diagrams, add those who draw architecture, infrastructure or process flows. If you first describe roles, choosing Project licenses by role and the approach to Visio becomes much clearer.

A useful role map to start from:

• Project managers: build schedules, manage resources, monitor workload, prepare reports.
• Schedulers/PMO: handle many projects, maintain templates, oversee calendars and standards, compile the portfolio view.
• Team members: receive tasks, update statuses, sometimes enter actual work time, without deep planning.
• Visio authors: create diagrams and templates, responsible for design and structure.
• Occasional users or viewers: open files for review and approval without editing.

A simple rule helps: those who change data need a full license; those who only view need viewing access. Mixing editor and viewer roles is what turns infrequent use into a "just-in-case" installation that later lives independently.

Example: PMO maintains the portfolio, project managers update plans weekly, the team marks statuses. If everyone gets the same Project license, overpayment becomes visible. If you assign full licenses to PMO and project managers and give team members only status update access, licenses align with real actions and control becomes simpler.

To keep roles from spreading over time, once a quarter answer two questions: who edited plans and who created or changed diagrams. This reduces compliance risk and makes procurement predictable.

How to choose a license option for each role

The right choice starts not with "who to install Project/Visio for" but with what actions the person performs regularly: editing, reviewing, only viewing or compiling reports. This makes it easier to control installations and compliance and avoid paying for unused features.

Microsoft Project: when the desktop is needed and when the web is enough

The desktop app is generally required by those who maintain complex plans: dependencies, baselines, scenarios, large files and deep customization. Web access is often suitable for those who update task status or collaborate on a plan but do not build it from scratch.

Practical guidance by role:

• Project manager/scheduler: desktop if the plan is large and active; web if plans are simpler and collaboration is more important.
• Program manager/stakeholder: usually viewing and reporting rights are enough without edit permissions.
• Team member: access to update assigned tasks, add comments and statuses without advanced planning features.

Visio: creating diagrams or only viewing

Overpayment for Visio happens most often. If someone only needs to open a diagram, review, print and approve, they usually don’t need a full author license. A full license is justified where people regularly create processes, network diagrams, architecture, floor plans or maintain standardized templates.

Check compatibility with the corporate environment: sign-in via Microsoft 365 work accounts, unified access policies and storing files in corporate storage (for example, SharePoint or OneDrive). If diagrams and plans are kept on the author’s local drive, collaboration breaks down, people start sending files back and forth, and extra installations appear.

To avoid overpaying, answer four questions per role: does the person create content or only view it; is collaborative editing and common storage needed; are there heavy files or complex features; is the minimum-rights approach sufficient for the job?

This breakdown usually leads quickly to a clear scheme where Microsoft Project and Visio licensing matches actual use and extra installations stop being the norm.

Step-by-step plan: from inventory to purchase

To stop living in "someone has it installed and we don’t know why," start with facts, not buying. A working plan can be made in 1–2 weeks — it shows how many licenses are needed and for whom.

Step 1. Collect roles and tasks for the next 30–60 days

You don’t need to describe "all department work." It’s enough to understand what people will actually do in Project and Visio in the coming months: build schedules, manage portfolios, draw process diagrams, edit others’ diagrams or just view them.

Then make a short list of roles (for example: project manager, scheduler, team member, architect, analyst, viewer-only).

Step 2. Check actual usage

Find out who already uses the tools and how often. A few sources usually suffice: a list of installations on PCs, app sign-ins, location of working files in shared folders, quick confirmation from team leads. Focus on "who actually opened and worked," not "who asked."

Step 3. Choose a licensing model and forbid shared access

Adopt one principle: license per user or per device. For office staff it’s usually more logical to choose "per user," so a person can work from a laptop and a desktop. Forbid "lend it to a colleague for an hour" and any floating installations without accounting; otherwise compliance won’t hold.

Immediately separate users by level of work: who needs full functionality and who only needs viewing or occasional edits.

Step 4. Fix rules for issuance and installation

Formulate a few rules that are actually easy to follow:

• where and in which cases installation is allowed
• who confirms the need (role and tasks)
• how quickly rights are issued and through which channel
• what to do on role change or dismissal
• how often installations and users are reconciled

Then collect this into a simple template: role -> license type -> who approves -> duration.

Step 5. Run a pilot then purchase

Take a small group (10–20 people from different roles), configure issuance and check that processes aren’t broken. A pilot quickly reveals nuances: viewers sometimes need a one-off edit in Visio, and schedulers may need reporting access in Project.

After the pilot purchasing is straightforward: you buy for confirmed roles and clear rules, not "just in case."

How to control installations without bureaucracy

Installation control for Project and Visio only works when it’s built into regular processes. If people must collect signatures and wait weeks, they will again install "as it fits." For order you need clear roles and simple records.

Separate duties and responsibilities

A common cause of floating installations is one person approving, installing and somehow distributing licenses. Separate these functions, even if it’s 2–3 people for the whole company:

• the user submits a request (why they need Project or Visio and for how long)
• manager or process owner confirms role and tasks
• IT installs only after confirmation and only on the required device
• the licensing owner records the assignment and tracks counts

About accounts: do not use shared logins for the department. This almost always breaks rules and destroys accountability because you can’t prove who actually used the product.

Inventory without a "thick folder"

Keep one clear registry (a table or service-desk record) instead of many documents. Facts matter: product and edition, device, user and role, installation date, justification (request number), review or return date if access is temporary.

The policy for new PCs and reimages should be equally simple: when replacing or issuing a new device, installation only by request and the old binding is closed. The rule "one action — one entry in the registry" helps.

In organizations with a large fleet, it’s convenient to fix this in a standard in advance. For example, when buying computers, all-in-ones or servers from GSE.kz and building support in parallel, you can define which workstation types are allowed to have Project/Visio installed and which remain with basic office apps. This reduces disputes and eases audits.

Common mistakes and traps that lead to violations

The biggest problems with Microsoft Project and Visio usually come from habits: someone "helped" a colleague by installing, someone bought a license "just in case," and then no one remembers who got what. The result: licenses exist but compliance does not.

A typical mistake is buying licenses "in advance" without a clear owner. A license sits "for the project," the project changes, people leave, and after six months no one can explain who it was assigned to. In an audit this looks like chaos: purchases are separate, usage is separate.

Another risky habit is installing on multiple PCs "because the employee sometimes works from home." Different licensing models have different conditions. When an installation spreads to work, home and a spare laptop, it quickly goes beyond allowed use, especially without a clear binding to user and device.

Passing keys or accounts between people on termination or rotation is also dangerous. It seems logical: someone left, hand the access to the next person. But without formal deprovisioning (revocation, reassignment, recorded owner) you lose history: who used what, when and on what basis. In a dispute it’s nearly impossible to prove correctness.

Mixing license types also leads to violations. In records it often looks the same: "we have Project and Visio." In practice rights, activation methods and how a license must be assigned differ. The error is usually not in choosing, but in failing to verify and describe conditions with simple rules for IT and managers.

The least noticeable problem is lack of regular reconciliation. Procurement is handled by one person, installations by another, HR manages the staff list. If you don’t reconcile "who works," "what was purchased" and "what is actually installed" at least quarterly, floating installations appear by themselves.

A quick compliance checklist in 10 minutes

To quickly assess the risk of violations, check that three things match: people, their tasks and actual installations. This mini-check often tells more than long reports.

10-minute check

Record answers in one place (table or note):

• There is a current list of Project and Visio users by roles, not by departments.
• Each user has a justification: what task requires Project or Visio and for how long.
• No shared accounts are used to run apps or access files.
• The list of installations on PCs matches issued rights: no right — no installed and activated app.
• Dismissals and transfers are handled immediately: revocation of rights, disabling access, verifying the product is no longer used.

Red flags

The risk is high if you regularly see any of these:

• "temporary" use has lasted six months or more without formal justification
• the app is installed "just in case" on laptops that are passed between employees
• access is granted verbally in chat and revoked only "when someone remembers"

A simple technique: pick 10 random users from the installations list and ask managers to confirm why they need Project or Visio and until when. If there’s no confirmation, that user is a candidate for revocation or reassignment to a more appropriate option.

To keep control from becoming bureaucracy, appoint an owner of the list (usually IT or InfoSec) and one short control point: on transfer or dismissal, rights are revoked the same day. The rule stays simple: "task — duration — access — installation."

A practical example: bringing order without stopping work

In a 200-person company, Project was actually needed by 12 people (project managers and schedulers) and Visio by about 35 (analysts, architects, engineers, some IT). But Project was installed on 25 computers.

The reason was simple: Project had been included in the corporate Windows image years ago and migrated to new PCs out of habit. Users opened Project "just in case," some started trial periods and others used old keys. IT could not honestly answer: who really needs a license, how many to buy next quarter and where the compliance risk is.

They began cleanup not by mass uninstallations but by roles and rules so as not to interrupt projects. In two weeks they took three steps:

• agreed the list of roles and process owners (who approves access to Project and who to Visio, including deputies for vacations)
• updated the base image: removed Project from default installs
• introduced a request-based issuance process: Project and Visio installed only by request, and local install rights were revoked for those who do not need them

Extra Project installations were removed selectively: first where the app had not been launched or was used rarely. For remaining users they clarified the required edition and assigned specific licenses.

They also handled temporary roles: contractors, interns and cover staff received time-limited access; review lists were kept and rights revoked automatically without manual reminders.

The usual result: Project installations drop to match real need, each license has an owner, and next year’s budget is easier to defend because numbers are based on roles and actual use.

Next steps: lock in the result and avoid backsliding

Order with Project and Visio doesn’t come from a one-time cleanup but from a process owner and clear rules. You need a responsible person or small group including IT, HR, InfoSec and representatives of key units. Then transfers, dismissals and new projects don’t become manual fires.

Keep a simple cycle: inventory and roles -> plan selection -> issuance rules. If roles are defined, lock them in a matrix: "role — what they do — which plan they need — who approves — when to disable." This is faster and fairer than arguing by departments.

Three regular habits prevent a return to floating installations:

• reconciliation: who is active, who left or changed role
• disabling rule: revoke the license within the agreed time after role change or project end
• installation control: installation only via a standard channel, no "self-admin" privileges

Do the one-time cleanup right after rules are approved: remove duplicates, old versions and trial copies on shared PCs. After that, it’s more important to reconcile facts regularly: installations, sign-ins and assigned licenses.

A good practice is to tie license issuance to an event. For example, when someone is appointed project manager for three months, issue the right Project plan the same day and return the license to the pool or reassign it after the work is complete.

If you lack internal resources to maintain the process, involve a systems integrator: they help prepare for a Microsoft SAM audit, tidy inventories and build rules that don’t interfere with work. When updating the fleet and infrastructure at the same time, many organizations choose locally produced PCs, all-in-ones and servers from GSE.kz with implementation and 24/7 support — this simplifies standardization and ongoing maintenance.

Review role structure briefly every quarter. Teams and projects appear quickly and the matrix should evolve with them.